Проектируем интерфейс на основе карты — начало

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

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

Статья большая, поэтому я кратко освежу в голове ее содержимое.

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

Решаемая задача:

Когда я работаю — получаю довольно много писем и сообщений в скайпе, которые отвлекают меня и мешают выполнить текущую задачу. При этом среди писем есть такие, на которые точно надо ответить и я в принципе могу их отложить, но боюсь их пропустить. А есть и такие, которые требуют срочного ответа. Аналогично с мессенджерами.
Я хочу иметь инструмент, который поможет мне настроить, как я хочу провести день и что сделать, подскажет, как обходиться с каждым приходящим сообщением.
Так, чтобы в результате я плотно, сосредоточенно и комфортно работал, сохраняя фокус на главном; выполнил много работы; чтобы важные письма/сообщения получили ответ; чтобы безотлагательные письма/сообщения получили немедленный ответ; чтобы остальная почта и переписка была разобрана, но не отвлекала от основных задач.

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

Давайте наконец начнем проектировать.

В прошлый раз я уже сделал первый подход к структуре моего приложения:

Как превратить их в конкретные экраны? Здесь я буду (и вам рекомендую) использовать концепцию атомарного дизайна.

В нем предлагают использовать:

отдельные контролы (например, кнопка) в качестве “атомов”;
простые группы элементов (например, строка поиска) — в качестве “молекул”;
блоки/сложные группы элементов (например, хедер) — в качестве “организмов”;
шаблоны — прототипы или макеты, в которых присутствуют все блоки, необходимые на данной странице;
страницы — конкретная ситуация применения шаблона, отдельный кейс. Например, "главная страница, в ситуации, когда у нас нет текущей акции, опубликовано 4 новости, есть 15 товаров со скидками, а пользователь смотрит с мобильного".

Это довольно удобная модель. Я ниже покажу, как это складывается в конкретное решение.

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

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

Итак, накидаю схему своего решения:

Каждая колонка — это шаг пользовательского сценария. Возможно, я потом добавлю в конце еще один шаг.

Синие прямоугольники — страницы или шаблоны.

Белые прямоугольники — это "организмы" (крупные и сложные группы контролов)

Буллиты — "атомы" (конкретные контролы) или "молекулы" (простые группы контролов).

Давайте поглядим один из шагов покрупнее и немного доработаем его "организмы" и "атомы".

Это шаг сценария, в котором пользователь разбирается с письмом/сообщением.

Как пользователь в принципе может поступить?

временно проигнорировать письмо/сообщение и вернуться к рабочей задаче,
поставить про это письмо таску и вернуться к рабочей задаче,
ответить немедленно.

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

Если же пользователь надолго “залипнет” на письме — напомнить о том, что задача ждет.

Для этого я хочу использовать два экрана:

Decision helper
Notification

И вот в первом из них есть небольшой избыток функционала:

Пункты, выделенные красным, можно безболезненно убрать. Почему? Я хочу максимально собрать пользователя на простом и быстром решении вопроса “что делать с письмом/сообщением?”. Это решение должно происходить очень быстро, и пользователь должен мгновенно возвращаться к основной задаче. В этом и планируется ценность приложения.

Исходя из этого, экран облегчается и шаг сценария начинает выглядеть вот так:

Не исключено, что и нотификацию можно сократить, но я хочу это решить уже “на месте”, когда буду рисовать прототип.

Начинаем рисовать

Я спроектирую 2-3 шага сценария, этого будет достаточно, чтобы проиллюстрировать подход.

Выберу шаги
Соберу референсы (хорошие примеры интерфейсов, на которые можно опереться) с dribbble.com , плюс сделаю скриншоты тех гайдлайнов MacOS, которые могу мне понадобиться.
Накидаю “организмы” в каждом шаге
Заполню их “молекулами” и “атомами”
Прорисую “молекулы” и “атомы”
Доработаю (в этом пункте может скрываться бездна всего)

Итак, выбираю шаги:

И начинаюю собственно проектировать.

Шаг 1, “узнать о концепции”.

Здесь пользователь должен познакомиться с приложением и его захотеть.

Собираю референсы и накидываю “организмы” (основные блоки):

Слева я продублировал шаг сценария, и общую структуру, чтобы не закопаться в процессе и не забыть, зачем делается этот шаг. Справа — часть собранных мной образцов. В центре — накиданн��е мной “организмы”:

Как я пришел именно к такой схеме страницы?

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

Чтобы это сделать, нужно рассказать о решаемых приложением проблемах и дать Call to action.

Мое приложение поможет пользователю “отмахиваться” от писем и мессендежров, и успешно выполнять рабочие задачи. Про это и будет текст. Так родился основной блок (под шапкой) и три блока ниже.

Более подробно этот шаг я сейчас проектировать не буду, и сосредоточусь на следующих шагах (там больше именно интерфейсов).

Шаг 2. Настроить рабочую сессию.

На этом шаге пользователь устанавливает приложение, и настраивает рабочую сессию.

Установку приложения я пока порежу, предположив, что это будут обычные скрины MacOS. А вот с настройкой сессии надо разобраться, это один из ключевых интерфейсов.

Как-то у меня в голове не укладывается этот визард, попробую описать работу с ним, как историю. Я как пользователь собираюсь 2-3 часа плотно поработать. Опасаюсь, что меня будут отвлекать. Отключить при этом уведомления в почте и мессенджере не готов, там может быть что-то важное (например, у разработчиков может быть какой-то срочный вопрос-блокер). Соответственно, хочу указать время моей работы, задачи, критерии выполнения, и настроить приложение, чтобы оно помогло мне отвлекаться только на неотложные письма-сообщения, фиксировать (писать заметки или таски) важные, и временно игнорировать остальные.

Какие “атомы/молекулы” в связи с этим мне нужны в “организме” под названием “виззард”?

Снова собираю референсы, бОльшая часть — просто скрины гайдлайнов MacOS (в этот раз я постараюсь максимально придерживаться стандартных контролов)

Набрасываю организмы и молекулы-атомы моего этого шага.

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

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

Дальше я спроектирую конкретные контролы, приведу в порядок акценты, цвета, отступы, типографику, оси взаимодействия и прочие нюансы, касающиеся высокодетализированного проектирования.

Пока все, спасибо за внимание!

Присылайте мне ваши вопросы и соображения, и я буду дополнять эту статью.

И не забывайте подписываться на мой канал о UX