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

Обучение в онлайн-университете: курс «UI-дизайнер»

Что мы вынесли из этой беседы:

главное — это продукт, а не оформление;
общение с пользователями и пользовательская аналитика позволяют сделать максимально удобный в использовании интерфейс (но это не точно);
один из самых эффективных методов оценки пользовательских действий — тестовое задание;
не стоит рассматривать UI в отрыве от UX — первое всегда стоит на страже второго;
субъективный вкус в интерфейсах — это хорошо, но data-driven подход всё же лучше;
самый простой и дешевый способ проверить продукт — «коридорное тестирование», которое в любом случае намного лучше, чем отсутствие какого-либо пользовательского тестирования вообще;
чаще всего новые итерации какой-либо готовой функциональности направлены на её упрощение, а не на увеличение возможностей: а всё потому, что конечный пользователь не очень хочет вникать в интерфейс;
даже если показать результаты А/B-теста заказчику, у него всё равно могут возникнуть неконструктивные замечания — тут помогает спокойная планомерная работа и постоянный диалог по важным вопросам;
UI должен помогать пользователю решать свои задачи в интерфейсе, и рассматривая его вне этого контекста, есть риск сместить смысл с пользы на украшательство;
всегда спрашивайте себя: зачем мы это делаем? решает ли это нашу задачу? какую пользу это принесет?

Александр Петерман, основатель Notify.Network:

«чтобы UI был максимально удобным, мы используем собственную аналитику и прямое общение с пользователями»

У нас объединенная команда разработчиков-дизайнеров для всех проектов, которыми мы занимаемся: от головной компании инвестиционного фонда до ключевых проектов, генерирующих денежный поток. Это позволяет эффективно использовать ресурсы, всегда предоставлять разработчикам интересные и новые задачи, а дизайнерам повышать квалификацию за счет применения подходов из разных отраслей. Самое главное, что наш подход позволяет привлекать самых талантливых людей из отрасли, которые одновременно обладают опытом и не скованы в своей творческой реализации. У нас прекрасно себя чувствуют специалисты по дизайну из Sberbank CIB и ряда европейских банков.

Так как основная сфера деятельности связана с инвестициями и корпоративным рынком, мы создаем интерфейсы и стили, наиболее востребованные в деловой среде, поэтому эмоджи и селфи-смайлики — это не про нас.

Какой алгоритм мы используем для утверждения макетов?

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

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

Чтобы UI был максимально удобным, мы используем собственную аналитику и прямое общение с пользователями.

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

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

Сергей Подшивалин, CPO Movista:

«невозможно сразу сделать идеальный продукт, поэтому не стоит бояться разрабатывать сервис вместе с пользователями»

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

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

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

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

Самым эффективным методом оценки пользовательских действий в сервисе мы считаем тестовое задание.

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

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

На рынке продажи билетов сложились различные типы поведений: авиабилеты чаще покупают туда и обратно, и пользователи хотят видеть сразу весь маршрут, в то время как в ЖД-сфере типична покупка билета сначала в одну сторону, а потом в другую.Мы не сразу выявили эти поведенческие особенности и реализовали универсальную выдачу маршрутов сначала туда, а потом обратно. Сейчас планируем сделать это нашим преимуществом, ведь когда пользователь привыкнет покупать билет на один вид транспорта, ему будет так же просто приобрести и билет на другой вид транспорта.

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

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

Иван Ардинцев, CPD Worki:

«в визуальной составляющей мы не доверяем вкусовщине, а используем data-driven подход, поэтому разные варианты интерфейсных решений запускаем только через А/B-тестирование»

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

Вся техническая работа над интерфейсами у нас проходит в Sketch с системой контроля версий Abstract. Когда макеты готовы, соединяем их через Overflow, который генерирует удобную карту функциональности. Исходники для разработчиков загружаем в Zeppelin.

Наш UI связан c UX, a UX — c умными алгоритмами формирования ленты вакансий и кандидатов. Мы используем машинное обучение, чтобы показывать кандидатам наиболее подходящие вакансии, а рекрутерам — наиболее подходящих кандидатов при холодном поиске в базе. Мы достигаем этого за счет четырех аспектов:

Социально-демографические характеристики кандидатов. У нас накопилась большая история просмотров и откликов вакансий от кандидатов, и сейчас мы ее используем, чтобы cделать продукт лучше, извлекая пользу из этих данных. Например, девушку восемнадцати лет, скорее всего, не заинтересуют вакансии грузчика или водителя, но могут заинтересовать мужчину сорока лет. Кроме того, скоро у нас появятся «Желаемые профессии», и кандидат сможет указывать, кем именно он хочет работать в первую очередь. Это еще больше улучшит ML-ленту. Сейчас мы генерируем персонализированную ленту с помощью 150 фичей.

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

Штрафы. Если рекрутер не обрабатывает отклики в течение определенного времени, мы делаем вывод, что по данной вакансии потребность в кандидатах удовлетворена, и понижаем ее в выдаче. Так мы стимулируем рекрутеров быстрее отвечать кандидатам.

Группировки вакансий. Существуют действительно массовые вакансии, вроде кассиров в KFC. Чтобы кандидат видел более разнообразную ленту, мы группируем их в одну вакансию, при этом показывая в ленте наиболее подходящую ему.

