Рубрика: UX обучение

 

 

Автор — Андреас Камнинос (Andreas Komninos)

Что на самом деле создает UX-дизайнер? В этой статье мы рассмотрим концепцию конечных результатов UX — этот термин описывает результаты процесса UX-дизайна на разных этапах. Результаты, созданные UX-дизайнерами, различаются в зависимости от их роли в команде дизайнеров, а также в зависимости от методов и инструментов, используемых каждой ролью. Мы рассмотрим некоторые из наиболее распространенных типов результатов.

Процесс UX-дизайна обычно опирается на что-то схожее с подходом дизайнерского мышления, который состоит из пяти основных этапов:

• Понимание чувств пользователей (изучение аудитории)
• Определение проблемы (определение потребностей пользователей)
• Создание идей (генерация идей для дизайна)
• Прототипы (превращение идей в конкретные примеры)
• Тест (оценка дизайна)

Первые два этапа (понимание чувств пользователей и определение проблемы) часто группируются в термин «Исследование пользователей», то есть понимание сущности пользователей и того, как это влияет на их потребности. На каждом этапе можно использовать ряд инструментов и методов. Каждый инструмент или метод может предоставить другой тип вывода (UX-результат), но здесь мы сосредоточимся на некоторых наиболее часто используемых типах, чтобы предоставить вам обзор того, что вам предстоит создавать в роли UX-дизайнера.

 

Результаты исследований пользователей

Персоны

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

Copyright holder: Rosenfeld Media, Flickr. Copyright terms and license: CC BY 2.0

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

Раскадровка

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

Copyright holder: Rosenfeld Media, Flickr. Copyright terms and license: CC BY 2.0

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

Карта путешествий потребителя

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

Copyright holder: Tobias Maier, Wikimedia. Copyright terms and license: CC BY-SA 3.0

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

 

Результаты создания идей

Мозговой штурм

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

Copyright holder: visualpun.ch, Flickr. Copyright terms and license: CC BY 2.0

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

Пользовательский маршрут (User Flow)

User flow — простая диаграмма, описывающая шаги, которые пользователь должен предпринять с вашим продуктом или услугой для достижения цели. В отличие от карты путешествия потребителя, в user flow учитывается только то, что происходит с вашим продуктом (т. е. игнорируются все внешние факторы). Эти диаграммы могут помочь дизайнерам быстро оценить эффективность процесса, необходимого для достижения цели пользователя, и могут помочь определить «как» (то есть выполнение) великих идей, определенных посредством мозгового штурма.

Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright terms and licence: CC BY-NC-SA 3.0

Пример диаграммы user flow, которая показывает действия пользователя в приложении.

 

Результаты прототипирования

Карты сайта

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

Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright terms and licence: CC BY-NC-SA 3.0

Пример карты сайта, показывающей, как организовывается контент на веб-сайте, и как пользователи могут перейти от раздела к разделу. Здесь дизайнер показывает иерархию путем нумерации разделов содержимого (например, 2.0 является «родительским» разделом и 2.1 является подразделением).

Прототипы с низкой точностью

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

Copyright holder: VFS digital design, Flickr. Copyright terms and license: CC BY 2.0

Примеры насованных вручную (слева) и на компьютере (справа) прототипов с низкой точностью

Прототипы с высокой точностью

Эти прототипы на ступень выше прототипов с низкой точностью. Часто они называются идеально-пиксельными прототипами (pixel-perfect prototypes), потому что они пытаются показать все визуальные и типографические детали продукта, как это было бы показано на настоящем экране. Они учитывают размеры физического экрана и создаются в размере, соответствующем размеру физического устройства. Хотя эти прототипы требуют гораздо больше времени для создания по сравнению с прототипами с низкой точностью, они часто являются примером иллюстрации, которую вы хотели бы показать клиенту или заинтересованному лицу.

