Дизайн
Собака Павлова

Четыре фазы разработки интерфейса: что обсуждать с заказчиком, когда нет даже картинок?

Мы делаем дизайн интерфейсов. Заказчик приходит к нам за дизайном и в основном готов обсуждать только его. То есть картинки. Но разработка интерфейса — долгий процесс, и в нем есть много промежуточных документов. Да и сами дизайн-макеты не сразу приобретают финальный вид — к нему еще нужно прийти в результате обсуждений.

То, что придется обсуждать промежуточные состояния дизайна и документы, — для многих заказчиков сюрприз на старте. Поэтому некоторые торопятся поскорее перейти к UI — там-то они уже чувствуют себя увереннее, потому что результат перед глазами. Из-за такой спешки мы не получаем достаточной обратной связи в процессе и работаем в условиях нехватки информации. Из-за этого финальные макеты могут получиться хуже — легко упустить какие-то ситуации, забыть про редкие сценарии, если их не проговаривать.

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

Три предупреждения, чтобы никто не обвинил «Собаку Павлову» в категоричности:

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

  • мы работаем по аджайлу и без жесткого планирования, поэтому процессы на каждом проекте отличаются — статья описывает общую картину;

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

Авторы материала — UX-дизайнеры Ахнаф Кунакулов и Антон Илларионов.

Фаза синхронизации и сбора требований

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

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

  • бизнес-требования;

  • портреты и роли пользователей;

  • жизненные ситуации пользователей;

  • модель информационных ожиданий.

Чтобы определиться с требованиями, мы общаемся с заказчиком и пользователями. Из головы ничего не берем. Роль заказчика на этом этапе — поставлять информацию и проверять, правильно ли мы все зафиксировали.

Роль заказчика на этом этапе — поставлять информацию и проверять, правильно ли мы все зафиксировали.

После этого приступаем к концептуальному проектированию и составляем:

  • список сценариев и варианты использования;

  • карту фокусов;

  • карту навигации.

Эти документы могут быть текстами, эскизами, диаграммами или таблицами — по ситуации.

Из них действительно стоит обсуждать только список пользовательских сценариев. Если мы разрабатываем профессиональный интерфейс, часто у заказчика уже задокументированы рабочие процессы, и мы их просто перерабатываем.

Следующая тема для обсуждения — связность истории

А вот карта фокусов, карта навигации и варианты использования — это высокоуровневые промежуточные документы, которые нужны дизайнеру для работы. Они описывают результат. Не с каждым заказчиком нужно их обсуждать. Если пройти мимо, трагедии не случится и дизайн хуже не станет.

Параллельно мы прорабатываем первые концепты — на бумаге, на доске или в Figma. И это именно то, что обсуждать надо. Только главное здесь — не расположение кнопок и меню. Есть вещи поважнее.

Что обсуждаем:

  • связность истории, воплощенной в концепте;

  • отвечает ли история портретам целевой аудитории;
  • детали истории;
  • стартовые точки ключевых сценариев;
  • чем пожертвовали в концепте.

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

Фаза детализации

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

Это основное требование этапа. И проверять, насколько мы его выполнили, нужно на высокодетализированном прототипе. Только так мы сможем взглянуть на интерфейс под разными углами и найти в нем узкие места. Высокая детализация нужна для проверки надежности, а не для красоты. Бывает, что прототип при этом не сильно похож на финальный дизайн — мы используем готовые UI-киты, чтобы ускорить и удешевить разработку, и они могут здорово отличаться от фирменного стиля заказчика. Это не критично.

Высокая детализация нужна для проверки надежности интерфейса, а не для красоты

По мере разработки дизайна заказчик должен:

  • следить за разнообразием отрисованных ситуаций;

  • просить объяснить интерфейсные решения;

  • настаивать на фиксации всех комментариев;
  • обсуждать отклонения от базовых сценариев.

Мы говорим «по мере разработки», потому что процесс растянут во времени. Мы прорабатываем сценарий, показываем прототип и обсуждаем. Обычно два раза в неделю. Затем переходим к следующему сценарию. Если забить и ждать, пока будет готов весь высокодетализированный прототип, можно упустить что-то очень важное. Или сделать не так, как ожидал заказчик.

Фазу можно считать пройденной, если мы с заказчиком уверены, что прототип позволяет выполнить все основные и альтернативные сценарии и в нем любым способом можно решить пользовательские задачи.

Фаза финализации

Ну, теперь-то уж мы добрались до самого-пресамого дизайна и можем обсуждать красоту? Да, но не сразу. Есть вопросы поважнее.

Третья фаза процесса посвящена проработке UI: мы подбираем подходящие паттерны, думаем про компоновку элементов интерфейса. Наша цель — с помощью интерфейсных элементов упростить и ускорить выполнение пользовательских задач.

