Делимся алгоритмом работы над созданием дизайн-принципов, который сработал для нас и может пригодиться кому-то ещё.
Интродакшн
Раньше дизайнеры в нашей компании работали в едином отделе по принципу “студии”. Руководитель распределял задачи по навыкам, загруженности и грейдам. Но по мере роста и развития компании и команды, стали менять и подходы к проектированию. Поэтому осенью 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. Рисерч и поиск референсов
Вначале мы подглядели готовые базы принципов разных команд, потому что хотели узнать, как это устроено у других. Принципы многих команд очень схожи между собой и часто пересекаются.
Вот подборка ресурсов, где собраны референсы от других команд:
https://principles.design/
https://www.designprinciplesftw.com
Нам нужно было создать принципы, которые бы решали базовые, низкоуровневые проблемы. Например, доступные цвета и контрасты, понятная коммуникация в текстах, отклик интерфейса и его текущее состояние. Нашей главной целью было повысить качество продуктов прямо сейчас.
Шаг 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-маркетах).
Дизайн-принципы пишутся не один раз и на всю жизнь. Они должны решать вашу конкретную проблему в данный момент. Мы уверены, что в будущем будем пересматривать свои принципы, когда осознаем, что текущие стали обыденностью, будем строить новые принципы вокруг наших продуктов. Но это будет уже следующий этап стратегии развития дизайна продуктов.
