×

Как построить дизайн-процесс в команде

Сейчас все больше компаний понимают, что просто написать хороший код для конкурентоспособного продукта уже недостаточно. Необходимо обращать внимание на решение проблем юзеров и свою целевую аудиторию, которая уже достаточно избалована и требовательна. В этой статье я расскажу, почему так важен дизайн-процесс и на примере своего опыта работы с 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 и активно внедряют в свои дизайн-системы. Это прекрасная тенденция и хорошее конкурентное преимущество на рынке. Также важно не впадать в различные крайности. Да, несомненно процессы и структуры очень важны, но когда ваша компания постепенно начинает превращаться в бездушного корпоративного монстра с винтиками в системе — это значит, что процесс выстроен ошибочно, и люди начнут покидать ваши офисы. Хорошо построенный, отлаженный процесс должен одновременно повышать качество и результат работы, мотивируя сотрудников с удовольствием и креативностью выполнять свои задачи.

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

Если у вас возникнут вопросы, со мной можно связаться:

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному1
LinkedIn

Схожі статті




8 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Статья классная. Такой подход мы тоже пытаемся практиковать. Но я не увидел ничего ни про тестирование на пользователях ни про общение с ними (интервью, опросы и тд). Хотя, возможно это входит в пункт про исследования. Было бы хорошо если бы эта часть работы была тоже освещена.

Якщо ви хочете побудувати поганий продукт — почніть опитувати користувачів.

Звучить дико, катастрофічно неправильно, але реальність саме така. Мені ніхто не вірив, поки я наочно не показав людям, з чим ми маємо справу. На пару обговорень бізнес-фукнціональності запросив людей, які розповідали, що побудувати гарний продукт можна тільки базуючись на запитах кінцевих споживачів. Після другої зустрічі запитань більше не було :D

Тестирование на пользователях (упомянутое на слайдах А/Б тестирование) это не опрос их мнения.

Спасибо! Если вкратце. У нас есть лаборатория с девайсами, видеокамерами и тд. где проводятся юзер интервью по прописанным скриптам, различные тесты. Также, используем www.usertesting.com , www.crazyegg.com, google analytics

Интересная статья, у нас все очень похоже

Спасибо, в аутсорсе еще многое зависит от команды, проекта, сроков и бюджета. Вполне реально применить.

Ми пішли навіть далі. Результатом роботи UI відділу є повнофункціональний прототип, який працює з dummy даними. Це дозволяє перевіряти не тільки UX, але й зафіксувати протокол обміну між FE <=> BE та структури даних. Так, інколи це збільшує час розробки, але в цілому ми скорочуємо його, бо прототипи збираються із готових компонентів оминаючи фазу мокапів. Під ций підхід було розроблено цілу низку різних рішень, починаючи з фреймворка, закінчуючи максимальним повторним використанням компонентів UI.

Підписатись на коментарі