Валидные данные о свежести осетрины

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

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

В какой-то момент мы стали отказываться от фиксирования времени: слишком много условий делало этот показатель недостоверным. Например, на тестах в формате «Мысли вслух» уже сам метод вносил изрядную погрешность – пока человек всё изложит, что ему в голову пришло, куча времени пройдет, да и думается вслух по-другому.

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

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

Мировая гармония и слезинка ребёнка

Один из зарубежных партнеров, заказавший нам тестирование, прислал образец отчета, в котором практически отсутствовали численные данные. Таблица была только одна – со списком участников тестирования. Указывалась критичность проблем, но выводилась она не по формуле, а экспертно. Наверно, в силу стереотипности мышления, я все-таки подготовил нашу типовую табличную сводку по итогам тестирования, хотя изрядно её урезал – до ранжирования по частотности проблем. «Спасибо», — написал мне партнер, — «но вы гензаказчку эти данные не показывайте. Мы-то знаем, что проблема – это проблема, и что на такой выборке не важно, 2 или 3 человека с ней столкнулось. А в большой корпорации эти цифры могут стать поводом диктовать, что важно, а что нет».

По сути, коллега (тут надо пояснить, что заказчиком в данном случая была также юзабилити-компания, мы для них были локальным подрядчиком) озвучил мне то, что проповедуется и в нашей компании: проведение качественных, а не количественных исследований. То есть главное – выявить проблему, а не обмерить и взвесить её. Ещё в одном коллега был прав: если показывать бизнесу показатели, слишком низкие или слишком высокие, то наиболее очевидным действием будет казаться изменение этих показателей, а не решение проблемы в корне и по существу.

Комикс: xkcd.com

В сентябре 2012 года наша компания проводила в Москве UX Masterclass. Среди выступавших был Гэвин Ли из User Сentric, и среди прочего он отстаивал нередко оспариваемую мысль о том, что юзабилити можно измерить. Для примера он приводил дурацкое диалоговое окно медицинской программы и просил публику в зале оценить, сколько времени потребуется на ответ, и какова вероятность ошибки.

Конечно, измерить можно всё. В том числе издержки от умершего в результате ошибки пациента, и даже то, стоит ли вся мировая гармония слезинки замученного ребёнка.

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

Можно ли из невалидных данных узнать правду?

Еще один зарубежный клиент был представлен целой командой: разработчик, менеджер, UX-специалист. При обсуждении работ разработчик сказал нам сурово, почти грубо: «Вы в нашей отрасли ни черта не понимаете, поэтому дайте нам сырые данные, без всяких оценок, ранжирования и выводов. Мы сами разберемся». Этот клиент присутствовал на всех тестах и активно в них участвовал. Например, таким образом: по ходу теста просил поменять условия задания. Наш UX-коллега вздыхал: никаких валидных данных не осталось. Я чуть не вздрогнул, услышав это, потому что формулировка почти дословно повторяла те слова, которые мне пришлось слышать в начале своего юзабилистического пути.

Но грубость разработчика вызвала у меня больше положительных чувств, чем вздох коллеги. Было видно, что человек болеет за продукт и хочет сделать его идеальным. Ему неважно, сколько раз проявилась та или иная проблема. Если проблема есть, продукт надо улучшать. Критичность, кажется, его не сильно интересовала, так же, как требовательного повара не интересуют степень свежести осетрины. Она должна быть свежей, и всё тут. Точность измерения тухлости совершенно не имеет значения, если речь идет о званом ужине.

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

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

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

Автор: Антон Алябьев, аналитик UIDesign Group.

P. S. Кстати, на этой неделе нашей компании исполняется 10 лет. Рассказать тут есть что, поэтому мы решили описать всю историю UIDesign Group (от подработки по выходным до выхода на международный рынок) в серии статей, которые будем размещать в своем «обычном» блоге (не на хабре т.к. не совсем формат). Если вдруг кому будет интересно – почитать первую статью можно по этой ссылке.