{"id":10776,"title":"\u0411\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f \u044d\u0442\u043e\u043c\u0443 \u043a\u043e\u043c\u043f\u044c\u044e\u0442\u0435\u0440\u0443 \u0432 \u043e\u043a\u0435\u0430\u043d \u043f\u043e\u043f\u0430\u0434\u0451\u0442 \u043c\u0435\u043d\u044c\u0448\u0435 \u043f\u043b\u0430\u0441\u0442\u0438\u043a\u0430","url":"\/redirect?component=advertising&id=10776&url=https:\/\/vc.ru\/acer_russia\/347915-acer-vypustila-pervyy-noutbuk-iz-pererabotannogo-plastika&placeBit=1&hash=368c351f012741e124bb4bc6c0b9b05d5e0f9033fab83ea5e301424877f73936","isPaidAndBannersEnabled":false}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0
11 комментариев
Популярные
По порядку
Написать комментарий...
indievision

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

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

Ответить
8
Развернуть ветку
Антон Илларионов

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

Ответить
2
Развернуть ветку
Egor Komarov

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

Ответить
8
Развернуть ветку
Egor Komarov

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

Ответить
3
Развернуть ветку
Антон Илларионов

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

Ответить
2
Развернуть ветку
Dmytro Shvydkyi

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

Ответить
2
Развернуть ветку
Советский глобус

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

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

Ответить
2
Развернуть ветку
Собака Павлова

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

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

Ответить
0
Развернуть ветку
Собака Павлова

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

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

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

Ответить
0
Развернуть ветку
Анастасия Целуковская

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

Ответить
0
Развернуть ветку
Pykhtik

То о чем вы тут написали это та причина по которой я ушла после одного крупного проекта в Игровую индустрию. Прелесть игровой индустрии в том, что есть четкие цели всегда и зачастую клиент - это геймдизайнер, который точно знает что он хочет. Игроки же либо поддержат его и купят продукт либо нет. В игровых индустриях самое прекрасное это заимствование, зачастую они заимствуют игровые механики, а вместе с ними и пользовательские сценарии. Я стараюсь не делать здесь что-то инновационного так как в игровых интерфейсах в плане Юзабилити всё только только постепенно идёт в сторону оптимизации процессов, но игроки это воспринимают очень болезненно, когда это отклоняется от общепринятой нормы. Часто вижу истории в которых есть крутые решения для тех или иных сценариев, но их намеренно игнорируют и не берут потому что, игроки это не оценят. Но тут интерес в другом. По сути игрок видит интерфейс уже после покупки и это самое кайфовое, потому что тебе не нужны какие-то нейромаркетинговые схемы и аналитика, чтобы куда то там локус внимания направлять. Главная цель сделать опыт максимально приятным для игрока, чем я и занимаюсь уже 3 года. После веб/мобильных продуктов это истинное блаженство, работать не на маркетологов и продажи, а на положительный пользовательский опыт. 

Ответить
0
Развернуть ветку
Читать все 11 комментариев
«Инновации — это поле для сражений»

Как фуд-ритейл внедряет новые технологии.

Саид
Как заработать на проекте который не реализован и лежит в столе или NFT как способ заработка для архитекторов?

Вчера не без училий, но и не сильно долго - минут за 20-30 я делала свой первый #NFT который посвящен перезапуску депрессивных территорий с помощью средств ландшафтной архитектуры на платформе #opensea из одного из проектов которые лежали, что называется, "в столе". Работа над проектом если сравнивать трудозатраты условно длится месяц (может и…

Предпринимательский стаж и кредитная история больше не работают

15 лет предпринимательского стажа, «зелёная» кредитная история и отсутствие действующих кредитов вдруг в один момент стали обесценены. Всё это теперь прах и не имеет значения.

«Холакратия, любимые мемчики и прозрачность»: программист о работе в Точке, моделинге и запуске треков на Spotify

Точка — это про людей. Про сотрудников, которые создают удобный банк для бизнеса. Мы запускаем серию интервью с нашей командой, чтобы рассказать, как у нас всё устроено.

Авито потеряла посылку и не возвращает деньги

21 декабря 2021 года решил заказать на авито куклу в качестве подарка. Товар сразу оплатил вместе с авито доставкой(boxberry), продавец в этот же день отправил посылку, дело оставалось за малым - просто подождать. Для заметки, я с продавцом нахожусь на расстоянии в 15-20 км.

Как пандемия изменила рынок онлайн-страхования

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

Статус бота Veles
Токсичная маркетинг-тусовка: как у номинального директора по маркетингу Самолета подгорело от нашего кейса

Наш c Digital Bands кейс про продажу квартир на PornHub завирусился после публикации на VC. По сути мы были первопроходцами: до нас никто не продавал недвижимость на порносайтах. Получили награду, опубликовали кейс — и хапнули негатива от коллег по цеху и приближенных к маркетингу. Но одно дело — комментарии среднестатистического спеца под…

В Москве появился фонд, инвестирующий в перспективные транспортные проекты

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

Яндекс.Директ меняет формат работы корректировок в Конверсионных стратегиях. «Нас не просили, но мы сделали!»

В конце Декабря 2021-го года Яндекс.Директ анонсировал изменение формата работы корректировок ставок для кампаний с конверсионными стратегиями. Теперь выставленная корректировка будет влиять не на стоимость клика, а на конечную стоимость конверсии. Что это, и как это повлияет на эффективность и окупаемость рекламы — разберём сегодня в статье.

null