Нужен ли креатив в UX/UI?

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

Разработка интерфейсов — это все еще разработка

Когда я только учился программированию, я считал интерфейс приложения чем-то очень вторичным по отношению к его функциональности. Я писал гениальный, как мне тогда казалось, код, а затем на скорую руку приматывал к нему скотчем интерфейс по принципу: не влезает кнопка — сделай форму пошире. Потом я поумнел, набрался опыта и наконец осознал, что пользоваться моим приложением буду не только я, поэтому нужно сделать интерфейс не только функциональным, но и красивым. А еще лучше — креативным. Нет, даже не так, — креативным. Да.

Рандомный интерфейс с Dribbble. Креативно? Весьма. Удобно? Едва ли

Шутки шутками, но представление о UX/UI как о чем-то требующем неординарной креативности бытует до сих пор. В том числе среди заказчиков. И это вредит всем. Дизайнер, очарованный креативностью своих интерфейсных творений, не замечает, что продуктом невозможно пользоваться. Заказчик отклоняет грамотные решения в пользу очевидно неграмотных, потому что первые выглядят «как-то простовато, не чувствуется вложенных в дизайн средств». И теряет на этом деньги. А пользователи выбирают пусть простоватые, но более удобные решения, если у них есть выбор, или ругаются на креативные, если выбора нет.

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

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

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

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

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

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

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

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

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

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

Что анализируем:

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

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

Именно поэтому так важно обозначить портреты потенциальных пользователей продукта и их конкретные цели: чего они на самом деле хотят добиться с помощью приложения? Заказать доставку еды? О'кей, но для чего? Каков конкретный сценарий? Соответствует ли UI нашего приложения этому сценарию? И что нужно сделать, чтобы соответствовал? Вообще — правильно ли мы понимаем своего пользователя и его «боли»?

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

Customer Journey Map позволяет понять, где именно по пути превращения пользователя в клиента может возникнуть запинка

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

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

1. Формируем список важных для продукта функций. Фича-лист обозначает наиболее приоритетные задачи, которые должен решать продукт.

2. Создаем несколько вариантов user flow для важных функций продукта в схематичном формате (wireframe). Такие упрощенные прототипы позволяют быстро оценить, в правильном ли направлении движется разработка UX/UI.

Читайте также

Переходный период. Правда и мифы о российских СУБД

Михаил Рощин, заместитель директора отделения управления проектами и архитектуры в IBS, рассказал IT-World о том, действительно ли российские системы управления базами данных уступают западным в функциональности и производительности и могут негативно сказаться на эффективности бизнеса.

Вот так выглядит wireframe-прототип интерфейса условного онлайн-магазина

А здесь — фрагмент wireframe-прототипа одного из приложений, разработанных нами

3. Визуализация прототипа (мокап). Визуализация на этом и предыдущем этапах выполняется в черно-белом виде, чтобы не отвлекать заказчика от важного. Цветовую гамму подберем позднее, когда прототип будет утвержден.

Пример Ч/Б мокапа интерфейса одного платежного сервиса

После согласования мокапов начинаем «играть» с цветами. Здесь показано три итерации, но их может быть и больше. Всё зависит от бюджета заказчика

А вот один из финальных концептов

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

В результате UX/UI-проектирования получаем некий первичный прототип еще не полноценного интерфейса приложения, а скорее его идеи или MVP.

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

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

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

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

Сборка UI

Итак, фундамент заложен, пора строить дом.

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

Пример UX/UI-концепции, иллюстрирующей один из пользовательских сценариев

• Собираем UI Kit. Согласованный UI приложения тиражируем на все остальные экраны приложения. Собираем дизайн-систему и презентуем ее заказчику.
  
• Дорабатываем все элементы интерфейса. Здесь речь о том, что UI — это не только экраны, но и, к примеру, анимации. Кроме того, интерфейс приложения плотно завязан на особенности реализации продукта (вот почему мы начали с аналитики) и их нужно учесть при реализации выбранной схемы UX/UI.

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

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

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

