Интерфейсы

индекс
44,19

Design & Usability. Введение в предмет

Хочется поделиться мыслями об этой области разработки. Что я и сделал, изложив основные аспекты. Статья представлена в виде опорного конспекта. И если у меня все удалось, то воспринимается она легко.

Информация в данной статье взята из свободных источников, а так же выдумана или подслушана автором. Посему все написанное ниже можно считать свободной информацией и использовать везде, где душе угодно. Без каких либо ограничений, ссылок на источник и прочие мелочи жизни. Вся информация в этой статье спорна, и вы можете с ней не соглашаться. Также её можно обсуждать с целью выявления истины.

О том, почему это важно и зачем это нужно знать разработчику.

Юзабилити и дизайн важен каждому человеку причастному к разработке. Почему? Потому, что целью практически любого разработчика является привлечение потенциального пользователя. Пользователю же в свою очередь важно получать наиболее позитивные чувства (или наименее негативные в случае принуждения к работе с нашей абстрактной доброй сферической системой в вакууме). Его не интересуют внутренние процессы, он их не видит. А значит взаимодействуем мы с ним через интерфейс, который должен подчиняться определенным нормам. Для управления этими нормами и нужно юзабилити. Дизайн же нужен, для того чтобы все это грамотно воплотить в жизнь.

image

В итоге наша основная цель, доставить пользователю наиболее приятные ощущения при взаимном обмене информацией, во время работы с нашей системой.

Дизайн.


Перед вами основной свод конкретизированных рекомендаций, которые дают наиболее полную картину стратегии построения интерфейсов.

— Видимость состояния системы (правило обратной связи)
— Информированность пользователя
— Средства обеспечения обратной связи
— Время оповещения
— Равенство между системой и реальным миром
— Свобода действий пользователя
— Последовательность и стандарты
— Предупреждение ошибок
— Понимание лучше, чем запоминание
— Гибкость и эффективность использования
— Эстетичный и минималистический дизайн
— Распознавание и исправление ошибок
— Описание ошибки
— Описание решения проблемы
— Справка и документация

image

Это пятнадцать главных заповедей любого разработчика компьютерных интерфейсов, т. е. минимальные критерии, которым должен отвечать интерфейс любой программы.

Чуть-чуть подробнее:
Видимость состояния системы (правило обратной связи)
Система (в данном случае — компьютерная программа) должна всегда информировать пользователя о состоянии своей работы с помощью соответствующих средств, в разумное время.

Информированность пользователя
Пользователь всегда должен иметь информацию о текущем статусе работы программы.
image

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

Время оповещения
Промежуток времени, в который пользователь получает информацию о реакции на его действие или о событии, должен быть минимальным. Это особенно важно, т. к. от наличия или отсутствия у пользователя информации о текущем состоянии системы определяет его дальнейшие действия. Если он не будет знать, что последняя операция была завершена неудачно, то последующие действия могут вызвать новые ошибки.

Равенство между системой и реальным миром
Система должна разговаривать с пользователем на его языке. Имеется в виду не язык его страны, хотя это тоже имеет значение. В данном случае подразумевается использование понятий, образов и целых концепций, которые уже знакомы пользователю по реальному миру, к которым он привык. Представление информации и объектов в программе должно быть организовано в естественном и логичном порядке.

Свобода действий пользователя
Пользователь должен иметь контроль над системой и возможность изменить текущее состояние программы.
image
Последовательность и стандарты
Принцип последовательности означает использование одних и тех же средств для выражения схожих образов и выполнения действий, имеющих одинаковую природу. Принцип последовательности при разработке интерфейсов должен соблюдаться буквально во всем.

Предупреждение ошибок
Этот принцип широко распространен и в обычной жизни, вне сферы компьютеров и интерфейсов для них. «Пожар легче предупредить, чем потушить» — гласил один из плакатов, изданных в конце девяностых годов Министерством внутренних дел для обучения людей технике пожарной безопасности. «Преступление легче предупредить, чем раскрыть» — гласит одно из правил науки криминологии.
Применительно к теме проектирования интерфейсов компьютерных программ, принцип предупреждения ошибок означает следующее: «Дизайн, который предупреждает возникновение проблем, лучше, чем самое хорошее сообщение об ошибке».
image

