Создание продукта
Руководство по UI дизайну для программистов
Глава9: Создание продукта
Руководство по UI дизайну для программистов
Глава9: Создание продукта
Автор: Джоэл Сполски
Переводчик: Наталья Лунева
Техническая поддержка и моральная помощь: Алексей Матюшкин
Редактор: Евгений Дурцев
9. 5. 2000
Мы обсудили принципы хорошего дизайна. Но принципы могут дать возможность оценить и улучшить лишь существующий дизайн. Как же узнать, как должен выглядеть первоначальный дизайн? Многие пишут масштабные, подробные описания всех придуманных ими опций. Затем каждую разрабатывают и размещают в списке меню программы (или на веб-странице). В результате, программа (или страница) обеспечена запланированным объемом функциональности, но работа с ней отчего-то не ладится. Пользователь тупо сидит перед ней, толком не понимая, что же программа делает, не зная, как с ее помощью сделать то, что ему нужно.
В Mictosoft эту проблему решают на основе Планирования Деятельности. (По моим сведениям, идея принадлежит Майку Конте -- одному из разработчиков Excel, которому в один прекрасный момент все надоело, и он переквалифицировался в гонщики.) Суть состоит в том, чтобы предугадать те виды дейтельности, которые будет осуществлять пользователь с вашей программой, и сконцентрироваться на том, чтобы сделать выполнение деятельности простым и удобным. Рассмотрим в качестве иллюстрации следующий пример.
Вы решили сделать веб-страницу, с помощью которой можно рассылать поздравительные открытки. Пользуясь природной интуицией, вы составляете следующий список функций:
| |
Нежелание или неспособность создателей приложения предоставить пользователю какой-нибудь интуитивно понятный способ обменяться данными с программой -- может закончиться созданием типичного для Macintosh середины 80-х интерфейса: вначале программа предлагает пустую открытку со списком меню для набора текста, картинок, для поиска и загрузки открыток из библиотеки, и для рассылки.
Далее пользователь вынужден листать списки меню, пытаясь угадать все возможные комманды, и заниматься синтезом этих атомарных команд для того, чтобы создать картинку.
По методу Планирования Деятельности, вы сначала описываете те виды деятельности, которые могут заинтересовать пользователя. Достаточно побеседовать с потенциальными пользователями, и вы сможете составить такой список:
Теперь, вместо того, чтобы рассуждать о программе как программист («какие функции нужны для того, чтобы сделать открытку»), вы думаете как пользователь: какие действия он совершает, а именно:
И вдруг, рой идей проносится у вас в голове. Вместо того чтобы начать с пустой открытки, можно предложить следующие альтернативы:
Что Вы хотите сделать?
|
|
Достаточно бросить взгляд на список основных действий, чтобы понять, что они тянут за собой дополнительные. Например, отправляя поздравление с днем рождения или юбилеем, вы можете захотеть, чтобы вам в следующем году напомнили поздравить этого человека. Поэтому уместно будеть добавить галочку «напомнить в следующем году». Приглашение же подразумевает реакцию приглашаемого, поэтому вам может прийти в голову идея, добавить опцию сбора сообщений от приглашаемых электронным путем. Подобные возможности остаются незамеченными, когда вы разрабатываете программу, исходя из функциональности программы, а не из деятельности пользователя.
Приведенный пример тривиален; при разработке любого серьезного приложения преимущества от Планирования Дейтельности будут еще больше. Начиная с нуля разработку программы, вы уже представляете, какие виды деятельности она будет охватывать. Развить ваше представление совсем несложно, достаточно просто собрать идеи ваших коллег (посредством мозгового штурма), составить список возможных действий, и выбрать из них те, на которых вы считаете нужным сконцентрироваться. Письменное оформление ваших представлений значительно улучшит дизайн будущей программы.
Планирование Деятельности приобретает еще большее значение, когда вы работаете над второй версией программы. В таком случае полезно понаблюдать за группой пользователей, чтобы понять, в каких целях они используют программу.
На первых этапах жизни Excel -- до версии 4.0 -- в Microsoft полагали, что большая часть клиентов пользуется программой для разработки финансовых сценариев типа «что -- если», когда вы, к примеру, изменяя переменную «рост инфляции», просчтиваете прибыльность предприятия.
При разработке Excel 5.0, когда мы впервые применили метод Планирования Деятельности, оказалось достаточным понаблюдать за тем, как пять клиентов используют программу, чтобы понять, что огромное количество людей применяют ее для ведения списков. Они не вводили никаких формул, и не совершали никаких арифметических действий! И это привело к тому, что мы придумали огромную массу функций, которые облегчали именно ведение списков: удобную сортировку, автоматическое внесение данных, автоматический фильтр для показа части списка, функции множественного пользователя, которые позволяли нескольким людям одновременно работать с одним и тем же списком при автоматическом согласовании данных.
В то время пока разрабатывался Excel 5.0, Lotus выпустил «образцовое» приложение для обработки крупноформатных таблиц, под названием Improv. Согласно пресс-релизам, Improv был программой нового поколения, которая должна была затмить все, что было придумано ранее. По странному стечению обстоятельств, Improv был сначала доступен на NeXT, что уж точно не способствовало росту продаж, но многие умные люди полагали, что Improv станет для NeXT тем, чем VisiCalc был для Apple II: приложением-приманкой, ради которого люди бросятся в магазины и закупят новое железо.
Конечно, Improv остался на задворках истории. Попробуйте поискать его в сети -- вы найдете его разве что на страницах архиорганизованных менеджеров складских помещений, которые -- по какой-то причине -- сделали веб-страницу с описью всего хлама, что пылится в их кладовых.
Почему? Потому что в Improv было практически невозможно вести списки. Его создатели полагали, что люди будут использовать приложение для создания сложных многомерных финансовых моделей. Если бы они спросили этих людей, то обнаружили бы, что ведение списков есть гораздо более распространенный вид деятельности, чем составление многоразмерных финансовых моделей, а в Improv ведение списков было мучительно тяжелой, а то и невыполнимой, задачей.
Итак, метод Планирования Деятельности полезен на начальной стадии развития продукта, когда нужно очертить круг действий. которые пользователи хотят выполнять, и безусловно полезен на стадии совершенствования продукта, когда нужно понять, какие действия пользователи совершают.
Еще одним примером может служить эволюция веб-страницы , которая замышлялась как огромных поисковый портал для Usenet. Первоначальный интерфейс содержал всего-навсего поле для ввода текста и кнопку «искать в Usenet». Проведенное в 1999 Исследование Деятельности показало, что характерной деятельностью для большинства клиентов был сравнительный анализ продуктов или услуг, типа «какую машину выбрать». Страница была рерганизована, и сегодня она представляет собой страницу по анализу отзывов о продуктах, ее изначальная поисковая функция осталась на заднем плане. Это возмутило небольшое количество клиентов, которые пользовались сайтом для поиска информации о том, совместима ли их видеокарта Matrox с Redhat Linux 5.1, но привело в восторг гораздо большую часть пользователей, которые просто хотели купить самую лучшую цифровую камеру.
Еще одна прелесть метода Планирования Деятельности состоит в том, что с его помощью вы можете составить список вещей, которыми вы заниматься не будете. При разработке какой бы то ни было программы оказывается, что список вещей, которые вы хотите сделать, в три раза больше списка вещей, которые вы успеете сделать по времени. А наилучший способ решить, что нужно сделать, и что можно не делать -- это оценить, какие функции обеспечивают решение самых важных действий пользователей.
Воображаемые пользователи.
Воображаемые пользователи.
Лучшие из лучших дизайнеров пользовательских интерфейсов единодушны в одном: перед тем как разрабатывать дизайн интерфейса, нужно придумать и описать воображаемых пользователей оного. Возможно, вы помните воображаемого пользователя Петра, которого я описал во к этой книге.
Итак, Петя. Он работает бухгалтером в издательстве технической литературы, Windows использует уже в течение 6 лет на работе и немного дома. Компетентен, разбирается в технике. Инсталлирует программное обеспечение на своих компьютерах, почитывает журнал «PC Magazine» и как-то раз программировал несложные Word макросы, чтобы помочь симпатичной секретарше в бюро с рассылкой инвойсов. Дома у него кабельный модем. Петя никогда не работал с Macintosh. «Они слишком дорогие»,-- скажет он вам,-- «компьютер на 700 Мгц с памятью на 128 Мб можно купить за...» Да, Петр, мы поняли.
Когда вы читаете эти строки, пред вашими глазами возникает образ вашего клиента. Я мог бы придумать и иной образ:
Патриция. Профессор английского языка, автор нескольких поэтических сборников, получивших признание в определенных кругах. Использует компьютер для обработки текстов, начиная с 1980 года, хотя за все это время пользовалась лишь двумя программами: Nota Bene (древний академический текстовый редактор) и Microsoft Word. Она не собирается тратить свое время на изучение того, как работает компьютер. Имеет склонность складывать документы куда придется, как будто понятия «директория» не существует.
Совершенно очевидно, что создание программы для Петра отличается от создания программы для Патриции, которое, в свою очередь, отличается от создания программы для Макса -- шестнадцатилетнего молодца, который установил Linux на свом домашнем компьютере, часами болтает по «аське», и не признает софтвера от Micro$oft.
Когда вы придумали своих пользователей, понимание того, является ли ваш дизайн соответствующим, приходит почти автоматически. К примеру, большинство программистов склонны переоценивать способность среднестатистического пользователя догадаться о предназначении той или иной штуковины. Стоит мне написать о том, что интерфейсы командной строки неудобны в использовании, как немедленно приходит неизбежное электронное письмо о том, что интерфейс командной строки супер-функциональны, потому что позволяет выполнять вещи наподобие 'gunzip foo.tar.gz | tar xvf-'. Но как только вы представите себе, как Патриция будет набрать 'gunzip...', становится очевидно, что подобный интерфейс просто не может отвечать ее требованиям, никогда. Игра с воображаемым пользователем позволяет вам почувствовать своего реального пользователя, что необходимо для того, чтобы создать программу, удовлетворяющую его потребности. (И конечно, если вы разрабатываете Linux backup софт для продвинутых сисадминов, вам придется нарисовать образ Серёги, который и на пушечный выстрел не подойдет к Windows, который он называет исключительно «операцинной системой» в кавычках, который пользуется персонально модифицированной версией tcsh, у которого целый день работает Х11 с четырьмя рабочими столами. И с 11 xperfs впридачу.)
Подведем итог: создание хорошего софтверного продукта разбивается на шесть этапов:
Хороший пользовательский интерфейс -- это залог успеха на рынке. Но, кроме этого, хороший пользовательский интерфейс делает людей немного счастливее, потому что люди счастливы тогда, когда они решают поставленные задачи. Именно поэтому работа в сфере UI дизайна приносит такое удовлетворение. Где еще найдешь возможность делать миллионы людей чуточку счастливее?
В английском оригинале статья называется
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005 by Joel Spolsky. All Rights Reserved.
| | |
