Скептицизм дизайнера

Блог Алексея Скуратова о дизайне, пользе, работе и инструментах
12 ноября, 19:19

Книга: Интерфейс

Книга «Интерфейс — Новые направления в проектировании компьютерных систем», написанная Джефом Раскином относится к классической литературе, стоящих у истока проектирования систем.

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

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


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

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

1. Предпосылки

При разработке интерфейсов следует сперва учесть общие факторы, а потом уже рассматривать индивидуальные различия

Последовательность разработки интерфейса должна быть цикличной:
Определить задачу → Спроектировать → Реализовать
Для лучшего результата всегда необходимо стремиться к максимальной гибкости.

Определение задачи будет постоянно меняться в ходе разработки и это нормально.

Время пользователя бесценно, а труд священен. Если перефразировать Первый закон робототехники Азимова: «Робот не может причинить вред человеку или своим бездействием допустить, чтобы человеку был причинен вред»

Первый закон звучит так: «Компьютер не может причинить вред данным пользователя или своим бездействием допустить, чтобы данным был причинен вред»


А второй закон: «Компьютер не должен тратить впустую ваше время или вынуждать вас выполнять действия сверх необходимых»


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

Простые задачи должны оставаться простыми независимо от уровня сложности всей системы.

Сравните, например, насколько труднее установить время на электронных наручных часах с четырьмя кнопками, чем выполнить то же самое действие на механической модели часов.

2. Когнетика и локус внимания

Совокупность сведений о свойствах и возможностях человеческого скелета и органов чувств составляет науку эргономику. В ней учитывается статистическая волатильность параметров человеческого тела. Проектируя автомобильное кресло, подходящее для 95% населения, мы делаем их неудобными для оставшихся 5%.


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

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

Любая привычка означает отказ от внимания к деталям

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

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

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

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

Человек имитирует одновременное выполнение нескольких задач, через последовательное переключение внимания

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

Если выдается сообщение, которое не требует ответа от пользователя, оно может быть устранено

3. Режимы, монотонность и мифы

Интерфейсы допускают несколько интерпретаций одного жеста. Например, в одном случае нажатие на «Return» можно вставить текст в символ возврата каретки, а в другом привести в исполнение написанной строки в качестве команды.
Режимы — это реакции интерфейса на один и тот же жест разными интерпретациями.


При этом монотонность означает не то, что с каким-то содержанием нельзя работать разными способами, а то, что для вызова одной и той же команды не должно использоваться множество жестов.

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

Норман (1983) указывает три метода предотвращения модальных (т. е. связанных с режимами) ошибок:

1. Не использовать режимы.
2. Обеспечить четкое различие между режимами.
3. Не использовать одинаковые команды в разных режимах, чтобы исключить ошибки связанные с неверным режимом

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

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

Используйте переключатели вместо выключателей. На выключатели стоит полагаться только в том случае, когда можно видеть значение контролируемого состояния и оно находится в локусе внимания пользователя или в кратковременной памяти.

Если интерфейс вынуждает вас запоминать существование того или иного его элемента, это означает, что этот элемент является невидимым.


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

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

4. Квантификация

Одним из лучших подходов к количественному анализу моделей интерфейсов является классическая модель GOMS — «правила для целей, объектов, методов и выделения» (the model of goals, objects, methods, and selection rules), которая впервые привлекла к себе внимание в 80-х годах (Card, Moran and Newell, 1983).

Моделирование GOMS позволяет предсказать, сколько времени потребуется опытному пользователю на выполнение конкретной операции при использовании данной модели интерфейса



Закон Фитса (Fitts’ Law) позволяет определить количественно тот факт, что чем дальше находится объект от текущей позиции курсора или чем меньше размеры этого объекта, тем больше времени потребуется пользователю для перемещения к нему курсора

Закон Хика (Hick’s Law) позволяет количественно определить наблюдение, заключающееся в том, что чем больше количество вариантов заданного типа вы предоставляете, тем больше времени требуется на выбор.

5. Унификация

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


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

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

Машина должна подстраиваться под людей

Иначе возникает непонимание между пользователем и интерфейсом

Облегченные версии программного обеспечения («lite» версии) зачастую не имеют успеха на рынке, поскольку пользователь никогда не знает, какие именно возможности полного пакета могут ему понадобиться и вынужден приобретать весь пакет.

Чем меньше объект (т. е. чем меньше его визуальный вес), тем больший контраст должен использоваться для его указания — однако это вопрос эргономический

6. Навигация и другие аспекты

Самый хвалебный термин, используемый в отношении интерфейсов, — «интуитивный». Его путают со «знакомый».


