Нужен ли креатив в UX/UI?
А устроены они так, что креативу в них отведено далеко не центральное место. Вместо него применяется систематизированный формальный подход, и сейчас я попробую обосновать, что для заказчиков такой подход к разработке интерфейса продукта — это не минус, а, напротив, один жирный плюс.
Разработка интерфейсов — это все еще разработка
Когда я только учился программированию, я считал интерфейс приложения чем-то очень вторичным по отношению к его функциональности. Я писал гениальный, как мне тогда казалось, код, а затем на скорую руку приматывал к нему скотчем интерфейс по принципу: не влезает кнопка — сделай форму пошире. Потом я поумнел, набрался опыта и наконец осознал, что пользоваться моим приложением буду не только я, поэтому нужно сделать интерфейс не только функциональным, но и красивым. А еще лучше — креативным. Нет, даже не так, — креативным. Да.
Рандомный интерфейс с Dribbble. Креативно? Весьма. Удобно? Едва ли
Шутки шутками, но представление о UX/UI как о чем-то требующем неординарной креативности бытует до сих пор. В том числе среди заказчиков. И это вредит всем. Дизайнер, очарованный креативностью своих интерфейсных творений, не замечает, что продуктом невозможно пользоваться. Заказчик отклоняет грамотные решения в пользу очевидно неграмотных, потому что первые выглядят «как-то простовато, не чувствуется вложенных в дизайн средств». И теряет на этом деньги. А пользователи выбирают пусть простоватые, но более удобные решения, если у них есть выбор, или ругаются на креативные, если выбора нет.
Между тем относиться к разработке UX/UI продукта следует точно так же, как к разработке чего угодно еще. То есть провести аналитику, максимально формализовать требования к продукту, выполнить поэтапное проектирование, сформировать UI Kit и в итоге — показать окончательный результат. Именно такой структурированный подход позволяет достичь бизнес-целей, а не просто удивить аудиторию необычным UI.
Конкретная реализация подобного подхода может выглядеть по-разному. У нас в Siberian.pro последовательность действий по разработке UX/UI-дизайна примерно такая:
Изучаем вводные данные. Проводим исследования и анализ. Проектируем UX. Защищаем и аргументируем решение для заказчика. Собираем UI. Тестируем. Поддержка.
И, забегая вперед, успокою — в этой структуре все еще есть место для креатива. Но об этом позже, а сейчас коротко опишу каждый этап.
Изучение вводных данных
На этом этапе собираем информацию о проекте у заказчика. Проводим созвоны с клиентом, интервью, коллективное обсуждение. Полученные данные структурируем и задаем конкретные вопросы заказчику уже с учетом ниши его продукта. Задача этого этапа — собрать максимум достоверной информации, подготовить информационную инфраструктуру. Ну и предварительно оценить стоимость проекта, конечно.
Первый этап важен, потому что именно здесь команда дизайнеров получает первое представление о продукте. Это пока не фундамент для разработки, а скорее фундамент для последующей аналитики и более глубокого погружения в особенности продукта и его целевой аудитории.
Проведение исследований и анализ
Какие исследования проводим:
изучаем конкурентов; изучаем отзывы пользователей; формулируем проблемы и «боли» пользователей; изучаем спектр доступных решений проблемы; если получится, берем интервью у реальных пользователей.
Что бизнес увидит в облаках: основные тенденции и перспективы рынка облачных решений О том, почему спрос на облачные ИТ-решения для бизнеса в прошлом году вырос на треть, какие сервисы сегодня наиболее востребованы и как искусственный интеллект изменит облачные вычисления, рассказал директор K2 Cloud Сергей Зинкевич.
Что анализируем:
цели и задачи бизнеса; цели и задачи продукта; портреты и CJM пользователей; особенности взаимодействия пользователей с приложением, например типичные ошибки.
Задача здесь — сформулировать реальные проблемы пользователей и возможные подходы к их решению с помощью продукта. Потому что даже идеальный интерфейс окажется бесполезен, если он не помогает пользователю.
Именно поэтому так важно обозначить портреты потенциальных пользователей продукта и их конкретные цели: чего они на самом деле хотят добиться с помощью приложения? Заказать доставку еды? О'кей, но для чего? Каков конкретный сценарий? Соответствует ли UI нашего приложения этому сценарию? И что нужно сделать, чтобы соответствовал? Вообще — правильно ли мы понимаем своего пользователя и его «боли»?
В нашей практике был случай, когда заказчик пришел, чтобы обновить приложение. Клиенты терялись где-то в процессе покупки и не завершали заказ. Первая мысль — user flow ломается, потому что в интерфейсе приложения есть проблема. Однако анализ показал, что всё сложнее. Пользователи мало заказывали, потому что ожидали приобрести не только товар, но и сопутствующую услугу, а приложение ее явным образом не выделяло. То есть UX/UI и интерфейс приложения были выстроены исходя из неверного понимания желаний и задач целевой аудитории. Стоило это пофиксить — продажи выросли.
Customer Journey Map позволяет понять, где именно по пути превращения пользователя в клиента может возникнуть запинка
Проектирование UX
Прежде чем создавать реальный прототип пользовательского интерфейса, мы проектируем UX — то есть формируем своего рода общий маршрут движения пользователя по функциям приложения и закладываем основы будущего UX/UI. В основе такого прототипирования лежит аналитика, выполненная шагом ранее. Что именно делаем?
1. Формируем список важных для продукта функций. Фича-лист обозначает наиболее приоритетные задачи, которые должен решать продукт.
2. Создаем несколько вариантов user flow для важных функций продукта в схематичном формате (wireframe). Такие упрощенные прототипы позволяют быстро оценить, в правильном ли направлении движется разработка UX/UI.
Вот так выглядит 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). Настолько детальная декомпозиция, конечно, нужна не всегда
С другой стороны, если 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.