Чем мы заменили креатив в UX/UI, чтобы помочь заказчикам достигать их бизнес-целей

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

Всем привет. Меня зовут Влад Кармаков, я основатель и CEO компании мобильной и веб-разработки Siberian.pro. Сегодня я расскажу о том, как устроены процессы разработки UX/UI в нашей компании.

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

Когда я только учился программированию, я считал интерфейс приложения чем-то очень сильно вторичным по отношению к его функциональности. Я писал гениальный, как мне тогда казалось, код, а затем на скорую руку приматывал к нему скотчем интерфейс по принципу «не влезает кнопка — сделай форму пошире».

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

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

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

1. Изучаем вводные данные.

2. Проводим исследования и анализ.

3. Проектируем UX.

4. Защищаем и аргументируем решение для заказчика.

5. Собираем UI.

6. Тестируем.

7. Поддержка.

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

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

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

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

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

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

В практике Siberian.pro был случай, когда клиент пришел к нам, чтобы обновить приложение. Клиенты терялись где-то в процессе покупки и не завершали заказ. Первая мысль — user flow ломается, потому что где-то в интерфейсе приложения есть проблема. Однако анализ показал, что все сложнее.

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

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

Что именно делаем?

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

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

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

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

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

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

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

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

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

- Алгоритм поступления данных в приложение. Что-то видно сразу, что-то подгружается быстро, а что-то — долго.

- Общий объем данных для отображения. Логично, что интерфейс, работающий с десятью элементами данных, отличается от интерфейса, где может одновременно загружаться сто элементов.

- Роли пользователей. Все ли функции доступны всем пользователям сразу? Нужен ли онбординг для новых пользователей?

- Формат приложения — независимое или часть какой-то экосистемы.

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

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

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

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

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

Почему? Во-первых, это красиво…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы в Siberian.pro сделали 220+ мобильных приложений, веб-сервисов и цифровых экосистем для бизнеса. Если вам нужна разработка приложения или интерфейса для него — пишите мне в личные сообщения или на почту sales@siberian.pro, будем рады вам помочь.

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