Понимание лучше, чем запоминание
При разработке интерфейса нужно делать все объекты, функции, действия видимыми и легко доступными пользователю. Минимизируйте запоминание — пользователь не должен постоянно стараться удержать в памяти информацию из одной части программы, чтобы применить ее в другой. В любой момент пользователю должно быть ясно, что нужно делать в данный момент.

Гибкость и эффективность использования
Правило вполне закономерное, ведь программа в первую очередь должна решать задачу, над которой работает пользователь. Однако при проектировании интерфейса перед разработчиком часто встает такая проблема: требуется, чтобы интерфейс был одинаково удобен и для новичков, и для опытных пользователей. Но нужно учитывать, это во многом разные потребители, с разными требованиями к программе и разным стилем работы.
image

Эстетичный и минималистический дизайн
Если выразиться проще, то это правило означает: «Ничего лишнего». Не нужно загромождать интерфейс программы элементами, которые в данном случае являются неуместными и малополезными. Дело в том, что каждый элемент, будь то кнопка или текстовая подпись, обязательно отвлекает часть внимания пользователя. Это может привести к тому, что видимость и, соответственно, легкость восприятия пользователем действительно нужных и полезных частей интерфейса будет сильно уменьшена за счет элементов, без которых в данном случае можно было бы вполне обойтись.

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

Справка и документация
Принцип о необходимости предоставления справочной системы и документации к программе, идущий в списке Якоба Нильсена последним, не становится от этого менее важным.
image

Эти пятнадцать так назынаемых эвристических правил известнейшего американского специалиста в области проектирования интерфейсов Якоба Нильсена (Jakob Nielsen), разработанных им совместно с другим исследователем, Рольфом Моличем (Rolf Molich). Формулировку этих принципов в оригинале можно прочитать по адресу www.useit.com/papers/heuristic/heuristic_list.html
Русский вариант с развернутым описанием можно найти в представлении автора Станислава Жаркова в его книге «Shareware: профессиональная разработка и продвижение программ».

Юзабилити.


Согласно википедии:
Юзаби́лити (англ. usability — дословно «возможность использования», «способность быть использованным», «полезность» ) — понятие в микроэргономике, обозначающее итоговый уровень удобности предмета для использования в заявленных целях. Термин имеет связь с понятием «эргономи́чность», но в отличие от последнего меньше ассоциируется с технической эстетикой, с внешним видом и более привязан к утилитарности «юзабельного» объекта.

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

принципы юзабилити

Правило 7±2
Возможности мозга по обработке информации не безграничны, в соответствии с результатами исследования Джорджа Миллера кратковременная память может одновременно содержать от 5 до 9 сущностей. Этот факт часто используется при обосновании необходимости сократить количество элементов в навигационных меню до 7, что вызывает горячие дебаты, поскольку не совсем ясно, как это правило должно применяться в вебе. [Miller’s studies]
image

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

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

Правило 80/20 (Принцип Парето)
Заключается в том, что 80% эффекта получается в результате 20% действий. В бизнесе это правило часто применяется в виде: «80% продаж приходится на 20% клиентов». В веб-дизайне и юзабилити это правило работает не менее эффективно. К примеру, значительно улучшить отдачу сайта можно определив 20% пользователей, заказчиков, действий, продуктов или процессов которые дают 80% прибыли и обратив на них особое внимание при разработке.
image

Правило Фиттса
Опубликованная Паулем Фиттсом в 1954 году модель движений человека, определяет время, необходимое для быстрого перемещения в целевую зону как функцию от расстояния до цели и размера цели. Обычно это правило используется при рассмотрении движения мышью от точки A к точке B. Это может быть важно при размещении элементов, количество кликов на которые желательно увеличить.

Перевернутая пирамида
Перевернутая пирамида — это стиль написания, при котором основная мысль представлена в начале статьи. Статья начинается с вывода, за которым следуют ключевые моменты, а завершается наименее важной информацией. Пользователи хотят получать информацию как можно быстрее, поэтому перевернутая пирамида как нельзя лучше подходит для веба, такого же мнения придерживается и гуру юзабилити Якоб Нильсен.

Удовлетворенность
Пользователи не выбирают оптимальный путь в поисках необходимой информации. Им не нужно самое лучшее и надежное решение, напротив — часто они готовы удовлетвориться быстрым и не самым лучшим решением, которое будет «вполне приемлемым». Применительно к вебу, удовлетворенность описывается именно этим случаем: пользовать получил «вполне приемлемое» решение проблемы — даже если альтернативные решения полнее покрывают его требования на длительный срок.
image

