Сложная простота: как делать удобный и практичный дизайн

[JOY]

Что важнее – оригинальный продукт или удобство в его использовании? Сколько прототипов нужно сделать, чтобы нарисовать понятный экран мобильного приложения? Партнер WM-Forum Евгений Мигачев – о том, как его компания находит ответы на эти вопросы.

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

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

Много раз – на одни грабли

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

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

Стив Джобс в 2009 году говорил в интервью журналу Fortune: «У всех нас были мобильные телефоны, и мы их ненавидели, настолько они были неудобны в использовании. Мы пообщались с нашими друзьями, и оказалось, что они тоже ненавидят свои телефоны. Все кругом ненавидели телефоны. И тогда мы подумали, что эти устройства могут стать куда более мощными и интересными».

Я также упоминал гибель целых экосистем. Например, один из основателей проекта Gnome Мигель Де Икаса считает, что Linux упустил шанс стать популярной пользовательской системой из-за Mac OS X (конечно, в числе прочего). И Linux, и Mac OS X – родственные Unix-системы, но при этом Apple позиционировала свою как «юникс с человеческим лицом». И хотя ни одна из систем не хуже другой, Mac OS X взял свое за счет удобства работы обычных пользователей.

Думаю, я вас убедил. Остался вопрос: что нужно делать, чтобы не попасть в такую ситуацию?

«Дизайн» не равно UX

В нашей культуре, как мне кажется, под дизайном зачастую подразумевается некое создание «красивостей». Дизайнер в России – оформитель, человек, способный ответить на запрос «сделай мне дорого и богато». В результате для разработки интерфейса нанимается, например, классический дизайнер, который, в первую очередь, видит задачу «сделать красиво и креативно». Ситуация осложняется еще и тем, что в России нет нормальной школы дизайна взаимодействия (дизайна интерфейсов). Самое близкое образование — это графический дизайн, веб-дизайн или промышленный дизайн. Да, многие интерфейсные дизайнеры пришли из графического дизайна. И столь же многие остались в своих же «классических» рамках. На самом деле современный дизайнер – это человек, способный мыслить гораздо шире шрифтов, цветовой палитры и пикселей на экране. Он думает о том, как будущий пользователь будет взаимодействовать с продуктом, обладает интуицией, логикой и здравым смыслом, позволяющими сделать нечто интуитивно понятное и удобное.

Опыт взаимодействия (User Experience, UX) – это ощущения, возникающие у человека при непосредственном взаимодействии с объектами окружающего мира. В более узком смысле – личное восприятие человеком функциональных и эмоциональных характеристик продукта или услуги в процессе использования. Очень часто UX упоминают вместе с UI (пользовательским интерфейсом), ставя между ними знак равенства.

Но графический (визуальный) дизайн и UX-дизайн – это две разные задачи, и чем больше проект, тем важнее доверить эти задачи разным специалистам, хоть и в одной команде. А с ростом сложности продукта необходима и дальнейшая специализация: пользовательские исследования, проектирование интерфейсов, визуальный дизайн, фронт-энд-активности и прочее.

Не изобретать велосипед

У графического дизайнера и UX-дизайнера разная мотивация: первый считает, что работа должна быть оригинальна, а вторичность порицается. У второго должен быть девиз: «Чем проще пользователю – тем лучше». А чаще всего пользователю проще то, к чему он уже давно привык. При проектировании интерфейсов дизайнер в подавляющем большинстве не изобретает с нуля, а берет существующие оптимальные решения и улучшает их. Поэтому, если вы не разделили обязанности, возникнет непонимание или даже конфликт: дизайнер часто начинает изобретать, вместо того, чтобы воспользоваться устоявшимися приемами.

Устоявшиеся решения работают, они привычны для пользователей и проверены опытом. Изобретать совершенно новый подход можно, только если ты абсолютно уверен, что он лучше существующих. Можно поиграть с анимацией, необычными карточками и таблицами, если у вас простое приложение с сотней аналогов, и вам нужно чем-то выделиться. Только нужно помнить, например, что Google Play при ранжировании приложения учитывает не только количество скачиваний, но и сколько человек это приложение потом удалили: чем меньше пользователей удалили приложение, тем лучше оно решает их задачу. Есть статистика, что если человек не разобрался, как работать с приложением в течение нескольких секунд (меньше минуты), то вероятность, что он его немедленно удалит, возрастает в десятки раз. А целых 12% активных пользователей, то есть самая «золотая» аудитория, проводит инвентаризацию своих приложений – скачивает новые и удаляет старые – ежедневно.

Например, в нашем мобильном приложении удаленного доступа Parallels Access, при всей его технологической сложности внутри, для основных функций всего два-три очень простых на первый взгляд экрана. Дизайнеру буквально нечем похвастать в своем портфолио. Для нас было крайне важным и создать что-то новое, и не учить пользователя, как со всем этим теперь работать. Чем естественней получается создать сервис, тем лучше. В идеале мы стремимся к тому, чтобы люди думали, что наши программы – это часть операционной системы. Чем однородней с системой, тем лучше. Parallels Desktop, Parallels Access – это прослойка между тем, что нужно пользователю и операционной системой. Приложение, как таковое, ему не нужно. Нашим пользователям нужен интуитивно понятный и удобный переход с Mac на Windows и обратно без перезагрузки компьютера. Чем меньше прослойка, тем лучше, в идеале лучше, чтобы ее вообще не было. Главное: интерфейс не должен мешать.

Прототипировать

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

