Введение в UX Дизайн – Дизайн-кабак

Мы видим, выделение ячейки красного цвета обводкой и галочкой. Под иконкой “А” также изменилась линия на красный цвет, так же само слово “Дизайн” в документе изменило цвет. Итак, все формы обратной связи в интерфейсе, которые вы возможно даже не заметили, сообщили мне о моем действии и отреагировали на то, что я делаю.

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

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

Case Study #2

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

В этом кейсе мы рассмотрим историю, описанную в газете Washington Post. Пожилая пара собираясь встретиться со своей дочерью в Бразилии вбили в свое “GPS приложение” адрес, место встречи с ней. На самом деле в реалии оказалось несколько улиц имело одинаковое название. В итоге они поехали не по тому адресу и оказались в очень опасном районе Бразилии, и были там убиты.

Дизайн принцип: эвристическая оценка / heuristic evaluation.

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

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

Но со своей стороны мы могли бы дать предупреждение пользователю. Например такое “Администрация города настоятельно рекомендует не заезжать в опасные районы, вы уверены, что хотите поехать именно туда?” При этом пользователь должен нажать “Да, я уверен, что хочу направиться туда”, либо кнопку “Я имел в виду другой адрес”. Так что такое решение возможно могло бы спасти чью-то жизнь, дизайн мог спасти жизнь!

Следующим примером дизайна служит знаменитый во всем мире кейс: Therac-25. В медицинском устройстве для радиационной терапии случился сбой и оно выдало смертельную дозу радиации пациентам. Четыре человека погибли, еще двоим был нанесен тяжкий ущерб для здоровья.

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

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

Ключевые уроки дизайна:

• Избегать ошибки

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

Техник не видел и не мог видеть, как много радиации подается пациенту. И это звучит очень опасно в данном контексте.

• Предупредить сообщением об ошибке

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

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

• Необходима хорошая документация

К машине прилагалась ужасная документация.

• Вовлекать пользователей в дизайн процесс и тестирование

При дизайне и тестировании машины не были привлечены пользователи. Многие из вышеперечисленных проблем могли всплыть на этом этапе.

Case Study #3

Следующий кейс будет показывать другой пользовательский интерфейс на примере панели управления Microsoft Office.

Мы будем рассматривать панель управления — это лента сверху документа, которая содержит в себе кучу кнопок и объектов, на которые вы можете щелкнуть. И ключевой идеей является то, что это единственное место для поиска всех функций в программе. Будь то Microsoft Word, PowerPoint, Excel и т. д. И если бы вы были бы человеком, который делает этот дизайн, то ваша команда столкнулась бы с серьезными испытаниями. Такими как, какие вы нарисуете иконки? Какой текст нужно использовать? Какой использовать шрифт? Какой цвет? Дизайнеры столкнулись с кучей вопросов, но мы рассмотрим самый ключевой.

Какие команды, какие функции программы вы должны включить в виде кнопок на ленту? Как решить какие команды включать, а какие нет? К примеру, возможно, нет необходимости в кнопке “Сохранить”, так как все уже привыкли использовать для этого control+S или аналогично для копирования, вставки или отмены действия.(control+C / control+V / control+Z).

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

Спустя время команда Microsoft применили новый путь проектирования этого интерфейса. Этот новый путь проектирования основывался на данных, которые команда собирала от настоящих пользователей программы анонимно. Эта программа называлась Customer Experience Improvement Program и позволяла команде получать информацию о всех действиях пользователей включая: все команды, что были использованы и какие команды было проблематично использовать, какие команды были выполнены при нажатии на кнопку, а какие при использовании shortcuts и многое другое. Затем дизайнеры задавали вопросы и получали ответы по тем или иным операциям от настоящих пользователей. Такие например команды как ctrl+z или undo очень популярны, потому что люди постоянно пытаются пробовать новые идеи, а потом корректируют их. Или например, что никто не любил Print Preview, потому что сама концепция этой команды казалась странной. И все эти идеи люди имели благодаря своему личному опыту использования этой программы. После этого исследования в блоге Microsoft появилась прекрасная цитата:

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

Теперь подумайте какие бы команды вы поставили в топ пять команд по вашей интуиции? Ответ будет идти далее…

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

1. paste /вставить (15% от всех команд)
2. save / сохранить
3. copy /копировать
4. undo /отменить действие
5. bold /выделить текст

Печален тот факт, что 32% всех проблем пользования программой приходился именно на эти пять топ команд. И самое интересное, что выявили дизайнеры. Для пользователей было не важно, используют они shortcuts для paste или кнопку, и одно и другое были очень популярны среди пользователей. Теперь посмотрите на фото (смотри выше). Можно понять почему команда Paste стоит самой первой в ленте инструментов, она выполнена в виде кнопки и является самой большой кнопкой рядом с такими командами как cut и copy.

Ключевые уроки дизайна:

• Знание — это сила

На примере Microsoft мы увидели, как дизайн основанный на интуиции пришлось заменить на дизайн полученный на данных.

Дизайн основанный на интуиции отличается от представлений пользователя. Поэтому такой дизайн будет неверным.

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

• Дизайн должен быть точным

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

Case Study #4

Следующий кейс будет покрывать тему дизайна “Поиска в детской цифровой библиотеке.”

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

На ум пришло бы: “Так, если мне нужна страница поиска, значит мне просто нужно нарисовать область поиска и кнопку “Искать” рядом с ней. И так как это библиотека, возможно мне нужны функции как искать книги, например по названию книги или автору. И далее, если кто-то начнет искать ниже появится каталог книг.
Но нам нужен ведь поисковик для детей, а дети любят все цветное, поэтому нужно просто все раскрасить в разные веселые цвета. Дети любят героев мультфильмов, поэтому надо нарисовать какого-нибудь мультяшку тут снизу для красоты.”

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

Итак вместо того, чтобы гадать, что может понравиться детям, цвета или мультики. University of Maryland в своем исследовании для Детской цифровой библиотеки начали работу непосредственно с самими детьми. Они хотели понять, что ожидают увидеть сами дети в поисковике своей библиотеки.

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

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

Благодаря этому исследованию и дальнейшей версии вебсайта с возможностью выбора стиля поиска: текстового либо визуального, стало ясно, что визуальный поиск использовался 71% всего времени.

Ключевые уроки дизайна:

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

Case Study #5

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

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

Итак как же интерфейсы этих двух сервисов могут отразить преследуемые ими цели?