Почему уникальные интерфейсы мешают пользователям Статьи редакции

Федор Подрезов, руководитель UI/UX-департамента Parallels, написал для ЦП колонку, в которой рассказал, почему при разработке интерфейсов не нужно пытаться создавать уникальные решения.

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

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

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

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

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

Windows на iPad — обычное дело

Когда мы начали работу над нашим приложением удаленного доступа Parallels Access, то хотели сделать интерфейс таким, чтобы пользователю не нужно было объяснять, как оно работает. Строго говоря, Parallels Access лишь формально приложение для удаленного доступа. Конкурентные продукты того периода были типичными remotedesktop-приложениями, основной сценарий которых — emergency-доступ (необходимость доступа во время аварийных ситуаций).

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

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

К тому же, десктопное приложение, как правило, существенно сложнее функционально, чем аналогичное мобильное, с соответствующе более сложным интерфейсом. Перед нами стояла задача сделать так, чтобы Word, Excel, PowerPoint и прочие сложные десктопные приложения воспринимались при работе с мобильного устройства так, как будто они для него и разрабатывались.

То есть, как такового приложения Parallels Access для пользователя почти и нет: есть Word, Excel, PowerPoint-презентация для босса, фотки из отпуска, фильмы в компьютерной медиатеке и т.д. Дизайн сводится не к отрисовке экранов, как это многими воспринимается, а к решению задачи предоставления пользователю всего этого. Дизайнеру потом особо нечего положить в портфолио, все промежуточные экраны максимально сокращены.

Три с половиной скриншота — вот и все приложение. Казалось бы, где тут полтора года твоей работы? Но вот эта простота — и есть большое достижение, а пользователю, в конечном итоге, плевать на интерфейс, он не на него смотреть пришел.

Разбор полетов при создании Parallels Access

Вначале казалось, что достаточно сделать разрешение удаленного экрана в 1024 пикселя (как на iPad), а ярлыки удаленных приложений положить на хоум-скрин мобильного устройства вместе с остальными мобильными приложениями (как ссылки в Safari). Переключаться между удаленными приложениями пользователь будет при помощи родного механизма, так же, как между обычными приложениями. Оказалось, что перетащить себе на хоум-скрин ярлыки могут только гики.

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

Запущенное удаленное приложение должно открываться в полноразмерном режиме и работать как нормальное, «местное» приложение. Это означает — реагировать на все действия, которые пользователь привык делать на планшете: когда двигаешь пальцами — должно скроллиться, когда тапаешь — должно кликаться, при двойном тапе — выделяться, когда тапаешь и держишь — появляться контекстное меню, и так далее.

Эти вещи должны напрямую транслироваться в действия на удаленном хосте, и нужно было «перевести» ПК и Mac, что тап — это у нас будет клик, двойной тап по тексту — двойной клик для выделения, двойной тап по файлу — запуск файла. То есть уже надо было понимать, что находится под курсором, где сейчас пользователь, и в зависимости от этого по-разному себя вести. А некоторые вещи вообще нельзя было нормально сделать, к примеру, drag&drop, потому что этой функции в таком виде не существует на планшете или телефоне. Значит, нужно было ее придумывать с нуля, а лучше — взять готовое решение и адаптировать под себя.

Мы взяли за образец существующую на iPad линзу для работы с текстом (позже этот прием использовали для Android). Это когда палец задерживается на каком-то месте, она позволяет очень точно куда-нибудь нажать или выбрать элемент, и сделали максимально похожую, использовав ее и для drag&drop, и вообще для точного позиционирования.

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

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

Далее есть приложения и файлы, а у приложений есть окна. И вся эта структура находится внутри одного мобильного приложения — Parallels Access. В результате мы остановились на супер-простой системе с тремя по очереди идущими экранами: экран с двумя хостами на странице (это наиболее типичная ситуация, обычно у пользователя есть домашний и рабочий компьютеры). Когда пользователь кликает на один из них, идет стандартное установление соединения с хостом, которое пользователь даже не видит, затем происходит аутентификация и пользователь попадает на экран с приложениями этого хоста, так называемый App Launcher. Видя такой экран, сразу понятно — тыкай в приложение, оно запустится.

Умный алгоритм за пользователя наполняет этот экран первоначальными приложениями (50% пользователей больше никаких ярлыков на него не добавляет, хотя такая возможность есть). Пользователь тапает на приложение и получает свою сессию удаленной работы. Итого — всего два шага, прежде чем он начнет работать.

Я так подробно остановился на описании реализованных интерфейсных решений в Parallels Access только с одной целью — объяснить, что часто дело дизайнера — это упростить восприятие технически сложного приложения.

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

1. Рисуй прототипы

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

2. Не останавливайся

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

3. Не расстраивайся

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

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

Вместо заключения

Проектируя интерфейс, ты проектируешь опыт взаимодействия пользователя с твоим приложением. Новые и оригинальные вещи в интерфейсах нужно делать только, если:

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

В остальном нужно (не тебе, а пользователю, в первую очередь), применять стандартные решения. Результатом твоей работы являются не экраны, иконки и кнопки, а продукт, понятный, надежный, приносящий пользу, радость, решающий задачи людей.