Copyright holder: amire80, Wikimedia. Copyright terms and license: CC BY-SA 3.0

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

Интерактивные прототипы

Прототипы с низкой и высокой точностью, рассмотренные выше, представляют собой не что иное, как набор статических изображений. Чтобы лучше оценить ваши проекты, вы можете превратить эти прототипы в интерактивную демонстрацию, нацеленную на отображение того, как взаимодействие может работать с ними. Программы для коммерческого прототипирования позволят определить активные области, переходы и события, чтобы создать интерактивный прототип, который охватывает user flow и демонстрирует взаимодействие без необходимости писать ни одной строки кода. В некоторых случаях вы можете использовать гораздо более простой инструмент, например, PowerPoint или Keynote. Даже лучше, вы можете использовать эти интерактивные прототипы в ранних тестах пользователей, прежде чем какой-либо код даже был написан. Таким образом, вы можете убедиться, что ваш дизайн, вероятно, будет работать хорошо, прежде чем перейти к дорогому и трудоемкому процессу разработки кода.

https://www.youtube.com/watch?v=AmXkqZ4dJhE

Пример того, как вы можете создать интерактивный прототип с таким простым инструментом, как программа для презентаций Keynote от Apple.

 

Результаты оценки

Отчет по юзабилити

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

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

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

 

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

Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright terms and licence: CC BY-NC-SA 3.0

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

Аналитический отчет

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

Например, вы можете обнаружить, что многие пользователи веб-сайта электронных продаж не регистрируются для завершения покупки. Означает ли это, что процесс регистрации недостаточно простой? Означает ли это, что они не видят, что существует такой вариант? Аналитический отчет содержит информацию из этих данных и выделяет области, где проект может быть улучшен. Хотя это заманчиво просто вставлять красивые графические элементы и диаграммы, созданные автоматически такими продуктами, как Google Analytics, но работа UX-дизайнера заключается не только в том, чтобы устанавливать факты, но и интерпретировать их. Таким образом, ваш отчет должен содержать данные, а также объяснения и рекомендации о том, что делать. Это также полезная запись, чтобы вы могли увидеть влияние изменений дизайна на свой сайт, после того как вы определили проблемы и попытались их устранить.

Copyright holder: pexels, pixabay.com. Copyright terms and license: CC0

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

 

В заключение

В статье 2015 года для Norman Nielsen group, специалист по UX Пейдж Лобхаймер (Page Laubheimer) анализировал тип UX-результатов, который UX-разработчики подавали чаще всего. Как сообщается, наиболее часто создавались вайрфреймы и прототипы, а также блок-схемы, карты сайтов и отчеты по юзабилити/аналитике.

Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright terms and licence: CC BY-NC-SA 3.0

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

Это то, что мы считаем «классическими» результатами UX, но один важный момент, который следует иметь в виду, состоит в том, что, хотя эти результаты производятся и передаются другим, многие другие типы результатов будут созданы, но ими никогда не будут делиться с другими (следовательно, рейтинг ниже в этом исследовании).

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

Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright terms and licence: CC BY-NC-SA 3.0

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

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

 

Ссылки и где узнать больше:

Hero Image: Copyright holder: Mark Congiusta, Flickr. Copyright terms and license: CC BY 2.0

Лобхаймер П. (Laubheimer, P). (2015). Какие конечные результаты UX наиболее часто создаются и передаются другим?

https://www.nngroup.com/articles/common-ux-deliverables/

Teixeira, F. & Braga, C. (2016). Методы и результаты UX-дизайна

https://uxdesign.cc/ux-design-methods-deliverables-657f54ce3c7d

Бабич Н. (Babich, N.) (2017). Полный список результатов UX

https://uxplanet.org/a-complete-list-of-ux-deliverables-d62ccf1de434

Морвилл П. (Morville, P. (2009)) Результаты UX

http://semanticstudios.com/user_experience_deliverables/

