Роль дизайна в продукте (15 День)

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

Посмотрел доклад Евгении Малковой из 2gis.ru «Дизайнер, разработчик, нет конфликта, нет драмы» на #CocoaHeads Moscow.

Затронем такие вопросы:

  • Что делать, если чувство прекрасного у разработчика развито сильнее, чем у дизайнера?
  • Как подвигать пиксели без риска для жизни?
  • Зачем разработчику иногда необходимо побыть дизайнером?

Получился лонгрид, не пугайтесь!

Дизайн, зачем?

Очень часто разработчики не испытывают должной эмпатии к дизайнеру.

Рассмотрим роль дизайна на конкретном примере, рассмотрим приложения для контроля финансов:
design

Всё, что лучше выглядит имеет больший рейтинг.

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

Классный продукт всегда находится на стыке Технологий и Дизайна.

Поговорим о создание продукта:
design2

Кто работает над продуктом:
design3

Менеджер ставит задачи, дизайнер проектирует интерфейс, разработчик пишет код, это понятно.

Часто в команде носители каждой роли ставят себя выше других, но на самом деле, в хорошей команде все равны!

Где происходят пересечения деятельности дизайнера и разработчика:
design4

На первом этапе — «Оценка продукта» вместе работают менеджер и дизайнер. Позже подключается разработчик.

Этот этап можно назвать «Договориться надо на берегу». Это один из самых важных этапов работы над продуктом.

Что происходит на данном этапе?

  • PM готовит продуктовые требования →
  • Дизайнер продумывает UX продукта →
  • Дизайн и требования отправляются в Confluence (инструмент для совместной работы atlassian.com) →
  • Команда разработки изучает требования и выносит оценку →
  • Составляется roadmap продукта со сроками.

Что может случиться:

  • 1) Разработчик не может реализовать дизайн.

Решение:

Выяснить, в чём проблема.

Если проблему невозможно решить, задать вопрос о целесообразности дизайна:

  • А зачем нам столько фич в приложении?
  • Может некоторые фичи вынести в отдельный продукт?

При отсутствии аргументов — пересмотреть дизайн.

Следующий этап — «Работа над продуктом».

Что происходит на данном этапе?

  • PM описывает требования к фиче в Confluence →
  • PM ставит задачу дизайнеру в Basecamp (онлайн-инструмент для управления проектами, совместной работы и постановки задач по проектам basecamp.com) →
  • Дизайнер разрабатывает интерфейс →
  • PM апрувит дизайн и выкладывает его в Confluence →
  • Разработка начинает заниматься фичей.

Инструменты для совместной работы:
design5

Basecamp это творческая мастерская для дизайнеров, туда не пускают разработчиков.

Confluence это самый важный документ проекта, в любой непонятной ситуации читай Confluence, там всё финальное.

Jira — инструмент разработчиков, где хранятся задачи для разработчиков.

Dropbox — для обмена файлами между дизайнерами и разработчиками.

Что может случиться:

  • 2) Дизайнер далеко ушёл от первоначального дизайна.

Решение:

Не стесняться и спросить у PM:

  • Почему изменили дизайн?
  • В первой итерации были нативные кнопки, где они?

Есть сомнения — задать вопрос.

Что может случиться:

  • 3) Разработчику не нравится дизайн.

Это хорошо, значит разработчику не всё равно, у него есть эмпатия к продукту.

Решение:

Подумать — зачем я это говорю?

Сформулировать и тезисно обосновать, что именно не нравится:

  • Нарушена логика UI в продукте.
  • Метафора иконки совсем неочевидна!

Крайний аргумент — Эстетически неубедительно.

Как ещё можно решить:
design6

Заносить задачи и пожелания в backlog и wishlist, самые удачные потом можно будет реализовать.

Третий этап — «Реализация дизайна».

Очень плотно работают дизайнер и разработчик.

Что происходит на данном этапе?

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

Что может случиться:

  • 4) Разработчик вдруг понял, что успевает сделать дизайн только на 70%.

Решение:

Успокоить дизайнера.

Попробовать найти ресурсы для выполнения.

Если это невозможно, предложить дизайнеру 2-3 варианта решения проблемы:

  • Прости, к релизу мы может сделать пока только через браузер, или вообще убрать.
  • С тебя — дизайн иконки и нарезка файлов.
  • Потом сделаем полноценную версию!

Что может случиться:

  • 5) Дизайнер неправильно подготовил файлы, а разработчик взял их в работу.

Ошибки в файлах:
design7

Решение:

Подробно и чётко рассказать, что Вам и как необходимо подготовить.

Объяснить дизайнеру особенности процесса разработки.

Поругать!

  • Для реализации фичи мне не хватает файлов для ретины и 3x.
  • Опять ты забыл!
  • Подготовь, и мы закроем задачу.

Не берите в работу файлы с ошибкой!

Четвёртый этап — «Фичефриз и дизайн-ревью».
Над данным этапом работают и менеджер, и дизайнер, и разработчик.

Дизайн-ревью это когда дизайнер смотрит на реализацию дизайна и сравнивает, то что хотел получить с тем, что получилось.

Что происходит на данном этапе?

  • Дизайн сделал →
  • Код написан →
  • Разработчики правят баги →
  • Дизайнер делает дизайн-ревью.

Что может случиться:

  • 6) Дизайнер вдруг полностью меняет интерфейс.

Что меняем?

Простые изменения заносим в Confluence, сложные изменения — не успеем! Если сложное изменение — идём к PM. Хорошо подумайте перед тем как брать на себя ответственность.

Что может случиться:

  • 7) PM прибежал и сказал делать новую фичу.

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

Объединитесь и примите решение вместе!

Что может случиться:

  • 8) Разработчик реализовал дизайн некорректно.

Некорректно это как:
design8

Как проверить:
design9

Почему?

  • 1) Ошибка разработчика — Давай-ка подвигаем пиксели.
  • 2) Ошибка дизайнера — Читай матчасть.

Не забывайте ставить задачи в Jira.

Хорошая идея, чтобы разработчик потратил час времени и написал методичку для дизайнера — Как готовить файлы.

Если кажется, что Вы художник:

Если Вам пришло вдохновение — отбросьте студию разработки.

Возьмите карандаш, бумагу, Sketch и начинайте творить.

В любой непонятной ситуации — не пишите код!

Если Вы придёте к дизайнеру с хорошей идеей — он это очень оценит!

Правила:

  • 1) Цель — крутой продукт!
  • 2) Правильно используйте инструменты!
  • 3) Уважайте чужой труд!
  • 4) Учите друг друга!
  • 5) Интересуйтесь параллельным миром!

Если всё получится будет вот так:
design10

Совет разработчикам и дизайнерам чаще общаться друг с другом.

Хороший совет для дизайнеров — читайте Human Interface Guidelines, причём по всем платформам.

Помарка — это рассказ о продуктовом дизайне, а не заказной разработке.

В этом процессе забыли аналитика и UX-проектировщика. Аналитик находиться до всех этих процессов, до продуктовых требований.

Дизайнер должен интересоваться аналитикой больше чем разработчик.

Про UX-проектировщика, во многих компаниях часто нет деления на дизайнера и UX-проектировщика, это делает один сотрудник.

Делайте классные продукты!

Подробнее в докладе «Дизайнер, разработчик, нет конфликта, нет драмы» techno.2gis.ru

Таких больших статей ещё не было, надеюсь Вам понравилось, если есть комментарии — я с радостью их прочитаю и учту!

Ещё поделюсь отличными новостями, меня позвали на собеседования в обе компании и этому я очень рад! Постараюсь получить два оффера!