Как-то на днях у меня возникла необходимость распечатать более десяти чеков из моей истории платежей, используя банкомат одного из крупнейших банков. Я перешёл в платежи, выбрал “История”, прокрутив скроллер списка до нужного платежа, выбрал его, а затем нажал кнопку “Операции” и выбрал печать. И так повторялось для каждого чека: каждый раз происходил переход в главное меню и всё начиналось заново. Я задумался — неужели, несмотря на обилие источников информации по UX, до сих пор тратятся огромные бюджеты на подобные неудобные интерфейсы? Почему разработчики не хотят делать интерфейс, позволяющий пользователю почувствовать себя волшебником, а делают пользователей беспомощными в достижении своих целей? Возможно, причина в том, что, несмотря на обилие теории, эти источники предоставляют мало примеров из реальных проектов.
Так как мы буквально на прошлой неделе завершили большой Web-проект, в котором как раз стояла цель разработки удобного интерфейса, я решил осветить в статье, на какие основные моменты при проектировании интерфейса стоит обратить внимание, и привёл примеры нашего решения.
Что такое волшебный интерфейс?
Интерфейсом обычно называют набор способов, которыми вы выполняете какие-либо задачи с помощью какого-либо продукта, а точнее совершаемые вами действия и то, что вы получаете в ответ.
Исходя из этого, волшебный интерфейс — это интерфейс, который исполняет то, что вы пожелали. Однако попробуем дать определение, более близкое к реальной жизни.
Психологи заметили, что при использовании различных вещей у пользователей задействовано три уровня когнитивной обработки:
- висцеральный (производит внутреннее положительное впечатление),
- поведенческий (соответствует ментальной модели),
- аналитический (устанавливает эмоциональную связь с пользователем, привлекает к дальнейшему изучению и получению опыта использования).
Каждому уровню соответствует достижение пользователями определённых целей. Цели, достигаемые на первом и последнем уровнях когнитивной обработки, лежат в области эмоций и личности пользователя. Поведенческим (конечным) целям соответствует техническое назначение вещи безотносительно личности пользователя. Здесь лишь стоит заметить, что у каждого человека будет свой уникальный сценарий, приводящий к конечной цели, т.е. каждый расскажет свою историю по её достижению.
Итак, если интерфейс впечатляет каждого пользователя, позволяет достичь желаемого путём последовательности интуитивных действий, а также запоминается или даже становится частью повседневной жизни, то пользователи могли бы назвать такой интерфейс волшебным.
Возможно ли создание волшебного интерфейса в конкретной предметной области? Мы при создании DevExpress Web Dashboard посчитали, что это возможно.
Целью разработки проекта DevExpress Web Dashboard (далее Dashboard) было создание интерактивной аналитической панели с заданным набором элементов визуализации, возможностью фильтрации и группировки. К сожалению, на этапе разработки в силу специфики бизнеса у нас не было доступа к реальным пользователям продукта, поэтому пользователями выступали различные сотрудники нашей компании и вымышленные персонажи.
Ниже я рассмотрю интересные особенности интерфейса, на наш взгляд претендующего быть “волшебным”.
Для каждой особенности я приведу примеры, как мы поступили в нашем проекте, а реализацию некоторых из них сравню с аналогичным нашим продуктом под другую платформу.
Природа положительного впечатления
Основой положительного внутреннего ощущения является привлекательность дизайна интерфейса со стороны чувств человека (зрение, слух, вкус, обоняние, осязание). Внешнее воздействие стимулирует работу соответствующего органа чувств, который передаёт информацию в мозг. В результате, человек воспринимает это внешнее воздействие, у него возникают позитивные или негативные ощущения. В случае программных интерфейсов, воздействием обычно является внешний вид интерфейса, а чувством — зрение.
Есть ли универсальные рецепты, как сделать так, чтобы то или иное воздействие приводило к нужному восприятию?.. Как понять и оценить, сделали ли вы хороший, привлекательный интерфейс? Известный промышленный дизайнер Дитер Рамс в поисках ответа на эти вопросы, сформулировал 10 принципов хорошего дизайна, подходящие для любого вида интерфейса. Также существует множество источников, где описаны модные тенденции и типовые решения в проектировании визуальных интерфейсов. Несмотря ни на что, тот факт, насколько внешний вид интерфейса понравится пользователю, прежде всего зависит от личности дизайнера, который, в свою очередь, ищет вдохновение где угодно. Похоже, здесь как и в живописи — как рисовать портрет описано в любом учебнике по основам изобразительного искусства, но Джоконду нарисовал только один человек.
Мы в Dashboard полностью полагаемся на художественный вкус, интуицию и опыт нашего главного дизайнера.
От новичка до эксперта
Алан Купер рекомендует создавать интерфейс так, чтобы новичок быстро начал работу, эксперт нашёл необходимый ему функционал, а средний пользователь комфортно выполнял свои повседневные задачи. Представитель каждой категории пользователей не должен быть раздражён интерфейсом.
В Dashboard мы сделали систему ненавязчивых «хлебных крошек», указывающих путь на начальном этапе создания аналитической панели. Рассмотрим наиболее типичный сценарий создания аналитической панели. После непосредственно подключения к источнику данных, пользователь создаёт элементы. Первым шагом создания элемента является настройка связи его с полями источника данных. Новичку этого будет достаточно, чтобы увидеть первоначальный результат.
Новичок
Средний пользователь продолжит работу, изменяя простые свойства, например, заголовки или вид диаграммы.
Средний пользователь
Эксперт задаст сложные фильтрационные критерии или перейдёт в свойства Dashboard‘а для создания собственных вычисляемых полей или параметров.
Эксперт
Сравнивая с аналогичным нашим решением под другую платформу, замечаем, что новичку довольно сложно понять с чего начать. Область перетаскивания полей (Drag Area) не кажется важнее свойств в ленте (Ribbon) и если начать со свойств в ленте, то новый пользователь не увидит изменений в элементе.
Новичок (другая платформа)
Среднего пользователя и эксперта будет раздражать необходимость переключения вкладок ленты для перехода со свойств элемента на общие свойства аналитической панели.
Средний пользователь (другая платформа)
Эксперт (другая платформа)
Пользователи любой категории всегда будут какое-то время задумываться, на какую вкладку ленты им перейти, чтобы найти необходимое свойство. Им будет очень сложно запомнить, какие свойства необходимо искать в ленте, а какие в диалоговых окнах области перетаскивания полей.
Эффективность пользователя
Эффективность пользователя при работе с интерфейсом должна быть максимальной (должно быть максимизировано полезное действие интерфейса). Это прежде всего означает, что необходимый инструментарий для данного функционала легко находится, расположен близко и доступен без “выцеливания”, т.е. как минимум удовлетворяется закон Фиттса. Из этого закона в частности следует, что часто используемые меню и панели инструментов оптимально располагать по четырём сторонам экрана (вспомним Mac с его верхним меню).
Печально, но для приложений, выполняющихся в окружении браузера и случаев, когда необходимо показывать панели списков и свойств, занимающие слишком много места, приходится идти на компромисс. В нашей аналитической панели основная инструментальная панель создания элементов зафиксирована слева — это оптимальное место для браузерного приложения и пользователей, читающих слева направо. Свойства всей аналитической панели настраиваются поуровнево через главное меню, всплывающее также слева. Настройка свойств элементов находится в их контексте. При нажатии на элементе, появляется меню, в котором можно выбрать тип настраиваемых свойств (связи с данными, интерактивность, общие свойства) и настроить их с помощью специальных элементов управления, о которых я расскажу ниже. Меню имеют достаточный размер, чтобы выбор их элементов не сопровождался “выцеливанием”, а элементы управления появляются поверх элементов, не занимая отдельное место, столь ценное для пространства аналитической панели.
Меню и панели инструментов
Эффективность напрямую связана с кратковременной памятью, объём которой ограничен. “Кошелёк Миллера” из 7± 2 элементов уже давно служит здесь своего рода законом, но если попробовать обобщить, то всё, что перегружает кратковременную память, будет снижать эффективность пользователя в процессе работы с интерфейсом.
В Dashboard мы старались делать не более 7 пунктов в меню, редакторах свойств и других элементах на одном уровне иерархии; пунктам давали краткие лаконичные названия.
Доказано, что сложные иерархии в интерфейсе снижают эффективность пользователя, поэтому их сокращают или разделяют на модули.
Нам было довольно сложно сократить количество иерархий в редакторе свойств элементов аналитической панели (гридов, диаграмм и т.п.). Здесь нам помог принцип “разделяй и властвуй” или как сейчас принято говорить — принцип модульности. Мы разделили настройки свойств на разные типы: BindingArea позволяет визуально представить элемент с точки зрения связей с данными, а контекстные PropertyAccordion’ы — с точки зрения свойств (при этом свойства объектов самой BindingArea также редактируются в всплывающем рядом окне с PropertyAccordion). PropertyAccordion отображает свойства, сгруппированные в плоский список в виде элементов-редакторов и позволяет редактировать лишь одну такую развёрнутую группу (слайд).
BindingArea и PropertyAccordion
Классический редактор свойств был слишком нагромождённым и сложноиерархичным, а лента занимала недопустимо много (для 16:9 мониторов) места в верхней части экрана и, как и область перетаскивания полей, требовала создания множества разнотипных диалоговых окон, специфичных к настройкам конкретного элемента.
Классический редактор свойств (другая платформа)
Лента и область перетаскивания полей (другая платформа)
Полезные привычки
Если интерфейс формирует полезные привычки, это становится его дополнительным большим плюсом. Понять, что уйдёт в подсознание пользователя довольно сложно. Однако очевидно, если похожие процедуры делаются похожим образом, если элемент своим видом или расположением говорит, что с ним требуется сделать (нажать, перетащить, свайпнуть и т.п.), то подобные вещи один раз осознанные, уже не уходят из мозга пользователя. Также нужно исключить возможность добиться одной цели разными путями.
Мы в Dashboard сделали настройку разных видов элементов единообразной посредством BindingArea и PropertyAccordion. Предположим, пользователь настраивает связи с данными для диаграммы. В BindingArea он видит серии, аргументы и значения, выбирает поля источника данных и настраивает свойства в PropertyAccordion. Затем, например, настраивая грид, он видит в BindingArea колонки грида, которые по настройке связей с данными схожи с сериями диаграммы, как и по настройке свойств в PropertyAccordion.
Настройка диаграммы и грида
Режимы
Избавиться от режимов в интерфейсе иногда бывает довольно сложно. Ведущие специалисты по UX и HCI уже давно активно агитируют за избавление от режимов. Известный сотрудник PARC и Apple Ларри Теслер даже на своём авто имел номерной знак с надписью “NOMODES” (кстати, и в Twitter Ларри Теслера можно найти по имени @nomodes).Несмотря ни на что, многие современные интерфейсы имеют режимы, и если при переключении между режимами интерфейс должным образом не изменяется, это может ввести пользователя в заблуждение. Например, моя клавиатура Microsoft Natural Ergonomic позволяет отключить F-режим (F Lock находится рядом с часто используемой мною F12) и у меня периодически бывает, что, нажимая F5, я какое-то время не понимаю, почему не происходит то, что я ожидаю. Также во многих современных средах разработки в режиме выполнения приложения нельзя добавлять/удалять/редактировать модули и т.п.
В Dashboard нам удалось исключить элементы, имеющие разное поведение в зависимости от какого-либо режима. Мы также не стали делать режим предварительного просмотра (вы сразу работаете с живыми данными), не стали разделять режим настройки элементов и лэйаута аналитической панели. Однако мы сделали режим, изменяющий доступность редактирования элементов прежде всего из-за того, что редактирование должно быть доступно ограниченному числу пользователей. Кроме того, при непосредственном анализе данных нет необходимости во многих окнах настроек.
Режимы: просмотрщик (для работы бизнес-аналитика) и редактор (для администратора-создателя аналитических панелей)
Индикаторы загрузки
Часто мы слышим выражение «Как же это тормозит!». Программисты уверены: в этом случае нужно оптимизировать и ускорять ядро вычислений, запросы к БД и т.п. Да, им можно было бы, например, порекомендовать распараллеливание операций или кэширование часто используемых данных… но как быть с интерфейсом? В интерфейсе необходимо сделать ненавязчивую систему «индикаторов загрузки», где возможно делать двойную буферизацию, показывать старую “картинку” пока не получена новая, а при сложных изменениях интерфейса применять плавные анимации.
Dashboard отображает все панели с плавной анимацией. При интерактивных действиях (фильтрация и т.п.) появляется индикатор загрузки в углу элемента, лоадинг-индикатор имеет маленький размер и показывается на месте иконки меню, что дополнительно избегает лишнего промаргивания. Готов поспорить, что системы, где показывается огромная крутящаяся лоадинг-панель в центре каждого элемента, далеки от волшебства.
Лоадинг-индикатор
Вездесущий скроллинг
В любом интерфейсе, а особенно в multi-widget интерфейсе, подобном аналитическим панелям, хотелось бы избежать какого-либо скроллинга. Конечно же, в общем случае это невозможно. Но, как известно, есть ряд важных вещей, которые делаются для улучшения ситуации, например, где возможно избавляются от горизонтального скроллинга. Кроме этого, мы считаем занимаемое scrollbar’ами место противоречащим принципу Эдварда Тафти максимизировать соотношение “полезные данные/чернила”.
Поэтому в Dashboard мы реализовали свой скроллинг, который появляется поверх контента при наведении мыши (т.е. по поведению похож на то, что мы видим в последних MacOS).
Обычный скроллинг
Скрывающийся (контекстный) скроллинг
“Отменить действие?”
Люди любят экспериментировать, поэтому интерфейс обязан уметь отменять и возвращать действие. В настоящее время системы с undo/redo уже стали стандартом, однако не все из них лишены кучи диалогов с подтверждениями о вводе чего-либо. «Вы уверены?» — спрашивают они. Зачем лишний раз напрягать пользователя, если есть одна простая кнопка «Отмена»?
Dashboard позволяет отменить и вернуть любое действие без лишних вопросов.
Undo/Redo
Первое правило юзабилити (с оговоркой)
Любой интерфейс необходимо “обкатывать” на живых пользователях, наблюдать за ними, спрашивать, чем они руководствовались, когда сделали именно так. При этом ни в коем случае не слушать, что они просят, кроме случаев, когда во время работы с интерфейсом пользователь может выявить так называемые “desire lines” и рассказать о них разработчикам интерфейса, чтобы не было известной ситуации:
Например, я постоянно пытался свернуть до этого несворачивающийся слайд PropertyAccordion. Ряд пользователей ожидали скрытие панели свойств элемента BindingPanel при повторном щелчке на нём (ранее повторный щелчок не скрывал панель, а приходилось нажимать кнопку “<” в правом верхнем углу этой панели). Изначально меню на элементе появлялось по наведению мыши, и многие пользователи всё равно делали дополнительный щелчок мышью, т.к. ожидали выделения именно по щелчку.
Примеры “desire lines”
Снимая видео для данной статьи, я постоянно ощущал недостаток возможности нажать Esc для закрытия панелей. В документе по юзабилити-тестированию про горячие клавиши упомянули лишь 10% пользователей и речь шла прежде всего про Delete.
Очевидно, что на практике создание такого волшебного интерфейса будет итеративным и как правило начинается с минимально жизнеспособного продукта.
Мы начинали именно так и сделали не менее 5 прототипов, которые проходили по сценариям разных пользователей. Несмотря на это, мы всё ещё CTP-версия и ждём ваших отзывов.
В заключение хотелось бы отметить, что многие из рассмотренных принципов можно и нужно применять при разработке любого продукта, имеющего интерфейс, будь то сушилка для рук или банкомат. Успех компаний (Apple, Dyson и т.п.), учитывающих эти принципы при разработке интерфейсов различных устройств уже подстегнул многих более серьёзно относиться к нюансам человеческого восприятия и удобства использования. Давайте вместе попробуем сделать жизнь проще.
В нашем проекте мы старались придерживаться принципов, описанных в приведённых источниках, часть которых я осветил в этой статье. Многие принципы были реализованы интуитивно, на основе нашего опыта разработки. При этом в силу сроков на реализацию проекта и человеческого фактора, некоторые элементы интерфейса нам ещё следует доработать в бета версии. Не исключено также, что мы что-то упустили и пересмотрим какие-то принципиальные моменты.
[2] Donald Norman ‘Emotional design’, Basic Books, 2004; стр.21
[3] www.quora.com/What-is-a-mental-model
[4] Алан Купер 'Об интерфейсе', Символ-Плюс, 2009; стр. 127
[5] Алан Купер 'Об интерфейсе', Символ-Плюс, 2009; стр. 123
[6] Алан Купер 'Об интерфейсе', Символ-Плюс, 2009; стр. 109
[7] Jeff Gothelf 'Lean UX', O’Reilly, 2013; стр. 26
[8] www.vitsoe.com/us/about/good-design
[9] artgorbunov.ru/bb/soviet/20150202
[10] ru.wikipedia.org/wiki/Закон_Фиттса
[11] Р. Солсо ‘Когнитивная психология’, Питер, 2012; стр. 231
[12] psychclassics.yorku.ca/Miller
[13] en.wikipedia.org/wiki/Hick%27s_law
[14] Джеф Раскин 'Интерфейс', Символ-Плюс, 2010; стр. 123
[15] C.Y. Baldwin, K.B. Clark ‘Design Rules, Vol. 1: The Power of Modularity’, MIT – 2000
[16] Джеф Раскин 'Интерфейс', Символ-Плюс, 2010; стр.39, гл. 2.3.1.
[17] www.nngroup.com/articles/progress-indicators
[18] Stephen Few ‘Information Dashboard Design’, O’Reilly, 2012; стр. 50
[19] www.nngroup.com/articles/scrolling-and-scrollbars
[20] Edward R. Tufte ‘The visual display of quantitative information’, Graphics Press, 2009; стр.96
[21] asktog.com/atc/principles-of-interaction-design
[22] www.nngroup.com/articles/first-rule-of-usability-dont-listen-to-users
[23] Батлер Д., Лидвелл У., Холден К. 'Универсальные принципы дизайна', Питер, 2012; стр. 76
[24] Jeff Gothelf 'Lean UX', O’Reilly, 2013; стр. 55
Картинки:
[1] Кадр из фильма «Minority Report», (с) Dreamworks LLC and Twentieth Century Fox Film Corporation, 2002
[2] itsthedatastupid.files.wordpress.com/2010/05/nomodes.jpg
[3] guycooksondotcom.files.wordpress.com/2015/06/user-experience-vs-design.jpeg
Комментарии (27)
PoltP
25.04.2016 08:38+2Вы правы, кликать нужно (и можно) именно на панель слева. В CTP версии мы для простоты, а также заполнения пустоты, сделали эти же кнопки в рабочем пространстве. У нас уже есть прототип нового дизайна, поправим это к релизу (возможно бете).
*сорри, не кликнул на «ответить»
vintage
25.04.2016 09:36+6Ребята, вы молодцы :-) Единственный нюанс — скроллбар выполняет не только функцию управления, но и функцию уведомления о том, что часть данных скрыта. Если вы скрываете скроллбар, то нужно иным способом уведомлять о переполнении. Например, классический приём с тенюшкой.
PoltP
25.04.2016 09:47Спасибо!:) Да, этот момент с индикацией «заполнения» является узким местом. Рад, что Вы заметили. Затенение — хороший вариант для обсуждения с дизайнером, но скорее всего ему не понравится «замыливание») В данный момент по нашей статистике, лишь единичные наши пользователи не очень довольны отсутствием видимости скрола, поэтому мы пока не зафорсили фикс этой проблемы. То, что есть над чем подумать — это факт.
passerby
25.04.2016 12:20+4Мало того — уведомляет не просто о том, что часть данных скрыта, а о том насколько объемная часть скрыта. Затенение тут не поможет и чтобы все это оценить как раз и приходится совершать лишние движения мышкой.
Поэтому я, как пользователь, сильно расстраиваюсь при виде скрывающихся скроллов. А уж если они еще и узкие, как это сейчас модно…
И кстати, раз уж так получается, что я, по вашему мнению, один из «единичных пользователей», то хочу поинтересоваться, нет ли у вас примера какой-либо открытой статистики по этому вопросу?PoltP
25.04.2016 12:33Да, безусловно Ваше замечание верно.
Статистикой мы можем называть лишь количество запросов нам в поддержку. На этот вид скрола был всего один запрос (такой скрол мы впервые внедрили около 2 лет назад в нашем старом вьювере аналитических панелей).
Но Вы правы насчёт того, что это может быть проблемой. Некоторые коллеги мне говорили про это, я убеждал их, что навести мышь — не трудно:) Нужно будет подумать, как это решать. Сейчас наведение мышки его показывает. Теоретически может быть опция типа «всегда показывать скрол» (тем более наш продукт — ASP.NET контрол).
Ohar
25.04.2016 13:11+1Почему вы считаете что у пользователя есть мышь? Он вполне может работать с планшета.
PoltP
25.04.2016 13:15На планшете у нас «родной» скрол (по крайней мере на iOS и Surface). И здесь уже вопрос привычки — мы не можем менять нативное поведение.
PoltP
25.04.2016 13:24В общем-то конечно на тач устройстве может быть ситуация, когда будет работать наш скрол. Это может быть банально тач-монитор. Здесь проблема будет, бесспорно. Пользователю придётся «тыкать» в элемент, чтобы понять, что он показан не полностью.
teifo
25.04.2016 13:36«При этом ни в коем случае не слушать, что они просят», собственно это и есть ответ на вопрос, почему нет «волшебных интерфейсов». Разработчики наверняка уверены, что их текущий интерфейс лучше всего отвечает поставленным задачам. А пользователи? Ну так, они сами не знают чего хотят:)
PoltP
25.04.2016 13:40Лично для меня интерфейс iOS — волшебный. Описанный наш — я верю, близок к волшебному:)
Конкретно по Вашему предложению — пользователи не знают чего хотят, но они могут сказать «Вау! Вот оно!» — и когда таких пользователей достаточное количество, это и есть тот случай, когда интерфейс можно назвать «волшебным» (на мой взгляд).
Чтобы пользователи так сказали, опять же лично я уверен — разработчикам нужно знать все описанные в источниках принципы и понимать как это воплотить в жизнь.
leggiermente
25.04.2016 15:34По иронии судьбы прочитал эту статью, в то время как на ноутбуке обновлялась Windows 10. На экране в течение > 40 минут виднелись две строки:
Configuring Windows updates
Do not turn off your computer
И никакого индикатора выполнения! Ни графического, ни числового. Что мне оставалось думать, когда 40 минут на быстром железе с SSD происходит непонятно что?PoltP
25.04.2016 15:42:) да, к сожалению, у производителя этой операционной системы во многих продуктах до сих пор куча проблем с User Experiece
shara
26.04.2016 00:35Вот вы упоминаете Тафти и тут же показываете аналоговые индикаторы, которые не умещаются в блок. Разве это волшебно?
PoltP
26.04.2016 05:25Индикаторы (если Вы имеете ввиду Gauges) обычно нуждаются в дополнительной настройке под отведённую область. У нас сейчас есть 2 вида индикаторов — круговые и горизонтальные. Круговые позволяют изменять угол от 90 градусов до 360. Горизонтальные («градусники») обычно занимают весь прямоугольник. Размер занимаемой области настраивается ползунками лэйаута.
Или возможно Вы хотели бы видеть другие виды индикаторов?PoltP
26.04.2016 05:38'Горизонтальные' — сорри, я имел ввиду линейные, они могут быть и вертикально ориентированными.
shara
26.04.2016 10:32Я имею в виду стрелочные индикаторы, их использование оправдано, когда у вас много свободного места на экране и его можно занять украшательствами, но вы положили их в блок, который из-за размера индикатора получил скроллбар, а это не согласуется с принципом «больше полезных данных / меньше чернил».
Это вполне решается респонсивным отображением индикатора в зависимости от размера блока — либо мы его уменьшаем в размерах, либо заменяем на другой тип вплоть до текста, но избавляемся от скролла.PoltP
26.04.2016 11:25Дело в том, что это просто демо-пример конкретной аналитической панели, в которой индикаторы я расположил так специально для этого видео, чтобы показать скрол не только в гриде. Я согласен, что здесь может возникнуть когнитивный диссонанс. Вы правы, именно с точки зрения визуализации данных вообще — это неудачный пример. Конечно же, скролы в индикаторах — это жестоко:) Но это не относится напрямую к нашему интерфейсу.
CopyPaste
26.04.2016 11:09Мне кажется, что вся ваша работа над статьей перечеркнута одной неправильной картинкой про тропинки и дорожки. Разве у тропинки нет дизайна? Или у дорожки нет user experience? Если же вы говорите о usability, то подумайте о случае с тропинкой, если пойдет дождь и все превратится в грязь.
PoltP
26.04.2016 11:15+1Похоже, Вы не верно поняли мысль, отображённую на этой известной картинке: спроектированная дорога не отражает опыт использования, пользователь выбирает путь обхода реализованного функционала, реализация не отражает его ментальную модель.
Я слышал, что в одном из московских ВУЗов перед тем, как делать дорожки, ректор сказал — «пусть сначала люди походят, где будут тропинки — там и сделаем». В реальных устройствах с интерфейсом такой подход редко осуществим, поэтому мы говорим о «desire lines». Более подробно здесь: Батлер Д., Лидвелл У., Холден К. 'Универсальные принципы дизайна', Питер, 2012; стр. 76.CopyPaste
26.04.2016 12:45-1Пока я только понял, что на картинке неверные подписи. И писал я именно об этом. Или вы несогласны?
PoltP
26.04.2016 13:21+1Вообще, это известная картинка, не я её придумал, есть куча мест, где она приводится в пример, есть указанный выше справочник, где подобное также приводится в пример.
Да, на мой взгляд подписи верные. На картинке показано, что User Experience= опыт использования (т.е. как людям удобно/соответствует их представлениям), отличается от задуманного разработчиками Design'а. У меня здесь сомнений нет.
CopyPaste
26.04.2016 13:45Ну знаете, заборы тоже все исписаны, а толку там не много (:
Давайте я еще раз напишу свои мысли, а вы мне скажете, где я не прав.
*Design* — не то как выглядит, а то как работает. И тропинка, и дорожка работают (я могу воспользоваться обоими вариантами). Мы не говорим о том, какой из них лучше. Мы говорим о терминах. И дизайн есть у каждого из этих решений.
*User Experience* — это опыт взаимодействия и только так. Весь спектр эмоций и переживаний, которые у меня возникли при взаимодействии с конкретным объектом или системой. Я чувствую неровности на тропинке, или чувствую стыки плиток на дорожке. Но в обоих случаях есть чувства и эмоции. Следовательно, у обоих решений есть свой собственный User Experience.
И User Experience — это совсем не опыт использования. Дон Норман приводит отличный пример с соковыжималкой. У него отличный опыт взаимодействия с ней, но по факту он ей даже не пользовался. Следовательно, опыт взаимодействия и опыт пользования — разные вещи. Могут совпадать, а могу и нет.
То, что вы называете _удобно_ — *это usability*.
Что мы имеем в сухом остатке:
Оба решения имеют design и user experience. Однако, одно из решений более удобное, потому что экономит время. Поэтому правильными будут подписи «More usable» и «Less usable». И то, при определенных условиях.
PoltP
26.04.2016 13:55+2Здесь не последние в России специалисты по интерфейсам (Артём Горбунов, Константин Горский) немного обсуждают термин «User Experiece». Расхождений с «опыт использования» я не вижу, хотя «опыт взаимодействия» — это перевод русской Википедии, я не вижу здесь критичных различий.
Здесь подробно обсуждается отличие концептуальной модели (собственно то, что спроектировали инженеры и дизайнеры) и ментальной модели.
Повторюсь, картинка показывает задуманную инженерами реализацию и то, что хотят пользователи (если выражаться неакадемическими терминами). На мой взгляд Вы «ищете чёрную кошку в тёмной комнате, когда её там нет». Но я ни в коем случае Вас не осуждаю, в целом Ваше понимание надписей я осознал, но я бы лишь не делал столь широкий вывод о перечёркивании работы над статьёй.
Writerim
Посмотрел видео «Новичок» и ожидал, что после того как появилась рабочая область, надо будет выбирать из левого меню иконки и выполнять какие то действия. Ну это видимо из «Фотошопа» и «Ворда» привычка. Какого же было мое удивление, что они не нужны и надо «кликать» на рабочую поверхность для работы. Мне кажется есть куда еще стремиться.
PoltP
*сорри, промахнулся с ответом