Гудман, Э. (Goodman, E.) (2012). Как я научился перестать беспокоиться и любить результаты взаимодействий, 19 (5), 8-9.

 

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

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

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

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

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

 

Практическое правило ментальной модели (The Mental Model Rule of Thumb)

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

Author/Copyright holder: Nathanael Crawford. Copyright terms and licence: CC BY-SA 3.0

 

Запутанные ментальные модели

Якоб Нильсен, член-учредитель Nielsen Norman Group, предлагает отличное понимание возможной путаницы в ментальном моделировании. Это происходит, когда пользователи не распознают ключевые различия между аналогичными (но не идентичными) частями системы.

Он отмечает, что многие пользователи не могут различать поле поиска в Google и поле ввода URL-адреса в браузере. Эти пользователи будут использовать Google для поиска имени известного веб-сайта, чтобы щелкнуть ссылку, а не просто вводить название и «.com» в строке URL. (Проблема, которую Google Chrome, показанный ниже, пытается решить, сделав URL-панель поисковым инструментом).

Author/Copyright holder: Axendo. Copyright terms and licence: Public Domain.

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

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

• Windows, входящей в операционную систему, и внутри браузера
• Windows и приложениями
• Иконками и приложениями
• Командами браузера и командами, которые проводятся в приложении
• Локальной и удаленной информацией
• Опциями регистрации и паролями (например, пользователь будет часто регистрироваться на любом сайте, как если бы он пытался войти в свою учетную запись электронной почты)

 

Использование ментальных моделей в дизайне

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

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

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

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

 Author/Copyright holder: Nite_Owl. Copyright terms and licence: CC BY-SA 2.0

 

В заключение

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

 

Ссылки

Дополнительное объяснение ментальных моделей можно найти здесь — https://www.interaction-design.org/literature/book/the-glossary-of-human-computer-interaction/mental-models

Доклад Якоба Нильсена о ментальных моделях для группы Nielsen Norman можно найти здесь — https://www.nngroup.com/articles/mental-models/

Hero Image: Author/Copyright holder: Rosenfeld Media. Copyright terms and licence: CC BY 2.0

Автор: Энджи Ли (ANGIE LI)

Оригинал статьи: https://www.nngroup.com/articles/date-input/

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

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

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

 

Шаблоны ввода даты

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

Пример calendar picker на мобильном телефоне, показанный в приложении Календаря Google.

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

Calendar pickers особенно полезны для выбора диапазона дат. В этих ситуациях они часто показывают два месяца бок о бок.

 

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

Прокрутка элементов для выбора даты (date pickers) на мобильных устройствах является обычным явлением, но они могут раздражать, если элемент выбора (picker) содержит много дат. В таких ситуациях прокрутка в небольшом пространстве медленная и непродуктивная; лучше дать пользователям возможность вводить дату напрямую.

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

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

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

DeviantArt предоставил раскрывающийся список для каждого раздела поля даты.

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

 

Рекомендации по дизайну ввода даты

Для ограниченного количества вариантов даты сделайте список подходящих дат.

В некоторых случаях у пользователей будет всего лишь несколько вариантов выбора даты. Например, Google Express, онлайн-сервис покупок, позволяет клиентам заказывать онлайн-продукты и планировать время доставки. Вместо того чтобы предлагать пустые поля даты или calendar picker с безграничными опциями, Google Express предоставляет короткий список вариантов даты. Любые даты, которые недоступны были закрашены в серый и отключены. (В качестве альтернативы, недоступные даты могут даже не включаться в список.)

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

В целом, мы не рекомендуем этот метод, если есть более 10 дат, поскольку людям может быть утомительно сканировать и прокручивать список дат.

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