То есть работа не сводится только к раскрашиванию.

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

Параллельно нужно следить, насколько полно дизайнеры обрабатывают комментарии заказчика, в том числе и прошлые. Они не должны воплощать все, могут и отклонять некоторые замечания, главное, чтобы ни о чем не забывали.

Одновременно обращаем внимание и на графическую часть:

  • визуальную иерархию;
  • типографику, иконки и отступы;

  • цветовую схему.

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

Если у заказчика есть фирменный стиль, используем его.

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

Фаза сдачи-приемки

Дизайн вроде бы готов. Но расслабляться рано. Его еще надо принять.

Перед этим нужно проверить и обсудить, не забыли ли чего дизайнеры или сам заказчик. Такое бывает, хоть и не часто. На что смотреть:

  • в финальных макетах проработаны все состояния;

  • файл подготовлен для передачи разработчикам;

  • в файле подготовлен UI-кит;
  • дизайнеры подготовили документацию.

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

Вместо вывода

Роль заказчика на проекте — поставлять информацию и обсуждать результаты в виде документов, эскизов, диаграмм, прототипов и, наконец, финальных макетов. Он становится частью команды и должен эту команду постоянно сопровождать: критиковать, спорить, объяснять и договариваться.

Если заказчик пропустит любую из фаз, это приведет к расхождению ожиданий и пробелам в интерфейсе. У нас такое бывает. Конечно, все можно доделать, исправить или переделать. Но выйдет дороже. И для этого все равно придется пройти каждую фазу.

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

{ "author_name": "Собака Павлова", "author_type": "self", "tags": ["\u0438\u043d\u0442\u0435\u0440\u0444\u0435\u0439\u0441\u044b","\u0434\u0438\u0437\u0430\u0439\u043d","ux"], "comments": 10, "likes": 35, "favorites": 174, "is_advertisement": false, "subsite_label": "design", "id": 197039, "is_wide": false, "is_ugc": true, "date": "Fri, 15 Jan 2021 14:56:12 +0300", "is_special": false }
Создать объявление Отключить рекламу
Маркетинг
Как «Пятёрочка» с помощью Perfluence через микроблогеров привлекла 18 000 новых клиентов доставки
«Пятёрочка Доставка» запускалась в феврале 2020 года на Юго-западе Москвы. Пандемия и режим самоизоляции стимулировали…
0
10 комментариев
Популярные
По порядку
Написать комментарий...
8

Хорошая статья, часто читаю их у вас на сайте. Очень нравится ваш подход, да и кейсы тоже. 

Работаю в компании для которой делаю внутренние сайты. При разговоре о пользовательских сценариях и какой-то стратегии развития сайта, все остается на этапе расплывчатых фраз и полного нежелания разбираться во всем этом, и вечным вопросом — «картинки-то когда покажешь?» Стараемся вместе с программистом углубиться и распутать клубок того как все устроено, но очень тугая обратная связь демотивирует полностью.

Ответить
2

Спасибо! Приятно, что оценили)
Да, есть такой момент, сложно обсуждать абстрактные вещи. Поэтому результатом каждого этапа должна быть какая-то осязаемая сущность (карта, таблица, гуглдок и т.п.) Презентуете, а потом отдаете на комментирование, не забыв обозначить сроки.

Ответить
8

- что обсуждать с заказчиком, когда нет даже картинок?
- предоплату

Ответить
3

Вообще молодцы. Почитал ваш блог, круто делаете. Так держать!
Правда дизайн блога в стиле Артемия Лебедева 2007 года ) 

Ответить
2

Спасибо)
И круто, что разгадали наш художественный замысел в плане дизайна ;))

Ответить
2

Отличная статья, много интересного, спасибо!

Ответить
2

Люблю Собаку, жаль, вы редко пишите, надо исправлять :)

Даёшь больше практических разборов, кейсов и аналитики!

Ответить
0

Спасибо! На прошлой неделе выложили на своем сайте крутой кейс. Почитайте, если пропустили: https://sobakapav.ru/portfolio/alfa-arm

Мы сюда не можем выкладывать все наши материалы. Особенно, кейсы. Так что лучше всего следить за нами в телеге :)

Ответить
0

*случайно написали в общий тред, это ответ на комментарий Андрея Андреевича :)

Спасибо! На прошлой неделе выложили на своем сайте крутой кейс. Почитайте, если пропустили: https://sobakapav.ru/portfolio/alfa-arm

Мы сюда не можем выкладывать все наши материалы. Особенно, кейсы. Так что лучше всего следить за нами в телеге.

Ответить
0

ЦЕЕЕНЫ!!!! НАПИШИТЕ ПРО ЦЕНУ ПРАВОК!!!! Пожалуйста! Очень актуальный вопрос!

Ответить

Комментарии

null