Михаил Елфимов об интерфейсах

Хорошее замечание написал synchro (автор briefly.ru):
При проектировании интерфейс рассматривают не с точки зрения логики и простоты, а понятности для тупорылого пользователя. Эх, консерваторы… Так ещё долго интерфейсы не станут лёгкими и прозрачными.

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

Сценарии использования

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

Большинство людей хорошо знакомы с фильмами, мы опишем создание сценария в терминах киносценария:

• Кто главный герой [пользователь]? Опишите основные характеристики главного героя [пользователя] и его особенности [недостатки];
• Что является целью главного героя [пользователя] в истории? Как он или она достигает этой цели? Опишите злодея [ограничения], которые мешают главному герою в достижении цели [выполнении задачи]. Как злодей [ограничения] создают проблемы [неоптимальность юзабилити] для главного героя [пользователя]?
• Когда происходит действие сценария? Сейчас или в будущем?
• Где происходит действие сценария? Опишите географическое [физическое] положение [дом, офис, автомобиль и т.д.];
• Почему действия главного пользователя приводят к решению проблемы [выполнению задачи]? Что делает главный герой [пользователь] для выполнения своей задачи?
• Как главный герой [пользователь] разрешает проблемы [выполняет свою задачу]? Набросайте план.

Кроме привычности фильмов, написание сценариев таким образом (описание ограничений с помощью злодея) поможет нам увидеть софт с другой стороны – насколько пользователя могут раздражать постоянные препятствия на каждом шагу. Очеловечивать софт и думать об этом как о человеке, совершающем действия, или мешающем совершать действия, подход, который позволяет наложить сценарии на идею создания фильма, впервые предложила Brenda Laurel (Computers as Theatre @amazon.com).

Цитата из «Effective Prototyping for Software Makers (Interactive Technologies)» by Jonathan Arnowitz, Michael Arent, Nevin Berger.
Перевод © 2007 Михаил Елфимов.

Долговечность прототипа

Долговечность прототипа выражается в двух вещах:

• Как долго прототип будет существовать. Будет ли это одноразовая проба концепции, или этот прототип будет использоваться в нескольких итерациях и разовьется в окончательный дизайн проектируемого софта?
• Как долго прототип влияет на продукт. Будет ли это быстрый набросок какой-то идеи, или это будет основой длительного процесса разработки софта?

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

Цитата из «Effective Prototyping for Software Makers (Interactive Technologies)» by Jonathan Arnowitz, Michael Arent, Nevin Berger.
Перевод © 2007, Михаил Елфимов.

Web Trend Map 2007 @informationarchitects.jp
200 самых успешных сайтов, отсортированные по категории, схожести, успешности, популярности и перспективности.

Представление “куда движется веб” в виде, напоминающем схему метро Токио. Наглядность сомнительная, но подборка и упаковка впечатляют.

У меня есть некоторое количество книг по юзабилити, которыми я могу делиться с желающими.
Напоминаю также про существование открытой библиотеки UPA:Russia.

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

The Design of Everyday Things [прочитал]
Donald Norman

Information Architecture for the World Wide Web [прочитал]
Louis Rosenfeld & Peter Morville

About Face: The Essentials of User Interface Design [прочитал]
Alan Cooper

Effective Prototyping for Software Makers (Interactive Technologies) [прочитал]
Jonathan Arnowitz

Information Design
Robert Jacobson

The Semiotic Engineering of Human-Computer Interaction (Acting with Technology)
Clarisse Sieckenius deSouza

The Visual Display of Quantitative Information, 2nd edition [прочитал]
Edward R. Tufte

Information Dashboard Design: The Effective Visual Communication of Data [прочитал]
Stephen Few

Understanding Your Users: A Practical Guide to User Requirements Methods, Tools, and Techniques (Interactive Technologies)
Catherine Courage, Kathy Baxter

Designing Interfaces: Patterns for Effective Interaction Design [прочитал]
Jenifer Tidwell

A History of Graphic Design [прочитал]
Philip Meggs

Умная толпа: Новая социальная революция [прочитал]
Говард Рейнгольд (@ozon.ru, @bolero.ru, @findbook.ru)

Как получить книгу
Я живу в подмосковье, Пушкино. Периодически я выбираюсь в Москву. Звоните мне, мы договоримся о встрече и я передам вам книгу.
Мой телефон: +7 (926) 46-86-402.
Книга дается на месяц, через месяц вы либо возвращаете её, либо говорите на какой срок она вам еще нужна.

Хочу почитать
WishList @amazon.com

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

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

Как реагировать на такие тестовые задания?

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

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

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

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