Психология в юзабилити

Синдром утенка (Baby-Duck-Syndrome)
Обычно пользователи привязываются к первому, изученному ими дизайну, и судят остальные по тому, насколько они на него похожи. В результате пользователи предпочитают системы, похожие на те, которые они знают, и не очень любят остальные. Эта проблема часто возникает при редизайне, пользователи, привыкшие к предыдущей версии дизайна, в новой структуре сайта чувствуют себя не комфортно.

Баннерная слепота
Пользователи игнорируют все, что похоже на рекламу, и что интересно, делают это весьма эффективно. Хотя рекламу замечают, ее все равно всегда игнорируют. У пользователей выработаны довольно-таки четкие схемы, которым они следуют, выполняя в вебе различные действия: в поисках необходимой информации они фокусируют внимание на тех частях страницы, где эта информация может быть расположена — на основном тексте и гиперссылках. Большие, красочные, анимированные баннеры в этом случае полностью игнорируются.
Пользователи не видят баннеров
Источник: Banner Blindness: Old and New Findings
Перевод: Пользователи не видят баннеров

Эффект неопределенности (Эффект Зейгарник)
Человек не терпит неопределенности — мы стараемся найти ответы на возникающие вопросы, причем как можно скорее. Эффект неопределенности основан именно на этой особенности поведения людей. Видео ролики, статьи и сюжеты, использующие эффект неопределенности, обычно заканчиваются внезапно, не разрешая сложную ситуацию и не отвечая на возникающие вопросы. Этот эффект часто используется в рекламе: задавая посетителям интересные и провокационные вопросы, рекламщики часто принуждают к чтению материала или клику на ссылке.
Обнаруженный Блюмой Зейгарник в 1927 году эффект помогает установить эмоциональную связь с читателем и невероятно эффективен в маркетинге. Читатели лучше запомнят, о чем была реклама, и даже мелкие детали будут запомнены более четко и точно. Эффект Зейгарник используется и при написании текстов для веба, чтобы привлечь и заинтересовать посетителей.

Гештальт принципы восприятия форм

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

Реальный пример действия закона близости c MTV Music Awards 2002. Источник.

Закон сходства утверждает, что сходные объекты человек подсознательно группирует.
The Law of Prägnanz утверждает, что один и тот же объект может играть важную роль в одном визуальном поле и быть частью фона в другом.
Pr?gnanz

В логотипе Macintosh можно разглядеть как обычное счастливое лицо, так и счастливое лицо в профиль. Источник.
Закон симметрии утверждает, что мы склонны воспринимать симметричные объекты как один объект.
Закон смыкания утверждает, что люди склонны объединять объекты, которые на самом деле едиными не являются.
Закон смыкания

В логотипе IBM мы видим буквы I, B, M хотя на самом деле там есть только линии различной длины. Источник.
Подробнее эта тема раскрыта в статье Gestalt principles of form perception.

The Self-Reference Effect
Этот эффект особенно важен при создании текстов для веба, поскольку может значительно улучшить связь между автором и читателем. Вещи, связанные с нашим собственным опытом, мы запоминаем лучше, чем те, которые с нами не связаны. К примеру, после прочтения статьи люди лучше запоминают персонажей, истории или факты, с которыми они были как-то связаны.

Оригинал на английском.

Ресурсы по юзабилити технологиям:
  • Interaction Design Encyclopaedia
    Развивающаяся энциклопедия по взаимодействию человека и компьютера. В статьях внимание обращено не только на термины юзабилити, но и на особенности их использования в современном дизайне.
  • Usability First Glossary: Alphabetical Index
    Один из крупнейших юзабилити глоссариев с сотнями статей о терминах и сущностях юзабилити.
  • Usability Glossary
    Юзабилити глоссарий от Information Technology Systems & Services of the University of Minnesota Duluth.


В России юзабилити технологии активно продвигают UsabilityLab. Ввод в нормы создания интерфейсов можно посмотреть в их видео на хабре
Так же много интересной информации можно найти на сайтах: www.usability.ru www.gui.ru
+51
14 ноября 2009, 13:43
161

