Юзабилити-специалист нужен всем: большим IT-компаниям и маленьким стартапам. О том, как обычно выстроен процесс работы юзабилиста в больших компаниях, на хабре писалось уже не раз. А тему «как взять и прямо сейчас организовать работу внутри вашей команды» (пусть и небольшой) почему-то все время обходили стороной.
Мы решили заполнить эту брешь. Не смотря на то, что Бухгалтерия.Контур (ранее Эльба) — проект большой компании, мы всегда старались воссоздать внутри команды атмосферу стартапа. Поэтому проблемы и нюансы работы в небольшой команде — понимаем хорошо.
Место юзабилити-специалиста в команде
Когда наш проект только начинал свое существование (почти 5 лет назад), юзабилити-специалист был человеком приходящим. На сегодняшний день, во многих компаниях до сих пор все так и работает. Но мы быстро убедились, что приходящий юзабилити-специалист, это как приходящий отец: даже если он очень старается и вообще прекрасный человек — он все равно не является частью процесса.
Так, например, перед юзабилистом ставилась задача: протестировать прототип вместе с пользователем. Он ее усердно выполнял, готовил отчет с рекомендациями и комментариями, высылал его и ждал следующего прототипа на проверку, зачастую так и не дождавшись фидбэка о своей работе. Комментарии, в свою очередь, не всегда учитывались. Во-первых, они были всегда не в том месте и не в то время. А во-вторых, согласитесь, не всегда просто принять на веру слова человека, который приходит в команду раз в неделю и постоянно говорит вам, что вы делаете не так.
Тогда пришло понимание, что место юзабилити-специалиста — в команде. Правда, где это место, мы тоже поняли не сразу. Было непросто вписать новое звено в годами устоявшиеся процессы разработки.
Так, методом проб и ошибок, мы выбрали Канбан. Данная аджайл-методика позволила сделать так, чтобы ни одна задача не уходила в разработку до тех пор, пока не будет опробована на пользователях.
Признаться, не сразу вся команда понимала важность этих изменений. Осознание пришло тогда, когда проектировщики и разработчики впервые поучаствовали в тестированиях и увидели, что пользователь испытывает сложности в работе с сервисом: не сразу находит нужную вкладку, не понимает, куда нажимать, чтобы отправить отчет или перейти в другой документ.
Но не только участие в тестированиях помогает команде понять пользователя. Задача юзабилиста инициировать различные внутренние мероприятия: совместное создание персоны пользователей и сценариев их работ, составление customer journey map и др. Это позволяет команде лучше понимать, для кого они делают свой продукт и что «болит» у пользователей.
На данный момент, для проверки одного прототипа мы проводим 5 встреч, а в процессе разработки серьезной функциональности — около 20 различных встреч с пользователями: это и полноценные юзабилити-тестирования и неформальное общение (были случаи, когда наш юзабилити-специалист проинтервьюировал человека в трамвае, услышав, что тот говорит по телефону о бухгалтерии).
Бумажный метод
Раньше на разработку кликабельного прототипа уходило до недели, затем он тестировался на пользователях, после, как правило, отправлялся на доработку (до недели) и снова тестировался, чтобы, только после всего этого, отправиться в разработку. Таким образом, на проработку одной новой функциональности уходил целый месяц. Поэтому мы решили упростить процесс и проводить тестирование идей быстрее. Так, мы дали пользователю карандаш и бумагу.
Это позволило отойти от простого тестирования наших идей к совместному созданию продукта: теперь на интервью пользователь сам или с нашей помощью зарисовывает свой обычный сценарий работы. А затем присутствующие интерфейсологи «оживляют» рисунок при помощи стикеров и его тут же можно показывать другим пользователям и проверять предполагаемую функциональность.
Листы бумаги удобно перекладывать, менять местами, клеить на них стикеры и перемещать их, делать пометки и фиксировать интересные идеи. Конечно, прототип на бумаге это еще не разработанный интерфейс, но это алгоритм, который покажет в какую сторону двигаться. А потратим мы на это не более 20 минут.
Конечно, это не значит, что мы полностью отказались от юзабилити-лабораторий с веб-камерами и зеркальным стеклом — они нужны для других целей: кликабельный прототип, живая система или общение с фокус-группой.
А когда есть только идея, достаточно листа бумаги, упаковки стикеров и карандаша.
Что можно сделать прямо сейчас
У небольших компаний часто возникают сомнения: нужен ли им юзабилити-специалист? По карману ли он им? Достаточно ли у них самих знаний, чтобы выполнять эту роль самостоятельно?
Ну, надеемся, что в первой части нам удалось объяснить, почему юзабилист обязательно должен быть частью команды, а во-второй — что юзабилити-тестирования это не затратный процесс. Сейчас давайте сосредоточимся на том, как вы можете все это реализовать в своей команде.
Роль юзабилити-специалиста в вашей команде, по сути, может взять на себя любой. Самое главное — это общаться с пользователями. Как правило, это бесплатно. И более того, пользователи часто сами готовы поделиться своими мыслями о вашем проекте, потому что хотят сервис, который бы им действительно подходил. Нашими первыми респондентами были именно такие люди, а в качестве благодарности за участие в тестировании мы дарили им наш сервис. Сейчас, мы стараемся приглашать самых разных людей: из различых сфер, с разным уровнем подготовки, а иногда и тех, кто нами еще никогда не пользовался — их можно отблагодарить сертификатом в в одну из крупных сетей (магазины парфюмерии, техники и т.д.).
В самом начале вам необходимо выяснить, как пользователи ведут свою работу, как проходит их рабочий день, с кем они взаимодействуют, чем пользуются. Обращайте внимание на то, как пользователь совершает различные действия, о чем говорит в первую очередь. Кстати, если встречи записывать на видео (только убедитесь в согласии на видео съемку у респондента заранее), то при повторном просмотре легко заметить реакцию пользователя. Эмоции не всегда просто увидеть, находясь на тестировании, но они также играют важную роль.
Но самое главное: вы должны внимательно прислушиваться к клиенту, понимать и принимать его комментарии, пусть не всегда выполнимые. Пользователь, да и вы сами, должны понимать, что его слова не могут быть ни «правильными», ни «неправильными», они просто важны для развития сервиса.
Автор: LenkMak
