Ни разу не слышал, чтобы наши (читай: совковые) вендоры коробочных CMS заказывали usability тестирование своих продуктов. Напрашивается два основных вывода:
- Usability этих систем и так на высоте! В каждой компании есть свои usability специалисты, которые принимают участие в разработке на всех стадиях развития продукта – организуют тестирования, дают рекомендации, экспертную оценку и т.д. В таком случае это UDD – User-Driven Development.
- Usability этих систем по-взрослому сосет. Программеры делают функционал. Дизайнеры делают дизайн. Маркетинг делает продажи. Программер думает об эклипсе. Дизайнер думает о фотошопе. Маркетолог думает о пауерпоинте. Ну а конечный пользователь периодически задумывается обо всех трех сразу – об их интеллекте, сексуальной ориентации и месте произрастания их передних конечностей. Это методология AUDD – Anti-User-Driven Development или Angry User Driven Development.
- Минимально необходимое количество отображаемых опций. На экране должны присутствовать только те элементы, которые могут понадобиться пользователю здесь и сейчас для выполнения задачи. Количество общих для всего интерфейса системы элементов должно быть минимальным.
- Надежность и обработка ошибок. Система обязана всегда обеспечивать сохранность данных, с которыми работает пользователь. Пример – функция авто-сохранения. «Обработка ошибок» подразумевает не только ясность сообщения об ошибке и способах ее исправления, но и общую толерантность системы к ошибкам пользователей (если мы знаем, как исправить ошибку – то нужно исправить ее автоматически, а не дергать пользователя).
- Интерфейс, ориентированный на задачу. Логика интерфейса должна исходить не из того, как работает система, и как она устроена внутри, а из того, как работает с ней пользователь – из его повседневных задач. Разработчики часто стремятся сделать все «элегантно», когда множество задач решается одним и тем же набором инструментов. Проблема в том, что журналисту электронного издания совершенно фиолетова бизнес-логика вашей гениально спроектированной CMS. Плевать он хотел на «модуль», «инфоблок» и «объект» – ему статью сдавать к двенадцати.
- Сокрытие деталей реализации. В предыдущем пункте 3 мы отказались от метафор из архитектуры системы. Осталось избавиться от деталей реализации – никаких HTML, JPEG, XML и прочих технических тонкостей и широкостей. Есть странички и папочки – никаких файлов, директорий и баз данных с индексами.
- Наглядный интерфейс. Пользователь должен понимать, с чем он сейчас работает, что он сделал и, что он еще может с этим сделать. Интерфейс системы должен быть целостным и логически продуманным. Размещать сочинения Хайдеггера в шрифте 8pt также не рекомендуется. Текст и подписи должны быть доходчивыми и однозначными.
- Соответствие умственным моделям пользователей. В большинстве случаев люди мыслят шаблонно, ведь любая умственная деятельность – штука энергозатратная. К чему навязывать новые понятия, схемы и сценарии работы, когда есть уже проверенные «папка», «страница» и «корзина». В одной фразе данный принцип радикально сформулировал Стивен Круг (Steven Krug): «Don’t make me think» («Не заставляйте меня думать»).
- Удобство как для новичков, так и для опытных пользователей. Новичкам – подсказки и наглядность, опытным юзерам – хоткеи, шорткаты и прочие средства повышения эффективности работы вплоть до специализированного интерфейса.
- Эффективность в дизайне интерфейса. Веб-интерфейс традиционно был менее эффективным ввиду своей медлительности и асинхронности. Сейчас интерфейсы в стиле веб-два-нуль-йоу уже приближаются по эффективности работы к обычным приложениям. Эффективность складывается из минимума движений, кликов и переходов между «экранами» до достижения результата. Формы и контролы должны быть логично сгруппированы, а не раскиданы по страницам и вкладкам. Еще одним немаловажным моментом является собственно скорость работы системы. Даже если серверное приложение задумывается надолго, это не значит, что интерфейс клиента должен точно так же подвисать.
- Справка и подсказки в интерфейсе. Конечно, нам нужна документация (с полнотекстовым поиском!) и обучающие материалы (видео!). Понимание даже очень сложного интерфейса можно сильно облегчить за счет добавления контекстной справки. Возможность узнать все об интересующем элементе интерфейса одним кликом в тот же момент устраняет потребность во всех прочих справочных материалах.
- Минимальный срок обучения работе с системой. Если руководствоваться всеми упомянутыми выше принципами, то порог вхождения для CMS можно значительно снизить. Конечные пользователи редко мечтают вновь сесть за парту. Тем более, разработчик коробочной CMS – не интегратор. Он зарабатывает не на дрессировке конечных пользователей, а на обучении разработчиков.
- Самодостаточность системы. Стандартные задачи должны выполняться без использования каких-либо внешних приложений или сервисов. Банальный пример – генерация превью для фотографий. Некоторые CMS уже имеют встроенные «графические редакторы» для корректировки и оптимизации изображений перед публикацией. Это действительно удобно.