Креатив в разработке UX и UI мобильных приложений не нужен, и вот почему

Считается, что яркие креативы и необычные подходы лежат в основе разработки интерфейсов. Реальность иная: креатив сильно переоценен, а фундаментом действительно качественного пользовательского интерфейса служат совсем другие вещи.

Разработка UX/UI — это все еще разработка

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

Конкретная реализация подобного подхода может выглядеть по-разному. Например, последовательность действий по разработке UX/UI дизайна может быть такая, чего придерживаемся и мы в компании:

1. Изучить вводные данные.
2. Провести исследования и анализ.
3. Спроектировать UX.
4. Защитить и аргументировать решение для заказчика.
5. Собрать UI.
6. Тестирование.
7. Поддержка.

Забегая вперед, успокою — в этой структуре все еще есть место для креатива. Опишу коротко каждый этап.

Изучение вводных данных

На этом этапе нужно собрать информацию о проекте у заказчика — созвоны, интервью, обсуждение. Полученные данные структурировать и задать конкретные вопросы заказчику с учетом ниши его продукта.

Задача этого этапа — собрать максимум достоверной информации, на основе которой будет проводиться аналитика.

Проведение исследований и анализ

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

Какие исследования стоит провести:

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

Что анализировать:

• цели и задачи бизнеса;
• цели и задачи продукта;
• портреты и CJM пользователей;
• особенности взаимодействия пользователей с приложением, например, типичные ошибки.

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

Если дизайнер не понимает сценарий использования продукта и не учитывает его в UX/UI, то путь пользователя (user flow) сломается и продукт окажется бесполезен.

В практике Siberian.pro был случай, когда пользователи нашего клиента терялись где-то в процессе покупки и не завершали заказ. Первая мысль — в интерфейсе приложения есть проблема. Однако анализ показал, что пользователи мало заказывали, потому что ожидали приобрести не только товар, но и сопутствующую услугу, а приложение ее явным образом не выделяло. Т.е. UX/UI приложения был выстроен исходя из неверного понимания целей и задач целевой аудитории.

Проектирование UX

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

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

На начальном этапе мокап обычно черно-белый, чтобы не отвлекаться от сути. Когда основные пути пользователя проработаны, можно начать «играться с цветами». А уже затем создать полноценный интерактивный прототип.

Аргументация UX-решения заказчику

При проектировании интерфейса рекомендую практически с самого начала предоставить заказчику доступ к материалам проекта. Тем самым вы снимаете эффект неожиданности («это не то, что я хотел») и облегчаете себе защиту UX-решения перед заказчиком — он был в курсе всего происходящего и знает не только, почему был выбран тот или иной подход, но и какие были альтернативы.

Сама аргументация — это, как правило, стандартные созвоны с расшаренным экраном. Ничего необычного.

Сборка UI

Это пока был фундамент, пора строить дом.

• Подобрать подходящий визуал. Запросить у клиента референсы, а также корпоративные стили, если они есть.

• Создать дизайн-концепцию. Для заказчика — это возможность быстрее посмотреть на финальный интерфейс в масштабе трех-четырех экранов. Для UX-дизайнера — возможность не делать лишнюю работу.

  

• Собрать UI Kit. Согласованный UI приложения тиражируется на все остальные экраны приложения. Собирается дизайн-система и презентуется заказчику.
• Доработать все элементы интерфейса с учетом особенностей реализации продукта.

Какие именно это особенности? Навскидку:

• Алгоритм поступления данных в приложение. Что-то видно сразу, что-то подгружается быстро, а что-то — долго.
• Общий объем данных для отображения. Логично, что интерфейс, работающий с десятью элементами данных, отличается от интерфейса, где может одновременно загружаться сто тысяч элементов.
• Роли пользователей. Все ли функции доступны всем пользователям сразу? Нужен ли онбординг для новых пользователей?
• Формат приложения — независимое или часть какой-то экосистемы.

Дальше готовятся специальные макеты в Figma. В таких макетах четко прописываются все элементы дизайн-системы, а также отношения между ними, например, отступы.

Тестирование

На этапе тестирования проверяется работа уже реального приложения (или билда). UX-дизайнера здесь интересует, все ли выглядит и работает вживую так, как было задумано.

Описанные выше шаги являются итерационными. Дизайнер остается на связи с разработчиками и оперативно вносит изменения по мере обрастания приложения фичами.

Преимущества структурированного подхода

Для разработчиков такой подход несет сразу несколько плюсов:

• Проще планировать сроки, ведь теперь ждать, пока дизайнера вдохновит, не нужно — его работа формализована по этапам и полностью предсказуема.
• Результат предсказуем. При формализованном подходе вы вправе ожидать определенного качества UX/UI по умолчанию.
• Простая доработка. Откатиться назад, когда в UX/UI уже вложен триста человеко-часов, слишком больно. Формализация существенно облегчает пошаговую доработку.
• Контроль версий. Причем не версий интерфейса, а версий вашего понимания пользовательских нужд.
• Взаимозаменяемость специалистов. Разбивая задачу на мелкие и хорошо документированные этапы, вы оставляете себе возможность безболезненно произвести замену игрока даже в самом разгаре разработки.

Для заказчиков формализованный подход к разработке UX/UI тоже выгоднее креативного:

• Интерфейс продукта сразу бьет в цель. Цель, я напомню, — сделать так, чтобы пользователь решал свои задачи с помощью продукта быстро и легко.
• Быстрый запуск MVP. Структурный подход позволяет проанализировать задачи пользователей и сформулировать список функций для MVP. Следовательно, продукт можно выпустить на рынок быстрее.
• Проще поддерживать и развивать приложение. Итеративный процесс разработки дает больше реперных точек, от которых можно оттолкнуться и оперативно исправить неточности или адаптировать интерфейс приложения по мере получения обратной связи от пользователей.
• Экономия бюджета. При работе в долгосрок, аналитика и формализованный подход к дизайну сокращают расходы на поддержку и дальнейшее развитие приложения.
• Прозрачность крайне важна для тревожных клиентов. Такой подход позволяет держать заказчика в курсе всех важных изменений в реальном времени. Заказчик видит, куда тратятся его деньги, и может сразу оценить результат. Причем не только с позиции «что сделано», но и «почему сделано так».

Заключение

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