В марте мы закончили проектирование интерфейсов мессенджера «Ответ». Сели писать кейс, стали вспоминать и обнаружили, что это был практически эталонный пример того, как надо работать с внешним подрядчиком по UX-проектированию. То есть с нами. И очень честный такой пример, без розовых пони. Было бы преступлением скрывать от общественности те мысли, которые мы наконец-то оформили в слова. Так что кейс подождет, а пока поговорим про совместную работу.

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

Проблема в том, что для разработки IT-продуктов нам нужно, чтобы пользователь подробно описал свои повседневные действия. Созданный продукт должен решать реальные задачи и органично вписаться в социальную и физическую среду пользователя. Как получить такое описание? Один из методов — это контекстные интервью (contextual interviews, contextual inquiry).

Мы уже много писали про роль качественной методологии в пользовательских исследованиях (например, http://bit.ly/25hnAMQ и http://bit.ly/2jmfkcM). В одной из статей (http://bit.ly/2ay3Nzg) мы рассказали про то, как качественные методы используются в UX research для разработки IT-продуктов в зарубежных компаниях. А что происходит в России?

В этой статье мы поговорим о своем опыте применения качественной методологии для разработки IT-продуктов на российском рынке. Говорить будем не только про специфику работы, но и про то, как к ней приступить. Как объяснить заказчику ценность качественной методологии? Что ему рассказать, чтобы он дал добро на общение с пользователями? И почему вообще возникает необходимость объяснять?

В предыдущих статьях мы рассказывали о том, как и в каких случаях используются качественные методы для разработки IT-продуктов. Логичный вопрос: а можно ли провести качественное исследование самому? Почитать статьи, послушать лекции, посетить мастер-класс и вперед, в поле — проводить наблюдение и брать интервью. Почему нет?

В идеальном мире качественные исследования проводят специалисты, вооруженные необходимыми навыками и компетенциями. Социологи, социальные антропологи, психологи — все они не один год изучали, как проводить такие исследования, разрабатывать инструментарий, собирать и анализировать качественные данные. Есть возможность нанять специалиста? Сделайте это, и не нужно самостоятельных экспериментов. Почему? Слишком высок риск получить некачественные данные: нерелевантные целям и задачам проекта, недостаточно подробные или вовсе бессмысленные (да-да, такое тоже случается).

Все части статьи: 1 | 2 | 3 | 4 | 5 | 6

---

«Чтобы двигаться дальше, мы должны понять, что нужно людям»: разработка нового сервиса

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

• изучение потребностей, поведения, страхов и проблем одной или нескольких групп пользователей;
• анализ жизненных ситуаций и среды использования;
• изучение повседневности пользователей и рутинных действий;
• выявление культурных особенностей, которые могут повлиять на использование IT-продукта.

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

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

Все части статьи: 1 | 2 | 3 | 4 | 5 | 6

---

«О рынке недвижимости Бразилии мы знали не слишком много»: выход на локальный рынок

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

Все части статьи: 1 | 2 | 3 | 4 | 5 | 6

---

«Создать идеальный день на работе»: профессиональные интерфейсы

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

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

Все части статьи: 1 | 2 | 3 | 4 | 5 | 6

---

«Я пользуюсь телефоном чаще, чем компьютером»: переход на мобильные
устройства

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

Все части статьи: 1 | 2 | 3 | 4 | 5 | 6

---

«Они все хотели быть на главной странице»: разработка общей платформы для нескольких групп пользователей

До сих пор мы рассматривали ситуации, когда нужно сделать продукт для конкретной группы пользователей. Теперь усложним ситуацию, добавив новую переменную, а точнее — еще одну или несколько групп пользователей. В известной степени мы уже подошли к этому в кейсе сайта для American Society for Aesthetic Plastic Surgery, но теперь «заострим» проблемы, которые возникают в таких условиях.

Все части статьи: 1 | 2 | 3 | 4 | 5 | 6

---

В предыдущей статье «Качественные методы в UX-исследованиях» мы давали практические рекомендации по эффективному использованию качественной методологии (интервью, наблюдения, этнографии) для решения UX-задач. Теперь мы решили обратиться к опыту зарубежных коллег, чтобы понять, в каких ситуациях они использовали качественную методологию и какие были результаты.

Спасибо прекрасному автору за симпатичную картинку.

Почему речь идет о зарубежных компаниях? Качественная методология там давно перестала быть экзотикой и вошла в арсенал IT-продуктологов. Изучение их опыта позволит лучше понять возможности и ограничения этих методов в сфере UX. Для этого мы провели собственное исследование.

Социальные науки и UX-исследования: ближе, чем вы думали

Начнем с вопроса. Можно ли сделать действительно качественный IT-продукт без пользовательской аналитики? Да или нет? Кто выбрал «да»? Если вы и так знаете, что на самом деле нужно вашим пользователям, дальше можете не читать. Сэкономите свое время. И деньги на аналитику. Правда, зачем оно вам?

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

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

Распространенная проблема для бизнеса — в call-центре не хватает операторов. Руководство не хочет увеличивать бюджет и нанимать новых специалистов, а поэтому устанавливает IVR (Interactive Voice-Response) — интерактивную систему предварительно записанных ответов оператора.

С точки зрения бизнеса кажется, что такая система серьезно разгрузит операторов. Она и работает 24/7, и зарплату не просит, и вполне себе может дать нужную информацию клиенту, не задействуя специалиста. Ну а клиенты как должны быть довольны! Им больше не нужно слушать десятиминутные midi-мелодии и устаревшие хиты в ожидании оператора, да и повторять свою проблему снова и снова по цепочке каждому специалисту не придется. Система запомнит сама. Говорите, хорошая вещь, ваша IVR? Надо брать.

Захотели сделать трафарет для упрощения бумажного проектирования интерфейсов. По образцу тех, что можно найти на UIStencils.com, но с местной спецификой.

Кто про что, а я про малый бизнес. И диджитал, куда без него.

Небольшое пояснение. Так исторически сложилось, что я работаю в малом бизнесе, с малым бизнесом и, до кучи, рулю своим маленьким, но гордым интернет-магазином. Поэтому всю диджитал-историю волей-неволей воспринимаю через боль настоящего малого и микробизнеса. Бедного, но гордого. Зато свой, зато сам. Без инвесторов и госраспилов, с одной стороны, и с несколько однобоким взглядом на этот прекрасный мир — с другой. Так вот, вижу я такую картину.

«Собачья площадка» — это блуждающая вечеринка «Собаки Павловой». Зовем в гости коллег и профи из смежных областей, задаем тему для обсуждения — и обмениваемся знаниями и мнениями в формате мозгового штурма (то есть по возможности без критики).

Тусовка бесплатная, но за вход взимается интеллектуальный взнос: нужно сосредоточиться и описать, чем вы можете быть интересны другим гостям «Собачьей площадки». Формат пользы от раза к разу меняется: иногда важен опыт, иногда знакомства, иногда профессия. В этот раз были важны идеи.

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

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


Фото: "Day 260 Allergies", автор parrchristy (CC BY).

За последние 7–8 лет наши сотрудники прочитали около 2000 резюме UX-проектировщиков. Отсобеседовали — под сотню. Пару десятков приняли на временную или постоянную работу. А параллельно пережили неисчислимое количество однотипных бесед с теми, кто «тоже хочет» (или делает вид, что хочет) заполучить себе в команду подобного специалиста.

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

Попробуем немножко расшатать самые распространенные мифы. Вдруг это кому-то поможет подойти к вопросу найма UX-проектировщика чуть более рационально и эффективно.

Маркетологи — притча во языцех российского IT-сектора. Суетливые тупые девочки, вечно на нервах и с претензиями, никогда не исполняют обязательств, постоянно пытаются надуть клиента и чуть что просят бюджет на каждый чих. Да?

Может, и да, но что-то тут не так. Давайте попробуем медленно подумать с точки зрения бизнеса.

Наш гендир Наталья Прокофьева посмотрела в календарь, увидела пятницу, 13-е, махнула на всё рукой и решила рассказать — для разнообразия — не об успехах, а о провалах. Точнее, об одном провальчике старта нового продукта.

Денег на ремонт не просим, чинить будем сами, а вот опытом с вами поделимся.