Добавить в цитаты Настройки чтения

Страница 9 из 10

Возможные проблемы. Чрезвычайно важный этап, над которым стоит хорошо подумать. Он может включать в себя как ошибки из-за невнимательности, так и непонимание интерфейса. Например, на первом этапе покупки билетов есть вероятность, что человек ошибется с выбором даты. Это критичная ошибка, а потому цель дизайна – помочь ее избежать. В данном случае не помешает несколько раз показать дату при поиске рейсов и перед оплатой. Таким образом, повышается вероятность, что пользователь заметит ошибку (особенно если помимо цифры вы добавите день недели). Возможное непонимание интерфейса решается тремя способами: упрощением, системой подсказок и сменой дизайнера. Стремитесь к первому и избегайте последнего. Мне удавалось находить до десяти потенциальных проблем на каждом этапе, и понимание таких вещей сильно упрощало дальнейшую работу. Благодаря этому все дизайн-решения подкрепляются конкретными причинами, а не случайно увиденными паттернами, и вы сможете аргументированно защищать их перед заказчиком и коллегами.

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

Таблица 1. Пример CJM

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

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

7. Работающий фреймворк

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

Фреймворк – структура, вокруг которой строятся элементы интерфейса.

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

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

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

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

7.1. Создание фреймворка





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

Скопировать решение и сказать, что так работает Google, – не вариант. Но можно найти проекты, которые решают схожие задачи, и перенять их опыт. Пусть не в точности, но какие-то полезные идеи найти вы сможете.

Рассмотрим, что важно учитывать при создании фреймворка.

Разберитесь, с чем вы будете работать. Это могут быть карточки, таблицы, картинки, статьи, графики. Заранее всё определив, вы сможете примерно понять, какая структура подойдет проекту.

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

Подумайте об устройствах, которые будут использоваться. Если предполагается значительный мобильный трафик, то следует заранее продумать адаптивный интерфейс. Недаром несколько лет назад была столь популярна концепция Mobile first, предлагающая сделать адаптивный дизайн для мобильных устройств и только после этого приступать к веб-версии.

Продумывая адаптив, заранее решите, как должна вести себя навигация. Самый популярный вариант – свернуть всё в бургерное меню. А что делать, если у него два уровня? В этом случае одно меню можно спрятать, а другое отображать в виде горизонтальной прокрутки. Всё зависит от конкретной задачи.

Делайте первые наброски на бумаге, так как в графическом редакторе трудно избежать перфекционизма и не уделять внимание мелочам. Ваш набросок не должен быть четким (мои вообще, кроме меня, никто не поймет). Главное – отобразить все свои идеи и выбрать от одной до трех наиболее перспективных. Не останавливайтесь на первой попавшейся, а подумайте еще. Многие полагают, что первая идея, пришедшая на ум, – правильная, хотя такая позиция больше смахивает на лень. Первая идея может оказаться лучшей, как и вторая, третья и четвертая. И чем больше их будет, тем лучше. Вполне возможно, в итоге вы соберете микс из нескольких идей, который и возьмете в работу.

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

При разработке фреймворка не нужно придумывать оригинальное решение, – конечно, если вы не ставите своей целью выиграть конкурс. В большинстве случаев лучше использовать работающую структуру, которая прошла проверку в реальном мире. Мы видим много интересных концепций на дизайнерских площадках, но редко встречаем что-либо похожее, скачивая приложение или открывая сайт. Сами подумайте, сделался бы аккаунт Apple популярным на Dribbble, если бы не имя компании? Скорее всего, он набрал бы несколько тысяч подписчиков, но не стал бы суперуспешным, как люди, проектирующие футуристические концепции. Возможно, что-то из этого и будет работать в дальнейшем, но задача дизайнера – решать задачи настоящего, думая о будущем, а не витать в облаках.

8. Поиск визуального стиля

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