User Testing, или как дизайнер может изменить проект

Нет лучшего тестировщика, чем новичок, который еще не надел очки-фильтры. Особенно если этот «новичок» — UI/UX-дизайнер. В этой статье я бы хотела поделиться своим опытом того, как дизайнер может повлиять на развитие проекта и вывести его на новый уровень благодаря использованию User Testing (UT), прямо как говорят на UX/UI designer курсах.

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

Осознание проблемы

Все мы знаем об идеальном пути, по которому должен двигаться проект, но в реальности о дизайнере вспоминают, когда основной функционал уже написан, и все видят, что что-то с ним не так и его надо «причесать».
Проекту, к которому я присоединилась, уже два года. Это довольно сложная медицинская система, которая позволяет работать с большим объемом данных в различных больницах и центрах — систематизировать их, хранить, обрабатывать и интегрировать данные из других баз.
Первые попытки что-то изменить я позволила себе лишь через год, когда четко поняла особенности проекта и дальнейшее направление его движения. До этого я составила список функций приложения, которые считала неудобными для использования. Я была убеждена, что работу с пациентами и организациями можно оптимизировать: для решения большинства задач можно уменьшить количество кликов, а часть функционала вряд ли используют вообще в такой форме, как она подана. Конечно, мое видение расходилось с видением заказчика. Однако наша команда разработчиков поддерживала значительную часть моих идей. Нельзя утверждать, что кто-то из нас прав, а кто нет.
Правильный ответ знает только пользователь. Никогда нельзя забывать, для кого это все.
За все время существования проекта User Testing не проводили никогда, потому что никто не знал, насколько это полезно и действительно нужно. Тем не менее приложение имело реальных пользователей, которые использовали его каждый день.
Все мы прекрасно знаем, что именно с исследования пользователей нужно начинать проект. Если это не удалось, тогда чем скорее его внедрить, тем лучшим будет результат. Именно в диалоге с теми, для кого мы это все затеяли, рождается истина. Подходы, которые работают в одних случаях, могут быть неэффективными в других, поэтому дизайнер и команда могут только строить предположения, основываясь на собственном опыте, но их все надо проверять — и желательно на каждом этапе.

Главная проблема в том, что дизайн в наших реалиях не может стать high-priority-задачей. Его переосмысление, улучшение и вместе с тем User Testing всегда будут откладывать «на завтра», потому что сегодня куча багов, и основная фича вдруг прекратила работать, и дедлайн вот уже сейчас. Это надо принять, но можно и изменить.

Я начала обращаться (читай «проедать» мозг) ко всем, кто мог мне помочь, чтобы провести User Testing. Кстати, это вообще казалось мне настолько очевидным и необходимым, что я не могла смириться с тем фактом, что это надо объяснять и кого-то убеждать. Почему для всех очевидно, что на проекте нужны QA или релизы? Для всех было дикостью, когда я говорила о User Testing. «Вы серьезно?», — думала я, но вслух мило объясняла, почему нам это надо.

Однако ни разу никто не отказал мне и не сказал отцепиться со своей идеей, не сказал, что мы не имеем на это времени. Но никто и не ответил: «Да, давай! Что тебе для этого нужно?». Я только слышала, что такая идея есть, но это в перспективе.

Начало суеты

Я убеждена, что нет смысла быть на проекте, который не в кайф, которым ты не можешь сделать чью-то жизнь удобнее. Я всегда внутри злюсь, когда слышу, как кто-то унижает свой проект. Хочется сказать: «Измени что-то или уходи!».

Первый раз за участие в проекте у меня появилась возможность поговорить с непосредственным заказчиком, когда он приехал к нам с визитом в офис. Для встречи с ним я подготовила четкий план продвижения User Testing:

• для чего это нужно
• что это нам даст
• команда
• расходы

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

Мне этого не сказали, я услышала только: «Да, конечно, но позже. Мы еще поговорим об этом ... завтра».

Активные действия

Я убеждена, что тему с UT нельзя закрывать никогда, даже когда кажется, что шансов нет, и «завтра», на которое намечено все, никак не наступает. Заказчику не до этого, и доступ к реальным пользователей — как мечта. Но рано или поздно выпадет момент, которая позволит вернуть проект в правильное русло. Главное — не пропустить его, сидя со сложенными руками.

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

Представьте, что у вас есть возможность переделать все, над чем вы работали несколько лет. Стереть все и сделать заново, но глубоко понимая структуру всех компонентов, без правок и пожеланий, без ограничений во времени и бюджете. «Не прикручивать» новый функционал на то, что уже есть, а выстроить взаимодействие. Как бы выглядел ваш проект? Это почти утопия.

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