В визуальной составляющей мы не доверяем вкусовщине, а используем data-driven подход, поэтому разные варианты интерфейсных решений запускаем только через А/B-тестирование. Вместе с отделом аналитики мы внимательно следим за целевыми показателями каждого решения и спустя некоторое время оставляем максимально эффективный.

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

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

Более сложный и дорогой: UX-тесты на реальных пользователях с записью всех взаимодействий с интерфейсом на камеру и последующим мини-интервью. В условиях стартапа на это не всегда есть время и ресурсы, но для зрелых компаний это может стать основным вариантом, особенно если у сервиса большая аудитория.

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

С каждой новой итерацией нужно просеивать интерфейсы и выносить на первый план наиболее важные элементы, а второстепенные отодвигать на второй план.

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

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

Александр Жулин, директор по продукту Rubrain.com:

«если всю работу начать с формирования общего визуального языка, это сильно облегчит работу сразу в нескольких направлениях в будущем и при этом почти ничего не будет стоить»

Когда отвечаешь за продукт, тем более в стартапе, ты защищаешь решения внутри команды, а затем непосредственно перед пользователями. Слушаешь фидбэк, взаимодействуешь с бизнесом, оптимизируешь решения. Ты всегда можешь сразу анализировать живые цифры. А вот в проектной работе все сложнее. Тут приходится идти на компромиссы — убедить заказчика, что решение оптимальное, что бизнес-задачи в таком же приоритете, как и опыт пользователя. И если с UX это сделать чуть проще, то с UI все более субъективно. Даже если ты покажешь результаты А/B-теста, у многих заказчиков будут неконструктивные замечания. Тут помогает спокойная и планомерная работа с заказчиком — его надо выводить на конструктивный диалог по важным вопросам. Также помогает перед работой составить и утвердить гайдлайн — это сильный аргумент в будущих неконструктивных спорах.

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

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

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

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

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

Никита Ушаков, сооснователь и директор по маркетингу TraceAir и Александр Сметанка, дизайнер TraceAir:

«чтобы понять, что нашим пользователям кажется удобным или неудобным, нужно их знать, а для этого нужно много с ними общаться»

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

У нас B2B-продажи, но с точки зрения пользования продуктом у нас больше B2C. Мы сторонимся неприятных, сложных для восприятия и использования многослойных интерфейсов, которые свойственны многим B2B-продуктам. Мы внимательно прислушиваемся к пользователям, к людям, как они пользуются продуктом, и адаптируем интерфейс, чтоб им стало ещё удобнее и проще решать свои проблемы. Процесс разработки UI не сильно отличается от аналогичного для B2C-продуктов: человек и его удобство во главе угла.

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

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

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

Пока мы все еще стартап, поэтому у есть ограничения по времени и ресурсам, и зачастую не получается просчитать всё, ошибки неизбежны. Например, мы не проводим масштабных A/B-тестирований интерфейсов из-за недостаточно большой для этого базы пользователей. Мы разрабатываем интерфейс, используя подробный фидбек от наиболее лояльных клиентов. Это быстро и удобно, но выводы, сделанные на основе общения с такой ограниченной аудиторией, рискуют не понравиться многим другим пользователям продукта. У нас никогда не было критических ошибок интерфейса, которые блокировали бы работу, но хот-фиксы интерфейса приходилось делать. Тут опять же очень помогала быстрая и проактивная связь от наших клиентов.

Сергей Киреев, руководитель дизайн-отдела AIC:

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

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

В каждой отрасли есть свои особенности, свои сложившиеся паттерны поведения и тренды. Но есть и универсальные конструкции, применяемые везде. Отслеживать, интерпретировать и грамотно их применять — задача профессионального дизайнера, а осознанность — основной критерий в работе с UI. Всегда спрашивайте себя: зачем мы это делаем? Решает ли это нашу задачу? Какую пользу это принесет?

Вот несколько правил для эффективной работы с UI, которые я выделил для себя:

Тестировать продукт постоянно. Важно проводить количественные и качественные тестирования. Количественные помогут оптимизировать сценарии и понять, где кроется проблема, а качественные — докопаться до сути проблемы и узнать глубокие инсайты.
Дизайн — это постоянная работа над ошибками. Важно быстро реагировать, исправлять и из каждого промаха извлекать опыт, фиксируя его, чтобы не допускать похожих ошибок в будущем.
Действовать аккуратно. Не стоит выкатывать новый дизайн сразу на всех пользователей — люди боятся всего нового и неизвестного. Надо определить ключевые метрики, найти лояльную аудиторию и начать с нее. Собрать фидбек, понять, где ошибки, поправить и сделать обновление. Действовать короткими итерациями.
Сформулировать 10 принципов, определяющих, что такое хороший дизайн для того продукта, над которым работаешь. Пусть они станут ориентиром и проверкой решений дизайн-команды. Эти принципы могут касаться самых разных аспектов, которые вы посчитаете важными для вашего продукта или компании, но не должны иметь двоякого или абстрактного трактования. Примеры таких принципов можно посмотреть на designprinciplesftw.com.
Заставить дизайн-команду документировать свои решения, проводить ревью макетов, составлять библиотеки элементов и паттернов. Это нужно для тех ситуаций, когда есть риск получить элементы интерфейса, которые выглядят по-разному, хотя и выполняют одинаковую функцию, или наоборот.

Читать еще: «Интерфейс завтрашнего дня: простой и дружелюбный»

Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.