Специализация
Говорят, в aic нет проектировщиков: дизайнеры проектируют и рисуют финальные макеты, которые увидят пользователи. Дизайнеры Яндекса верстают из готовых компонентов. Проектирование — довольно узкая специализация. Время от времени люди спрашивают меня в личных сообщениях ВКонтакте, неужели можно зарабатывать чисто проектированием?
Но в проектировании есть более узкие специализации.
По платформе:
- Мобильные приложения;
- Сайты;
- Приложения для настольных компьютеров (бухгалтерия);
- Программы для специальных устройств (касса в магазине);
- Голосовые меню.
По решаемой задаче:
- Продажа (лендинг);
- Информирование (онлайновая газета);
- Обслуживание (онлайновый сервис);
- Развлечение (игровой интерфейс).
По выполняемым работам:
- Исследование и аналитика;
- Проектирование и иногда информационная архитектура;
- Прототипирование;
- Тестирование.
Если специалист заточен на сайты, мобильное приложение он тоже спроектирует: изучит особенности платформы и на несколько первых проектов потратит побольше времени. Общие принципы проектирования и подход к решению задачи останутся прежними, добавятся нюансы.
В больших командах или узкоспециализированных компаниях встречаются прототиписты, которые работают с готовыми персонами, сценариями, визуальными концепциями и создают на их основе прототипы.
Чтобы прототип протестировать, придётся кардинально изменить рабочий процесс: выбрать способ исследования, определить объём выборки, найти респондентов и замотивировать на участие в тестировании, в конце концов, правильно его провести. (Возможно, придётся даже выйти из офиса!)
Придётся разбираться с понятиями вроде «объёма выборки» и вникать в нюансы разных способов исследования. Например, популярный метод think aloud (проговаривание респондентом своих действий) может искажать взаимодействие.
Тестирование
Проектировщики-фрилансеры и небольшие студии обычно тестированием не занимаются:
- Прототип похож на выполненную работу, которую можно сдать. Если он не противоречит задачам бизнеса и отражает все пожелания, скорее всего, клиент проблем не увидит;
- Тестирование увеличивает стоимость работ. Придётся обосновывать более высокую стоимость услуги проектирования. У клиента может не быть на это денег;
- По итогам теста придётся внести исправления. Это тоже увеличивает общую стоимость (и никто не любит правки);
- Тестировать надо уметь: выбрать способ, организовывать процесс, интерпретировать результаты.
Я пробовал следующие простые способы тестирования:
- Тестирование похожего сайта;
- Коридорное;
- Экспертное;
- Пользовательское (качественное).
Тестирование похожего сайта
Мы часто ориентируемся на существующие решения и можем заранее знать, что страница новостройки будет примерно такой, как на Яндекс-недвижимости. Это может быть референс клиента или просто наше ощущение, что она соответствует заявленным требованиям. Значит её можно протестировать.
Если мы делаем аналог существующего продукта, можно поработать с ним и обратить внимание на удачные решения и проблемные места, прежде чем копировать всё целиком. Возможно, конкурент уже в курсе проблем и сейчас как раз всё переделывает.
Эта работа может быть частью этапа исследования и аналитики, но по форме она не сильно отличается от тестирования своего продукта. Тестирование похожего сайта тоже может быть коридорным, экспертным или пользовательским — зависит от респондентов. (У вас всегда есть один эксперт — вы сами.)
Коридорное тестирование
Вот что о нём пишет Джоэл Сполски:
«Коридорное тестирование — это процедура, при которой вы выбегаете в коридор, хватаете первого попавшегося человека и заставляете его попользоваться программой, которую вы только что написали. Если вы проделаете эту процедуру на 5 разных людях, вы получите 95% информации о проблемах с удобством использования в вашей программе.
Показывая её горстке людей (фактически 5−6 человек уже достаточно), вы очень быстро узнаете, какие проблемы у них возникали. Прочитайте статью Якоба Нильсена, в которой он объясняет, почему так происходит».
Фишка такого тестирования — высокая скорость. Мы не просим пользователя пройти весь сценарий использования, так как это неудобно делать стоя, и он вообще-то спешит. Мы задаём простые вопросы:
- Куда бы вы нажали, чтобы сделать что-то?
- Как вы думаеете, что произойдет при нажатии сюда?
- Как вы понимаете эту фразу?
«В коридоре» можно провести 5-секундный тест: показать макет на 5 секунд и спросить:
- Что вы запомнили?
- На сайте какой организации вы оказались? Что она предлагает?
Такое тестирование не обязательно происходит в офлайне в коридоре. Недавно «Юзабилитилаб» провели first-click тестирование отдельных экранов банковских приложений. Посмотрите, как это работает, пока ссылка открывается.
Экран приложения «Альфа-банка» с заданием и сообщение после правильного выполнения
Это сделано с помощью Axure, Яндекс-метрики и Google Analytics. На выходе исследователь получил процент правильных нажатий и среднее время, затраченное на задание. Для «Альфа-банка» тестируется 3 варианта кнопки «Платежи и переводы» — это видно в структуре прототипа. По итогам теста можно выбрать самый доходчивый.
…
В продолжении расскажу, как сделать такой же тест, как в «Юзабилитилаб», а также о своём опыте пользовательского тестирования.
Ссылки из текста
- А/Б тестирование: от А до Б;
- Eye Tracking: Best Way to Test Rich App Usability;
- Тест Джоэла: 12 шагов к лучшему коду;
- Пять пользователей — всё, что нужно для теста (оригинал);
- Комикс «Когда коридорного тестирования недостаточно»;
- First-click тестирование «Юзабилитилаб».
Читайте также
- Айтрекинг в UX-исследованиях;
- Коридорное тестирование: получаем быстрый фидбек по макетам.