7. Гибкость и эффективность использования.
Одна из самых больших проблем – это как соединить простоту интерфейса и его функционал? Как сделать так, чтоб один и тот же интерфейс был понятен и удобен как профессиональному пользователю, так и новичку? Этот принцип юзабилити гласит, что интерфейс должен быть гибким, настраиваемым и с расчетом на ту аудиторию, которая преобладает. Делайте основной упор на простоту из расчета на простого пользователя. Элементы для продвинутых можно сделать значительно меньше и поставить в менее заметные части экрана, т.к. он их найдет везде. Ярким примером является Карта сайта. Согласитесь, что новичок туда вообще не полезет, а опытный пользователь найдет внизу экрана мелким шрифтом эту «картку сайта», или маленькую иконку где-то сбоку. Другой пример – кликеры/тайперы. Т.е. на каждую страницу можно попасть или из меню, кликая по навигации, или с помощью поиска по сайту. Оба варианта должны поддерживаться и в конечном итоге приводить к одинаковому результату.
(мы видим простой поиск для большинства пользователей, а так же расширенный, для продвинутых. При этом функции расширенного поиска спрятаны довольно далеко и только опытный пользователь может их найти, т.е. по сути только тот, кому он и нужен).8. Эстетический и минималистический дизайн
Этот принцип юзабилити гласит – в интерфейсе не должно быть информации, которая не нужна пользователю или которая может понадобиться ему в редких случаях. Аналогичным образом и в формах: вы не должны у пользователя спрашивать ту информацию, которая вам не нужна, или нужна в каких-то исключительных случаях. К сожалению, этим принципом практически никто не пользуется. В 90% случаев при регистрации вас спрашивают и домашний телефон, и мобильный, и адрес и e-mail, и даже дату рождения. А все для того – чтоб поздравить вас с новым годом и днем рождения. Все дополнительные данные вы сможете уточнить позже, при необходимости. А изначально, при регистрации например, или при оформлении заказа спрашивайте только ту информацию, которая вам действительно необходима. Точно так же, на сайте (или в программе, эти принципы универсальны), не стоит выводить пользователю ту информацию, которая может быть когда нибудь ему понадобиться. Например, возьмем тот же Микрософтовский Ворд. Скажите, как часто вы пользуетесь функцией «навигатор» или в вставкой Дата-Время? А тем ни менее, эти кнопки всегда на виду в тулбаре (в зависимости от версии кнопки могут быть разными, но я уверен что если вы посмотрите на них, вы найдете минимум 40% иконок, которыми вы НИКОГДА не пользовались, и даже не знаете что они делают).
(вот типичный пример. При регистрации Озон спросил меня и Имя и Фамилию. При этом, единственное где используется мое имя – это заголовок к письму. Фамилию вообще ни разу не видел, чтоб использовали. И спрашивается – зачем им эти данные? Ведь есть ник. Т.е. форму можно сократить вдвое легко…).9. Помочь пользователю понять и исправить ошибку.
Скажите, что означает ошибка базы данных в строке 433? Или длинные жуткие ошибки в строке памяти LXR-XXX-5438645? Все эти системные сообщения должны сохраняться в логах для администратора сайта/системы. Пользователю же пишите нормальным языком, в чем конкретно ошибка. Более того, пользователя по сути интересует только одно: виноват он или система? И можно ли что-то сделать? Уверен, что у вы сталкивались с тем, что заполняете форму, нажимаете отправить, а вам в ответ какая-то ошибка базы данных. И ты сидишь и мучаешься двумя главными вопросами: кто виноват и что делать? Ушла ли форма? Если да, то вся ли информация? Или попробовать отправить еще раз? Хотя все же такие серьезные ошибки встречаются все реже. Но другой вариант бесит еще больше – ты заполняешь довольно длинную форму, нажимаешь отправить и видишь красную надпись (или всплывающее окно) – внимательно заполните все поля, отмеченные звездочкой. И снова ты сидишь и думаешь – какие поля? Какой звездочкой? Вроде бы я все заполнил, внимательно просмотрел… а потом оказывается что там номер телефона надо написать с пробелами, а не дефисом.
(вот хороший пример – при создании почты на рамблере мне не только сообщается в чем моя ошибка, но и предлагаются варианты ее решения. К сожалению, этот принцип на практике применяется крайне редко).10 Помощь и документация
В идеале, конечно, система должна быть настолько понятной, что никакая помощь или документация не должна быть востребована. Но увы, этого не всегда можно достичь. Поэтому у вас всегда должне быть разработана система помощи. Помощь или документация должна быть простой, понятной, быть легко доступной, соответствовать задачам пользователя (если пользователь находиться на странице покупки, помощь должна подсказывать как работать с покупкой, а не про особенности вашего магазина и его учредителей). Кроме того, документация не должна быть большой и содержать четкие и понятные шаги. Если все-таки документ получается достаточно объемным – сделайте по ней краткую навигацию для быстрого переходы по разным разделам, а так же поиск по помощи.
(а вот тут Сапа подкачала: ведь я нахожусь на конкретной странице – мои площадки, и есть ссылка, которая прямо кричит мне – СЮДА! Справка по ЭТОЙ странице. Но, увы, перекидывает меня на общий раздел хелпа).Ну вот и все основные принципы юзабилити. Давайте еще раз перечислим:
1. Видимость статуса системы.
2. Связь между системой и пользователем.
3. Пользовательское управление (свобода выбора)
4. Последовательность и стандарты.
5. Профилактика ошибок.
6. Узнать проще, чем вспомнить.
7. Гибкость и эффективность использования.
8. Эстетический и минималистический дизайн
9. Помочь пользователю понять и исправить ошибку.
10 Помощь и документация
Принципы юзабилити универсальны, и подходят как для интернет-сайтов, так и для программ и мобильных приложений. Надеюсь, это поможет вам в работе. Еще раз спасибо оригиналу. Кстати, а вы находите Калейдоскоп удобным, или есть пожелания?
Немає коментарів:
Дописати коментар