Дизайнер интерфейсов - страница 17

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

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

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

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

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

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

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

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

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

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

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