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

Интродакшн

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

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

Проблема, которую мы решали

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

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

Небольшое отступление про компанию и команду

Kolesa Group – продуктовая IT-компания, основанная в Казахстане. Мы создаем и развиваем классифайды – сервисы для публикации объявлений для людей и компаний в Казахстане и Узбекистане.

Процесс

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

Шаг 1. Рисерч и поиск референсов

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

Вот подборка ресурсов, где собраны референсы от других команд:

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

Шаг 2. Исследование внутри компании и создание опросов

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

В опроснике были вот такие открытые вопросы:

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

Кроме внутреннего опроса, мы собрали распространенные проблемы в продуктах из базы службы заботы о пользователях (звонки, письма, отзывы в app-маркетах). Это помогло сегментировать проблемы, например, технического или интерфейсного характера.

Шаг 3. Подготовка к шторму

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

На доске подготовили такие штуки:

Вытащили примеры принципов некоторых дизайн-команд, которые покрывали наши проблемы.

Вытащили результаты опросов.

Подготовили площадку для “боя”. В этой области будет проходить брейншторм. У нас это проходило в Miro.

Шаг 4. Собственно брейншторм

Сам брейншторм был строго ограничен по времени и разделен на этапы. Прежде всего мы обсудили 3 главных вопроса:

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

Обсудив вопросы, модератор брейншторма обозначил “правила игры”, и все участники приступили к штурму.

Сначала каждый участник писал на стикерах ПЛОХИЕ реализации и характеристики интерфейса или пользовательских качеств в продуктах. Ставили таймер на 10 минут.
Затем рядом с каждой плохой реализацией каждый участник должен написать решение проблемы, чтобы “ПЛОХОЕ” стало “ХОРОШИМ” – 20 минут.

3. Затем нужно было структурировать карточки и найти “связи”, при этом мы использовали результаты опроса и продуктовых запросов из базы службы заботы, которые заранее подготовили на доске – 20 минут.

4. В итоге у нас вышло несколько категорий, которые мы тоже объединили в сегменты:

A) человекоориентированность, прозрачность и честность в продуктах;

B) осознанность в проектировании, консистентность, качество продукта, эстетичность;

C) контроль состояния, понятная коммуникация, простота и очевидность;

D) командность.

5. Затем каждый участник отдал голос наиболее важным, на его взгляд, категориям – 3 минуты.

6. После мы разложили варианты, набравшие наибольшее количество голосов, по пирамиде дизайн-принципов.

Что осталось?

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

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

Вот что у нас получилось:

[Сначала люди]

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

[Сознательный подход]

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

[Очевидность]

Наши интерфейсы и внешние коммуникации едины, понятно объясняют, на каком шаге находится человек сейчас, и помогают, если что-то пойдёт не так.

[Коллаборация]

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

[Инновации]

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

Корабль поплыл

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

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

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

Заметить эффективный рост качества продукта только от внедрения таких принципов сразу невозможно, пока мы только следим за показателями NPS и внешним feedback loop (звонки, письма, отзывы в app-маркетах).

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

«Ваш дизайн говно!»: гайд по созданию дизайн-принципов для продуктовой компании