Как исправить неуклюжий дизайн интерфейсов

Вам когда-либо приходилось работать с продуктом, которому как будто не хватает…чего-то, как будто бы он без души?

Скорее всего вы столкнулись с так называемым неудачным дизайном интерфейсов.

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

Вот вам пример из жизни: я пользуюсь Apple TV. Очень часто. (На самом деле сейчас на фоне играет последний эпизод «Звёздных войн: Повстанцы»). Когда я выбираю в меню «Приобретённые фильмы», на экране появляется это:

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

Должен признать это раздражает.

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

Видите эмпирическую разницу?

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

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

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

В неуклюжем интерфейсе это не учитывается. В какой-то момент были нарушены определённые правила.

Правила множества состояний дизайна интерфейсов.Об этом и поговорим.

Множество состояний UI

Каждой страницы цифрового продукта присущи различные особенности.

Пять, если быть точным.

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

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

Будьте честны с собой. Когда в последний раз вы разрабатывали страницу только с одним состоянием? Даже создавая приложения погоды (распространённая шутка на Dribbble), одного состояния будет недостаточно.

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

Как дизайнеру продуктов, вам следует это учитывать.

Поэтому для каждой страницы стоит разработать пять состояний:

• Идеальное состояние.
• Пустое состояние.
• Состояние ошибки.
• Состояние частичной заполненности.
• Состояние загрузки.

В процессе работы с продуктом пользователь взаимодействует с плавно переходящими состояниями.

Сюрприз! Пришло время слегка удариться в историю Интернета. В 2004 Basecamp, до этого известный как 37signals, оформили революционную для меня на то время статью под названием «Решение трёх состояний» (англ. The Three State Solution). (И да, это не план по решению израильско-палестинского конфликта).

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

Но всё меняется. Сначала революция AJAX, затем мобильные приложения. После них настала массовая ориентация на потребителя технологий. Потребности и ожидания UI изменились.

Давайте поговорим об идеальном состоянии.

Идеальное состояние

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

Пускай оно задаёт тон остальным. В процессе итерации этот UI может полностью поменяться. В этом одновременно прелесть и риск.

Создание этого состояния приводит к последствиям для остальных.

Все состояния UI ведут к идеальному. Начните с него, и пусть остальные будут построены вокруг него, реализуя поставленную клиентом задачу.

Пустое состояние

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

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

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

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

Давайте исследуем более детально состояния первого взаимодействия пользователя с продуктом.

Первое взаимодействие / Погружение

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

Мне кажется, что это состояние похоже на известное в литературных кругах «Путешествие героя». Представленное Джозефом Кемпбелом в его чудесной работе Герой с тысячью обличий (англ. Hero With a Thousand Faces), это основа для сказочных историй по всему миру, начиная с Одиссеи и заканчивая Звёздными войнами. Вот основной посыл:

«Герой вырывается из пут обыденности и направляется в мир сверхъестественных явлений: там ему встречаются сказочные силы и он одерживает победу в решающем поединке: герой возвращается с таинственного путешествия и дарует блага своим соратникам».

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

Как это сделать? Есть такие идеи:

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

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

Теме погружения и первого взаимодействия можно посвятить книгу. И так сложилось, что такая книга есть. Если вы хотите более детально ознакомиться с этими понятиями, я очень рекомендую прекрасную работу Самуэля Халика Элементы погружения в интерфейс (англ. The Elements of User Onboarding).

Очищенные пользователем данные

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

Эти типы пустых состояний — отличная возможность наградить пользователя или призвать к дальнейшим действиям. Во входящих больше нет непрочитанных? Отлично! Посмотрите на эту чудесную фотографию. Загрузили всю музыку? Хорошо, время её послушать. Ознакомились со всеми уведомлениями? Вот, возможно хотите прочесть ещё что-то.

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

Нет результатов

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

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

У Pinterest результаты поиска не похожи на Amazon, это и не удивительно.

На основе того как мой запрос был обработан, пользователю должно быть относительно легко изменить условия поиска, чтобы получить желаемое.

Урок: не отпугните пользователя. Отображайте на странице лишь то, с чем им возможно понадобиться работать или предложите альтернативу.

Состояние ошибки

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

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

Перефразирую Джефа Раскина, создателя оригинального Macintosh и автора Гуманного интерфейса (англ. The Humane Interface). Он пишет: «Система должна относиться ко всему введённому пользователям с почтением. Перефразируя первый закон о роботах Азимова, робот не должен вредить человеку или бездействием привести к тому, что человеку будет нанесён вред, первый закон дизайна интерфейсов должен звучать так: компьютер не должен вредить вашей работе или бездействием привести к тому, что вашей работе будет нанесён вред».

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

Нет! Да! Наверное?