Возникает логичный вопрос — куда с этим идти дальше? Времени мало, ведь команда должна уложиться в дедлайн и уже вовсю работает над web-версией. Я решила отправить клиенту мое предложение с альтернативной версией, добавив к нему огромное описание каждого изменения (отдельно выделила User Testing направление). В копию письма я добавила всех, с кем стоило согласовать это решение предварительно. Наверное, стоит добавить, что такой поступок очень неправильный и нерациональный — прежде всего он содержит колоссальное количество рисков и последствий как для меня, так и для проекта. Было трудно определить, соответствовало мое решение всем этим рискам. Но в моем случае я понимала, что стандартный процесс согласований катастрофически длинный, и велика вероятность того, что идея будет отложена в светлое будущее, и она не попадет к единственному человеку, который может изменить ход проекта. Одним словом, не повторяйте эти действия дома :)

Проведение User Testing

Через несколько дней внутренней паники и предчувствия, что проекту уже нужен новый дизайнер, я получила самый неожиданный ответ из возможных. Ответ был «да», «да» на все предложения, «да» на User Testing, «да» на изменения.

Наверное, тем, кто не сталкивался с проблемой уговорить на UT заказчика в проект, которому уже несколько лет, в компании, где таких проектов сотни, все эти слова кажутся странными и преувеличенными. Когда-то и я так думала и не видела в этом проблемы. А проблема в том, что заказчик думает: «Если все работает и так, то зачем что-то менять?». В основном клиент не может коммуницировать с пользователями непосредственно, задавать им вопросы по сценариям и записывать их работу на видео. Часто они еще и в разных частях мира. Поэтому все статьи о типах UT и работе с данными после — как идеальный недосягаемый мир — можно вспоминать вечность, но никогда не использовать в реальной жизни. Как часто вы тестировали своих пользователей? Если хоть раз, я вам завидую.

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

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

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

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

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

Поэтому я узнала:

• какой функционал они используют для различных задач
• какие задачи перед ними стоят чаще всего
• кто с какими проблемами сталкивается

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

Я смогла проверить все свои гипотезы, которые выложила в альтернативной версии приложения. Но главное — появилось много идей о том, как сервис можно усовершенствовать. Несколько блоков были переосмыслены и упрощены. Изменился сценарий работы с пациентами и организациями, а также принципы сортировки и фильтрации. Особое внимание было уделено работе с клавиатурой, добавлены горячие клавиши, несколько меню объединены и реорганизованы. Появилась вкладка с индивидуальной настройкой интерфейса и, конечно, выполнен ряд пожеланий пользователей. Это было бесценно.

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

Коммуникация — это важно

В рамках проекта надо поддерживать положительные отношения. Даже если идет мини-война, она должна быть профессиональной и дружественной.

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

• Я нигде не использовала в переписке «я», все изменения к лучшему называла «нашим успехом»
• Все правки, которые в результате поступали от бизнес-аналитика и во многом замедляли процесс и усложняли его, воспринимала положительно: «спасибо за поддержку и объяснения» и «самой мне было бы сложно, супер, что я не одна»
• А главное — «я бы никогда не осуществила User Testing без вас»
• Темы и правки тянулись цепочками на десятки писем. В таких случаях я временно прекращала эту линию и возвращалась к ней после успешно выигранной другой с положительными эмоциями
• Я понимала, что не уступлю ни один элемент и каждый из них была готова бесконечно объяснять
• Я не относила критику к себе и разграничивала себя и проект. Именно поэтому ни один жесткий комментарий не смог бы меня задеть или обидеть

Результаты и хеппи-энд

Собрав воедино всю информацию после опроса пользователей, я переосмыслила структурные блоки и работу некоторых элементов. Часть из них исчезла навсегда, а часть я объединила в логические группы, некоторые трансформировала. Помогло то, что о UI я уже не думала, поскольку описала основные стили и символы еще на этапе формирования своей первой идеи, которую отправляла овнеру в начале пути.

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

Страницы в Sketch были с максимальным количеством связей, чтобы можно было вернуться с любого экрана на нужный когда-либо во время презентации. Я разбила каждую страницу на логические блоки с описанием изменений и причин, по которым они были введены. Между блоками предложила делать паузы на обсуждение и дискуссию. Так мы двигались постепенно по всем макетам. Этот вариант мне нравится больше, чем презентация всего сразу и дальше бесконечное обсуждение.

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

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

Примечание: а если ваш ребенок интересуется дизайном, курсы веб дизайна для детей будут полезны!