Дизайнер Брейден Ковитц, который за свою карьеру поработал над многими проектами Google (Gmail, Google Apps for Business, Google Spreadsheets, Google Trends), а сейчас трудится партнером по дизайну в Google Ventures, в своем блоге рассказал о том, почему даже маленькие изменения могут сделать продукт значительно лучше и как дизайнеру убедить в этом остальных членов команды.
Подходит время релиза, всем в команде кажется, что продукт в порядке. Он функционален, все работает как надо. И только дизайнеру кажется, что было бы круто подвинуть вон ту кнопку еще на 3 пикселя влево. Но как такое микроскопическое изменение может улучшить продукт? К тому же, кнопки уже двигали перед прошлым релизом, и толком, вроде бы, ничего не поменялось. Поэтому не лучше ли обсудить какую-нибудь оригинальную масштабную идею и новые функции, которые хорошо бы добавить в будущем?
Как же дизайнеру убедить всех вокруг в том, что даже небольшие детали могут оказать значительное влияние на конечный успех продукта?
Дизайн не ради дизайна
Между функциональностью и восхитительным дизайном есть определенная дистанция. Разработчики и те, кто отвечает за визуальное восприятие продукта, могут мыслить разными категориями. Инженерам нужно развивать продукт, добавляя в него интересные возможности и выпуская новые версии. Вылизывание каждого пикселя в таком случае просто замедляет релиз и воспринимается, как трата времени на ерунду. Поэтому дизайнеру недостаточно просто сказать "Это выглядит круче". Нужно объяснить, почему вся команда должна потратить свое время на реализацию этой небольшой идеи.
Доверие
Клиенты оценивают онлайн-продукты по их внешнему виду, качеству текстов и удобству взаимодействия с сайтом. Если для вашего бизнеса важно доверие, то тогда дизайн для вас тоже очень важен. Ученые (в частности, из Стэнфорда) проводили целые исследования, которые подтвердили связь между дизайном и доверием.
Такие проекты, как Mint, Square и Simple проделали большую работу, чтобы создать качественный дизайн и завоевать доверие пользователей. Каждый из этих стартапов начинал с нуля, их продукты были никому неизвестны. Тем не менее, пользователи доверили им свои финансовые данные и обработку платежей.
Детали улучшают юзабилити
Обезьянка в логотипе MailChimp не может не вызвать улыбку, отсутствие лишнего на главной странице Google даже как-то успокаивает, а отточенный до мелочий стиль Apple восхищает. Все эти компании с помощью дизайнерских деталей смогли добиться возникновения правильного эмоционального отношения к бренду. Но почему это так важно?
Разум человека крепко связан с его эмоциональным состоянием. В зависимости от настроения - хорошее оно или плохое - меняется и восприятие проблем. Например, если человек не в духе и запутался в вашем продукте, то вместо того, чтобы спокойно разобраться, может начать в гневе кликать на все кнопки подряд, не получая эффекта и злясь еще больше.
Когда у человека все хорошо, то весь мир вокруг похож на пазл, который легко складывается - это же относится и к работе с интерфейсами разных продуктов. То есть, фактически, дизайн, который вызывает положительные эмоции, еще и улучшает юзабилити интерфейса!
Упаковка багов
Если над вашим продуктом надо еще прилично потрудиться, прежде чем его можно будет назвать законченным, то в такой ситуации, конечно, одно маленькое изменение не осчатливит пользователей. Если на дороге множество ям и ухабов, то засыпать одну яму явно недостаточно, чтобы назвать дорогу ровной. Это незначительное изменение.
Но есть небольшой трюк: можно исправить выявленные баги в UI за один спринт разработки. Если в вашей команде есть, например, день, которые выделяется на исправление косяков в коде, то почему бы не применить ту же практику к дизайну? Дизайнер вполне может заранее составить список своих задач в баг-трекере и расставить им приоритет.
В день "Д" надо собраться с мыслями и пройтись по получившемуся списку. Скорее всего, не удастся исправить все - это вполне нормально. Но несколько улучшений, сделанных за день, сделают ваш продукт заметно качественнее. Это отметят все, а когда работа явно видна, то убедеждать окружающих в ее необходимости не приходится.
Полировка продукта на последних этапах разработки
Ковитц приводит пример неудачного взаимодействия дизайнера и разработчика из своей практики. Как-то раз они с коллегой-инженером обсудили то, каким должен быть будущий продукт. На следующий день Брейден выслал несколько мокапов. Но когда разработчик еще через день показал, что у него получается, оказалось, что все совсем не похоже на то, что рисовалось в воображении дизайнера.
В результате Ковитц высказал свои критические замечаия, что, естественно, привело к тому, что инженер не стал больше хотеть с ним работать и советоваться. Это в свою очередь еще больше сказалось на качестве дизайна. Классический замкнутый круг.
Но с опытом дизайнер понял, что ему лучше всего подключаться с "вылизыванием" интерфейса тогда, когда 90% инженерных работ уже выполнены. Так уже окончательно ясна функциональность продукта, и нужно лишь немного причесать его внешний вид, чтобы все стало совсем прекрасно.
Еще одна хорошая идея заключается в том, чтобы устанавливать ментальные триггеры, подключая к этому инженеров. Например, дизайнер может попросить их о чем-нибудь типа:
Эй парни, можете показать мне, что получилось, когда добьете эту штуковину, но перед ее релизом?
Этот подход позволяет отлаживать даже самые маленькие детали прямо в процессе работы, но уже не отвлекая других членов команды.
Айсберги кастомизации
Нарисовать уникальну кнопку в Photoshop очень просто - но это лишь верхушка айсберга, видимая глазу. Под водой остается множество усилий, которые необходимо приложить, чтобы все заработало, как нужно: прописывание статусов (нажата кнопка или нет), избежание подсветки текста по двойному клику, тестирование доступности, добавление возможности размещение надписей справа-налево для клиентов из стран, где это принято, и так далее.
Об этом всегда следует помнить, когда вы хотите отказаться от нативных элементов управления. Например, использование Ajax потребует большей работы, чем в случае обычной веб-страницы. Собственные мобильные меню также реализовать сложнее, чем использовать стандартные их версии.
Если у вашей команды нет времени на дополнительные танцы с бубнами и вычищение всех ошибок, лучше на первом этапе оставить скучные стандартные нативные улементы управления, которые просто работают.
А как в вашей команде решаются вопросы о том, что и когда надо добавлять/подкручивать в продукте?