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