Независимо от того, какой формат пользователь выбрал для ввода даты (тире, пробелы, косые черты, точки между компонентами месяца, дня и года), их вход должен быть распознан. Более того, крайние левые нули не должны влиять на дату. В приведенном ниже примере Priceline дата 9-3-17 отклоняется, а принимается 09/08/17, хотя никакие требования к формату не были видны перед отправкой формы.

 Priceline отклонил дату 9-3-17, даже не представив предложения о том, как правильно ее форматировать. Вместо этого он должен был принять его и проанализировать для пользователя.

Сообщите об ошибках соответствующим образом.

Если пользователь вводит дату, которая, очевидно, является ошибкой, например, 11/81/17, не делайте никаких предположений. Обеспечьте пользовательскую обратную связь и предложите рекомендации по устранению ошибки.

Устраните нелогичные варианты дат

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

Сохраняйте работу пользователей.

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

Сохраняйте диапазоны дат постоянными.

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

Southwest Airlines изменили диапазон дат возвращения, основываясь на выборе даты вылета. После выбора даты вылета 8-16-16 из диапазона дат за июль-август диапазон дат возвращения изменился, чтобы показать август-сентябрь.

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

Поля ввода дат зависят от культуры и могут вызвать серьезные проблемы для тех пользователей, которые привыкли к другому формату. «10/11/2016» может означать 11 октября 2016 года для американца, но 10 ноября — для кого-то из Европы. Следуйте этим практическим правилам при разработке дизайна ввода даты для глобальной аудитории:

• Добавьте метки и разделите поля, чтобы было понятно, какие поля предназначены для месяца, дня и года.

Этот таймер обратного отсчета отделил компоненты даты и четко обозначил их.

 

• Укажите название месяца, чтобы отделить его от дня.

Сайт Tep Wireless, где пользователи могут арендовать портативные Wi-Fi-устройства, указал название месяца для обслуживания своей глобальной аудитории.

Веб-сайт Eurostar, показанный на английском (США), поддерживал несколько языков, но не сказал, какой формат даты он ожидал. Здесь дата отъезда может быть прочитана как 2 июля или 7 февраля.

 

• Используйте элементы для календаря (calendar pickers) с четко обозначенными названиями месяцев.

Некоторые фреймворки, такие как Bootstrap, предоставляют элементы для календарного выбора (calendar pickers) для поддержки однозначного выбора даты.

В календаре выбора (calendar picker) Bootstrap было указано название месяца, чтобы было ясно, какую дату выбрать.

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

 

Вывод

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

 

Автор — Дитте Мортенсен (Ditte Mortensen)

 

Думая о визуализации результатов исследования, у многих людей автоматически возникает в уме изображение графика. У вас также возникает этот образ? Вы были бы правы, думая, что многие результаты исследований выигрывают от графической визуализации, демонстрируя тенденции и аномалии.  Но это в основном справедливо для результатов количественных исследований пользователей. Графики часто являются не лучшим способом сообщать результаты от качественных методов исследования пользователей, таких как интервью или наблюдения. Часто количество участников этих типов исследований слишком мало для создания значимых графиков. Более того, информацию, которую вы захотите сообщить, иногда нельзя перевести в прямое число (clean number). Давайте покажем вам, как визуализировать более субъективные и нечеткие данные из качественных методов исследования пользователей, таким образом, чтобы сообщать основные идеи другим заинтересованным сторонам, чтобы им не нужно было просматривать обширные исследовательские отчеты.

«Цель визуализации — это не изображения, а проникновение в суть»

— Бен Шнейдерман, заслуженный профессор университета по информатике

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

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

 

Диаграмма сходства

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

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

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright terms and licence: CC BY-NC-SA 3.0

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

 

Карта эмпатии

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

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

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright terms and licence: CC BY-NC-SA 3.0

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

 

Карта путешествия пользователя

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

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

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

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

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright terms and licence: CC BY-NC-SA 3.0

 

В заключение

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

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

 

Ссылки и где узнать больше

Тереза ​​Тан (Teresa Tan), Диаграммы сходства: добавление цвета к нечетким данным, 2014:

http://www.extractable.com/insights/affinity-diagrams-adding-color-to-fuzzy-data

Рич Крендалл (Rich Crandall), Карта эмпатии, 2010:

https://dschool-old.stanford.edu/groups/k12/wiki/3d994/empathy_map.html

Кейт Каплан (Kate Kaplan), Картография путешествия в реальной жизни: обзор практикующих UX, 2016:

https://www.nngroup.com/articles/journey-mapping-ux-practitioners/

Автор – Вебби Клер (Webby Clare)

Оригинал статьи: http://webbyclare.com/design-thinking-the-gift-giving-experience/

Быстрый пост (я слишком долго его откладывала!), чтобы поделиться некоторыми наблюдениями, приобретенными знаниями и размышлениями о недавнем проведении «проекта дарения подарков» Стэнфордского института дизайна (Stanford Institute of Design‘s, d.school) с группой коллег в австралийской государственной службе (the Australian Public Service).

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

D.school делает это очень легким для координаторов, предоставляя им практически все материалы, необходимые для курса — руководство для координатора, листы участников и раздаточные материалы после курса (которые вы можете бесплатно скачать и использовать по лецензии CC BY -NC-SA здесь). Примечание —  недавно выпущенный виртуальный ускоренный курс делает это еще проще, поскольку он тоже эффективно снабжает координатора!

1. Материалы прототипирования. Наряду с распечатками руководства для координатора и раздаточного материала для участников, единственными дополнительными материалами, которые нужно организовать координатору, являются материалы прототипирования. Я сделала это довольно просто, дешево и легко — я обыскала стационарный шкаф и свои собственные шкафы дома, чтобы найти такие вещи, как: кусочки оберточной бумаги, фольги, резиновые полосы, цветную бумагу, старые цветные папки и множество переработанных упаковочных материалов (туалетные рулоны, картонные коробки, упаковки для яиц и т. д.). Я также взяла много клей-карандашей, кнопок, пластилина и скрепок. По сути — все, что я могла легко найти. Если бы у меня было больше времени, мне бы очень хотелось добавить такие вещи, как pipe-cleaners (щетки, проволка) и другие поделочные материалы (я пробовала Officeworks, но похоже у них нет этих материалов. Позже коллега предложил магазины типа Lincraft или Hot Dollar, которые я попробую в следующий раз).
2. Распечатка раздаточного материала для участников. Убедитесь, что вы выбрали опцию «разобрать по копиям» (collate) на копировальном аппарате при распечатке руководств участников! Я этого не сделала и в итоге потратила довольно много времени, вручную разбирая распечатки (не понимаю, почему «разбор по копиям» не является опцией по умолчанию для всех принтеров /копировальных аппаратов).      
3. Музыка/таймер. Курс рекомендует, чтобы вы показывали таймер и проигрывали музыку, но у нас не было доступа к проектору/громкоговорителям (плюс была большая официальная встреча, которая происходила в соседней комнате, поэтому мы пытались снизить уровень шума). Я просто следила за временем, используя секундомер на моем iPhone, и он отлично работал для нашей небольшой группы.
4. Размер группы. В группе было 9 человек, и это очень хорошее количество для прохождения курса в первый раз. Я бы определенно рекомендовала, чтобы в первый раз координаторы пробовали проводить курс с группой из 8-12 человек. Нечетное число участников было не идеальным — в итоге у нас была группа из трех человек (которая не работала отлично, но все же давала ощутить каждому вкус опыта дизайна), и я слегка манипулировала временными рамками и инструкциями, чтобы это сработало. Вот почему сокоординатор (или некоторые помощники) может быть действительно полезен — если бы было нечетное число участников, один из соорганизаторов мог бы участвовать, а не управлять.
5. Расчет времени. В целом, я думаю, что расчет времени сработал хорошо — мы закончили (включая подведение итогов/отчет) за 90 минут, как и планировалось. Иногда определенно чувствовалась спешка (и участники явно чувствовали себя некомфортно из-за этого), поэтому я думаю, что стоит подчеркнуть это и заранее дать участникам знать, что курс будет таким.
6. Разогрев. Потребовалось время, чтобы участники разогрелись и действительно погрузились в опыт. Я заметила, что первоначальные «интервью» были довольно формальными, спокойными, и было несколько неопределенных лиц. Но по мере того, как люди продвигались все дальше, вникали глубже в разговоры и начали ясно понимать возможные идеи/решения, разговоры стали более оживленными и восторженными. Если бы я снова проводила сеанс с группой участников, которые не знали друг друга, я бы попыталась провести быструю разминку после того, как пары были установлены — что-то веселое и быстрое, чтобы участники творчески мыслили и выстроили некую начальную связь/доверие/взаимопонимание.
7. Инструкция. Хотя целью упражнения является пересмотр опыта дарения подарка, некоторые из участников по-прежнему стремились к созданию лучшего подарка для своего партнера. Наверное, отчасти это потому, что легче проектировать и физически прототипировать продукт, а не услугу. Кроме того, на первом этапе интервью участникам предлагается спросить друг друга, как в последний раз они подарили подарок, поэтому некоторые из моих участников сосредоточились на создании лучшего подарка для этого конкретного сценария. В следующий раз я предоставлю участникам более общую инструкцию и, возможно, попрошу их поделиться не одним опытом, а несколькими (например, самый последний подарок, дающий опыт, самый положительный опыт, время, когда дарить подарок было трудно или неприятно), вместо того, чтобы фокусироваться только по самом последнем опыте. За этим нужно следить координатору и постоянно напоминать участникам, что они разрабатывают опыт, а не подарок.

 

