Ex Machina: Дизайн для думающих

Последнее обновление 12.11.02

	Наблюдения   Интерфейс   Веб   Про инструмент   Про бумагу   Про контент

Юноше, обдумывающему житье-II. Проблемы юзабилити в России

Данный текст представляет собой отражение личных взглядов автора и не соответствует точке зрения компании Usethics. Далее в тексте термин "юзабилити" употребляться не будет; вместо него будет использоваться термин "проектирование интерфейса".

Экономика

Даже в богатой Америке проектирование интерфейса не является обязательным этапом при разработке ПО. Можно, конечно, утверждать, что все дураки, но объясняется этот факт совсем не так просто: ресурсы, затраченные на интерфейс, должны окупаться. Средняя зарплата оператора в Америке составляет около 41 тысяч долларов в год, если приплюсовать к этой сумме стоимость аренды помещения, налоги, социальные выплаты и прочее, получится очень внушительная по нашим меркам сумма: сотрудник обходится своему нанимателю в 55-70 тысяч долларов в год. Если повысить производительность труда такого сотрудника всего на 10 процентов, в течении года экономия составит не менее пяти с половиной тысяч долларов. Это существенные деньги.

А у нас? Среднестатистический оператор обходится своему нанимателю не более чем в 6 тысяч долларов в год; соответственно, десятипроцентное повышение производительности сэкономит всего 600 долларов. Однако гораздо печальней другое: мы живем в нестабильной стране, наниматель у нас часто не знает, сколько времени ему вообще будет нужна выполненная этим конкретным сотрудником работа; вполне может оказаться, что через полгода ситуация настолько изменится, что сотрудника придется уволить или перевести на другую задачу. Таким образом, при расчетах надо учитывать, что срок окупаемости интерфейса должен составлять не два-три года и даже не год, а примерно 9 месяцев. Итого: общая стоимость интерфейса при десятипроцентном увеличении производительности должна быть меньше 450 долларов. При этом в эту сумму входит не только проектирование интерфейса, как кажется на первый взгляд, но и его оценка и внедрение, т.е. работа менеджера и программиста. Кроме того, не надо забывать, что увеличение производительности оператора на десять процентов требует отнюдь не десятипроцентного повышения эффективности интерфейса – улучшать его придется значительно больше.

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

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

Валидизируемость результатов

Предположим, некто приходит к разработчику интерфейса и предлагает работу. Разработчик интерфейс проектирует. Тут то и начинается самое интересное.

Если этот интерфейс является модернизацией интерфейса старого, лучше ли он или просто другой (шило на мыло). Если лучше, то насколько лучше? Если же интерфейс делается для новой системы, является ли он, по крайней мере, адекватным?

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

У заказчика иная проблема. Предположим, что разработчик таки померил до и после. Чего ради заказчику верить этим цифрам?

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

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

Самолечение

Когда врач прописывает пациенту лечение, пациент знает, что если он будет лечиться не так, как прописал врач, он может, мягко говоря, и не вылечиться. В случае проектирования интерфейса, все не совсем так. Действительно, если уж заказчик готов заплатить аванс исполнителю, то он предполагает, что исполнитель разработает лучший интерфейс, нежели он сам. С другой стороны, продолжая аналогию с врачом и пациентом, нужно отметить, что анамнез у "больного" значительно сложнее, чем в медицине: заказчик часто не без оснований полагает, что исполнитель недостаточно компетентен в предметной области и не в полной мере "чувствует специфику". Результат – заказчик начинает сам править спроектированный для него интерфейс. По вполне понятным причинам, результат для интерфейса порой оказывается плачевным. Заказчик недоволен ("Интерфейсом они занимались? Они!"), недоволен и исполнитель (его портфолио испорчено; заказчик не вернется).

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

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

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

Самоидентификация разработчика

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

— Рекламодатели у нас такие, что им объяснять надо, что им нравится, а что нет. И потом, рекламодатель зачем у нас рекламу дает?

Татарский пожал плечами.

— Нет, ты скажи, скажи.

— Чтобы товар продать.

— Это в Америке – чтоб товар продать.

— Ну тогда чтобы крутым себя почувствовать.

— Это три года назад было, — сказал Ханин поучительно. — А теперь по-другому. Теперь клиент хочет показать большим мужчинам, которые внимательно следят за происходящим на экране и в жизни, что он может взять и кинуть миллион долларов в мусорное ведро. Поэтому чем хуже его реклама, тем лучше. У зрителя остается ощущение, что заказчик и исполнители – полные кретины, но тут, — Ханин поднял палец и сделал мудрые глаза, — в мозг наблюдателя приходит импульс о том, сколько это стоило денег. И окончательный вывод про заказчика оказывается таким – хоть он и полный кретин, а бизнес у него так идет, что он может пустить в эфир любую байду много-много раз. А лучше этого рекламы быть не может. Такому человеку в любом месте дадут кредит без всякого скрипа.

— Замысловато, — сказал Татарский.

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

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

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

Заключение

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

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

Поживем – увидим.

Версия 1. Последнее обновление этого документа: 5.07.02