Не знаю - кто тут виноват. Толи организаторы мероприятия, не правильно определившие ЦА, толи сам докладчик, заранее не изучивший реалии национального IT-бизнеса. Но большая часть лекций была ориентирована на компании, зарабатывающие и имеющие возможность тратить деньги на юзабилити, как Майкрософт, IBM, Apple - не меньше. Много обобщенной информации. Мало примеров и конкретики. В итоге состояние аудитории до такой степени накалилось и стало откровенно враждебным к докладчику, что на последнего было больно смотреть.
Семинар состоял из 5-ти лекций, посвященных разработке и тестированию пользовательских интерфейсов.
Особое внимаение было уделено методам тестирования интерфейсов.
> Эвристическа (экспертная) оценка
Зачастую используется для удешевления процесса. Может использована на первом этапе работы над удобством интерфейса. Не дает полную картину. В дальнейшем все равно требуется откатка на юзверях.
> Фокус-группа
Задача - получить максимально приближенную к пользователям интерфейса группу 10 -15 человек. Для удешевления можно попробовать использовать в качестве фокус группы - маркетологов, владельцев, разработчиков. Но это будет взгляд "изнутри".
Каким бы обдуманным он ни был, несет свои значительные отклонения.
> Опросы пользователей
Тут есть большая проблема в том, что люди не всегда могут правильно определить что им нравится, а что нет. Они могут стесняться говорить, считая что непонимание - это их проблема, а не продукта. Или наоборот - нести много лишнего.
> Видеонаблюдения
Дорогое удовольствие. Мы говорим тестировщикам ЧТО они должны сделать, но не говорим КАК. В этом случае на практике, наблюдая за работой тестировщиков можно определить - на какую задачу ушло наибольшее кол-во времени, где были произведены лишние клики, запущены параллельные процессы, были ли прерывания, откаты в начало, с какого шага и т.д.
> Программное отслеживание
Не всегда применимо.
> Тестирование в динамике - эволюция продукта
Проведение тестирования с одними и теми же задачами на различных фокус-группах. На старте, в середине, и ближе к окончанию проведения работ.
Тестирование на этапе старта
- определение целей и задач тестов
- разработка сценариев тестов
- сбор информации
- обработка полученной информации
- анализ.
Результаты могут быть интерпретированы в качественные и количественные показатели.
Несколько часов крутились вокруг да около этой информации: анализ потребностей, пользовательские сценарии, профили, правило 80-20 и т.
Одна из лекций была посвящена культурным измерениям Хофстеда, и связанными с ними особенностями национальных дизайнов.
Интересно, познавательно, но мало применимо. Т.к. редким нашим ресурсам или ПО доводится выходить на рынки Кореи, Японии и т.д.
На мой взгляд, семинар был больше рассчитан на руководителей крупных компаний, менеджерский состав, но никак не прикладных разработчиков, коих в зале было большинство. Причем 5-10% - софтверных, парочка мобильных, а все остальные 80-90% - веб-ориентированные специалисты. При этом ни Интернета, ни должного количества розеток для ноутбуков в зале предусмотрено не было.
Чего хотелось - МЕТОДОЛОГИИ. А не теории.
Мнения Аарона и примеры того, на что он обращает внимание при эвристической оценке сайтов.
Накал страстей дошел до высокой точки.
Интернет удалось добыть с помощью моего ноутбука и пиплнета. С него докладчик сделал беглый анализ нескольких ресурсов.
Есть очень полезные, в частности для меня, замечания.
Хороший специалист != хороший лектор.
Даже если он в классной шапке.
МетаКонтакт