комментарии (56)

+1
jeje #
Как бы еще донести это до разработчиков? Они создают формы и т.п., которые сложны и глупы, я не знаю, как такое можно создавать.
+2
Avart #
Чтобы донести до разработчиков я этот пост и написал. Надеюсь, что каждый прочитавший прислушается.
+4
JerryJJ #
Выше как раз упомянуп принцип Парето. Если программер (разработчик) уже потратил 80% энергии на логику работы приложения, то на форму и ее внешний вид осталось всего 20%. Вот и форма соответствующая.

Впрочем, опубликовав эту форму на сильно известном сайте, разработчики честно сказали, что они разработчики (то есть, не проектировщики и не дизайнеры), и попросили совета на счет внешнего вида.
+1
jeje #
Программисты ведь люди с логикой, они видят другие приложения. Так почему же они делают нелогичные интерфейсы, хаос. Ведь разработчик — он и потребитель и не страшно, что глаз приелся во время разработки.
+1
akosarev #
Программисты прежде всего занимаются «начинкой». Очень часто, когда сроки горят кнопочки называются MyButtonXXX, а переменные — afgh (или что-то в этом духе). Думаю, проблема в том, что дизайн интерфейса надо выделять в отдельную задачу, ставить реальные сроки и т.д.

А еще есть случаи, когда человек просто «приучен» к совку, Delphi и VB. Тут даже постановка задачи не поможет.
+1
jeje #
Даже, когда сроков не существует, интерфейс все равно страдает. Как бы не горели сроки, а правильно именовать объекты не составляет труда (а вдруг, проект придется через месяц обновлять *креститься*). Я не говорю, что нужно быть проектировщиком, не зря это отдельная должность. Но и совок-style можно упростить. Хотя, что там говорить 1C, вот, только-только решила интерфейс изменить.
+1
VasilioRuzanni #
Вот как раз-таки, кнопочки могут находиться хоть у черта на куличиках, это не задача программиста их выставить правильно, но называть кнопки НЕ MyButtonXXX18, а переменные — НЕ afgh — это ЗАДАЧА разработчика. И должны огребать жесточайших люлей за такие проделки. В отличие от кнопочек — тут претензии обычно необоснованы — ну не дизайнеры они.
+1
JerryJJ #
Тут вы правы — нужно делить области ответственности специалистов. Одним проектированием интерфейса, другим — программирование и готовые макеты для «референса», а еще лучше отдельно графическое оформление вынести.

А вот от среды программирования качество интерфейсов зависит не сильно :) Скорее от наличия желания сделать хороший интерфейс.

Удобную вещь можно даже в консольном режиме сделать, если немного над этим подумать :)
0
VasilioRuzanni #
Ну тут смотря кого подразумевать под «разработчиками» — программисты, если даже и могут иметь определенное понятие «правильного» интерфейса — совершенно не обязаны быть гуру в дизайне и юзабилити.

Такой продукт, как на скриншоте получился по одной простой причине — сэкономили на специалистах. А отсутствие в команде одного из необходимых специалистов так или иначе скажется на качестве конечного продукта.
0
MobyDick #
а как бы вы изменили эту форму что бы стало хорошо?
0
jeje #
Как минимум выпадающие списки не на всю ширину окна, выравнивание элементов. Взять же тот же Sub BU, к чему он относится, где его поле.
0
Dalairen #
Этим ребятам уже в Блинче всё сказали.
0
jeje #
В линче не сказали ничего нового, я и сам так умею=)
+3
Pongo #
Ознакомьтесь с книгой «Психбольница в руках пациентов». В ней как раз рассказывается о том, как ужасны нынешние интерфейсы. Проблема в том, что интерфейсы разрабатываются программистами, которым лишь бы побольше функций напихать в программу. «Вдруг когда-нибудь кому-нибудь пригодится».

Эта книга предназначена в первую очередь для программистов и руководителей, чтобы они поняли ошибочность текущего подхода, когда интерфейс разрабатывается в самом конце.

В книге так же дан краткий обзор способов создания нормального интерфейса. Полное же руководство по проектированию есть в другой книге Купера: «About Face».
0
VasilioRuzanni #
> Проблема в том, что интерфейсы разрабатываются программистами, которым лишь бы побольше функций напихать в программу. «Вдруг когда-нибудь кому-нибудь пригодится».

