Дизайн какого либо продукта
Одна из секций прошедшей в Иннополисе ночной конференции IT Nights была посвящена продуктовому дизайну. Узнали у спикеров конференции, кто такой Digital Product Designer и что конкретно он делает.
Обучение в онлайн-университете: курс «Продуктовый дизайнер»
Продуктовый дизайнер — специалист, который отвечает за выявление проблем продукта, предлагает решения по его улучшению и реализует изменения с учетом бизнес-стратегии продукта.
До сих пор не существует однозначного устоявшегося определения профессии продуктового дизайнера, поэтому бытуют стереотипы, что продуктовый дизайнер — это тот, кто рисует продукты. На самом деле это специалист широкого профиля — обладает широкими навыками и пониманием основ ряда узкоспециализированных профессий: UX-дизайнер, графический дизайнер, исследователь, аналитик, прототипировщик, маркетолог, бизнес-стратег. Продуктовые дизайнеры востребованы и хорошо зарабатывают.
IT Nights
Алена Кирдина
Дизайнер компании Evil Martians
Дизайнер продукта — профессия достаточно новая. С непривычки нас можно перепутать с дизайнерами интерфейса, графическими дизайнерами, исследователями или даже бизнес-аналитиками, но на практике нам удается совмещать в одной роли все вышеперечисленное. Главная задача продуктового дизайнера — помочь цифровому продукту прийти к измеримому успеху, а для этого одного рисования интерфейсов недостаточно.
Дизайнер на «Марсе» [в компании Evil Martians. — прим. Нетологии] обращается к аналитике и пользователям, чтобы найти основные проблемы продукта, изобретает эффективные решения посредством прототипирования в графическом редакторе или коде, сопровождает разработку этих решений, тестирует результат и повторяет цикл, если нужно. Это не просто ремесленник, а стратег и инженер, движущая сила веб-сервиса или приложения.
Ярослав Шуваев
Head of R&D компании «Ак Барс Цифровые Технологии»
Продуктовый дизайнер — человек, который должен совмещать в себе три базовые роли. Первая — это ответственность за качество пользовательского опыта. Он должен регулярно получать обратную связь от пользователей, проводить исследования текущего пользовательского следа внутри актуального цифрового продукта и постоянно его улучшать. А также думать над востребованными улучшениями, проводить исследования по изучению пользовательского спроса.
Вторая большая область влияния — это ориентация в технологическом мире, чтобы придумывать оптимальные с точки зрения технической разработки решения задач. Это как архитектор — с одной стороны должна быть эстетическая роль, с другой — он должен разбираться в технологиях.
Третье — экспертиза, связанная с бизнесом цифрового продукта. Ему нужно разбираться в модели монетизации, стратегии, понимать основные метрики жизнеспособности продукта. Каждое его решение должно быть продиктовано пониманием этих метрик и быть максимально ориентированным на их увеличение.
Влад Зелинский
Руководитель команды продуктового дизайна компании Miro
Digital Product Designer работает с бизнес-эффектами и гипотезами, достигая первые и проверяя вторые, через итеративную работу с цифровым продуктом. Мы в Miro вовлекаем дизайнера на ранних стадиях работы с проектами, чтобы он или она могли определять, как должно выглядеть решение.
В зависимости от стадии продукта, опыта дизайнера и задачи специалист адаптирует свой процесс работы под цель. Например, чтобы расширить число этапов, которые закрывает продукт в работе команд, нужно провести исследование рынка, пользователей и конкурентов, чтобы сформировать видение: как мы можем это сделать. Либо же, получив такое понимание от стейкхолдеров, взять в проработку вид, опыт и функциональность, которые потенциально могут привести нас в ту точку, о которой мы договорились. Дробя вышесказанное на этапы, можно схематично зафиксировать процесс так: проблема/эффект/гипотеза → исследование → проектирование решения → тестирование → улучшение → запуск → анализ. Повтор.
Митя Осадчук
Креативный директор компании Mail.Ru Group
В компании Mail.ru целая экосистема сервисов, чтобы закрыть большинство потребностей пользователей в онлайне. Они различаются по содержанию, стилю и разной фазе активности работы над ними (концепции/запуск/поддержка), поэтому заскучать невозможно и есть где развернуться.
Мы создаем концепции, прорабатываем их и внедряем, параллельно работая над отдельными задачами по улучшению какой-то локальной части сервиса.
Нам повезло: мы доказали внутреннюю экспертизу и уже давно занимаемся задачами шире создания самого продукта — креативная часть, айдентика, маркетинг. К этому тоже можно прикоснуться в своей работе, так как большой пул проектов и постоянно запускаются новые.
Выступление на IT Nights
По данным сайта hh.ru, среднее предложение для продуктовых дизайнеров составляет от 40 000 ₽ до 90 000 ₽ ежемесячно (данные по состоянию на август 2019), в зависимости от города:
- Москва — 90 000 ₽
- Санкт-Петербург — 75 000 ₽
- Новосибирск — 58 750 ₽
- Екатеринбург — 60 000 ₽
- Нижний Новгород — 57 500 ₽
- Казань — 60 000 ₽
- Челябинск — 47 500 ₽
- Омск — 42 500 ₽
- Самара — 66 250 ₽
- Ростов-на-Дону — 50 000 ₽
- Уфа — 50 000 ₽
- Красноярск — 45 000 ₽
- Пермь — 40 000 ₽
- Воронеж — 47 000 ₽
Работу продуктового дизайнера готовы предложить компании, которые занимаются разработкой ИТ-продуктов: веб-студии, интернет-стартапы, ИТ-холдинги, банки, телеком. От масштаба компании и сложности задач зависит и оплата.
По данным hh.ru, 41% вакансий приходится на компании ИТ-сферы. 11% — на розничную торговлю. В 9% случаев продуктовых дизайнеров ищут в компании, занимающиеся маркетингом, рекламой, BTL, PR. 7% предложений размещены организациями, которые специализируются на товарах широкого потребления. 5% приходится на финансовый сектор.
Можно предположить, что приведенные зарплаты относятся к уровню начинающих или мидл-специалистов. Топовому сотруднику или руководителю продуктовой команды компании в городе-миллионнике готовы предложить оклад в несколько сотен тысяч рублей.
Половина предложений для продуктовых дизайнеров подразумевает опыт работы от 1 года до 3 лет, еще 37% — опыт от 3 до 6 лет. 8% работодателей трудоустроят кандидатов без опыта работы.
Александр Пелевин
Руководитель отдела дизайна продуктов компании «Актион-МЦФЭР»
Чтобы быть дизайнером продукта, нужно сначала всесторонне изучить, как устроен продукт: модель монетизации, портрет аудитории, задачи, сценарии, боль и радости пользователей, структура взаимодействия, интерфейс, используемые технологии и так далее. А потом прикладывать силы к тому, чтобы продукт становился лучше. Аналитическое мышление, эмпатия и умение учиться — главные hard skills дизайнера. Умение слушать, понимать и говорить — ведущие soft skills. А важнейшими установками должны стать желание делать дела (а не витать в облаках) и разделение коллективной ответственности за то, что вы отдаете пользователю в результате.
Ярослав Шуваев
Head of R&D компании «Ак Барс Цифровые Технологии»
Прежде всего, это ожидания от UX-дизайнера, пользовательские исследования перед запуском итерации (to be customer journey map), а также после (as is customer journey map). Это создание прототипов разной степени детализации, которые применяются в исследованиях. Умение декомпозировать функциональность, которая находится в бэклоге, например, используя инструменты user story mapping. Умение проводить стратегические сессии вместе с командой с использованием таких инструментов, как lean canvas; потому что проведение сессий в формате коллективного творчества — самый эффективный метод сбора требований для продуктового дизайнера.
Также требуются базовые навыки UI-дизайна, непосредственно связанные с созданием дизайн-системы цифрового продукта: UI-кит, модульные сетки, типографические стили, стилистика иллюстраций, пиктограммы, набор токенов, разные фирменные цвета, набор компонентов интерфейса, анимация и прочее.
Дополнительной экспертизой является понимание владения продуктом, чтобы говорить на одном языке с бизнес-владельцем: бизнес-модель, модель ценообразования, маркетинговые исследования, vision продукта. И свободная ориентация в таких актуальных процессах цифрового производства продукта, как lean development, scrum и так далее.
Митя Осадчук
Креативный директор компании Mail.Ru Group
На мой взгляд, сейчас важно не быть «одностаночником» — большинство сложных дизайнерских задач находятся на стыке ролей и специальностей. Уже нельзя просто нарисовать прототип, разукрасить его и отдать. Вы точно найдете, где применить навыки в копирайтинге, полиграфии, айдентике и даже 3D.
Важно понимать, что продуктовый дизайнер — один из элементов пазла успешного продукта. Только в команде рождаются идеальные решения, сделать все одному можно, но сложно — это только одна точка зрения за продукт или задачу. Как следствие, важно прокачивать свои коммуникационные навыки.
Внимание к мелочам: как говорится, дьявол в деталях — по умолчанию от продуктового дизайнера ждут аккуратности в смыслах, в макетах, в решениях. Важно осознавать, что каждый день именно ты можешь сделать продукт лучше. Следствие инициативы — брать ответственность за свои идеи и решения.
Ну и один из самых приятных моментов в работе — понимание, что ты делаешь это все для конкретных людей, которых сотни, тысячи, миллионы. И ты делаешь их жизнь проще, лучше и удобнее!
Влад Зелинский
Руководитель команды продуктового дизайна компании Miro
Рад, если для кого-то это прозвучит очевидно, и ещё больше рад, если в вас это уже есть — дайте мне знать, я в постоянном поиске таких людей.
Итак:
1. Моделирование сценариев: что было до, что будет после, как мы сюда попали, а что если?… Работу опытного дизайнера отличает отсутствие логических дыр и разрывов во взаимодействии: всегда ясно, откуда, куда и как может двигаться пользователь.
2. Снижение неопределенности. Это иногда называют исследованиями, но мне не хотелось бы сужать до конкретного инструмента. Задача может быть шире: формализовать требования или критерии результата, сформулировать вопрос, на который нужно ответить, или гипотезу, которую нужно проверить, а затем провалидировать их. Это о том, чтобы двигать работу вперёд, даже если результат невозможно описать в текущем моменте.
3. Проектирование. Опять же в широком смысле: как это будет выглядеть, как это будет работать, что будут чувствовать люди, используя это?
4. Коммуникация. Причём как внешняя, так и внутренняя. Команде важно объяснить: почему принято то или иное решение, а клиенту донести ценность, которую он получит от этого. Ещё важно слышать, задавать открытые вопросы и контролировать эмоции.
5. Менеджмент. В начале — научиться управлять собой: своим временем, обязательствами и ресурсами. Затем это масштабировать на проектную группу, отдел, департамент и всю компанию.
6. Бизнес-мышление. Как мы влияем на благосостояние компании? Делаем ли мы самую важную вещь с точки зрения эффектов в текущий момент? Как мы можем вырасти в десять раз в годовом доходе?
7. Проактивность. Что-то не ок → предложи, как улучшить. У тебя есть идея → обсуди. Не хватает ресурсов → придумай, как скорректировать решение или передоговорись. Не ждать, а жить интересную и правильную в вашем понимании жизнь.
IT Nights
- «Живая типографика», А. Королькова
- «Типографика», Э. Рудер
- «Представление информации», Э. Тафти
- «Не заставляйте меня думать», С. Круг
- «Дизайн привычных вещей», Д. Норман
- «Интерфейс», А. Купер
- «Найти идею», Г. Альтшуллер
- Гайдлайны по дизайну от Apple
- Гайдлайны по дизайну от Google
- «Элементы стиля», В. Шранк
- «Пиши, сокращай», М. Ильяхов и Л.Сарычева
- Курс UX-аналитика в Нетологии
- Вводный курс по Google Analytics от Analytics Academy
- Курс базовой статистики от University of Amsterdam
- «Сначала скажите Нет», Д. Кемп
- «Культура дизайна», В.Головач
- Телеграм-канал Кости Горского Design & Productivity
- Телеграм-канал Юлия Вертова «Дайджест продуктового дизайна»
- Телеграм-канал Влада Зелинского vladzely.zip
- Блог «Дизайн-кабак»
- Видеолекция Майка Монтейро
- Лента Smashing Magazine о дизайне и фронтенд-разработке
- Behance
- Dribbble
- Awwwards
- CSS design awards
Продуктовый дизайнер сочетает в себе аналитику и творчество, инженерный подход и нестандартность решений. Если это про вас — пройдите курс «Продуктовый дизайнер» и освойте востребованную профессию.
Читать еще: «Разбираемся в основах типографики за 10 минут»
Полный цикл работы над проектом от дизайнера Славы Яшкова, работавшего с райдшеринговым сервисом Beepcar.
Командра дизайнеров Beepcar
Хочу пошагово объяснить, как сделать готовый дизайн продукта, опираясь на собственный опыт работы в Beepcar. У сервиса есть веб-версия и мобильные приложения для Android и iOS.
Перед дизайном
Прежде чем приступать к дизайну, нам нужно знать: что именно мы делаем и зачем. Понимать причины задач и их цели нужно всей команде — за это отвечает менеджер по продукту.
Но в реальности у менеджера полно других задач, встреч, исследований и разных забот. Из-за этого донести причины и цели ему удаётся не всегда. Поэтому проявим инициативу и разберёмся сами, откуда приходят задачи.
Так как проект запущен, у нас уже есть аудитория — большая или пока маленькая. Это люди, которые выбрали наш продукт для решения своих задач (работ по JTBD). Этих людей нам нужно уметь слышать, понимать их потребности. От удовлетворения их потребностей зависят наши метрики, которыми мы оцениваем успешность продукта.
Как можно выявлять потребности?
Отзывы
Их нужно читать регулярно и всей командой. Есть три простых способа.
- Люди оставляют отзывы в Google Play и App Store.
- Нужно заранее предусмотреть возможность отправки отзывов напрямую из приложения или сайта.
- Нужно искать отзывы в сообществах компании в соцсетях.
Собственный опыт и опыт друзей или знакомых
Скорее всего, нашим продуктом будут пользоваться окружающие нас люди, не надо стесняться лишний раз спросить, всё ли им нравится в сервисе. Вопросы ставить открытые, пытаться разговорить человека. Часто во время таких интервью всплывают интересные кейсы. Ну и не стоит забывать самостоятельно вставать на место людей, которые пользуются сервисом.
Эксперименты на «живом»
«Живыми» мы в команде называем действующие версии продукта: ими прямо сейчас пользуются люди. Чтобы проводить эксперименты, требуется специальная подготовка. При начальной разработке нужно потратить время на установку счётчиков для разных событий. Благодаря этому мы сможем замерять воронки, выдвигать гипотезы, а затем проверять их. Ниже простой пример воронки:
Почему из 100% людей, которые попали на экран бронирования, на кнопку «Забронировать» нажимает только 21%? Самый очевидный вывод будет: люди не находят кнопку. Тогда наша гипотеза такова: если поставить кнопку на более видное место, можно увеличить количество бронирований.
UX-тестирования
В Mail.Ru Group, как и во многих больших компаниях, есть UX-лаборатория. Это специальный отдел, который приглашает сторонних людей, показывает наши продукты, проводит интервью, записывает реакцию и по результатам этих исследований готовит отчёт о продукте.
Компании поменьше, без доступа к лабораториям, могут самостоятельно проводить UX-тестирования и интервью со знакомыми. А ещё это можно сделать через онлайн-сервисы. Например, через Fabuza.
Конкуренты
Ну, и конечно, подглядываем за нашими соседями. Нас должны интересовать как прямые конкуренты, так и косвенные. С прямыми всё понятно, а косвенными могут быть абсолютно разные компании.
Например, наш косвенный конкурент — «Почта России», потому что в нашем сервисе люди могут отправлять с водителями посылки. И когда кто-то из конкурентов выпускает какую-либо функцию, нужно изучить её и решить, насколько она нужна в нашем продукте.
После выявления потребностей их нужно превратить в функции. В половине случаев всё будет достаточно банально, например: пассажиры хотят оплачивать картой — давайте сделаем онлайн-оплату, гениально!
С остальными потребностями стоит копнуть поглубже. Одна из последних: люди хотят оставлять комментарии к поездке. Тут можно было не думать, а просто вставить функцию комментариев (спойлер: в итоге мы так и сделали).
Но сначала мы пошли другим путём и рассуждали на тему того, что именно они хотят спрашивать в комментариях? Может, можно предупредить эти вопросы? А почему именно комментарии к поездке? Может, это должен быть общий чат? Или личные сообщения? И так далее. Зачем усложнять себе жизнь этими вопросами? Потому что это правильно, интересно и зачастую приносит интересные наблюдения и мысли.
Дальше у нас сложится список функций, которые мы хотим ввести. И сначала всё будет хорошо, он будет небольшим и аккуратным, но потом количество «хотелок» будет расти как снежный ком. Тут нужно выставлять приоритеты, чтобы в итоге у нас получился ровненький бэклог с задачами. Приоритизировать задачи можно, опираясь на две вещи:
Модель «Ааа, горит!»
Часто у нас есть задачи, которые нужно было решить ещё вчера. Например, после публикации последней версии сервиса просела важная для нас метрика. Или конкуренты выпустили очень важную функцию, которой у нас ещё нет.
А ещё могут принять новый закон, например, «Закон о соглашении на обработку персональных данных». Чтобы его выполнить, тоже нужно время на дизайн и разработку. Сюда же можно добавить маркетинговые активности к праздникам и разным событиям. Все эти задачи в большинстве случаев встают на первое место.
Модель Кано
Когда пожар потушен, можем двигаться дальше. Для этого берём наш бэклог и прогоняем его через модель Кано. Этот метод помогает понять, какому проценту людей понравится новая функция, кому будет всё равно, а кто огорчится.
В связке с оценкой разработки это позволяет увидеть соотношение наших трудозатрат на функцию и пользы от неё. После этого наш бэклог приобретёт вид списка с приоритетами. Про саму модель можно посмотреть тут.
Дизайн
Теперь начинаем рисовать. В отличии от первого модуля, за который отвечал продуктовый менеджер, здесь главную роль играем мы — продуктовые дизайнеры. Так как ответственность целиком на нас, мы не должны пропадать. Поэтому переодически согласовываем промежуточные решения с менеджером. Процесс дизайна поделён на три части:
- Рисуем. Перед первым подходом полезно встретиться в узком кругу менеджеров и дизайнеров и проговорить основные моменты. Рисовать начинаем уже на этой встрече, поэтому на выходе у нас будут наброски мокапов и более чёткое понимание, чего все ожидают. Далее прорабатываем все идеи, переносим в Sketch и продумываем всё более подробно ещё раз. На каждый потенциальный вопрос у нас должен быть ответ.
- Проверяем. Чтобы проверить простые функции, достаточно показать дизайн на устройстве. Для более сложных нужны кликабельные прототипы. Демонстрируем нашей команде и другим коллегам, запоминаем реакцию, делаем выводы. На этом этапе стараемся задавать побольше вопросов, ответы на них нам очень пригодятся. Почему ты так считаешь? Как бы ты сделал? Что смущает? Сразу разобрался? И так далее.
- Три вопроса. Первый — что хорошо? В наших решениях почти всегда будут плюсы (мы же хорошо думали над ними, правда), главное, уметь их замечать и фиксировать: ага, кот на экране загрузи всем понравился, лайк. Второй вопрос — что плохо? Будут и минусы, их тоже подмечаем и запоминаем: кот, конечно, классный, но непонятно, что в этот момент идёт загрузка. Третий вопрос — какие идеи? Здесь нужно придумать, как сохранить и приумножить плюсы, а также убрать минусы: попробуем добавить анимацию, пускай кот катает клубок, тогда будет понятно, что приложение не зависло. Теперь у нас есть идеи для дальнейшей работы, поэтому завершаем первый цикл и начинаем опять рисовать.
В итоге у нас получается замкнутый круг, выйти из которого мы сможем тогда когда результат будет устраивать всех в полной мере.
Защита решений
Это огромная часть работы дизайнера, и можно очень долго её обсуждать. Но я попробую донести основную мысль.
На этапе дизайна всегда возникают дискуссии, и это нормально. Плохо, когда споров нет. Но многие споры можно решить достаточно просто, главное, «разговаривать» числами. К сожалению, не все даже опытные дизайнеры умеют это делать.
Всякая мелкая «вкусовщина» решается тестированием Side By Side. Это младший брат A/B-тестов: человеку показываются две статичные картинки, а он должен выбрать ту, что нравится больше. Подчеркну, что серьёзные вещи таким способом проверять нельзя.
Бесплатно такой метод можно применить в обычной email-рассылке, для этого вам нужна только база адресов и время. Можно и быстрее, но тогда за деньги, для этого есть специальные сервисы: Amazon Turk или «Яндекс.Толока». Мы в команде пользуемся «Толокой», потому что там русскоязычная аудитория, для которой и делается наш продукт.
Крупные вопросы мы решаем полноценными A/B-тестами на «живом». Об этом вкратце я рассказал выше: выставляем гипотезу, замеряем воронки, получаем данные для разговора.
И никто не отменял коридорные тестирования. Берём в руки прототип и идём показывать коллегам, знакомым. Если воспитание позволяет, можно даже на улицу выйти и поприставать к прохожим. Всем задаём одни и те же вопросы, по итогу такого тестирования у нас будет статистика ответов, которая и станет нашим аргументом в защите дизайна.
Используя этот подход к работе, у дизайнеров всегда будет показатель, который станет аргументом в спорах: 67% людей ответили, что эта иконка понятнее; 7 человек из 10 сразу же выполнили правильное действие; 41% людей отвалились на этом варианте выдачи результатов.
Принципы дизайна
В тоже время, бесконтрольный метод работы с числами может превратить наш продукт в винегрет. Заранее стоит позаботиться о принципах дизайна в нашей команде, прописать их и утвердить всей командой. Можно даже распечатать и повесить на видное место.
Классическим примером будут принципы Дитера Рамса, которые он продвигал в Braun. Ещё есть подборка принципов более молодых компаний, можно изучить и вдохновиться. Бонусом к подходу станут разрешения споров. Когда у нас нет возможности проверить разные варианты решения, тогда принимать стоит то, которое больше следует нашим принципам дизайна. Убираем лишние споры — экономим рабочее время.
Конечно, эти советы по защите решений не помогут нам во всех ситуациях, но следуя им, утверждать дизайн будет проще.
После утверждения дизайна
Начинается разработка приложения. Продуктовый дизайнер тесно связан с разработчиками. У нас в команде Beepcar дизайнеры сидят вместе с разработчиками, это ускоряет решение мелких вопросов и повышает взаимопонимание между сотрудниками.
Весь последний этап крайне важен для дизайнера. Кому нужны наши красивые макеты, если на выходе люди увидят откровенно обескураживающий продукт. Тогда большая часть наших усилий пройдёт в пустую. Поэтому следим за правильной реализацией нашего дизайна. Если что-то будет выглядеть или работать не по утверждённому дизайну, спрашивать будут с нас.
Подготовка
Перед тем как отдавать макеты, нужно убедиться, что мы просчитали все состояния для всех экранов. Чтобы ничего не забыть, хорошо сделать себе чек-лист состояний. Для каждого проекта он будет индивидуальный, но можно начать со стандартных вещей:
- как будет выглядеть экран, если нет контента;
- что будет, если интернет пропадёт или будет медленным;
- как это выглядит для незарегистрированного пользователя;
- максимальная и минимальная длина текстовых полей;
- как сокращаются длинные названия;
- названия на кнопках умещаются на всех языках, которые мы поддерживаем;
- где могут возникнуть ошибки и как они должны выглядеть;
- какие элементы могут быть неактивными.
Помимо этого мы должны быть уверены, что наш дизайн будет отображаться на всех доступных экранах платформ одинаково хорошо. Бывает, что сложно угодить всем. Тогда можно взглянуть на аналитику и пожертвовать качеством отображения на непопулярных разрешениях. И наоборот, те разрешения, которые у нас находятся на первых местах, должны быть проработаны до мелких деталей.
Как передать макеты
Для передачи макетов используем всем известный сервис Zeplin и менее известный Sympli. Если в команде много людей которые должны иметь доступ к макетам, стоит обратить внимание на второй сервис. Он выйдет дешевле из-за безлимитного количества мест за фиксированную цену.
Если есть анимация, показываем её на GIF или видео, делаем описание c изменениями каждого параметра:
animation: easy in-outtime: 0.2opacity: 100% → 90%
Во время разработки всегда остаёмся на связи, любой вопрос по дизайну тормозит разработку. Стараемся сразу отвечать на электронные письма и по остальным каналам связи.
Финальным этапом идут тестирования и Design Review. У нас в Beepcar эти процессы построены следующим образом:
- Если говорим про мобильные приложения, то разработчик выкатывает функцию в тестовую сборку через HockeyApp. Если про веб, то функция отправляется на наш тестовый сервер.
- Тестировщики смотрят на всех устройствах и сравнивают макеты дизайнера с тем, что получилось. Откровенные ошибки они сразу комментируют в задаче и снова отправляют разработчикам на доработку. В спорных моментах к обсуждению привлекают дизайнера.
- После того, как тестировщики полностью удовлетворяются качеством исполнения функции, задача возвращается к дизайнеру. Он должен провести Design Review. Теперь к нам в руки попадает практически финальная версия функции. По большей части, от дизайнера требуется проверить все отступы, кегли, цвета, иконки и прочее, чтобы всё выглядело ровненько и чистенько. Тут всё зависит от разработчика: если он внимателен к деталям, тогда особо и проверять ничего не нужно. Как только дизайнер окончательно подтвердил, что его всё устраивает, фукция отправляется в финальную сборку.
Эпилог
Конечно, чётко следовать циклу получается не всегда. Бывают отклонения: переосмысления задач, откаты назад и всё остальное, что присуще нашей работе. Но за год использования внутри Beepcar этот принцип работы дал свои плоды: по срокам дизайн стал более предсказуемым, а сами дизайнеры больше погружены в продукт.