Pull to refresh

Принципы usability для CMS

Reading time 4 min
Views 2K
Ни разу не слышал, чтобы наши (читай: совковые) вендоры коробочных CMS заказывали usability тестирование своих продуктов. Напрашивается два основных вывода:
  1. Usability этих систем и так на высоте! В каждой компании есть свои usability специалисты, которые принимают участие в разработке на всех стадиях развития продукта – организуют тестирования, дают рекомендации, экспертную оценку и т.д. В таком случае это UDD – User-Driven Development.
  2. Usability этих систем по-взрослому сосет. Программеры делают функционал. Дизайнеры делают дизайн. Маркетинг делает продажи. Программер думает об эклипсе. Дизайнер думает о фотошопе. Маркетолог думает о пауерпоинте. Ну а конечный пользователь периодически задумывается обо всех трех сразу – об их интеллекте, сексуальной ориентации и месте произрастания их передних конечностей. Это методология AUDD – Anti-User-Driven Development или Angry User Driven Development.
Если вам известны компании, которые работают по первой схеме, то дайте знать. На ребят, делающих все по второй схеме, я насмотрелся вдоволь, поэтому считаю полезной для всеобщего ознакомления публикацию «11 usability principles for CMS products» за авторством James Robertson. Далее позволю себе привести вольный пересказ списка из одиннадцати принципов CMS usability, которые выделяет Джеймс, с моими комментариями.
  1. Минимально необходимое количество отображаемых опций. На экране должны присутствовать только те элементы, которые могут понадобиться пользователю здесь и сейчас для выполнения задачи. Количество общих для всего интерфейса системы элементов должно быть минимальным.
  2. Надежность и обработка ошибок. Система обязана всегда обеспечивать сохранность данных, с которыми работает пользователь. Пример – функция авто-сохранения. «Обработка ошибок» подразумевает не только ясность сообщения об ошибке и способах ее исправления, но и общую толерантность системы к ошибкам пользователей (если мы знаем, как исправить ошибку – то нужно исправить ее автоматически, а не дергать пользователя).
  3. Интерфейс, ориентированный на задачу. Логика интерфейса должна исходить не из того, как работает система, и как она устроена внутри, а из того, как работает с ней пользователь – из его повседневных задач. Разработчики часто стремятся сделать все «элегантно», когда множество задач решается одним и тем же набором инструментов. Проблема в том, что журналисту электронного издания совершенно фиолетова бизнес-логика вашей гениально спроектированной CMS. Плевать он хотел на «модуль», «инфоблок» и «объект» – ему статью сдавать к двенадцати.
  4. Сокрытие деталей реализации. В предыдущем пункте 3 мы отказались от метафор из архитектуры системы. Осталось избавиться от деталей реализации – никаких HTML, JPEG, XML и прочих технических тонкостей и широкостей. Есть странички и папочки – никаких файлов, директорий и баз данных с индексами.
  5. Наглядный интерфейс. Пользователь должен понимать, с чем он сейчас работает, что он сделал и, что он еще может с этим сделать. Интерфейс системы должен быть целостным и логически продуманным. Размещать сочинения Хайдеггера в шрифте 8pt также не рекомендуется. Текст и подписи должны быть доходчивыми и однозначными.
  6. Соответствие умственным моделям пользователей. В большинстве случаев люди мыслят шаблонно, ведь любая умственная деятельность – штука энергозатратная. К чему навязывать новые понятия, схемы и сценарии работы, когда есть уже проверенные «папка», «страница» и «корзина». В одной фразе данный принцип радикально сформулировал Стивен Круг (Steven Krug): «Don’t make me think» («Не заставляйте меня думать»).
  7. Удобство как для новичков, так и для опытных пользователей. Новичкам – подсказки и наглядность, опытным юзерам – хоткеи, шорткаты и прочие средства повышения эффективности работы вплоть до специализированного интерфейса.
  8. Эффективность в дизайне интерфейса. Веб-интерфейс традиционно был менее эффективным ввиду своей медлительности и асинхронности. Сейчас интерфейсы в стиле веб-два-нуль-йоу уже приближаются по эффективности работы к обычным приложениям. Эффективность складывается из минимума движений, кликов и переходов между «экранами» до достижения результата. Формы и контролы должны быть логично сгруппированы, а не раскиданы по страницам и вкладкам. Еще одним немаловажным моментом является собственно скорость работы системы. Даже если серверное приложение задумывается надолго, это не значит, что интерфейс клиента должен точно так же подвисать.
  9. Справка и подсказки в интерфейсе. Конечно, нам нужна документация (с полнотекстовым поиском!) и обучающие материалы (видео!). Понимание даже очень сложного интерфейса можно сильно облегчить за счет добавления контекстной справки. Возможность узнать все об интересующем элементе интерфейса одним кликом в тот же момент устраняет потребность во всех прочих справочных материалах.
  10. Минимальный срок обучения работе с системой. Если руководствоваться всеми упомянутыми выше принципами, то порог вхождения для CMS можно значительно снизить. Конечные пользователи редко мечтают вновь сесть за парту. Тем более, разработчик коробочной CMS – не интегратор. Он зарабатывает не на дрессировке конечных пользователей, а на обучении разработчиков.
  11. Самодостаточность системы. Стандартные задачи должны выполняться без использования каких-либо внешних приложений или сервисов. Банальный пример – генерация превью для фотографий. Некоторые CMS уже имеют встроенные «графические редакторы» для корректировки и оптимизации изображений перед публикацией. Это действительно удобно.
Tags:
Hubs:
+11
Comments 19
Comments Comments 19

Articles