1.7-1.11 "Об интерфейсе", Алан Купер, Роберт Рейман и Девид Кронин



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

1.8 Так что же такое проектирование взаимодействия? Это не просто красивые кнопки и поля ввода с иконками или брендинг. Это проектирование поведения продуктов и систем с более глубоким пониманием контекста. Тут нам помогут методы синтеза и анализа. Важным этапом в проектировании взаимодействия является выявление целей пользователей (с. 43-44).

1.9 Необходимо различать цели пользователей и их нанимателей; например, мы можем подумать, что цель бухгалтера при использовании какой-либо программы — эффективная обработка накладных. Но это не так, это может быть цель его начальника, но не самого бухгалтера. У бухгалтера целью может быть повышение, интерес к работе, профессионализм.
Если изучить существующие интерфейсы, мы увидим, что многие заставляют чувствовать пользователя себя идиотом, делать ошибки, опыт работы с интерфейсом не вызывает положительных эмоций и т.д.
Эти ошибки возникают, т.к. компании неверно ставят свои приоритеты. Их волнует в первую очередь реализация и они забывают о самых пользователях, их целях и потребностях. Сейчас в разработке проектирование выполняется зачастую чуть ли не в конце, что является жесткой ошибкой, ведь невозможно эффективно спроектировать здание после его строительства или вознесения фундамента (с. 44-45).

1.10 Первый и главный вопрос не «Каковы задачи?», а "Каковы цели пользователей, которые будут пользоваться нашим продуктом?". Цели связаны с мотивами, а посему они практически не меняются со временем в отличие от задач и деятельности, зависящих от технологий. Пример? Цель пассажира из точки А в Б всегда — скорость, удобство, безопасность. Только раньше этому удовлетворяла здоровая лошадь, а сейчас — определенный технический транспорт. Цели не изменились, но задачи и деятельность — идут в след за технологиями (с. 45-46).

1.11 Не стоит следовать правилам в отрыве от целей пользователя. То есть важную роль играет контекст; многие думают, что упрощение освоения интерфейса должно всегда соблюдаться. Но это не значит, что это правило первично, особенно, если оно в ущерб целям пользователя, например, у приложения может быть первичное требование эффективности, а уже простота интерфейса — в последнюю очередь.
Здесь работает следующий принцип: результат качественного проектирования делает пользователей более эффективными (с. 47-48).

Далее речь о том, в чем же состоит целеориентированный процесс проектирования.

1.1-1.6 "Об интерфейсе", Алан Купер, Роберт Рейман и Девид Кронин


Книга «Об интерфейсе» — настольная книга проектировщика UI, одна из самых известных и ценных по данной теме. Книга в первый раз была издана в далеком 1995 году, но мысли, высказанные в ней, не потеряли свою актуальность и до нашего времени.

В цикле Алана Купера ведется краткое изложение о прочитанном.

1.1 Процесс проектирования должен предшествовать созданию кода и тестирования (с. 35).

1.2 Надо думать о целесообразности содержимого, не копировать слепо поведение интерфейса из других приложений: автор приводит пример всплывающего окна об ошибке, где есть кнопка «ОК» и кнопка закрытия.
Он объясняет, что это выглядит как обвинение пользователя программой в ошибке, в которой нет вины пользователя. Также автор поясняет, что подтверждающие запросы, точно ли удалить то или сё — тоже являются лишними (36-37).

1.3 Интерфейс должен предугадывать наиболее возможные потребности пользователя к приложению (с. 37).

1.4 Программы требуют от пользователя компьютерной грамотности — и это серьезный недостаток, который можно ликвидировать качественным проектированием (с. 37-38).

1.5 Автор считает, что проблема в том, что продукт проектируют программисты. Им приходится выбирать между простотой кода и простотой интерфейса. Они проектируют для себя, а не для пользователей, которые программистами не являются (с. 39).

1.6 Проектировщик такой же специалист, как и программист, со своими специальными знаниями и навыками. Программисты не спрашивают помощи у пользователей в написании кода и в плане проектирования ситуация аналогичная. Стоит различать пользователей и заказчиков продукта (с. 39-40).

Дальше речь пойдет об эволюции проектирования в промышленности.