Вот почему в команде так важны хорошие управленцы.
0
Avart #
Тут скорее не управленцы важны, а грамотные проектировщики.
0
VasilioRuzanni #
На самом деле и те, и другие. Следить за отклонением от целей ближайшего milestone — задача PM-а, а не проектировщика.
0
SergeyKish #
Проблема в том что заказчики требуют фичи. Очень отговорить их от добавления фичи. Иногда удается найти удачное преобразование задачи, вписывающееся в интерфейс.

В open source продуктах заказчиками являются пользователи. А значит что даже если вы объясните одному пользователю бредовость затеи, то обязательно найдется другой.

А за книгу спасибо, ознакомлюсь
+1
wolfsider #
Нас с artyfarty заказчики просто убивают своим «правилом 3-х кликов». Эта проблема, наверно, всем знакома.
0
jeje #
А вы в лоб, правило 2x3 =)
+1
habraname #
по названию думал, что будет уныло как обычно
ан нет, бодренько, компактно, главное — по существу
и ещё б заменить слова «правила» на «рекомендации» и будет совсем кошерно
0
Avart #
Согласен. Заменил :)
0
habraname #
я говорил про названия пунктов «правила...» в разделе про «юзабилити»
0
Avart #
Там тоже заменил.
0
Kumarunster #
и еще слово «веб» просклонять:)
0
Avart #
С этим в личку. Что вас не устраивает в моем вебе? :)
0
Kumarunster #
отчасти согласен насчет личных сообщений по орфографическим и грамматическим вопросам. Сам пишу с ошибками. Но вот насчет склонения заимствований, тут такое дело:) можно устроить такой холивар, что потом все не рады будут:) Лично мое мнение, «веб» надо склонять как в вашем комментарии, а так-же и по тексту, как то:

«применяться в веб»'e
«подходит для веб»'a
«Применительно к веб»'у итд.

мне кажется, что так читается намного лучше. Прошу прощения за оффтоп!
0
Avart #
Оке. Я тебя услышал. Завтра подправлю.
+4
p1uton #
Вся информация в этой статье спорна, и вы можете с ней не соглашаться — отличная отмазка :) Самое печальное в том, что информация в этой статье действительно спорна.

habrahabr.ru/blogs/ui_design_and_usability/70943/ — практически все, что там написано, относится и к этой статье.
0
Avart #
Я попытался сформулировать основные аспекты, на которые можно полагаться во время разработки дизайна. Я надеюсь они принесут практическую ценность. Данный текст не претендует на звание научной работы.

Давайте обсуждать. В споре рождается истина.

Если не сложно, то прям по пунктам, как у вас в ссылке высказывайте ваше недовольство.
0
p1uton #
Правило 7±2
Возможности мозга по обработке информации не безграничны, в соответствии с результатами исследования Джорджа Миллера кратковременная память может одновременно содержать от 5 до 9 сущностей. Этот факт часто используется при обосновании необходимости сократить количество элементов в навигационных меню до 7, что вызывает горячие дебаты, поскольку не совсем ясно, как это правило должно применяться в веб. [Miller’s studies]

В этом пункте 2 ссылки — на само исследование Миллера (от 1956 года) и на статью, подробно объясняющую, что правило «7 ± 2» не имеет отношения ни к числу пунктов в меню на сайте, ни к юзабилити сайтов вообще.

Довольно станно со стороны автора (оригинала) сначала сообщать, что есть «правило 7 ± 2», потом говорить, что «оно спорное» и ставить ссылку на статью, опровергающую его первоначальное утверждение. При этом ссылок, подтверждающих его утверждение, вообще нет.
0
Avart #
Вы считаете, что оно не оправдано?
Поделюсь примером из жизни.

Со времен второй мировой войны существует правило «Приказов». Согласно ему при подаче письменного приказа его текст нужно разбивать на 2-3 части. Вне зависимости от смысла приказа. Если он излагается как-то иначе, то воспринимается он в разы хуже. Источник я вам привести не смогу, но если вы не поленитесь поискать письменные приказы российской армии, вы легко найдете этому подтверждение.

