Как построить дизайн-процесс в команде
Сейчас все больше компаний понимают, что просто написать хороший код для конкурентоспособного продукта уже недостаточно. Необходимо обращать внимание на решение проблем юзеров и свою целевую аудиторию, которая уже достаточно избалована и требовательна. В этой статье я расскажу, почему так важен дизайн-процесс и на примере своего опыта работы с Emirates Airlines поделюсь подробным планом дизайн-процесса, в разработке которого я принимал участие и которому мы следуем в проектной работе нашей команды.
Как делают лидеры индустрии
Если вы все еще думаете, что работа дизайнера — это рисовать картинки и ходить в черной одежде, попивая латте макиато, — могу вас огорчить. Сегодня, как в огромных enterprise-продуктах с корпоративной средой, так как и в небольших стартапах, сформированы дизайн-отделы, которые занимаются исследованиями по улучшению продукта и решению актуальных проблем пользователей.
После посещения конференции для дизайнеров Awwwards 2018 в Сан-Франциско я еще больше убедился, что все современные лидеры техиндустрии, такие как Airbnb, Google, Microsoft, Adobe, Facebook, Dropbox, Netflix, IBM и другие разрабатывают свои кастомизированные дизайн-процессы и методологии, которые являются базой их продуктов. Около 41% презентаций касались именно построения и описания дизайн-процессов в компаниях и командах.
Со слайдов видно, что у одних компаний процессы более сложные, у других — более простые. При этом все больший упор делают именно на постоянные итерации и data driven подход в дизайне. Другими словами, все предположения и концепты должны быть подтверждены цифрами и тестироваться как можно больше и если что-то не работает, проводить следующий цикл итераций по улучшению и составлению новых гипотез.
Подробный план дизайн-процесса
Итак, вот дизайн-процесс, которому мы следуем в Tigerspike и в разработке которого я принимал участие. Этот процесс разработан и используется исключительно в рамках моей проектной команды и может не совпадать с общими официальными процессами компании.
Стандартная команда состоит из специалистов следующих направлений: UI Designer, UX Designer (да, у нас есть разделение), PM, QA, Developers. Дизайн-среда состоит из следующих инструментов: Sketch, Adobe CC, Invision, Slack, Dropbox, UXPin.
Чаще всего команда стартует с получения брифа (задания) от PO на личной встрече или по имейлу. После, следует так называемый kickoff meeting, где мы обсуждаем проблемы, цели, метрики, какими будет измеряться успешное достижение цели, сессия вопросов-ответов. Если поставленная задача не ясна до конца — команда коммуницирует до тех пор, пока появляется кристальная ясность.
Следующий этап — внутренняя встреча команды, на которой обязательно присутствуют UI, UX, PM, где мы планируем работу в разрезе спринта и заводим все в Jira. Чаще всего мы используем двухнедельные спринты и agile-подходы.
Далее начинается активная фаза дизайна с несколькими циклами итераций по улучшению решений, где мы начинаем проводить исследования, обсуждаем проблему, проводим различные воркшопы. На этом этапе используем различные методологии, как внутренние так и внешние (design thinking, catalyst и другие). Результат работы — аналитика, исследования, скетчи с идеями, мокапы и прототипы различных уровней детализации. Все документируется, заливается на Dropbox и Invision.
Первые варианты и концепты подвергаются внутренней критике и различным стресс-тестам остальных коллег-дизайнеров, которые работают над другими проектами. На данном этапе заполняются различные пробелы и исправляются ошибки. Мы работаем в рамках большого международного продукта. Таким образом, необходимо учитывать такие факторы, как переводы на другие языки, людей с ограниченными возможностями (accessibility standards).
Когда очередной цикл итерации завершен, прототипы отправляются на проверку качества дизайна (design QA review), проверку на соответствие стандартам для людей с ограниченными возможностями (accessibility review, АА standard). Также, перед отправкой PO на стороне клиента, необходимо получить финальное утверждение от UI-дизайн-лида и UX-дизайн-лида по соответствию стандартам, бренд-гайдлайнам и внутренней дизайн-библиотеке.
Готовые прототипы на Invision отправляются PO для финального утверждения. Обычным процессом является получение новых бизнес-требований или комментариев, что ведет к очередной итерации и повторению процессов.
После очередного цикла правок и финального утверждения проводится чистка исходников, стандартизация наименования компонентов, конвертация в символы и генерация HTML/CSS с помощью различных плагинов как sketch measure или Invision Inspect mode. Далее идет коммуникация с Front-end разработчиками, где обсуждаются все непонятные моменты и функционал.
Прототипы и техническая спецификация отправляется в разработку. Когда разработчик закончил первый цикл своей работы, QA тестирует код и создает задание в Jira для дизайнера на проверку и утверждение готового кода и front-части. Проверка осуществляется дизайнером через Chrome Inspect Mode. На данном этапе в Jira заводятся UI-баги, которые исправляются в следующем цикле итераций.
Финальный этап — передача готового проекта для общей глобальной интеграции. Командой мы всегда стремимся передать часть проекта на общую интеграцию, имея 0 issues.
Выводы
Основные ошибки (с моей субъективной точки зрения), которые особенно характерны для украинского аутсорса, — это полное отсутствие или частичное присутствие дизайн-процессов.
Важно понимать, что компании торгуют человеко-часами, зарабатывая на разнице, и ориентированы только на разработку или исправления устаревшего/некачественного кода, чем на комплексный подход в разработке продукта.
В основном различные дизайн-методологии используются на этапе presale, чтобы впечатлить потенциального клиента и подписать долгосрочный контракт. Таким образом, весь дизайн, если он вообще присутствует, базируется на поиске хороших решений на таких платформах, как Dribbble, Behance, Uplabs и подобным, с последующим копированием и изменением элементов. Нет никакой аналитики, исследований, данных. Большинство решений остаются на этапе «предположений» (assumptions) и не подкреплены реальными данными с рынка, другими словами, не валидны.
С другой стороны, все больше компаний, особенно продуктовых, начинают инвестировать в разработку своих или берут уже готовые методологии от лидеров, например, Google, IBM, IDEO и активно внедряют в свои дизайн-системы. Это прекрасная тенденция и хорошее конкурентное преимущество на рынке. Также важно не впадать в различные крайности. Да, несомненно процессы и структуры очень важны, но когда ваша компания постепенно начинает превращаться в бездушного корпоративного монстра с винтиками в системе — это значит, что процесс выстроен ошибочно, и люди начнут покидать ваши офисы. Хорошо построенный, отлаженный процесс должен одновременно повышать качество и результат работы, мотивируя сотрудников с удовольствием и креативностью выполнять свои задачи.
Буду рад, если вышеописанные процессы помогут улучшить качество вашего продукта и решить проблемы ваших пользователей более эффективно.
Если у вас возникнут вопросы, со мной можно связаться:
