Недорогие способы интегрировать проектирование опыта пользователя? [закрытый]

One low cost method is using a site like http://usertesting.com. It's relatively cheap and it enables you to do quick and easy hallway testing.

In our case it was even easier than to actually go out and find people in the hallway!

Бумажное прототипирование - отличный способ взаимодействия дизайна перед фиксацией кода или даже пикселей. Это больше, чем просто рисунок на бумаге, см. Papper Prototyping (книга), это методология недорогого прототипирования. Некоторое время назад я пробовал это в одном проекте, и это действительно помогло. Любой прототип, который дает вам то, что вы можете запустить с пользователем и получить обратную связь, действительно поможет. смотрите также http://en.wikipedia.org/wiki/Paper_prototyping . РЕДАКТИРОВАТЬ (конечно, вам нужно найти человека для тестирования, который не знает о вашем приложении и является чем-то вроде одного из ваших пользователей. Если для использования приложения требуется опыт в предметной области, вам понадобится пользователь, у которого есть это. Если вы делаете приложение для Spear Fishermen, вам, вероятно, понадобится одно приложение для тестирования)

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

1. Как другие люди делали то же самое UI
2. Лучшие практики разработки различные типы пользовательских интерфейсов

Затем, когда у меня что-то работало, я садился с новым пользователем, который никогда не видел продукт, и просто наблюдал, как они его используют, и делал заметки о том, как они интерпретировали интерфейс и как они взаимодействовал с ним.

Это будет зависеть от того, на каких языках вы используете для разработки, но с помощью инструмента проектирования пользовательского интерфейса, такого как Expression Blend, вы можете довольно быстро разработать оболочку пользовательского интерфейса (в данном случае в WPF или Silverlight). Вы должны иметь возможность сделать то же самое в выбранной вами технологии. Просто внедрите достаточно кода, чтобы иметь возможность перемещаться по пользовательскому интерфейсу.

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

Но будьте осторожны, не надо »

Я бы сказал тест на удобство использования в коридоре одновременно эффективен и дешев:

Возьмите следующего человека, который проходит мимо коридор и заставить их попытаться используйте только что написанный код. Если вы это сделаете это пяти человек, вы узнаете 95% того, о чем можно узнать usability problems in your code.

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

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

Почему? Сколько раз вы сталкивались, читали ли вы, люди, у которых нет выбора в используемом программном обеспечении? Будь то массовые маркетинговые кампании (Windows Vista) или корпоративные распоряжения, сотни, тысячи, даже миллионы людей привязаны к использованию определенного программного обеспечения. Разве это помогает простым цифрам?

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

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

Вы также не нужна «формальная» лаборатория юзабилити для проведения юзабилити-тестирования. Я проводил тестирование удобства использования в пустых кабинах в тихой части здания, а мониторы спокойно сидели в соседнем помещении.

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

Наконец, рассмотрите идею персон. Алан Купер хорошо описывает их полезность в своей превосходной книге «Заключенные управляют убежищем», но идея хорошо развита в книге «Жизненный цикл личности». Еще одна хорошая книга, которая может дать вам хорошие идеи о том, как включить и интегрировать удобство использования в процесс разработки, - «Дизайн взаимодействия: помимо взаимодействия человека и компьютера». (Предварительное предупреждение: последние два больше подходят для учебников по стилю книг и их нелегко читать, но они содержат не только тонны полезной информации, но и много-много полезных ссылок.)

Алан Купер хорошо описывает их полезность в своей превосходной книге «Заключенные управляют убежищем», но идея хорошо развита в книге «Жизненный цикл личности». Еще одна хорошая книга, которая может дать вам хорошие идеи о том, как включить и интегрировать удобство использования в процесс разработки, - «Дизайн взаимодействия: помимо взаимодействия человека и компьютера». (Предварительное предупреждение: последние два больше подходят для учебников по стилю книг и их нелегко читать, но они содержат не только тонны полезной информации, но и много-много полезных ссылок.)

Алан Купер хорошо описывает их полезность в своей превосходной книге «Заключенные управляют убежищем», но идея хорошо развита в книге «Жизненный цикл личности». Еще одна хорошая книга, которая может дать вам хорошие идеи о том, как включить и интегрировать удобство использования в процесс разработки, - «Дизайн взаимодействия: помимо взаимодействия человека и компьютера». (Предварительное предупреждение: последние два больше подходят для учебников и их нелегко читать, но они содержат не только тонны полезной информации, но и множество полезных ссылок.)

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

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

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

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

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

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

Первым шагом для разработчиков (как и для меня) может быть изменение мышления. Это необходимо для того, чтобы выслушать критику пользователя к нашему любимому пользовательскому интерфейсу, не прибегая к аргументации. Выступая в роли пользователя, я получил очень агрессивную реакцию от разработчиков, особенно от юниоров, когда указал на проблемы с пользовательским интерфейсом. В идеале избегайте разговоров с пользователем. Для того, чтобы сделать "Hallway test" Конаминман получил пользователя, дал ей задание и молча наблюдал за ее борьбой. Воздерживаться от помощи или пролития инструкций! Если пользователь теста дает обратную связь, не спорьте: если она попала в беду, то обязательно есть проблемы . Упростите пользовательский интерфейс для исправления проблемных шагов и попробуйте еще раз, с другим пользователем. С помощью этого процесса вы строите знания так, чтобы ваш следующий пользовательский интерфейс не имел таких проблем.

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

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

.