{"id":14276,"url":"\/distributions\/14276\/click?bit=1&hash=721b78297d313f451e61a17537482715c74771bae8c8ce438ed30c5ac3bb4196","title":"\u0418\u043d\u0432\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0432 \u043b\u044e\u0431\u043e\u0439 \u0442\u043e\u0432\u0430\u0440 \u0438\u043b\u0438 \u0443\u0441\u043b\u0443\u0433\u0443 \u0431\u0435\u0437 \u0431\u0438\u0440\u0436\u0438","buttonText":"","imageUuid":""}

Как создать дизайн-концепты мобильного приложения

Отличить плохой дизайн от хорошего непросто. Под плохим я имею ввиду тот дизайн, который не решает проблемы пользователя. Зачастую компании понимают, что у них плохой дизайн лишь по сообщениям пользователей, когда те в очередной раз не смогли успешно закончить действия и им срочно необходима помощь. Например, не смог оформить заказ на сайте — перезвонил в колл-центр. Но есть и невидимые скрытые проблемы, которые воспринимаются пользователями, как собственные ошибки, о них подробно писал Дон Норман, когда пользователь, что-то делает, а интерфейс программы ведёт себя не так, как ожидал пользователь. Тогда у пользователя складывается впечатление — он что-то сделал неправильно.

Условимся сразу, мы не будем смотреть на картинки, шрифты, кнопки и меню. Забудем дизайн, как то, про что можно сказать красиво или некрасиво, нравится или не нравится. Выкинем это из своей головы на время. Будем понимать дизайн, как задачи и решения, как идеи.

Если в прошлый раз мы говорили о том, как важно собрать группу для создания технического задания и подробно прописать кажущиеся очевидными функции мобильного приложения, то сегодня хочу поговорить о втором шаге по созданию мобильного приложения — о концептах. О том, как мы их создаем и что в концепты закладываем, как о них говорим с клиентом, по каким критериям клиенту их оценивать.

Концепты — это несколько упрощенных экранчиков, которые показывают, как будет работать мобильное приложение. А в действительности, концепты — это стратегический вектор развития всей цифровой инфраструктуры компании. От того, что будет заложено в концептах, а именно какие представлены идеи, будет зависеть дизайн воплощение, как следствие и образ компании для потребителей. Именно то, как потребитель будет думать о компании.

Мы начинаем с того, что уже есть требования к приложению. Есть техническое задание.

Для работы над концептами дизайнеру необходимо быть на фронте индустрии. Он должен быть в курсе современных трендов, что сейчас в топе, какие направления дизайна на подъеме, какие становятся неактуальными. Есть обязательная часть процесса создания концептов design reserch. Когда дизайнер исследует предметную область. К примеру, если мы создаем приложение для заказа воды, то дизайнеру необходимо изучить всех конкурентов, все на тему «заказа воды» и посмотреть главные кейсы с логикой «заказать товар». Таким образом, появится moodbord — визуальные ассоциация для будущего концепта. Далее, дизайнер определится с экранами, которые будут представлены в концептах. Это может быть несколько нагруженных логикой экранов, которые показывают всю стилистику будущего продукта: цвета, шрифты, стили иконок и функциональных элементов.

Иногда это может быть один экран, тогда дизайнер покажет его в разных состояниях. Например, когда пользователь авторизован и не авторизован, или пользователь положил товар в корзину и сбросил приложение, а затем запустил приложение и открыл главный экран.

Начинается самая интересная часть. Дизайнер определяет какую задачу он будет решать. К примеру, необходимо собрать главный экран приложения по заказу воды. Вот она задача. Что тут определять? Поставим кнопку «заказать воду», к ней добавим счётчик с количеством баллонов, поставим бургер в навигации — готово. В действительности, каждый экран, который видит пользователь на своем смартфоне, предлагает ему что-то, решает какую-то задачу пользователя: купить, записаться, вызвать и т.д.

