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

Не тратьте время и деньги на:

• Фокус-группы
• Тестирование удобства использования (формируя для этого отдельную внутреннюю рабочую группу)
• Независимое экспертное тестирование

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

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

Аскар Байбузов (Информационный архитектор и проектный менеджер компании eSector Solutions)

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

С одной стороны, есть такое мнение:

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

Аскар Байбузов (Информационный архитектор и проектный менеджер компании eSector Solutions)

А с другой, есть и такие:

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

Джеф Этвуд (Разработчик ПО для Windows)
Читать всю публикацию Джефа о разработке ПО в крупных компаниях: http://www.codinghorror.com/blog/archives/001082.html (на английском)

Я не сделал ни одной презентации в Power Point. Мы даже не используем документы Microsoft Word, мы просто разговариваем друг с другом.

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

Брет Тейлор (бывш. сотрудник компании Google, ныне — основатель компании FriendFeed)
Читать интервью Брета для Fortune: http://blogoscoped.com/archive/2008-03-18-n20.html (на английском)

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

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

Санжар Ахмедов (Ведущий разработчик компании eSector Solutions)

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

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

Но, разрабатывая продукт, выпуская и управляя им, не забудьте:

1. Включить в него возможности для того, чтобы быстро сообщить об ошибке, задать вопрос, пожаловаться на неудобства или отсутствие важной возможности. Если ваш продукт ориентирован на англоязычную аудиторию, можете использовать этот http://getsatisfaction.com/ сервис. У них есть виджеты и API http://getsatisfaction.com/for_companies для интеграции с сайтом вашего продукта.

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

3. Следить за тем, что говорят о вашем продукте в блогах, форумах, вопросах и ответах...

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

5. Исправлять критические ошибки в кратчайшие сроки и сообщать об этом пользователям.

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

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

Аскар Байбузов (Информационный архитектор и проектный менеджер компании eSector Solutions)

Поэтому веб-формы, в которых вы предложите пользователям делиться с вами своими идеями и сообщать о проблемах, не единственный способ анализа. Такие инструменты как Google Analytics, RobotReplay и CrazyEgg позволят вам узнать о проблемах, и не задавая вопросы посетителям.

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

Для кого подойдет предложенный выше подход

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

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

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

Якоб Нильсен
Читать всю статью про латание бреши между дизайнером и пользователем: http://www.useit.com/alertbox/designer-user-differences.html (на английском)

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

Вы запускали веб-проекты без опросов и тестирования? Пожалуйста, расскажите о вашем опыте.