Увы, визуализировав много разных вариантов, вы либо поймете, что первоначальные не будут работать, либо обнаружите, что под очевидным участники команды понимали совершенно разное. Да и какой совершенно новый проект запускается с четкими требованиями и задачами? Единицы. Чаще всего у команды есть только примерная идея того, как это должно работать.

При этом нужно быть готовым к тому, что 80%, а то и все 100% сделанных наработок и прототипов, на которые потрачены время, деньги и усилия разработчиков, могут быть выброшены в мусорную корзину. Достаточно вспомнить, как в Apple работали над созданием клавиатуры для iPhone: сделали около тридцати прототипов, и начали исследовать каждый из них на подопытных сотрудниках: давали набирать разные тексты, засекали время и проверяли количество ошибок. В итоге осталось два финалиста, один – это та клавиатура, которую вы сейчас видите в своем iPhone, а второй – где кнопок было в два раза меньше и на каждой кнопке было по две буквы. Интересно, что скорость печати на этой клавиатуре была почти в два раза выше при аналогичном с первой количестве ошибок. Тем не менее, казалось бы, бесспорный победитель был также выброшен в корзину. Когда начался второй этап исследований – на пользователях – оказалось, что эта клавиатура слишком для них необычна. От 29 прототипов, на которые были потрачены два года разработки, пришлось отказаться!

Мы для первой версии Parallels Access сделали более 40 прототипов различной функциональности (как должна себя вести мышка, курсоры, лупа), потратив на это примерно полгода. А в продукте в итоге осталась только половина.

Командная работа

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

- Конфликт интересов внутри команды разработчиков.
- Ограниченный бюджет и сжатые сроки вывода продукта на рынок.
- Узкая специализация членов проектной команды и закрытая информационная среда.

Конфликт интересов обычно возникает в разрозненных командах крупных компаний, где есть несбалансированные KPI. Решением может быть формирование плоской управленческой структуры, выделение команды проекта в отдельный бизнес-юнит, наделение менеджеров широкими полномочиями и командной ответственностью за результат. Когда «нет претензий к пуговицам, но есть вопросы ко всему костюму», стоит рассматривать ситуацию глубже. Возможно, внутри тлеет закрытый конфликт или существуют серьезные информационные разрывы. Часто решить ситуацию помогает парная работа дизайнера и разработчика, UX-дизайнера и product-менеджера. Можно складывать подобные паззлы в различных комбинациях, главное – на выходе получить понимание того, что за результат отвечает вся команда. Система мотивации также должна отражать этот подход.

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

В третьем случае (узкая специализация) стоит отметить, что данный подход прошел свой эволюционный путь по спирали. 10-20-30 лет назад программист объединял в себе все, что так или иначе было связано с компьютерами, системами связи, разработкой и так далее. Все занимались всем. Сейчас же все очень быстро развивается. Огромное количество технологий появляются каждый день. Что-то появляется, что-то умирает достаточно быстро. Цикл порой может быть в год-два. Например, с точки зрения пользовательского опыта или web-технологий, то, что сейчас считается мейнстримом, через три года может быть никому не нужно. Поэтому, с одной стороны необходимо повышать свои профессиональные навыки, глубоко разбираясь в своей области, с другой, нужно расширять свой кругозор и навыки командной работы. Дизайнер перестает быть просто двигателем пикселей, он своего рода творец будущих решений. Сегодня необходимо, чтобы дизайнер, архитектор, проектировщик, project-менеджер смотрели за рамки своей прямой функциональности. Интерфейс, упаковка, организационные аспекты, продажи, ценообразование, клиентский опыт, из всего этого складывается понимание бизнеса и потребностей пользователя. Крайне важно соотносить свое мироощущение с восприятием конечного потребителя. Поиск ответов на вопросы «кто», «что», «где», «когда», «почему», «как» поможет структурировать работу. Необходим системный подход к организации бизнес-процессов.

Продукт должен постоянно развиваться

Главная вещь, которую следует осознать: продукт, сервис или услуга никогда не являются окончательно завершенными. Более того, продукт не должен восприниматься единым мерилом ценности, поскольку необходимые для его создания техники также очень важны. Большинству UX-специалистов может быть сложно придерживаться строгих шагов и планов разработки, однако большинство рисков исключаются именно таким способом.

Тем не менее, во многих отношениях единственной константой этого процесса является постоянное изменение и так будет всегда. Если вы хотите создать свой продукт, то вам следует нацелиться на определение необходимых для этого методик, а также на постоянное улучшение общего результата. Для UX-дизайнеров полезен периодический обзор предыдущих, прежних проектов (провальных и успешных) для осознания того, чему они научились, и как этот опыт может использоваться в дальнейшей работе.

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

Где кончается проектирование и дизайн и начинается реальная жизнь какой-либо вещи, услуги, сервиса? Что важнее – продукт с оригинальными свойствами или же его дизайн? В поиске ответов на эти вопросы стоит ориентироваться на конкретного пользователя. Создаваемый продукт или услуга должны, прежде всего, решать конкретные существующие потребительские запросы. За решение проблем, с которыми люди сталкиваются каждый день, они готовы дорого платить. Если вы нашли то, что с первых минут решает поставленные задачи, в дальнейшем вы можете совершенствовать его свойства. Конечно же, хорошо, если у вас получается с самого начала делать удобные, красивые и практичные продукты, но ничто не мешает доводить их до идеала уже после появления на свет.

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

В качестве эпилога

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

Именно поэтому, крайне важно внимание к деталям. Нужно, чтобы вы, как владелец продукта или сервиса, лично, своими руками его потрогали, прислушались к своим ощущениям, сделали все, чтобы он не стал очередной «дверью Нормана».