Четыре фазы разработки интерфейса

Мы делаем дизайн интерфейсов. Заказчик приходит к нам за дизайном и в основном готов обсуждать только его. То есть картинки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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