Дизайнер Брейден Ковитц, который за свою карьеру поработал над многими
проектами Google (Gmail, Google Apps for Business, Google Spreadsheets,
Google Trends), а сейчас трудится партнером по дизайну в Google
Ventures, в своем блоге рассказал
о том, почему даже маленькие изменения могут сделать продукт
значительно лучше и как дизайнеру убедить в этом остальных членов
команды.
Подходит время релиза, всем в команде кажется, что продукт в порядке.
Он функционален, все работает как надо. И только дизайнеру кажется, что
было бы круто подвинуть вон ту кнопку еще на 3 пикселя влево. Но как
такое микроскопическое изменение может улучшить продукт? К тому же,
кнопки уже двигали перед прошлым релизом, и толком, вроде бы, ничего не
поменялось. Поэтому не лучше ли обсудить какую-нибудь оригинальную
масштабную идею и новые функции, которые хорошо бы добавить в будущем?
Как же дизайнеру убедить всех вокруг в том, что даже небольшие детали
могут оказать значительное влияние на конечный успех продукта? Дизайн не ради дизайна
Между функциональностью и восхитительным дизайном есть определенная
дистанция. Разработчики и те, кто отвечает за визуальное восприятие
продукта, могут мыслить разными категориями. Инженерам нужно развивать
продукт, добавляя в него интересные возможности и выпуская новые версии.
Вылизывание каждого пикселя в таком случае просто замедляет релиз и
воспринимается, как трата времени на ерунду. Поэтому дизайнеру
недостаточно просто сказать «Это выглядит круче». Нужно объяснить,
почему вся команда должна потратить свое время на реализацию этой
небольшой идеи.
![](http://static0.cmtt.ru/paper-media/design-details/ef70bdd8b86dfb455a45.jpg) Доверие
Клиенты оценивают онлайн-продукты по их внешнему виду, качеству текстов
и удобству взаимодействия с сайтом. Если для вашего бизнеса важно
доверие, то тогда дизайн для вас тоже очень важен. Ученые (в частности,
из Стэнфорда) проводили целые исследования, которые подтвердили связь между дизайном и доверием.
Такие проекты, как Mint, Square и Simple
проделали большую работу, чтобы создать качественный дизайн и завоевать
доверие пользователей. Каждый из этих стартапов начинал с нуля, их
продукты были никому неизвестны. Тем не менее, пользователи доверили им
свои финансовые данные и обработку платежей. Детали улучшают юзабилити
Обезьянка в логотипе MailChimp не может не вызвать улыбку, отсутствие
лишнего на главной странице Google даже как-то успокаивает, а отточенный
до мелочий стиль Apple восхищает. Все эти компании с помощью
дизайнерских деталей смогли добиться возникновения правильного
эмоционального отношения к бренду. Но почему это так важно?
Разум человека крепко связан с его эмоциональным состоянием. В
зависимости от настроения – хорошее оно или плохое — меняется и
восприятие проблем. Например, если человек не в духе и запутался в вашем
продукте, то вместо того, чтобы спокойно разобраться, может начать в
гневе кликать на все кнопки подряд, не получая эффекта и злясь еще
больше.
![](http://static0.cmtt.ru/paper-media/design-details/28302af50205cba21b30.jpg)
Когда у человека все хорошо, то весь мир вокруг похож на пазл, который
легко складывается - это же относится и к работе с интерфейсами разных
продуктов. То есть, фактически, дизайн, который вызывает положительные
эмоции, еще и улучшает юзабилити интерфейса! Упаковка багов
Если над вашим продуктом надо еще прилично потрудиться, прежде чем его
можно будет назвать законченным, то в такой ситуации, конечно, одно
маленькое изменение не осчатливит пользователей. Если на дороге
множество ям и ухабов, то засыпать одну яму явно недостаточно, чтобы
назвать дорогу ровной. Это незначительное изменение.
Но есть небольшой трюк: можно исправить выявленные баги в UI за один
спринт разработки. Если в вашей команде есть, например, день, которые
выделяется на исправление косяков в коде, то почему бы не применить ту
же практику к дизайну? Дизайнер вполне может заранее составить список
своих задач в баг-трекере и расставить им приоритет.
В день «Д» надо собраться с мыслями и пройтись по получившемуся списку.
Скорее всего, не удастся исправить все — это вполне нормально. Но
несколько улучшений, сделанных за день, сделают ваш продукт заметно
качественнее. Это отметят все, а когда работа явно видна, то убедеждать
окружающих в ее необходимости не приходится. Полировка продукта на последних этапах разработки
Ковитц приводит пример неудачного взаимодействия дизайнера и
разработчика из своей практики. Как-то раз они с коллегой-инженером
обсудили то, каким должен быть будущий продукт. На следующий день
Брейден выслал несколько мокапов. Но когда разработчик еще через день
показал, что у него получается, оказалось, что все совсем не похоже на
то, что рисовалось в воображении дизайнера.
В результате Ковитц высказал свои критические замечаия, что,
естественно, привело к тому, что инженер не стал больше хотеть с ним
работать и советоваться. Это в свою очередь еще больше сказалось на
качестве дизайна. Классический замкнутый круг.
![](http://static0.cmtt.ru/paper-media/design-details/1c89a1cced7f7c7d448c.jpg)
Но с опытом дизайнер понял, что ему лучше всего подключаться с
«вылизыванием» интерфейса тогда, когда 90% инженерных работ уже
выполнены. Так уже окончательно ясна функциональность продукта, и нужно
лишь немного причесать его внешний вид, чтобы все стало совсем
прекрасно.
Еще одна хорошая идея заключается в том, чтобы устанавливать ментальные
триггеры, подключая к этому инженеров. Например, дизайнер может
попросить их о чем-нибудь типа:
Эй парни, можете показать мне, что получилось, когда добьете эту штуковину, но перед ее релизом?
Этот подход позволяет отлаживать даже самые маленькие детали прямо в
процессе работы, но уже не отвлекая других членов команды. Айсберги кастомизации
Нарисовать уникальну кнопку в Photoshop очень просто — но это лишь
верхушка айсберга, видимая глазу. Под водой остается множество усилий,
которые необходимо приложить, чтобы все заработало, как нужно:
прописывание статусов (нажата кнопка или нет), избежание подсветки
текста по двойному клику, тестирование доступности, добавление
возможности размещение надписей справа-налево для клиентов из стран, где
это принято, и так далее.
Об этом всегда следует помнить, когда вы хотите отказаться от нативных
элементов управления. Например, использование Ajax потребует большей
работы, чем в случае обычной веб-страницы. Собственные мобильные меню
также реализовать сложнее, чем использовать стандартные их версии.
Если у вашей команды нет времени на дополнительные танцы с бубнами и
вычищение всех ошибок, лучше на первом этапе оставить скучные
стандартные нативные элементы управления, которые просто работают.
|