WikiDer > Гибкая инженерия юзабилити - Википедия

Agile usability engineering - Wikipedia

Гибкая инженерия юзабилити это метод, созданный из комбинации гибкая разработка программного обеспечения и юзабилити-инжиниринг практики.[1] Agile-инженерия юзабилити пытается применить принципы быстрой и итеративной разработки в области пользовательский интерфейс дизайн.

Ранние реализации юзабилити-инженерии в ориентированный на пользователя дизайн пришел в профессиональную практику в середине – конце 1980-х годов. Ранние реализации гибкой разработки программного обеспечения появились в середине 1990-х годов. Только в последние несколько лет взаимодействие человека с компьютером Сообщество увидело широкое признание гибкой юзабилити-инженерии.[1]

История

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

Ранний пример юзабилити-инженерии в гибкой среде разработки программного обеспечения можно найти в работе Ларри Константин и Люси Локвуд, разработавшая информацию для класса в браузере. система управления. Во время этого процесса команда дизайнеров работала напрямую с командой обучения, которая служила как профильные эксперты и представитель конечные пользователи разработать начальную роль пользователя модели и перечень кейсов. Этот процесс имитирует совместный дизайн. С помощью этого материала были итеративно разработаны макеты для достижения желаемой цели - «строгой цели проектирования - обеспечения немедленного и продуктивного использования системы на основе одностраничного учебника».[2]

В следующей таблице показаны различия и сходства процессов легкого веса по сравнению с процессами тяжелого веса, предложенные Томасом Меммелем.[1]

Процессы с тяжелым весомЛегкие процессы
Подробная актуальная документация и моделиКарточные и нарисованные от руки абстрактные модели
Путешествовать налегке
Общайтесь, а не документируйте
Прототипы с высокой точностьюАбстрактные прототипы, используйте самые простые инструменты
Разрабатывайте и проверяйте концепции с отзывами пользователей
Повторять		Храбрость
Дизайн для нужд (задач пользователя), а не ожиданий пользователя
Получайте дизайн из моделей, а не из постоянной обратной связи с пользователем
Длительные оценки юзабилити, семинары с интенсивной интеграцией заинтересованных сторонБыстрые проверки юзабилити
Нет необходимости оценивать правильность моделей

Методы

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

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

Пол Макинерни и Фрэнк Маурер провели тематическое исследование подтверждая это UI дизайн практика требует корректировки; особенно для того, чтобы адаптировать итеративную разработку. Однако был сделан вывод, что в результате UI дизайн конечно не хуже, чем то, что было бы сделано при стандартном подходе тяжеловесов.[4]

Основные практики в гибкое моделирование как описано Скотт Эмблер, помогите описать фокус в гибкой разработке удобства использования. Основные методы включают валидацию, командную работу, простоту, мотивацию, производительность, документацию, а также итеративную и инкрементную.[5]

Модифицированный процесс гибкой разработки с включенными инструментами удобства использования был разработан и представлен в CHI '08 Расширенные рефераты по человеческому фактору в вычислительных системах. Инструменты юзабилити включают расширенные модульные тесты для оценки юзабилити, экстремальные персонажи расширить типичный экстремальное программирование история пользователя, исследования пользователей для расширения концепции экстремального программирования для локального клиента, экспертные оценки удобства использования для решения для этого случая проблемы и тесты юзабилити для решения проблем представителя клиента на месте.[6]

вопросы

Из-за борьбы за включение традиционных методов проектирования удобства использования в гибкую среду возникло множество проблем. Без исчерпывающих ресурсов практикующие пытались следовать образцам других, которые ранее добивались успеха.[7] В таблице 2 представлена ​​таблица проблем, симптомов и возможных решений, разработанная Линн Миллер и Дезире Си и представленная в CHI '09 Extended Abstracts on Human Factor in Computing System.

В следующей таблице приведены основные проблемы, с которыми сталкиваются специалисты по пользовательскому опыту при выполнении Agile UCD.[7]

ПроблемаСимптомыВозможные решения
Недостаточно времени на дизайн• Разработчики ждут дизайна
• Снижение качества дизайна
• Дизайн не подтвержден покупателями.		• Отдельные и параллельные треки UX-дизайна / разработчика[8][9][10][11][12]
• Сделайте UX-действия небольшими, постепенными.[8][9]
• Формирующее юзабилити-тестирование RITE [13][14]
• Быстрый контекстный дизайн[15]
• "Студия дизайна"[16]
• Разделение дизайна[8]
• Объедините различные UX-действия в одно занятие.[17]
• Привлечь пользователя (и данные) к вам[17]
• Упростить процесс сбора требований[8][9][10][11][18]
[8][9][10][11][18]
Спринты слишком короткие• Дизайн нельзя завершить вовремя
• Нет времени на юзабилити-тестирование
• Нет времени устанавливать контакт с клиентом		• Отдельные и параллельные треки UX-дизайна / разработчика [8][9][10][11][12]
• Сделайте UX-действия небольшими, постепенными.[8][9]
• Формирующее юзабилити-тестирование RITE[13][14]
• Быстрый контекстный дизайн[15]
• "Студия дизайна"[16]
• Разделение дизайна[8]
• Объедините различные UX-действия в одно занятие.[17]
• Предоставить вам пользователя (и данные)[17]
• Упростить процесс сбора требований[8][9][10][11][18]
Недостаточно отзывов пользователей• Обратная связь недостаточно ранняя
• Нет данных для принятия мер - правило мнений
• Продукт не прошел валидацию		• Отдельные и параллельные треки UX-дизайна / разработчика[8][9][10][11][12]
• Сделайте UX-действия небольшими, постепенными.[8][9]
• Формирующее юзабилити-тестирование RITE[13][14]
• Быстрый контекстный дизайн[15]
• "Студия дизайна"[16]
• Разделение дизайна[8]
• Объедините различные UX-действия в одно занятие.[17]
• Предоставить вам пользователя (и данные)[17]
• Упростите процесс сбора требований[8][9][10][11][18]
Слабый гибкий «клиент»[16]• Конечные пользователи и клиенты не будут участвовать
• Невозможно получить бай-ин от остальной команды
• Принимаются необоснованные решения		• Пользователь UX может выступать в роли гибкого клиента.[19]
• Каждый UX-человек работает в одной scrum-команде[19]
• Выбирайте, с какими scrum-командами работать с умом[18]
• Утвержденные проекты передаются разработчикам для реализации[8][9]
• UX участвует в планировании цикла,[9] предоставление соответствующих отзывов пользователей[8]
• Никакие функции не входят, если что-то не выходит[18]
UX не работает полный рабочий день в одной agile-команде• Время UX, потраченное на множество встреч, а не на дизайн и итерацию
• Деморализация из-за падения качества UX		• Пользователь UX может выступать в роли гибкого клиента.[19]
• Каждый UX-человек работает в одной scrum-команде[19]
• Выбирайте, с какими scrum-командами работать с умом[18]
• Утвержденные проекты передаются разработчикам для реализации[8][9]
• UX участвует в планировании цикла,[9] предоставление соответствующих отзывов пользователей[8]
• Никакие функции не входят, если что-то не выходит[18]
Нет планирования спринта / цикла• Большое количество функций / ошибок
• Обратная связь по приоритетам игнорируется.
• Отсутствие контроля над сроками разработки		• Пользователь UX может выступать в роли гибкого клиента.[19]
• Каждый UX-человек работает в одной scrum-команде[19]
• Выбирайте, с какими scrum-командами работать с умом[18]
• Утвержденные проекты передаются разработчикам для реализации[8][9]
• UX участвует в планировании цикла,[9] предоставление соответствующих отзывов пользователей[8]
• Никакие функции не входят, если что-то не выходит[18]
Отзывы пользователей игнорируются• Набор функций высечен из камня
• Нет времени вносить изменения
• Изменение порядка функций запрещено.		• Пользователь UX может выступать в роли гибкого клиента.[19]
• Каждый UX-человек работает в одной scrum-команде[19]
• Выбирайте, с какими scrum-командами работать с умом[18]
• Утвержденные проекты передаются разработчикам для реализации[8][9]
• UX участвует в планировании цикла,[9] предоставление соответствующих отзывов пользователей[8]
• Никакие функции не входят, если что-то не выходит[18]
Отсутствует "общая картина"• Нет общего видения или конечной цели
• Слишком много внимания уделяется деталям.
• Трудно расставить приоритеты / принять дизайнерские решения		• Убедить agile-команду принять Cycle Zero[8][9][10][11][20]
[8][9][10][11][18]
• Рассмотрение целей дизайна с разных уровней детализации (продукт, выпуск, возможности, фрагмент дизайна[12]
Плохое общение• Неправильно понятый дизайн
• Agile-команда не верит в дизайн
• Важная информация потеряна		• Вовлекайте разработчиков в процесс проектирования[8][9]
• Удобство использования включено в критерии приемки[8][9]
• Ежедневный контакт для проверки прогресса[8][9]
• Дизайн карточек для фуршетов.[8]
• Выдача карточек для отчетов об удобстве использования.[8]
• Документы предназначены для команды разработчиков.[8]
Команда не совмещена• Отсутствие чувства команды - отсутствие доверия
• Языковые и / или временные барьеры
• Недостаточно общения		• Инструменты для удаленной работы (замена телефона и Интернета)[11][18]
• Совместное размещение для планирования цикла[11][18]
Проблемы с зависимостью• Требование участия неагильных команд (например, специалистов по маркетингу, юристов)• Лидер схватки или фасилитатор с сильными навыками убеждения может быстро продвинуть дело.[18]

Рекомендации

  1. ^ а б c Меммель, Т. (2006). Agile Usability Engineering. Получено 4 ноября 2013 г. из http://www.interaction-design.org/encyclopedia/agile_usability_engineering.html
  2. ^ Константин, Л. Л., Локвуд, Л. А. Д. (2002). Разработка веб-приложений, ориентированная на использование. Программное обеспечение IEEE, 19 (2), 42-50. Дои:10.1109/52.991331
  3. ^ Стобер, Т., Хансманн, У. (2010). Гибкая разработка программного обеспечения: лучшие практики для крупных проектов разработки программного обеспечения. (п. 3.7.2). Берлин, Гейдельберг: Springer-Verlag.
  4. ^ Макинерни, П. и Маурер, Ф. (2005 г., ноябрь). UCD в Agile проектах: команда мечты или странная пара ?. ACM Interactions, 12 (6), 19-23. DOI :: 10.1145 / 1096554.1096556
  5. ^ Эмблер, Скотт В. (2002). Гибкое моделирование: эффективные практики экстремального программирования и единый процесс. Доступна с http://common.books24x7.com/toc.aspx?bookid=3755
  6. ^ Волькерсторфер П., Манфред Т. и др. Исследование гибкого процесса юзабилити. CHI '08 расширенные рефераты по человеческому фактору в вычислительных системах, 5 апреля 2008 г., Нью-Йорк, штат Нью-Йорк. Дои:10.1145/1358628.1358648
  7. ^ а б Си, Д., Миллер, Л. (2009). Гибкий пользовательский интерфейс SIG. CHI '08 расширенные рефераты по человеческому фактору в вычислительных системах, 751-2754. Дои:10.1145/1520340.1520398
  8. ^ а б c d е ж грамм час я j k л м п о п q р s т ты v ш Икс у z аа ab ac Си, Д. Адаптация исследований юзабилити для гибкого дизайна, ориентированного на пользователя. Журнал исследований юзабилити 2, 3 (2007), 112--132
  9. ^ а б c d е ж грамм час я j k л м п о п q р s т ты v ш Миллер, Л., Пример использования клиентского вклада для успешного продукта, Труды конференции по гибкой разработке, стр.225-234, 24–29 июля 2005 г. Дои:10.1109 / ADC.2005.16
  10. ^ а б c d е ж грамм час я Федерофф, М., Вилламор, К., Миллер, Л., Паттон, Дж., Розенштейн, А., Бакстер, К., Келкар, К., Экстремальное удобство использования: адаптация исследовательских подходов к гибкой разработке, Расширенные тезисы CHI '08 «Человеческий фактор в вычислительных системах», 05–10 апреля 2008 г., Флоренция, Италия. Дои:10.1145/1358628.1358666
  11. ^ а б c d е ж грамм час я j k Си Д., Миллер Л., Оптимизация гибкого проектирования, ориентированного на пользователя, Расширенные рефераты по человеческому фактору в вычислительных системах CHI '08, 05–10 апреля 2008 г., Флоренция, Италия. Дои:10.1145/1358628.1358951
  12. ^ а б c d Паттон, Дж. Двенадцать новых лучших практик для добавления работы UX в Agile-разработку. 3 октября 2008 г .: «Архивная копия». Архивировано из оригинал на 2013-09-14. Получено 2013-12-14.CS1 maint: заархивированная копия как заголовок (связь)
  13. ^ а б c Медлок, М., Террано, М., Уиксон, Д. Использование метода RITE для улучшения продуктов: определение и тематическое исследование. Материалы УПА 2002.
  14. ^ а б c Шраг, Дж. Использование формирующего юзабилити-тестирования в качестве инструмента быстрого проектирования пользовательского интерфейса. Материалы УПА 2006.
  15. ^ а б c Хольцблатт К., Венделл Дж. Б. и Вуд С. (2005) Быстрое контекстное проектирование. Морган Кауфманн/ Elsevier.
  16. ^ а б c d Унгар, Дж., Уайт, Дж., Гибкий дизайн, ориентированный на пользователя: войдите в дизайн-студию - тематическое исследование, расширенные тезисы CHI '08 по человеческим факторам в вычислительных системах, 5–10 апреля 2008 г., Флоренция, Италия. Дои:10.1145/1358628.1358650
  17. ^ а б c d е ж Sy, D. Формирующие исследования юзабилити для открытых задач. Материалы УПА 2006.
  18. ^ а б c d е ж грамм час я j k л м п о п Си Д., Миллер Л., Неофициальная SIG: Оптимизация Agile UCD, CHI 2007
  19. ^ а б c d е ж грамм час Миллер, Л. Дизайнеры взаимодействия и гибкая разработка: партнерство. Материалы УПА 2006.
  20. ^ Шарп, Х., Биддл, Р., Грей П., Миллер, Л., Паттон Дж., Гибкая разработка: возможность или причуда ?, Расширенные тезисы CHI '06 по человеческим факторам в вычислительных системах, 22–27 апреля 2006 г., Монреаль, Квебек, Канада. Дои:10.1145/1125451.1125461

дальнейшее чтение