Но у дизайна, ориентированного на пользователей, есть и недостатки:
♦ В системах, где пользователи получают деньги за работу с системой и эти пользователи легко заменимы, мнение пользователей важно лишь отчасти. Интерфейс должен быть производительным и эффективным, чтобы приносить деньги, а нравится он или не нравится — вопрос глубоко вторичный. Например, если идет речь о кассовом терминале, важна скорость обслуживания, процент ошибок и невозможность воровства денег персоналом, а если кассирам терминал не нравится, это сугубо их проблемы, пускай увольняются, наймем других.[23]
♦ ДОП не учитывает того простого факта, что человек — очень адаптивная система. Пользователи способны к адаптации в очень широких пределах. Например, я ни разу не видел кассира (а я интересовался вопросом), который бы ругал терминал, на котором он работает сейчас. Как правило, оценки варьируются от «намано» до «да хорошо всё». Но тот же кассир во время внедрения новой версии терминала будет верещать до посинения, потому что всё плохо. А через недели две — всё опять «намано». Как учитывать принципы ДОП в таких случаях? Ориентироваться на пользователя текущего, неадаптированного, или на уже адаптированного, но ещё не существующего?
♦ ДОП требует исследований. Эти исследования, по сути, являются этнографическими. В свою очередь, этнографические исследования почему-то всегда дороги и длительны, вдобавок, почему-то всегда более длительны и дороги, чем запланировано (вероятно, потому, что этнографическое исследование применительно к интерфейсу — это всегда «найди то, не знаю что»).[24] Поэтому включать в проектный цикл этнографическое исследование — верная гарантия того, что проект с управленческой точки зрения пойдет насмарку. Кроме того, до конца исследования совершенно непонятно, будет от него польза или нет, что депрессивно действует на всех участников проекта.
Суммируя, можно сказать, что ДОП негласно подразумевает: есть система (в частности — интерфейс) и есть её пользователи, которые и важны. Того, что делают пользователи в системе и ради чего они, собственно, с системой взаимодействуют, ДОП не покрывает. Зато его покрывает…
Дизайн, ориентированный на задачи пользователей
Когда имманентные проблемы ДОП стали несомненны, на смену старой концепции пришла новая. Согласно дизайну, ориентированному на задачи пользователей (Task Centered Design, далее ДОЗ), тот интерфейс хорош, в котором эффективно выполняются задачи пользователей.
Задача здесь — совокупность действий, в свою очередь являющихся совокупностями операций. Как правило, задачи могут быть решены несколькими разными способами, каждый из которых определяет свой набор действий. Например, девочка, которая хочет найти хорошего мальчика, может поставить себе задачу «прочесть Коэльо, чтобы не слыть дурой» или «купить новые стринги» (или обе эти задачи разом). Каждая из этих задач требует определенной, но достаточно свободной последовательности действий, так, она может купить книжку Коэльо в магазине, взять у подруги или прочесть в интернете. Дело дизайнера интерфейсов, согласно идеям ДОЗ — выбрать наиболее эффективное решение задачи и обеспечить её выполнение.
Этот метод несколько лучше ДОП, просто потому что шире и включает в себя ДОП (правда, в неявной форме): в самом деле, как мы выберем наилучшее решение для пользователей, если мы не знаем всего об этих пользователях? Но ДОЗ обладает и другими достоинствами:
♦ В отличие от ДОП, цели и методы которого не имеют прямого коммерческого выражения, дизайн, ориентированный на задачи пользователей, может быть оценён экономически. Например, если мы делаем интерфейс кассового терминала быстрее, мы можем посчитать, насколько он стал выгоднее владельцу (нужно всего лишь посчитать полную себестоимость работы, которая высвободилась при улучшении).
♦ В отличие от потенциальных особенностей пользователей, число задач конечно и более предсказуемо при планировании. Благодаря этому проекты с ДОЗ значительно более управляемы, что очень приятно менеджменту.
Но у дизайна, ориентированного на задачи пользователей, есть и заметный недостаток. ДОЗ не позволяет определить, какое именно число решаемых продуктом задач является необходимым и достаточным. Всегда есть задачи, которые система (ещё) не решает; согласно ДОЗ, все их не просто можно, но даже нужно засунуть в интерфейс, поскольку чем больше задач будет решать система, тем она будет лучше. Отсюда бесконечный рост функциональности (т. н. creeping featurism).
23
Тут, правда, важно не увлечься. Сейчас кассиры, в принципе, расходный материал — их легко переобучить и у них довольно высокая текучка. Если экономическая ситуация изменится (на что я, кстати сказать, искренне надеюсь), тоталитарный интерфейс окажется, мягко говоря, неуместным.
24
Расходы и продолжительность исследования можно зафиксировать, но при этом не будет гарантии, что исследование даст результаты.