Итак, это были мои ключевые приобретенные знания в качестве координатора…. Но как насчет ключевых знаний/мыслей участников…

1. Изображения против слов. Я работаю в среде, где мы постоянно используем слова! Наше общение очень сосредоточено на письменных электронных письмах, инструкциях, отчетах и ​​т. д. или устных отчетах/отзывах, полученных на встречах. Необходимость делать наброски идей определенно было тем, что вызывало дискомфорт у участников. Было много комментариев «но я не умею рисовать» и слегка расстроенных лиц. Но когда они вникли в суть упражнения и поняли, что им «нужно» рисовать, они, казалось, приняли это (или, по крайней мере, стали меньше беспокоиться об этом), будучи менее, чем идеальным художником!
2. Фокусировка на быстром получении количества. Опять же, это была трудная часть упражнения для многих участников. Придумывание множества сумасшедших идей — это не то, что мы делаем регулярно, но определение цели («вы должны придумать хотя бы 5 идей») заставляет всех думать немного шире (и, возможно, немного безумно), чем они могли бы, если бы им просто нужно было разобраться с одним решением.
3. Вовлечение пользователей заранее. Если бы участникам было предложено сделать редизайн опыта дарения подарка для своего партнера, не разговаривая или не взаимодействуя с ним, тогда результаты определенно были бы другими (и, вероятно, значительно худшими). Это упражнение четко демонстрирует, почему так важно взаимодействовать с пользователем на ранней стадии процесса и понимать их потребности и желания.

 

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

 

 

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

 

Lean UX — что это?

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

Author/Copyright holder: Vimeo. Copyright terms and licence: Public Domain

 

Потребность в предположениях в Lean UX

В традиционном UX проект построен на охватывании и выполнении требований. Цель — обеспечить, чтобы результаты были максимально подробными и отвечали требованиям, изложенным в начале проекта.

Lean UX немного отличается. Вы не ориентированы на подробные результаты. Вы стремитесь произвести изменения, которые улучшают продукт здесь и сейчас — в основном, чтобы улучшить результат в лучшую сторону.

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

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

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

Стандартные вопросы:

• Кто наши пользователи?
• Для чего используется продукт?
• Когда он используется?
• В каких ситуациях он используется?
• Какая будет самая важная функциональность?
• Каков самый большой риск для доставки продукта?

 

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

Author/Copyright holder: visualpun.ch. Copyright terms and licence: CC BY-SA 2.0

 

Создание гипотезы в Lean UX

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

Пример:

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

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

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

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

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

 

Минимальный жизнеспособный продукт и Lean UX

Минимальный жизнеспособный продукт (Minimum Viable Product, MVP) — это основная концепция Lean UX. Идея состоит в том, чтобы создать наиболее простую версию идеи, протестировать ее, и если нет никаких ценных результатов, отказаться от нее. Многообещающие MVP могут быть затем включены в дальнейшие этапы дизайна и разработки без особых проблем.

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

Author/Copyright holder: Eric delcroix. Copyright terms and licence: CC BY-NC-SA 2.0

 

Исследование пользователей и тестирование в Lean UX

Исследование и тестирование пользователей по самой природе Lean UX основаны на тех же принципах, что и в традиционных средах UX. Тем не менее, этот подход имеет тенденцию быть «быстрым и грязным» — результаты должны быть предоставлены до начала следующего Agile Sprint; поэтому гораздо меньше внимания уделяется мощным, тщательно документированным выводам и больше внимания уделяется необработанным, сырым данным.

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

 

Заключение

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

Header Image: Author/Copyright holder: Rosenfeld Media. Copyright terms and licence: CC BY 2.0

 

 

 

Автор — Андреас Комнинос (Andreas Komninos)

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

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

Интуитивный дизайн — «Относится к внешнему виду».

Этот уровень дизайна относится к ощутимым качествам объекта и тому, какие чувства они вызывают у пользователя/наблюдателя. Например, фамильные старинные часы не имеют больше возможностей или функций, определяющих время, чем маленькие, безликие часы каминной полки, но интуитивные (глубоко укоренившиеся, бессознательные, субъективные и непроизвольные чувства) качества отличают эти два объекта в глазах владельца. Большая часть времени, затраченного на разработку продукта, теперь посвящена интуитивному дизайну, поскольку большинство продуктов в определенной группе (например, горелки/фонарики, чайники, тостеры и лампы) имеют тенденцию предлагать один и тот же или аналогичный набор функций, поэтому внешние аспекты помогают отличить продукт от конкурентов. То, что мы тут подразумеваем, — это «брендинг», а именно акт различения одного продукта от другого, для чего применяют не преимущества, которые они предлагают пользователю, а используют взгляды, убеждения, чувства пользователей и то, что они хотят чувствовать, чтобы вызывать такие эмоциональные реакции.

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

Поведенческий дизайн — «… имеет отношение к удовольствию и эффективности использования».

Поведенческий дизайн, вероятно, чаще всего называют удобством использования (юзабилити), но эти два термина в основном касаются практических и функциональных аспектов продукта или всего того, что мы можем использовать в нашей среде. Поведенческий дизайн (мы будем использовать этот термин вместо юзабилити с этого момента) заинтересован, например, в том, как пользователи выполняют свою деятельность, насколько быстро и точно они могут достичь своих целей и задач, сколько ошибок пользователи делают при выполнении определенных задач и насколько хорошо продукт учитывает как опытных, так и неопытных пользователей. Поведенческий дизайн, пожалуй, легче всего тестировать, поскольку уровни производительности можно измерить, когда физические (например, ручки, кнопки, рычаги, переключатели и ключи) или используемые части объекта будут изменены. Например, кнопки, ответственные за две отдельные операции, могут располагаться на разных расстояниях друг от друга, чтобы проверить, сколько времени потребуется пользователю для выполнения двух задач последовательно. В качестве альтернативы, частота ошибок может быть измерена с использованием той (тех) же манипуляции(ий). Примеры опыта на поведенческом уровне включают удовольствие, получаемое от возможности найти контакт и немедленно позвонить на мобильном телефоне, а также легкость печатания на клавиатуре компьютера, сложность ввода на маленьком сенсорном устройстве, например, iPod Touch и наслаждение, которое мы чувствуем при использовании хорошо продуманного контроллера компьютерной игры (например, по моему скромному мнению, панель управления N64). Поведенческий уровень в основном относится к эмоциям, которые мы испытываем в результате выполнения или невыполнения наших целей. Когда продукты/объекты позволяют нам выполнять свои задачи с минимальными трудностями и небольшими сознательными усилиями, эмоции, скорее всего, будут положительными. Напротив, когда продукты ограничивают нас, заставляют нас менять или корректировать наши цели в соответствии с их ограничениями или просто вынуждают нас быть пристально внимательными во время использования, мы более склонны испытывать опыт негативных эмоций.