Клиент хочет получить нечто, что должно значительно превосходить то, что предлагается конкурентом.

То что должно быть превосходящим, значит должно быть другим — чем значительнее улучшение, тем сильнее разница

Поэтому результат не может быть интуитивным . Клиент хочет получить интерфейс, который бы не сильно отличался от существующей практики разработки интерфейсов (что почти неизбежно означает Microsoft Windows) и, в то же время, каким-то образом стал бы значительным усовершенствованием. Это может быть достигнуто только в редких случаях, когда исходный интерфейс имеет какой-то существенный недостаток, который можно исправить простыми средствами.

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

Проблему пиктограмм можно рассматривать как проблему ограниченной видимости.

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

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

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

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

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

Не смотря на то, что описанные подходы уже используются и проверены временем, заметка будет обновляться по мере нахождения более эффективных приемов работы.

1. В проекте нужен «Мастер»

Задача Мастера в том, чтобы заниматься слиянием исходников (синхронизацией). Хотелось назвать его библиотекарем, но в продуктовых командах — библиотекарь это отдельный исполнитель, занимающийся исключительно библиотекой и гайдлайнами.

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

2. Версии файлов заменяем датами

Новый день работы начинается с дубликата папки с самыми актуальными исходниками. Таким образом вы сможете откатиться обратно или восстановить хронологию действий, если этого потребует проект в любой удобный для вас момент.

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

Формат имени папки строится на привычном дедуктивном методе:
«Project-name-yyyy-mm-dd». Где имя может содержать дополнительную информацию, например «АЕ Анимация иконок меню». Это нужно для более быстрого поиска работ.

Комментарии стоят не везде, а во благо приоритетности и быстрого поиска.

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

Изредка, случается, что необходимо иметь две разных версии в один день. Тогда рекомендуется дописывать версии и пояснять их при необходимости:
Project-name-yyy-mm-dd ver-1
Project-name-yyy-mm-dd ver-2

Поскольку мы полностью в курсе только тех изменений, которые произвели сами, необходимо следовать следующему правилу

3. Чужие исходники не трогать

Совместная работа над проектами подразумевает наличие исходников-дубликатов. Если вам необходимо взять исходник другого участника команды — берите его дубликат, а оригинал не трогайте.
Для удобства работы рекомендуется исходники делить именами, например:
Project-name-yyy-mm-dd User 1
Project-name-yyy-mm-dd User 2

Открывая оригинал — вы рискуете по неосторожности испортить чужой исходник не заметив этого. Зачем потом тратить время на поиски и исправления подобных курьезов?

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

В этом скриншоте видно, что в проекте уже теперь две папки — появилась Sedisheva

4. Архив без мусора

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

Дубликаты, которые нужны только для открытия и копирования отдельных данных лучше переименовывать для отличия.

5. Читаемость исходника

То, насколько легко вы или любой другой участник команды сможет сориентироваться в исходнике зависит от ряда важных моментов:

  1. Как выставлены имена артбордов и групп
  2. Есть ли порядок в рабочей области
  3. Как построена работа с листами
  4. Где хранятся утвержденные и не утвержденные макеты.

Про имена

Давайте нумерацию артбордам. Наличие порядковой нумерации сокращает издержки при поиске нужных экранов и синхронизации их со сторонними сервисами (например InVision). Работа с сервисами по прежнему связана с рисками неверной или частичной загрузки контента, которую проще отследить по легким отличительным чертам в именах.

Для отображения разных состояний одних и тех же экранов в нумерации дописывается алфавит.
01. Название экрана — Деятельность на нем
01а. Состояние А
01б. Состояние Б
02. Название экрана — Деятельность на нем

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

1-01. Флоу 1
2-01. Флоу 2
3-01. Флоу 3

Порядок в рабочей области

Хорошим тоном считается нормальная сетка из артбордов. Помимо того, что она радует глаз, так же легко «читается», а главное создает четкую структуру в хаосе драфта из кучи версий.

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

Для отображения нескольких флоу на одном листе я пользуюсь визуальным разделением.

Работа с листами

Разделение проекта на страницы — значительно упрощает работу. Например, использование отдельной страницы для GUI поможет сократить временные издержки на перемещение от экрана с которым работаете до GUI с которого необходимо взять нужный объект.

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

Утвержденные и не очень макеты

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

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

26 июня 2017, 0:04

Книги

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

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

Книги:

  1. Дизайн — это работа Майк Монтейро
  2. Сначала мобильные Люк Вроблевски
  3. Scrum — Революционный метод управления проектами Джефф Сазерленд
  4. Интерфейс Джеф Раскин
Ctrl + ↓ Ранее