Цветовая схема

В UI Kit приводятся правила отрисовки всех типов элементов и их визуальный стиль. Здесь — свитч

Архитектура мобильного UX/UI. Для всех типов элементов расписываются параметры и правила использования

Готовая дизайн-система — это визуализация всех компонентов и полностью прописанное их взаимодействие. Можно отправлять разработчикам

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

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

Всё готово? Не совсем. Работа UX-дизайнеров в целом уже закончена, но ведь разработка приложения еще продолжается. Поэтому описанные выше шаги являются во многом итерационными. Дизайнер остается на связи с разработчиками и оперативно вносит изменения по мере обрастания приложения фичами. А где-то даже и сдерживает программистское рвение, чтобы могучая функциональность приложения не порвала по швам всё, что с таким трудом отрисовывалось UX-командой.

Ну теперь-то всё? И вновь нет. Готовый дизайн интерфейса нужно поддерживать, актуализировать и, возможно, улучшать дальше. Последний пункт существеено облегчается, когда заказчик готов предоставить объективные метрики взаимодействия пользователей с интерфейсом приложения. К сожалению, это происходит реже, чем хотелось бы. Без обратной связи от заказчика наши UX-дизайнеры грустят.

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

Читайте также

ИИ в деле: как автоматизировать рутинные рабочие задачи?

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

Преимущества для разработчика

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

1. Проще планировать сроки

Каждый этап разработки UX/UI состоит из внятно прописанных действий и получаемых в результате этих действий артефактов. Причем среднее время работы над каждым этапом тоже примерно известно. Как следствие, команда хорошо понимает, сколько дней или недель уйдет на разработку интерфейса продукта в каждом конкретном случае. Более того — этот срок можно аргументированно озвучить заказчику.

2. Предсказуемый результат

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

ИИ в разработке программного обеспечения

Предсказуемость появляется в тот момент, когда разработка интерфейса начинает опираться не на смутные догадки и внезапные озарения, а на статистику, исследования рынка и анализ маршрутов пользователя (user flow) в приложении. Да, это всё еще не стопроцентная гарантия. Однако опыт однозначно показывает: интерфейсы, разработанные системно, «заходят» пользователям лучше и лучше решают задачи наших клиентов.

3. Возможность отката и доработки

Еще одно преимущество структурированного подхода для разработчика — возможность откатиться к любой из предыдущих итераций и оперативно внести изменения, если что-то пошло не по плану. Действительно, прежде чем начинать работу над UI Kit, можно еще на этапе концепта в реальном времени обсудить с заказчиком три-четыре основных экрана, и если окажется, что выстрел ушел в «молоко», то мы просто вернемся на шаг назад и попробуем снова.

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

4. Контроль версий

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

5. Гибкость при разработке

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

6. Взаимозаменяемость специалистов

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

Конечно, о конвейерной сборке интерфейсов речи не идет, но ввести в курс дела нового дизайнера становится намного проще.

Теперь давайте посмотрим, выигрывают ли заказчики от, возможно, менее креативного, но более формализованного подхода к разработке UX/UI-дизайна.

Преимущества для заказчиков

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

1. Интерфейс продукта, сразу достигающий целей

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

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

Фрагмент CJM (Источник: HardClient). Настолько детальная декомпозиция, конечно, нужна не всегда

Читайте также

Устали от найма и решили растить своих. Как маленькая студия учит Junior-дизайнеров для работы на федеральных проектах

Основатель и арт-директор дизайн-команды Charger расскажет, почему компания предпочитает работать с Junior-специалистами. Какие методы использует Charger для обучения и развития сотрудников? Как поддерживается корпоративная культура в команде на удалёнке? С какими трудностями сталкивается Charger при подборе новых сотрудников?

С другой стороны, если UX/UI-дизайнер заранее озаботился составлением CJM и понимает, какие функции продукта будут наиболее востребованы пользователем, то, скорее всего, правильный в этом отношении интерфейс получится с первого раза. О том, как составить CJM и как его применять, я рассказал выше. В результате заказчик экономит на стоимости и времени разработки продукта.