Информацию до пользователя стоит доводить так же. Порциями по 5-9 кусочков.
0
puzik_ua #
Понятное дело что пользователь не запомнит неограниченное число элементов(например пунктов меню). Но все же не понятно почему люди продолжают втюхивать число 7 ± 2 когда сами приводят опровержение о отсутствии магических чисел. Правило скорее должно звучать как «Не перегружайте пункты меню » или «человек не в состоянии запомнить бесконечное количество пунктов меню, поэтому число пунктов меню должно быть небольшим и легко восприниматься»…
+1
p1uton #
Все правильно — его же нужно запомнить. А пункты в меню запоминать не нужно.
0
p1uton #
Правило 2-х секунд
Заключается в том, что пользователь не должен ждать любой реакции системы, к примеру, запуска или переключения приложения, более 2-х секунд. Значение 2 секунды выбрано произвольно, но кажется достаточно подходящим. В общем случае, чем меньше ждет пользователь, тем лучше.

Правильнее так: пользователь не должен ждать больше 2 секунд определенных типов реакции системы, таких как переключение между приложениями или запуск приложения (это ошибка перевода).

Но и в этом случае получается так: «Правило 2-х секунд» -> «вообще-то это число взято с потолка» -> «чем быстрее, тем лучше». Спорить сложно, но принципом юзабилити это не является.
0
Avart #
Про ошибку перевода согласен. Сейчас исправлю.

А вот про то, что не является принципом юзабилити, не согласен.
0
p1uton #
Принципы и правила — это утверждения, которым можно воспользоваться на практике. Например, я верстаю текст, в тексте ссылка и я не знаю как ее нужно оформить. Смотрю в гайдлан — там написано «ссылка в тексте — цвет такой-то, подчеркнутая, при наведении цвет меняется на такой-то».

«Время реакции не больше 2 секунд» — это правило (им можно воспользоваться на практике при необходимости). «Чем быстрее, тем лучше» — уже не правило.
0
Avart #
Я больше чем уверен, что если бы вот в этой конкретной статье не было бы картинок, заголовков и выделения болдом, её бы осилило больше 10 человек. А посему возникает мнение, что внешний вид очень важен.
+1
Zyava #
Вы пропустили заголовок «Равенство между системой и реальным миром» жирным выделить, раз уж Вы печетесь о внешнем виде — поправьте пожалуйста.
0
Avart #
Спасибо.
+1
Pongo #
Может уберете лишние картинки из текста? Они не содержат никакой дополняющей информации. Зато они мешают, отвлекают от чтения.
–1
padonaque #
Может уберете этот лишний комментарий? Он не содержит никакой дополняющей информации. Зато выглядит глупым, отвлекает от чтения.
0
grobitto #
информация должна быть доступна в 3 клика — имхо неверно.

количество кликов неважно, если каждый последующий клик очевиден
0
Avart #
Не всегда так. Длинные последовательности однообразных действий(кликов) утомляют пользователя.
0
grepto #
Свобода действий пользователя
Пользователь должен иметь контроль над системой и возможность изменить текущее состояние программы.


Очень часто в требование к разрабатываемым системам включается обязательное ограничение действий пользователя (в той или иной степени) системой
0
Avart #
Конечно. Оно в большинстве своем направлено на ограничение возникновения ошибок и их предотвращение.
+1
grepto #
И второй аспект, помимо предотвращения ошибок, — это разграничение доступа к получению и модификации данных.
+1
curt #
Я сегодня увидел лицо в профиль на иконке Finder'a офигеть :)
0
zimer #
> В логотипе IBM мы видим буквы I, B, M хотя на самом деле там есть только линии различной длины.

В логотипе IBM мы видим буквы I, B, M, потому что там именно это и написано
+2
zimer #
также на всей этой странице мы видим какой-то текст, хотя на самом деле там есть только черные и белые пиксели которые «случайным» образом оказались сгруппированы
+1
vrecobra #
в разделе «Дизайн»:
Видимость состояния системы (правило обратной связи)
Система (в данном случае — компьютерная программа) должна всегда информировать пользователя о состоянии своей работы с помощью соответствующих средств, в разумное время.

Информированность пользователя
Пользователь всегда должен иметь информацию о текущем статусе работы программы.


Эти пункты по смыслу никак не отличаются, просто разная формулировка («система должна информировать» и «пользователь должен иметь информацию»). Стоит их объединить.
Еще я бы объединил эти два пункта с двумя следующими, т.к. они дополняют первоначальное утверждение:

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

