Завет «Испытывай эмпатию к пользователю» на скрижалях нашей дисциплины — юзабилити — не то что начертан, он выполнен сквозной перфорацией. Нередко способность к эмпатии включают в перечень критериев годности к строевой службе в качестве адвоката пользователя. Но почему только пользователя?
Вообще, если эмпатия у вас врождённая, а не усвоенная в форме вежливости или ещё как-то, то вы будете влезать в шкуру всех окружающих, включая живущую у вас в подъезде кошку. Урождённому эмпату не нужно послание, которое сейчас прозвучит: в сопереживании нуждается не только пользователь, но и разработчик, вольный или невольный проектировщик. У того же Купера при всем его человеколюбии бизнес-цели рассматриваются скорее как ограничения проектирования, а не как чаяния живых людей. Пусть даже эти чаяния заключаются в использовании булевой алгебры.
Сколько раз я смотрел на какую-нибудь экранную форму или страницу и думал: да боже мой, чего они хотели этим добиться? Например, зачем при регистрации запрашивается телефон пользователя? Они действительно хотят выслать ему пароль, или это для сбора личных данных? Или просто потому что сегодня «все так делают»? Почему из двух предложенных вариантов календаря заказчик выбрал тот, который явно слабее? Из каких посылок исходила всепобеждающая формальная логика, если она привела к тому, что весь экран поделён между карточками двух продуктов, но это не сценарий сравнения и выбора между ними?
Передо мной вставал выбор — или искать аудиенции у автора обозреваемого творения, или читать длинные нудные спецификации (которые иногда тоже ещё надо суметь выпросить), или… включить эмпатию к автору.
Не подумайте, что я хочу показаться выше или мудрее всех. Просто со стороны (сбоку, а не сверху!) разработчик и пользователь часто выглядят примерно одинаково: как дети, играющие в конструктор. Один собирает, а второй пытается в это собранное играть. Первый собирал танк, второй увидел в собранной штуке самолёт. Первый обижен недооценённостью себя как танкостроителя, второй злится «зачем у самолёта приделаны гусеницы, летать же мешают!!!». У каждого своя Галатея, и оба хотят любить её на свой лад.
В приложении к разработчику эмпатия становится больше похожей на психоанализ: обычно приходится проводить некий реверс-инжиниринг разработки, дабы докопаться до мотивов, определивших проектные решения. Не добравшись до «зачем» и «почему», которые могли и вовсе не иметь в голове разработчика в сколь-нибудь явной формы, трудно дать уместные рекомендации. Конечно, юзабилити-эвристики всегда уместны – наверно, поэтому только ленивый сейчас не ставит себе приставку UX и не добавляет в список услуг «юзабилити». Но не вжившись в шкуру вашего «пациента», вдвойне сложно подать рекомендации так, чтобы самые добрые пожелания не были встречены калёными штыками. А это наверняка произойдет, если ваши пожелания рушат картину мира (в просторечии – ментальную модель). Ид (Оно) разработчика будет бесноваться и буянить, хотя словами он свой гнев объяснить не всегда сможет.
Хотя пользователь и разработчик со стороны довольно симметричны относительно продукта, разница, конечно же, есть. Сопротивление к переменам со стороны разработчика намного больше. У пользователя в качестве протеста есть только ментальная модель, да и той он готов поступиться, если продукт сулит достаточно большие выгоды. У разработчика чувства к Галатее гораздо сильнее, потому что он вложил в неё больше усилий. К тому при помощи неё он намерен покорить мир, ну или хотя бы заработать на новое жилье/авто/пальто. Ну и, само собой, у разработчика бывает слегка радужное представление о пользователях, с которым приходится расстаться.
Конечно, в жизни всё не так запущено. К счастью, нередко встречаются заказчики, которые по сути впрямую покупают услугу под названием «поговорить», понимая, что у них глаз замылился, им нужна встряска и хотя бы небольшая доза рефлексии. Обычно так происходит, когда заказчик представлен директором по продукту или CEO. Если же уровней менеджмента несколько и/или в нём присутствует замшелость, то чаще господствует тенденция покупать отчёт «по весу» — чтоб страниц было не меньше, чем в договоре прописано, да ещё с прототипами, да с гарантией роста конверсии. Но более уверенные в себе люди понимают, что лучшие решения все равно найдут они сами, а не мы, а от нас нужны только правильно заданные вопросы. Также как в психотерапии.
И что же делать, к какому месту разработчика прикладывать свою эмпатию юзабилисту? Так же, как и с пользователем, с разработчиком работают канонические подходы.
Во-первых, целеориентированность. Если вы будет помнить и чувствовать цели не только пользователя, но разработчика, то вы сможете вести беседу не только в ключе «как все плохо», но и «как достичь цели». На случай, когда нет полной уверенности в понимании, подойдет вариант «если ..., то...».
Во-вторых, меньше внимания словам, больше действиям. Часто разработчики не могут объяснить, почему у них в продукте нечто устроено именно так, а не иначе. Точь-в-точь как пользователь, который не может внятно сказать, в чем у него сейчас проблема. Если разработчик – это не конкретный Линус Торвальдс, Стив Джобс или Билл Гейтс, а коллектив, то вероятность незнания ещё выше. Поэтому смотрите на деяния и думайте: зачем тут кнопка, почему тут скролл? Не отметайте не глядя даже очевидно ошибочные решения, а обязательно поймите, почему было сделано именно так.
Резюме: будьте адвокатом для пользователя и психотерапевтом для разработчика.
Автор: Антон Алябьев, аналитик UIDG.
Автор: UiDesignGroup