2. Быстрый запуск MVP

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

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

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

3. Приложение легче развивать и поддерживать

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

Особенно актуальным это преимущество становится при работе компании заказчика в парадигме CI/CD, когда регулярные обновления приложения должны бесшовно вливаться в существующую инфраструктуру, а разработка UX/UI подчинена общему графику развертывания (deployment) продукта.

4. Экономия бюджета

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

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

При работе на перспективу «скучная» аналитика и формализованный подход к дизайну сокращают расходы на поддержку и развитие приложения. А еще они исключают ситуацию, когда на аналитике сэкономили, продукт не «выстрелил» и пришлось всё переделывать с нуля, переплачивая в несколько раз. Структурированный подход к разработке UX/UI существенно снижает стоимость ошибки на любом этапе.

А что делать, если интерфейс уже есть? Часть работ по грамотной проектировке UX/UI приложения можно выполнить и постфактум. Называться это будет «аудит», но суть ровно та же: адаптировать интерфейс продукта к реальным потребностям целевой аудитории. И это тоже будет дешевле, чем переделывать заново.

5. Прозрачность

Среди заказчиков есть типаж, который мы в компании между собой называем «тревожный клиент». Такой заказчик очень переживает, что получится не так, как он хотел, – и как ему потом с этим жить? Или что процесс прямо сейчас идет не в ту сторону, а он и не знает об этом. Или что мы не попадем в те референсы, которые он обозначил, и просто проедим зря его деньги (не маленькие, между прочим!). Ну и т. д.

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

А в нашем случае клиент синхронизирован с UX/UI-разработчиками и может снять свое беспокойство практически в реальном времени. Мы просто выдаем ему доступ к проекту в Figma и позволяем своими глазами увидеть, как шаг за шагом формируется внешний вид его приложения. Опять же, и обратную связь в таком формате получать проще и быстрее.

Заказчик может оставить комментарии прямо в рабочем документе в Figma

Так что, креатив в UX/UI не нужен?

Креатив в UX/UI нужен. Но не во главе угла. Креативность UX/UI-дизайнера просто нужно направить в определенное русло.

• Эстетика UI. Красивым и стильным интерфейсом пользоваться приятней. Хороший UX при плохом UI — это нонсенс. Нужны интересные эстетические решения, отвечающие ожиданиям пользователя и попадающие в корпоративный tone of voice.
  
• Размещение элементов UI. В индустрии уже успел сложиться определенный стандарт размещения типовых элементов интерфейса. Но когда речь идет о чем-то менее шаблонном, нужны свежие мысли.
  
• Креатив в UX-процессах. Иногда привычные паттерны взаимодействия с приложением нужно сломать ради достижения какой-то бизнес-цели. Хороший пример — геймификация. По всем канонам, игра внутри приложения — это лишняя трата ресурсов. А если внедрение геймификации приведет к двукратному росту retention rate пользователей? Это другое дело! Придумать и органично вписать в UX/UI мобильного приложения такую игру — задача весьма креативная.
  
• Новые интерфейсные решения. Творческий подход необходим в сферах, где пока нет четких стандартов по UX/UI или сама задача новая. Например, интерфейсные решения в приложениях для людей с ограниченными возможностями требуют нестандартных подходов. А иногда — принципиально других.
  
• Понять пользователя. Умение влезть в шкуру потенциального пользователя — это даже не навык, а образ мышления, чем-то схожий с талантом писателя или актера. Лучшие UX-дизайнеры — мастера перевоплощения.

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

Читайте также

Техподдержка в эпоху ИИ. Как искусственный интеллект меняет ландшафт ИТ-услуг

Как ИИ помогает в работе службы технической поддержки? Почему ИИ может не справиться с некоторыми запросами клиентов? Какие навыки нужны специалистам, чтобы помогать ИИ в нестандартных ситуациях? Как можно организовать работу первой линии службы технической поддержки с использованием ИИ?