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

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

Не нужно много опыта в 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, Михаил Елфимов.

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

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

Цитата из «Designing Interfaces: Patterns for Effective Interaction Design» by Jenifer Tidwell.
Перевод © 2007, Михаил Елфимов.

Софт не разрабатывается, а создается

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

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

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

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