Классифайд

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

Интродакшн

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

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

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

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

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

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

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

У нас 4 основных продукта:

Kolesa.kz классифайд в категории Авто с MAU в 5 млн пользователей. Это 32 % всех интернет-пользователей в стране.
Krisha.kz классифайд в категории Недвижимость с MAU 3.5 млн пользователей. Это 23 % всех казахстанских интернет-пользователей.
Market.kz классифайд для всех категорий товаров и услуг. Ежемесячная аудитория более 2 млн человек.
Avtoelon.uz автоклассифайд в Узбекистане. MAU 2 млн пользователей.

Процесс

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

Шаг 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-маркетах).

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