Дизайнер должен найти проблему, которую он будет решать. Виктор Папенек в своей книге «Дизайн для реального мира» писал, что самая важная вещь в дизайне — понять, какую задачу надо решать, а какую не надо. Когда дизайнер поймёт какую проблему пользователя он закрывает с помощью своего дизайна, он сможет перейти к формированию идей для её решения.

Один из инструментов, который использует дизайнер для определения проблемы, которую необходимо решать, для грамотного построения логики переходов внутри приложения, для учета пользовательского опыта — составление маршрутов пользователей Customer Journey Map (CJM). Это может быть от 5 до 10 пользовательских портретов с описанием их чувств, мыслей, страхов, нужд. CJM позволяет определить точки контакта пользователя с продуктом, почему они покупают или не покупают. CJM позволяет, что самое главное, вычислить реальную боль пользователя и попробовать ее закрыть! Для этого потребуется предварительно собрать информацию об аудитории и выделить портрет пользователя. Такую информацию могут дать менеджеры по продажам, сотрудники колл-центра и данные вэб-аналитики. Таким образом, дизайн будет захватывать основные сценарии взаимодействия пользователя с приложением. Это помогает в первую очередь отойти от гипотез и перейти к моделированию поведения аудитории. Чем лучше мы знаем свою аудиторию и понимаем ее опыт, тем выше перспективы бизнеса.

От описания проблем с которыми сталкивается реальный пользователь, дизайнер переходит к формированию идей, которые решают описанные проблемы в рамках требований и ограничений, которые накладывают гайдлайны операционных систем, брендбук клиента и нормативы WCAG.

Один из самых прекрасных моментов в дизайне — формирование идей. Дизайнер должен включить мышление. Выгрузить информацию о предмете на бумагу или макет. Увидеть все простые и сложные объекты, и найти новые связи между ними.

По мере создания концептов дизайнеру и менеджеру необходимо прописать метрики для оценки эффективности будущего дизайна. Метрики необходимы для того, чтобы выработать общие критерии, с помощью которых можно понять слабые места дизайна того или иного экрана. Кроме того, метрики позволяют переместить диалог с клиентом в русло измеримых решений. Сфокусироваться на главном. О метриках поговорим в следующий раз.

Например, для мобильного приложения по заказу воды задача, которую будет решать дизайнер, может звучать так: дать пользователям возможность всегда быстро заказать воду. Что это может значить?

Это значит, что есть новые пользователи и те кто уже заказывал. Для новых нужно предложить выбор количества баллонов и адрес доставки. Для пользователей, которые уже заказывали воду и ничего не меняют в своей логике заказа, должна быть возможность сделать заказ буквально в пару тапов. Поэтому необходимо разместить кнопку «повторить заказ». Она позволит быстро пройти шаги выбора товара и выбора адреса доставки. Фактически, для новых и старых пользователей будет разные UX и логика переходов в приложении.

Чтобы мы и клиент могли измерить готовность концептов, дизайнер и менеджер готовят чеклист с функциями приложения, которые необходимо учесть при создании концептов. Этот список позволяет декомпозировать проблему, он превращает любую сложную задачу в набор маленьких простых подзадач. Также, в обязательном порядке, необходимо пройти этот список перед презентацией.

Когда команда презентует концепты клиенту, то клиенту необходимо узнать, как ставилась задача, какие были идеи для её решения. Команде же не надо спрашивать, нравится клиенту дизайн или нет (привет Майку Монтейро)! Дизайнер не ребёнок, а клиент не родитель. Встреча на которой презентуют концепты — это возможность рассказать клиенту о его продукте, о том почему он будет работать, как этот продукт поможет пользователю решить его проблемы. На встрече важно задать клиенту несколько ключевых вопросов:

  1. Учитывает ли дизайн стратегию компании?
  2. Помогает ли дизайн решать потребности пользователя?
  3. Помогает ли дизайн добиться измеряемых показателей бизнеса?

Дизайн уровня идей, которые решают верно выбранные задачи — такой дизайн необходимо отгружать клиенту.

0
3 комментария
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Арина Герасимова

Спасибо за статью)

Ответить
Развернуть ветку
0 комментариев
Раскрывать всегда