Наконец-то, внятное контекстное сообщение об ошибке . Небольшая шутка как бонус добавляет интерфейсу человечности.

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

Следует добавить, что состояния ошибок не должны быть драматичными и размытыми. Помните «синий экран смерти»? Или «тревогу, сбой в ядре» Mac? Или — для совсем уже ветеранов — сообщение о критической ошибке DOS «прекращение работы и попытка повторить заново не удались»? Все эти состояния отображают существенную ошибку системы и за ними следует перезагрузка компьютера. Но до сих пор их помнят за шок, страх и замешательство, в которые они вводят конечного пользователя.

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

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

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

Это просто. Делайте человечные, а не технические сообщения об ошибках, позаботьтесь о том, чтобы ваша аудитория смогла их понять. Что бы вы хотели слышать, если что-то пойдёт не так?

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

Состояние частичной заполненности

Разницу между состоянием ошибки и идеальным состоянием можно описать как разницу между днём и ночью. Но как же выглядит страница, если на ней изображён лишь один ряд данных? Несколько фотографий? Заполненный на половину профиль?

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

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

Здесь вам могут пригодиться принципы дизайна видеоигр. Я не имею в виду, что стоит заставлять пользователей делать что-то наподобие сбора кристаллов в Clash of Clans. Вместо этого я предлагаю выстроить так называемое ускорение для достижения идеального состояния продукта.

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

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

Вот несколько чудесных примеров состояния частичной заполненности.

Состояние загрузки

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

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

Это мнение Люка Вроблевски, эксперта в дизайне продуктов, который возглавлял команды eBay, Yahoo! и Google. С последними он сейчас сотрудничает после продажи своего стартапа Polar, мобильного приложения для голосования.

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

Вроблевски осознал, что:

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

Скелетная схема страницы

Осознание этого привело к разработке того, что он называет скелетной схемой страницы. Этим приёмом сейчас пользуются Pinterest и Facebook, как в мобильных приложениях, так и на сайтах.

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

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

Оптимистическое предположение

«Никто не хочет ждать в процессе ожидания»,

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

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

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

Вы познакомились с примерами множества состояний UI отдельно друг от друга. Но как они будут работать вместе? Как отобразить в интерфейсе переходы между ними?

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

Для иллюстрации этих идей я создал гипотетическое приложения обмена сообщениями.

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

Итак, с чем нам предстоит работать в приложении обмена сообщениями?

1. Нам необходимо учесть пустое состояние, то есть когда сообщений ещё нет.
2. Состояние частичной заполненности — это когда один собеседник отправил первое сообщение.
3. Затем получение ответа — индикатор того, что собеседник печатает, другими словами это состояние загрузки.
4. Но погодите, есть ещё состояния загрузки — когда мы отсылаем сообщение. Затем отображается подтверждение доставки.
5. В этот момент может произойти сбой и сообщение может быть не доставлено.
6. Вам не стоит забывать о механизме исправления ошибки и о необходимости повторной отправки. Это ещё одно состояние загрузки.
7. Наконец, мы достигаем идеального состояния: сообщения превратились в беседу.

Гипотетический пример

Допустим, Марти и Док обменялись номерами телефонов и Марти хочет поведать Доку, что он только что увидел в супермаркете «Две сосны».

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

Что происходит после того, как сообщение отправлено? Нам необходимо плавно перейти от пустого состояния к состоянию частичной заполненности: в данном случае, это когда Марти отправляет только одно сообщение

Давайте перейдём к ответу Дока. Он отправил одно сообщение — но ещё не закончил! Поэтому отображается индикатор того, что он печатает, одна из форм состояния загрузки.

Как только он закончил печатать и сообщение отправлено, мы видим переход от индикатора к появлению нового сообщения, в то время как другие подвигаются вверх.

Что происходит, когда Марти хочет ответить? Сначала, нам необходимо отобразить состояние того, что в поле введён текст — обратите внимание как кнопка «Отправить» меняется с серого цвета (неактивная) на синий (активная). Затем видим другое состояние загрузки — иллюстрацию процесса отправки. В это время сообщение затемнено, ведь ещё неизвестно успешно действие или нет, до тех пор пока «Доставлено» не сообщит пользователю, что всё в порядке.

Что происходит, когда сообщение не доставлено? Тут пригодится наше состояние ошибки. Красный значок заменяет индикатор загрузки и сообщение все ещё затемнено. Нажатие на его (или в данном случае на прототип Quartz Composer) повторяет попытку. Теперь нам повезло и сообщенное отправлено, красный значок пропадает и мы видим индикатор доставки.

А в реальном мире…

Вы наблюдали множество пяти состояний UI, а также плавные переходы между ними в действии. Без этих переходов мы рискуем вызвать у пользователя замешательство или удивление внезапным появлением и исчезанием состояний. Это явно не входит в нашу работу, не правда ли?

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