Человеческий фактор в программировании - Ларри Константин

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

Одним из путей к поддержанию такой сосредоточенности является проведение систематических юзабилити-инспекций (Constantine, 1994 [23]). Они напоминают традиционный анализ программ и проектных решений, но особое внимание они уделяют пользовательскому интерфейсу и юзабилити — для выявления изъянов в этой области. Такие инспекции заставляют разработчиков думать о пользователях и юзабилити программного обеспечения. Одной-единственной инспекции, проводимой непосредственно перед принятием окончательной версии продукта, недостаточно. Разработчики и специалисты по построению интерфейсов должны внимательно проверять модели рабочих процессов, первые бумажные прототипы, начальные варианты дизайна, рабочие прототипы, а также альфа- и бета-версии программного продукта. Как показал Якоб Нильсен, юзабилити улучшается с каждой инспекцией (Jacob Nielsen, 1993 [52]). С каждой новой инспекцией разработчики узнают немного больше о хорошем дизайне пользовательского интерфейса и ошибках, которых следует избегать.

Слишком мало, слишком поздно

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

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

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

Поверхностные функции

Разработка программного обеспечения сводится к созданию различных функций. На рынке выигрывает тот, кто предлагает наибольшее количество функций или самые необычные возможности. Однако программное обеспечение с притягательной 3D-графикой, перегруженное функциями, может оставаться несовершенным с точки зрения пользовательского интерфейса. Юзабилити программного обеспечения касается общей организации пользовательского интерфейса. При анализе юзабилити не рассматриваются функции программы и их взаимодействие, призванное облегчить работу пользователя, А значит, каждый участник команды должен обращать внимание на архитектуру и детали интерфейсов в течение всего процесса разработки.

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

Из журнала Software Development, том 2, № 4, апрель 1994 г.

40

Редактирование интерфейсов

Моя компания только что закончила редактировать пользовательский интерфейс. Официально контракт предусматривал проведение «экспертной оценки юзабилити», но на самом деле мы занимались редактированием. Хороший пользовательский интерфейс начинается с хорошей архитектуры, но для обеспечения удобства и практичности программного обеспечения необходимо выявить и устранить изъяны в пользовательском интерфейсе. Часто для исправления ошибок приходится не один раз проводить критический анализ, пересмотр и доработку. В этом состоит процесс редактирования, а навык редактирования является одним из важнейших навыков для разработчиков программного обеспечения и прикладных программ. Редактирование программы, книги или пользовательского интерфейса во многом очень похожи.

Я всегда завидовал писателям, чьи пальцы с легкостью парят над клавиатурой, создавая первые черновики, которые можно считать окончательным вариантом. Я пишу медленно, иногда мучительно, зачастую нерегулярно, а первые плоды моего труда редко бывают съедобными. К счастью, я довольно хороший редактор. За многие годы я научился «отключаться» от своих сочинений, чтобы спустя время окинуть их свежим придирчивым взглядом и найти места, требующие переделки. Статья может пройти через четыре или пять раундов безжалостной редактуры, прежде чем я смогу с удовлетворением сказать, что теперь она готова.