Почему вам следует пододвинуть ту кнопку на 3 пикселя влево

Как дизайнеру-перфекционисту не выбесить программистов

Когда продукт близок к запуску, я становлюсь перфекционистом. Любой невыровненный элемент или неудобное взаимодействие — как бельмо на глазу. Всегда найдётся с дюжину мелких ошибок внедрения дизайна, которые отвлекают меня каждый раз, когда я на них натыкаюсь. Как будто всё поломалось.

Но для остальной команды продукт выглядит нормально. Он работает. Они спрашивают: «Улучшит ли наш продукт смещение этой кнопки на 3 пикселя?» И спорят: «Когда мы в прошлый раз исправили мелкий баг с дизайном, для продукта не было никакой разницы». И команда принимается за следующую большую идею или набор фич.

Если вы похожи на меня, то вы понимаете, как это расстраивает. Как дизайнеры мы несём ответственность за качество взаимодействия от начала и до конца. Но в то же время мы находимся во власти наших команд. Мы можем создать красивый и сложный дизайн с восхитительными деталями, но мы не можем всё это разработать, протестировать и выложить.

Как нам убедить инженеров и других коллег внимательно относиться к мелочам в дизайне? Я много боролся с этим. И вот, что я понял.

Это не дизайн ради дизайна

Дизайнеры понимают разницу между функциональным и красивым, поэтому мы одержимы деталями (littlebigdetails.com). Но это очень важный компромисс между совершенствованием дизайна и созданием нового функционала: проработка деталей зачастую означает более медленное движение вперёд.

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

Повышает доверие

Клиенты судят о надёжности онлайновых продуктов, оценивая визуальный дизайн, тексты и взаимодействия. Если вашему бизнесу важно доверие клиентов, то детали дизайна тоже должны стать важными. Посмотрите научную литературу на тему «дизайн интерфейса и доверие» или взгляните на Stanford’s Web Crediblity Project.

Mint, Square и Simple провели великолепную работу по совершенствованию деталей и завоеванию доверия клиентов. В начале пути они были непроверенными продуктами, но клиенты доверили им финансовую информацию, проведение платежей и защиту аккаунтов.

Улучшение юзабилити

Я всегда улыбаюсь, смотря на логотип MailChimp. Отсутствие шума на главной странице Google умиротворяет. Лощёные, попиксельно выверенные интерфейсы Apple восхитительны. У них всё в порядке с деталями, и это создаёт положительное эмоциональное состояние, но почему это имеет значение?

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

Если мы счастливы, работа с интерфейсом воспринимается как игра. Мир — похож на головоломку, а не поле битвы. И если мы где-то запнёмся, мы скорее постараемся разобраться и найти другие пути к цели. На эту тему есть целая книга Дона Нормана «Эмоциональный дизайн». Важная мысль: проработанные детали могут вызвать позитивные эмоции, которые реально сделают продукт более простым в использовании.

Группируйте работу

Если вашему продукту требуется много полировки, отдельное исправление не принесёт особой радости вам или вашим клиентам. Если вся дорога в ямах, устранение отдельной ямы не сделает дорогу ровной — вы даже не заметите разницы!

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

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

Полируйте в процессе разработки

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

Я ною, жалуюсь, указываю на все ошибки, это совсем не весело. И в следующий раз инженер уже не хочет, чтобы я давал обратную связь. Качество ухудшается, и я расстраиваюсь всё больше. Путь в никуда.

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

Также я пытаюсь встраивать триггеры, благодаря которым смогу дать обратную связь до того, как инженеры закончат задачу и сменят контекст. Я говорю: «Позови меня, как соберёшься заливать результат». Таким образом мы можем пройтись по всем небольшим правкам, пока все файлы открыты и не залиты в репозиторий.

Избегайте айсбергов кастомизаций

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

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


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

Интересно, как команды определяют нормы качества? Как вы создаёте культуру, в которой команда может быстро договориться, надо ли выделять больше времени на полировку дизайна? Что сработало в вашем случае? Что нет? Давайте обсудим?


Понравилось — подписывайтесь


Статью «Why you should move that button 3px to the left» написал Брейден Ковиц 29 ноября 2011 года. Брейден — партнёр по дизайну в Google Ventures.

Перевёл Антон Григорьев по лицензии Creative Commons Attribution-NonCommercial License.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.