Usability.by

Сделать в России простую и удобную платёжную систему как для продавца, так и для покупателя - серьёзный вызов для любого UX-специалиста/проектировщика интерфейсов. Чем интереснее и сложнее задача, тем больше опыта и знаний получаешь в процессе работы. Именно над такой задачей я работаю и в этой статье хотел бы поделиться полученным опытом по перепроектированию и доработке системы интернет-платежей A1Pay.

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

Прочитать кейс полностью

Первым результатом сотрудничества наших читателей стал совместный перевод статьи “Case study of agile and UCD working together”. Сегодня мы публикуем этот перевод:

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

Этот реальный случай демонстрирует, как команда проектирования UX сайта ComputerWeeekly была интегрирована в группу разработки, придерживающейся гибких методологий. Важно заметить, что сами по себе методы, которые мы использовали, не гарантируют успешное завершение проекта. Люди могут как сделать, так и провалить любой проект. Найти и удержать “правильных” людей - ключ к успеху проекта.
Читать полностью »

В блоге Usemenot опубликован перевод статьи Джареда Левандовски “Doing More With Less Time”:

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

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

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

Прочитать весь перевод

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

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

5-ти минутный видеоролик “The Right Way to Wireframe” сделан на основе одноименного воркшопа Фреда Бичера, Руса Ангера, Тодда Заки, автора книги “Prototyping“, и Вила Эванса на конференциях SXSW 201 и interaction10. Вы сможете увидеть результаты работы специалистов на каждом из этапов процесса проектирования: от анализа требований и изучения аудитории, до создания графического дизайна.

В 8-ми минутном сюжете “Переключаясь на экономию энергии” канал Евроньюс показал весь цикл Human-Centered Design от исследования пользователей, проектирования интерфейсов для iPhone до юзабилити-тестирования в реальных и в лабораторных условиях, eye-tracking и т.д.

В сюжете показано, как команда под руководством Джулио пытается сделать систему, которая называется Energy Life, как можно более интуитивной. Главная проблема по их мнению – это понятный интерфейс.

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

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

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

“Мы используем самые разные методики, – говорит профессор психологии университета Лучано Гамберини, – от структурированного видеоанализа до элементов когнитивных наук, и даем советы разработчикам в реальном времени. Каждый день мы заново обкатываем программу с теми изменениями, которые программисты внесли в нее накануне и сообщаем им: “осторожно, в этой операции трое из пяти испытуемых допустили ошибки”.

Видео сценариев использования программы

Сюжет на сайте Евроньюс на русском языке
Сайт проекта BeAware

Тира Рауч (Thyra Rauch) — работает в IBM уже почти 23 года. Она сыграла важную роль в усилении отрасли UI, роли пользователя в целом ряде областей для различных продуктовых решений. Истории пользователей и работа с архивными документами — неотъемлемая часть её процесса проектирования. Тира также использует целый спектр различных технологий, таких как контекстные запросы, постановка задач, сбор требований и приоритетов, разработка прототипов и проектирование дизайна, основанных на принципах human-centered design.

Тира активный член UPA с 1992 года, 2 года была президентом этой ассоциации и в настоящее время в третий раз входит в состав совета директоров. Она является автором 10 патентов в области дизайна пользовательских интерфейсов.

Тира - была ключевым докладчиком конференции User Experience Russia - UPA Europe 2009, которая состоялась в октябре 2009 года в Москве. Данная статья написана специально по просьбе организаторов конференции.

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

Читайте всю статью Тиры Рауч на сайте сообщества SoftwarePeople

В прошедшую субботу Сергей Мордович постарался обратить внимание участников курса IT-предпринимательства на полезные навыки, которые используются в практике интерэкшн-дизайнеров. Презентация получила позитивный отклик в сообществе, предлагаю её вниманию читателям Usability.by.

Ярослав Перевалов в статье на сайте usability.ru рассказывает о том, как проектировщику провести минимальный комплекс работ по бизнес-аналитике, написанию и согласованию концепции продукта в условиях сжатых сроков и изначального отсутствия согласованного ТЗ:

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

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

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

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

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

Такой (заполненный) шаблон я и называю карточкой продукта и собираюсь поделиться им сейчас с вами.

Читать полностью

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

Прочитать всю статью Джеффа Джонсона на сайте Software People

Максим Гулевич, Директор по исследованиям и разработке ITONLINE GROUP (Москва)

В преддверии конференции User Experience Russia 2009 публикуем, пожалуй одну из лучших презентаций User Experience Russia 2008, презентацию Максима Гулевича, разбитую на нескольких тематических частей.

Креатив, мотивация, увольнение, дизайнер, руководитель

Геннадий Драгун, Lead Information Architect EPAM

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

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

Так чьей же помощью может воспользоваться проектировщик взаимодействия для оценки пользовательского интерфейса?
Читать полностью »

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

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

Хорошее описание персонажа, включает в себя:

• Цели
• Социальное положение
• Описание рабочего процесса
• Описание окружения
• Уровень подготовки
• Неудовлетворённости и ожидания

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

В июле 2008 The Power of Information Taskforce поручила UX агентству Bunnyfoot провести анализ положительных и отрицательных сторон правительственных веб-сайтов. В ходе этого исследования было установлено, что некоторые сайты содержат много ошибок, которые создают трудности во взаимодействии с ними. Например:

• Не позволяют людям легко ориентироваться на сайт
• Не позволяют поисковым системам, таким как Google, найти что-то на своём сайте
• Не говорят на одном языке с пользователями

Компанию COI попросили разработать юзабилити-гайдлайны для использования веб-разработчиками и веб-редакторами различных государственных сайтов. Цель всей проделанной работы заключается в повышении внимания к вопросам юзабилити и повышение качества государственных веб-сайтов.

Гайдлайны охватывают 8 тем:

• Layout и дизайн
• Навигация
• Написание контента
• Элементы содержания
• Формы
• Поиск
• Качество и стандарты
• Общие страницы (например, главная страница)

Презентация Алексея Копылова на конференции TrainingLabs

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

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

3. Также имеется несколько способов достижения одного и того же результата. В докладе показаны преимущества и недостатки каждого способа.

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

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

IDEO в партнёрстве с International Development Enterprises (IDE), Heifer International, ICRW и фондом Билла и Мелинды Гейтс разработали инструментарий для применения практик Human-Centered Design для поиска новых решений проблем в сложных условиях и местах, где в них особенно нуждаются.

Инструментарий HCD содержит описания различных методов и инструментов сбора информации, а также рекомендации по проведению исследований. Кроме этого, есть рабочие бланки и материалы. Многое разбирается на примерах (case study)

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

О других средствах прототипирования вы можете узнать из презентации “Обзор средств прототипирования веб-сайтов”

Алан Купер в книге “Психбольница в руках пациентов” писал о личных и корпоративных целях следующее:

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

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

Личные цели:

• Не чувствовать себя глупо;
• Не совершать ошибок;
• Выполнить адекватный объем работы;
• Развлечься (или хотя бы не страдать от скуки);

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

Корпоративные цели:

• Увеличить прибыль;
• Увеличить рыночную долю;
• Победить конкурентов;
• Нанять больше сотрудников; предложить новые продукты и услуги;
• Выпустить акции компании в свободное обращение;

Психологи, изучающие рабочую обстановку, применяют термин «гигиенические факторы», которые Сол Геллерман (Saul W. Gellerman) определяет как «элементы, обязательные для эффективной мотивации, но не способные мотивировать самостоятельно». Освещение в вашем офисе – гигиенический фактор. Вы ведь не ходите на работу только потому, что там хорошее освещение, но если бы освещения не было, вы не ходили бы туда вовсе. Все корпоративные и практически цели, приведенные в списке, являются гигиеническими. С точки зрения корпорации, это все важные цели, однако работу выполняет не корпорация, а люди, а для людей важнее цели личные.”

В книге “Об интерфейсе” Алан более подробно раскрывает вопросы выявления и проектирования для целей пользователя.

В стать “User Goals and Corporate Goals” приводится пример конфликта личных целей пользователя и корпоративных целей на примере организации взаимодействия с вендинговым аппаратом:
Читать полностью »

Ким Гудвин, автор книги “Designing for the Digital Age” и сотрудница компании Cooper, в своей заметке “A “to do” list for integrating design into your organization” рассуждает о 5 аспектах успешной интеграции проектирования в процессы компании:

1. Процесс
2. Структура
3. Умения
4. Инструменты
5. Культура

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

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