Рефлективный дизайн — «… рассматривает рационализацию и интеллектуализацию продукта.

Могу ли я рассказать историю об этом? Обращена ли она к моей самооценке, к моей гордости?»  Это самый высокий уровень эмоционального дизайна; представляющий сознательный уровень мысли, где мы сознательно приближаемся к дизайну; взвешивая свои плюсы и минусы, судя по нашей более нюансной и рациональной стороне и извлекая информацию, чтобы определить, что это значит для нас как индивидуума. Рефлективное мышление позволяет нам рационализировать информацию внешней среды, чтобы влиять на поведенческий уровень. Возьмем, например, умные часы (smartwatches)/ «Исследователи Jaewon Choi и Songcheol Kim из Корейского университета изучили намерения пользователей пользоваться умными часами по двум основным факторам: восприятие пользователем устройства как технологического новшества и как роскошного модного продукта. Взгляд пользователей на умные часы в качестве технологической инновации связан с их восприятием полезности устройства и простоты использования (поведенческий уровень). С другой стороны, взгляд пользователей на умные часы как на роскошный модный продукт связан с их восприятием того, насколько они будут радоваться часам, и с уровнями самовыражения, которые им предоставит устройство, то есть способность выражать себя и улучшить свой имидж. И наслаждение, и самовыражение зависит от интуитивного уровня («Выглядят ли часы красиво?»), но также и от рефлекторного уровня («Что подумают мои друзья, когда увидят меня в этих часах?»). Рефлективный уровень взаимодействует с последствиями поведенческого уровня — пользователи могут смириться с трудностями и недостатками в удобстве использования умных часов, потому что они считают, что они получат другие, нефункциональные преимущества от него. Первая версия умных часов Apple имела множество функциональных недочетов и проблем юзабилити, но это не помешало компании получить второй по величине мировой доход в часовой индустрии в течение первого года продажи!

В заключение

Здесь мы представили три уровня дизайна Дона Нормана: интуитивный, поведенческий и рефлекторный. Интуитивный уровень дизайна относится к первому впечатлению от дизайна, как с точки зрения восприятия пользователем продукта, так и с точки зрения чувств, которые возникают у пользователя из-за продукта. Поведенческий уровень относится к опыту использования продукта. Мы часто думаем об этом уровне, когда мы думаем о пользовательском опыте. Рефлекторный уровень относится к размышлению пользователя о продукте, как до, во время, так и после использования. Все три уровня объединяются, чтобы сформировать весь опыт продукта.

Ниже следует идеальное видео: три способа хорошего дизайна делают нас счастливыми от Дона Нормана

Ссылки и где узнать больше

Choi, J., & Kim, S. (2016). «Являются ли умные часы IT-продуктом или модным продуктом? Исследование факторов, влияющих на намерение использовать умные часы.» Компьютеры в поведении человека, 63, 777-786.

 

(далее…)

Автор — Дитте Мортенсен (Ditte Mortensen)
(далее…)