Время оповещения
Промежуток времени, в который пользователь получает информацию о реакции на его действие или о событии, должен быть минимальным. Это особенно важно, т. к. от наличия или отсутствия у пользователя информации о текущем состоянии системы определяет его дальнейшие действия. Если он не будет знать, что последняя операция была завершена неудачно, то последующие действия могут вызвать новые ошибки.


Итого эти 4 рекомендации можно было бы свести в одну, например так:
Обратная связь
Система должна своевременно предоставлять пользователю обратную связь, т.е. информировать его о текущем состоянии системы, и о смене состояний в результате действий пользователя. Выбор конкретного типа обратной связи зависит от типа информации и типа действий пользователя. При смене состояния системы (например, в результате нажатия пользователем кнопки и т.п. действиях) следует стремиться информировать пользователя об этих изменениях как можно раньше, т.е. минимизировать время отклика.

В более подробной версии текста можно было бы еще дать пояснения, почему это важно, привести пару примеров и т.п.
Проблема многих подобных рекомендаций (это касается не только дизайна), на мой взгляд, в том, что авторы, зная о правиле 7+-2 (или даже включая его в перечень рекомендаций), при этом вываливают на разработчика/проектировщика список из 15, 30,… пунктов, особо при этом не связанных, и ждут, что он их запомнит и будет следовать. Лучше было бы привести эти рекомендации в некоторую иерархическую систему: выделить основные направления, в каждом направлении указать несколько принципов, дать конкретные рекомендации как примеры использования этих принципов.
0
Avart #
Я бы даже сказал больше:
Информированность системы — это 1. видимость состояния; 2. информированность юзера; 3. Обратная связь; 4. Время оповещения.

С вторым замечанием — согласен, не хорошо получилось.
0
DKurilo #
Общие лозунги, положения и прочее выглядят просто потрясающе. Если бы не одно но. В реальности я сталкивался (в России) только со специалистами по юзабилити которые не могут отойти от этих лозунгов.
И их анализ превращается в медвежью услугу и клиенту и компании, для которой они делают исследование.
Например далеко не всегда функциональность ДОЛЖНА БЫТЬ доступна в 3 клика. Зачастую ее надо спрятать, т.к. она хоть и удобна для пользователя, но не несет полной информации, ведет к логической ошибке или подобное, а функциональность, которая должна заменить старую, пока непривычна (смотри синдром утенка). Но все известные мне юзабилисты настаивают, что если людям удобно старое, то оно должно быть легко доступно, если есть телефон, то он должен быть большим и очень толстым (условно), чтоб его было легко найти. При этом никто не хочет посмотреть на проблему более широко и отрицает возможность идти на компромисс с реальностью, утверждая, что это верное решение и других быть не может, поэтому надо менять реальность на разработанное удобство.
Плюс все забывают принцип Парето и пытаются внедрять 100% удобства, хотя на 80% работы, которая необходима для последних 20% «удобства» требуются разработчики, время которых, как известно, дорого. Усугубляет положение тот факт, что большое количество юзабилистов — это бывшие разработчики, порядком подзабывшие землюкод, потому считающие, что они могли бы это все сделать за 2 часа, а им говорят 3-е суток.
Все это приводит к тому, что даже разумные исследования становятся камнем преткновения и из-за чисто эмоциональных реакций иногда так и не внедряются или внедряется тот кусок, которые не критичен.
Писалось в комментариях про грамотного управленца, но в российских реалиях управленец очень часто не отвечает за весь проект и может только дипломатично (или не очень) реагировать на изменение ТЗ, которое происходит вследствие подключения специалистов по юзабилити. Что опять таки не приводит к хорошим результатам. Можно говорить о грамотности заказчика и понимания им, что ему надо и зачем. Но таких по пальцам перечесть и они, обычно, довольны работой.
0
Max2D #
Отличная статья!

Посему все написанное ниже можно считать свободной информацией и использовать везде, где душе угодно. Без каких либо ограничений, ссылок на источник и прочие мелочи жизни.

Судя по этому, Вы не будете против, если я использую материалы статьи в основе своего доклада на IT-конференции?
0
Avart #
Берите. Мне не жалко :)
0
Avart #
Только изучите коменты. Тут есть правки и здравые замечания по поводу материала.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.