 | Поиск |
Скачать 5.84 Mb.
|
| часть всего процесса, и здесь не стоит срезать углы. Далее представлены подробные описания каждого из пяти шагов. Шаг 1: постановка задачи и определение образа продукта Прежде чем приступить к генерации идей, проектировщику важно получить надежное основание для процесса проектирования. Целеориен-тированный подход направлен на создание исчерпывающего определения продукта посредством персонажей, сценариев и требований, однако на данном этапе необходимо определить направление, в котором следует двигаться при разработке сценариев и требований. Сейчас у нас уже есть представление о пользователях, на которых ориентирован продукт, однако еще нет достаточного основания для создания продукта, так что остается место для замешательства. Таким основанием должна стать постановка задачи, а также образ будущего продукта -они чрезвычайно полезны, так как помогают достичь согласия между заинтересованными лицами, прежде чем процесс проектирования двинется дальше. Говоря в общем, постановка задачи определяет цель самого проекти- рования (Newman and Lamming, 1995). Постановка задачи проектирования кратко отражает ситуацию, требующую изменения, как с точки зрения персонажей, так и с точки зрения бизнеса, который создает для этих персонажей продукт. Часто между интересами бизнеса и персонажа существует причинно-следственная связь. К примеру: Рейтинг удовлетворенности клиентов компании X низок, а доля на рынке уменьшилась на 10% за последний год, потому что у пользователей нет адекватных инструментов, позволяющих посредством решения задач X, Y и Z достичь цели G. Увязывание бизнес-вопросов с вопросами юзабилити крайне полезно, когда необходимо убедить заинтересованных лиц в необходимости затрат на проектирование, и позволяет рассматривать этот процесс как с точки зрения пользовательских целей, так и с точки зрения бизнес-целей. Определение образа продукта - действие, обратное постановке задачи: постановка задачи служит обоснованием и высокоуровневой целью проектирования, а определение образа продукта ставит на первое место потребности пользователей, уже от них переводя вас к тому, как благодаря удовлетворению этих потребностей достигаются бизнес-цели. В новой версии продукт X поможет пользователям достичь G, поскольку даст им возможность выполнять X, Y, и Z с большей [точностью, эффективностью и т. п.], при этом избавляя от существующих сейчас про-ОлемА, В и С. Это резко повысит удовлетворенность клиентов компании А и приведет к увеличению присутствия на рынке. Как постановка задачи, так и определение образа продукта опираются на данные исследований и модели пользователей. Цели и потребности Выработка требований с использованием персонажей и сценариев 155 пользователей должны вытекать из описаний ключевых и второстепенных персонажей, а цели бизнеса нужно извлечь из интервью с заинтересованными лицами. Постановка задачи и определение образа продукта полезны как при перепроектировании существующего продукта, так и при создании продукта, основанного на новой технологии или нацеленного на неизученную рыночную нишу. Сводка целей пользователей и испытываемых ими сложностей в виде постановки задачи и определения образа продукта помогает достичь взаимопонимания внутри команды и привлечь ее внимание к приоритетам предстоящего проектирования. Шаг 2: мозговой штурм Цель мозгового штурма на ранних стадиях процесса выработки требований в некоторой степени карикатурна. К этому моменту команда проектировщиков, вероятно, провела дни или даже недели, исследуя и моделируя пользователей и предметную область. В такой ситуации трудно избежать возникновения определенных предубеждений относительно того, как должно выглядеть решение. Однако в идеальном случае проектировщик создает контекстные сценарии, не имея заранее составленного мнения и полностью сосредотачиваясь на персонажах и их желаниях в отношении взаимодействия с продуктом. Смысл мозгового штурма в этот момент состоит в том, чтобы извлечь такие идеи из головы и, записав, тем самым «отпустить» их, по крайней мере на какое-то время. Тем самым основная цель штурма - по возможности избавить проектировщиков от предубеждений и дать им возможность открыто и гибко работать над созданием сценариев, задействуя свое воображение и применяя свои аналитические способности для извлечения требований из этих сценариев. Побочная выгода проведения мозгового штурма на этом этапе состоит в том, что мозг проектировщика переключается в «режим поиска решений». На стадиях исследования и моделирования приходится выполнять в основном аналитическую работу, а для поиска неожиданных решений проектирования требуется совсем другой настрой. Мозговой штурм должен происходить без ограничений, без критики -выкладывайте все те сумасшедшие идеи, которые вы уже обдумывали ранее, а также те, которые не обдумывали, и будьте готовы записать их и убрать на хранение до гораздо более поздней стадии процесса. Далеко не все их них могут оказаться в конечном итоге полезными, однако в них может быть зерно чего-то прекрасного, что отлично впишется в общую структуру продукта, которую вы построите позднее. Карен Хольцблат и Хью Вейер описывают удобную для мозгового штурма методику, которая может быть полезна для «расшевеливания» мозгового штурма, особенно если в команду входят не только проектировщики (Beyer and Holtzblatt, 1998). 156 Глава 6. Основы проектирования: сценарии и требования Не тратьте слишком много времени на этот шаг процесса выработки требований - нескольких часов должно быть более чем достаточно для того, чтобы вы и другие участники команды излили все свои безумные идеи. Если вы заметили, что идеи начали повторяться или иссякли, значит, пора прервать сеанс. Шаг 3: выявление ожиданий персонажей Как уже обсуждалось в главе 2, ментальная модель - это внутреннее представление человека о реальности, то, как он думает о чем-либо или как объясняет себе это. Ментальные модели глубоко встроены в сознание и часто являются итогом продолжительного жизненного опыта. Ожидания людей относительно продукта и того, как он работает, в большой степени зависят от ментальных моделей. Возвращаясь к нашему разговору в главе 2, еще раз подчеркнем важность того, чтобы модель представления интерфейса - то, как ведет себя и как выглядит продукт, - максимально точно соответствовала ментальным моделям пользователей, а не отражала модель реализации -то есть внутреннее устройство продукта. Чтобы этого добиться, необходимо записать ожидания пользователей в формальном виде. Это важный источник требований. Для каждого ключевого или второстепенного персонажа необходимо выявить:
Может оказаться, что описания персонажа уже содержат достаточно информации для непосредственного ответа на эти вопросы; однако данные исследований остаются при этом ценным источником - используйте их, чтобы проанализировать, как пользователи определяют и описывают объекты и действия, входящие в состав шаблонов использования, какой язык и грамматику они при этом используют. Вот некоторые вещи, на которые следует обращать внимание:
Выработка требований с использованием персонажей и сценариев 157 Шаг 4: разработка контекстных сценариев Любой сценарий - это рассказ о людях и их деятельности, однако из трех типов используемых нами сценариев именно контекстные сценарии более всего похожи на рассказы. Они сконцентрированы вокруг деятельности персонажа, его ментальных моделей и мотивов. Контекстные сценарии описывают широкий контекст, в котором проявляются шаблоны использования, и включают информацию о среде использования и об организационных вопросах (в случае с производственными системами (Kuutti, 1995). Как мы уже говорили, именно здесь начинается проектирование. Создавая контекстные сценарии, концентрируйтесь на том, как проектируемый продукт может наилучшим образом помогать персонажам в достижении их целей. Контекстные сценарии устанавливают основные точки соприкосновения каждого ключевого и второстепенного персонажа с проектируемой системой (возможно, и с другими персонажами посредством системы) в течение дня или иного осмысленного промежутка времени. Контекстные сценарии должны быть достаточно общими и не слишком детализированными. Не следует описывать в контекстных сценариях подробности взаимодействия или особенности продукта - сконцентрируйтесь на высокоуровневых действиях с позиции пользователя. Важно сначала нарисовать общую картину, позволяющую систематически подойти к выявлению требований пользователей. Лишь тогда мы сможем проектировать качественное взаимодействие и удобные интерфейсы. Контекстные сценарии отвечают на вопросы, подобные этим:
Контекстные сценарии не должны представлять поведение системы в его текущем виде. Они представляют дивный новый мир целеориен-тированных продуктов, поэтому, особенно на первых стадиях, сосредотачивайтесь на целях. Не стоит пока беспокоиться о том, как в точности будут решаться задачи, - изначально необходимо смотреть на продукт отчасти как на некий волшебный черный ящик. 158 Глава 6. Основы проектирования: сценарии и требования В большинстве случаев требуется написать более одного контекстного сценария. Это крайне необходимо, когда ключевых персонажей несколько, однако и у одного ключевого персонажа могут оказаться два или более различных контекстов использования продукта. Необходимо также сказать, что контекстные сценарии являются полностью текстовыми. Мы пока говорим не о будущей форме системы, а только о поведении пользователя и системы. Для такого обсуждения наилучшим образом подходит текстовое повествование. Пример контекстного сценария Ниже приводится пример первоначального варианта контекстного сценария для ключевого персонажа. Продукт объединяет в себе смартфон и сопутствующую услугу оператора. Персонажа зовут Вивьен Стронг, она - агент по продаже недвижимости из Инднанаполиса. Цели Вивьен - достичь равновесия между рабочей и семейной жизнью, успешно завершать сделки, добиться того, чтобы каждый ее клиент чувствовал себя единственным. Контекстный сценарий для Вивьен:
Выработка требований с использованием персонажей и сценариев 159 и смартфон автоматически связывает ее с Фрэнком, поскольку знает о скорой встрече с ним. Вивьен сообщает Фрэнку, что будет на месте через двадцать минут.
Обратите внимание, что описание в сценарии ведется на достаточно высоком уровне, не затрагивая подробности интерфейсов и технологий. Безусловно, созданные сценарии не должны выходить за пределы технологических возможностей, однако на данном этапе детали реального продукта еще не важны. Мы стремимся оставить пространство для новаторских решений - отступить назад никогда не поздно. В конечном итоге мы хотим получить оптимальный, но по-прежнему реалистичный сценарий взаимодействия. Обратите внимание, что сценарий тесно увязывает деятельность с целями Вивьен и стремится исключить как можно большее число задач. Игра в волшебство Полезный на ранних стадиях разработки сценариев прием - представить, что интерфейс волшебный. Если у вашего персонажа есть цели, а продукт волшебным образом этим целям соответствует, насколько простым может быть взаимодействие? Такие размышления помогают проектировщикам выйти за рамки привычного. Волшебные решения, конечно, невозможны, однако поиск творческих путей такой технической реализации взаимодействия, которое было бы максимально близко к волшебному (с точки зрения персонажей), составляет сущность высококлассного проектирования взаимодействия. Продукты, которые позволяют достигать целей с минимальным количеством преград 160 Глава 6. Основы проектирования: сценарии и требования и навязчивых излишних действий, представляются пользователям почти чудом. Некоторые варианты взаимодействия в приведенном выше сценарии могут показаться несколько волшебными, однако все они находятся в сфере досягаемости для современных технологий. Волшебство состоит не столько в технологии, сколько в ориентированном на цели поведении. На ранних стадиях проектирования считайте интерфейс принцип волшебным. проектирования Шаг 5: выявление требований Получив первый удовлетворяющий вас набросок контекстного сценария, вы можете приступить к его анализу с целью извлечения потребностей персонажей - требований. Эти требования могут включать в себя объекты, действия и контексты (Shneiderman, 1998). Помните: мы предпочитаем не отождествлять требования с возможностями или задачами. Таким образом, из приведенного выше сценария можно определить, например, такую потребность: Звонок (действие) человеку (объект) непосредственно из записи о встрече (контекст). Этот формат достаточно хорошо работает; если извлекать потребности в таком формате вам покажется неудобным, попробуйте разделить их на группы информационных, функциональных и контекстных требований, описанные в следующих подразделах. Информационные требования Потребности персонажа в данных - это объекты и информация, которые должна представлять система. Если говорить в терминах приведенной выше семантики, бывает полезно считать информационные требования объектами и прилагательными, связанными с этими объектами. Например, учетные записи, люди, документы, сообщения, песни, изображения, а также их свойства, такие как состояние, дата, размер, автор, тема. Функциональные требования Функциональные требования- это операции или действия, которые должны выполняться с объектами системы и которые, как правило, реализуются в виде интерфейсных элементов управления. Функциональные требования можно считать действиями продукта. Кроме того, функциональные требования определяют места или контейнеры, с помощью которых объекты или данные отображаются пользователю. (Очевидно, что это не самостоятельные действия, да и не действия вовсе, однако присутствие контейнеров обычно подразумевается действиями.) Выработка требований с использованием персонажей и сценариев 161 Прочие требования Поиграв с волшебством, важно составить четкое представление о реалистичных требованиях бизнеса и технологий, для которых выполняется проектирование (хотя мы надеемся, что у проектировщиков есть определенное влияние на выбор технологии в том случае, если этот выбор непосредственно связан с целями пользователей).
Теперь у вас есть приблизительное и творческое описание того, как продукт поможет пользователям достигать своих целей. Это описание включает в себя контекстные сценарии, а также сокращенный перечень потребностей и требований, извлеченных из данных исследований, пользовательских моделей и сценариев. Теперь вы готовы глубже погрузиться в детали поведения продукта и начать думать о том, как будет представлен продукт и его функции. Вы готовы к формированию инфраструктуры взаимодействия. 7 От требований к пользовательскому интерфейсу: общая инфраструктура и детализация В прошлой главе мы рассказали о первой части процесса проектирования - о разработке сценариев, помогающих придумывать идеальное для пользователей взаимодействие, а также о том, как формулировать требования на основе этих сценариев и других источников. Теперь мы готовы приступить к проектированию. Общая инфраструктура пользовательского интерфейса Однако заниматься деталями пока еще рано - мы остановимся на более высоком уровне и озаботимся общей структурой пользовательского интерфейса и соответствующего поведения продукта. Мы называем эту фазу целеориентированного процесса построением общей инфраструктуры пользовательского интерфейса. Если бы мы проектировали дом, в этот момент нас интересовало бы, какие комнаты нужны в доме, как их следует расположить друг относительно друга и каковы примерно должны быть площади этих комнат. Нас не занимали бы точные размеры комнат, а также детали, вроде дверных ручек, водопроводных кранов и кухонных столешниц. Общая инфраструктура пользовательского интерфейса определяет структуру опыта пользователя в целом - от расположения функциональных элементов на экране до интерактивного взаимодействия и его организующих принципов, а также визуальный язык, используемый для представления данных, концепций, функциональности и отличительных признаков бренда. Наш опыт показывает, что форму и пове- Общая инфраструктура пользовательского интерфейса 163 дение нужно проектировать как тандем: инфраструктура интерфейса включает в себя инфраструктуру взаимодействия, визуальную инфраструктуру, а иногда и физическую инфраструктуру (инфраструктуру взаимодействия с физическим устройством). На этой стадии проекта сценарии и требования служат проектировщикам сырьем для создания грубых набросков экранов и вариантов поведения, составляющих инфраструктуру взаимодействия. Одновременно с этим графические дизайнеры занимаются исследованием визуального языка с целью создания визуальной инфраструктуры, которая, как правило, принимает форму детального макета типовых экранов, а промышленные дизайнеры анализируют язык формы, чтобы выработать грубую физическую модель и физическую инфраструктуру. О каждом из трех процессов мы поговорим в этой главе. Мы обнаружили, что если при проектировании сложного поведения и взаимодействия сразу сфокусироваться на пиксельной прорисовке, дизайне элементов интерфейса и конкретных аспектах взаимодействия, это может помешать эффективному проектированию исчерпывающей инфраструктуры, охватывающей все варианты поведения продукта. Используя подход «сверху вниз», мы можем начать с общей картины и создавать решения, не вдаваясь в детали, чтобы сохранить фокус разработки на самом главном - обеспечении достижения целей и удовлетворении требований персонажей. Пересмотр сделанного - нормальное явление в мире проектирования. Как правило, процесс материализации и презентации решений проектирования помогает проектировщикам и заинтересованным лицам совершенствовать видение продукта и достигать более глубокого понимания того, как продукт мог бы наилучшим образом служить потребностям человека. Трюк, стало быть, в том, чтобы материализованное решение содержало тот минимум деталей, который позволит спровоцировать живой мыслительный процесс. Нет смысла тратить слишком много времени или сил на создание макетов, которые все равно будут отброшены или модифицированы. Мы обнаружили, что раскадровки с эскизами в сочетании со сценариями-рассказами - весьма эффективный способ исследовать и обсуждать решения проектирования, не неся излишних расходов и не порождая ненужной инерции. Исследования в области восприятия архитектурных чертежей и визуализаций говорят в пользу такого подхода. Результаты изучения реакции людей на различные изображения, созданные в CAD-системах, приводят к заключению, что карандашные наброски стимулируют обсуждение предложенного дизайн-проекта, а также дают ясное понимание того, что представленная работа еще не закончена (Schumann et al., 1996). Кэролин Снайдер (Carolyn Snyder) подробно описывает данный эффект в своей работе «Paper Prototyping» (Snyder, 2003), где речь идет о ценности слабо детализированных представлений с точки зрения получения реакции от пользователей. Мы считаем, что юзабилити-тести- 164 Глава 7. От требований к пользовательскому интерфейсу рованне и отзывы пользователей наиболее полезны на стадии детального проектирования, но определенно существуют случаи, когда эта деятельность приносит пользу уже на стадии создания инфраструктуры. (Более подробно юзабилити-тестирование обсуждается в конце главы.) Создание инфраструктуры взаимодействия Общая инфраструктура взаимодействия задает не только высокоуровневую компоновку экранов, но также рабочий процесс, поведение и организацию продукта. Следующие шесть шагов составляют процесс создания общей инфраструктуры взаимодействия:
Мы разбили процесс на последовательные шаги, однако работа здесь выполняется не линейно, а требует последовательных итераций. В частности, порядок шагов с 3 по 5-й зависит от стиля мышления проектировщика (более подробно это обсуждается позже). Итак, вот описание перечисленных шагов. Шаг 1: определение форм-фактора, типа приложения и способов управления Первый шаг в создании общей инфраструктуры - определение форм-фактора проектируемого продукта. Будет ли это веб-приложение, используемое на компьютерах с высоким разрешением дисплея? Или это телефон, который должен быть маленьким, легким, иметь низкое разрешение экрана, изображение на котором должно быть одинаково четким как в темноте, так и в солнечный день? Или это киоск, который должен быть достаточно прочным, чтобы выжить в общественном месте, обслужив тысячи невнимательных неподготовленных пользователей? Каковы ограничения, накладываемые каждой из этих платформ на результат проектирования? Любой из этих факторов очевидным образом влияет на пользовательский интерфейс продукта, и ответы на заданные вопросы становятся фундаментом для всех последующих усилий по проектированию. Если ответ неочевиден, обратитесь к своим персонажам и сценариям, чтобы лучше понять идеальный контекст и среду использования продукта. В том случае, когда продукт требует проектирования еще и аппаратной части, необходимо заняться промышленным дизайном. Позже в этой главе мы обсудим, как координировать проектирование взаимодействия с промышленным дизайном. Общая инфраструктура пользовательского интерфейса 165 Определяя форму продукта, следует также выявить базовый тип интерфейса продукта и способы управления системой. Тип интерфейса продукта определяется тем, как много внимания пользователь будет уделять взаимодействию с продуктом и как продукт своим поведением будет отвечать вниманию со стороны пользователя. Решение по этому вопросу следует основывать на контекстах и окружении использования, упомянутых в контекстных сценариях (см. главу 6). Понятие типа интерфейса мы более подробно рассмотрим в главе 9. Способ управления определяет, каким образом пользователь взаимодействует с продуктом. Этот способ в некоторой степени диктуется форм-фактором и типом приложения, а также предпочтениями, взглядами и навыками персонажа. Вариантов здесь множество: клавиатура, мышь, панель с клавишами, клавиатура типа thumb-board (клавиатура для больших пальцев обеих рук), сенсорный дисплей, голосовое управление, джойстик, пульт дистанционного управления, специализированные кнопки и прочее, и прочее. Какое сочетание способов подходит вашим ключевым и второстепенным персонажам? Если для продукта уместно сочетание нескольких способов управления (так обычно бывает с веб-сайтами или компьютерными приложениями, рассчитанными на мышь и клавиатуру), выберите для продукта один ключевой способ управления. Шаг 2: определение функциональных и информационных элементов Функциональные и информационные элементы - это зримые представления функций и данных, доступные пользователю посредством интерфейса. Это конкретные проявления функциональных и информационных потребностей, выявленных на стадии выработки требований. В то время как требования намеренно описывались в общих терминах с позиции персонажей, функциональные и информационные элементы описываются на языке представления этих объектов и действий в интерфейсе. Важно отметить, что каждый такой элемент должен создаваться на основе конкретного требования, выявленного ранее. Тем самым мы добиваемся, чтобы каждый аспект проектируемого продукта имел определенное назначение и соответствовал конкретному аспекту существующего сценария использования или бизнес-цели. Информационные элементы - это, как правило, фундаментальные объекты интерактивных продуктов. Такие объекты, будь это фотографии, сообщения электронной почты, учетные карточки клиентов или заказов, являются основными единицами, на которые могут ссылаться, реагировать, с которыми могут работать пользователи продукта. В идеале эти объекты должны соответствовать ментальным моделям персонажей. На данном этапе крайне важно создать исчерпывающий каталог информационных объектов, поскольку функциональность продукта часто определяется именно в терминах этих объектов. В поле зрения 166 . Глава 7. От требований к пользовательскому интерфейсу проектировщика попадают также значимые атрибуты объектов (к примеру, отправитель сообщения электронной почты или дата создания фотографии), но они на данном этапе представляют меньший интерес. Главное здесь - составить представление о том, какое количество атрибутов интересует персонажей. Полезно рассмотреть взаимоотношения между информационными элементами. Иногда одни информационные объекты включают в себя другие, в других случаях их объединяют ассоциативные связи. Примерами подобных связей могут служить фотография в альбоме, песня в списке для проигрывания, отдельный счет внутри клиентской записи. Функциональные элементы - это операции, которые могут выполняться над информационными объектами и представляющими эти объекты элементами интерфейса. В большинстве случаев функциональные элементы представляют собой инструменты, работающие с информационными элементами, а также контейнеры, содержащие информационные элементы. Трансляция функциональных требований в детальные функциональные элементы - та точка, где проектирование начинает обретать конкретность. Контекстный сценарий был способом дать целостное общее представление об опыте, который мы создаем для пользователей; но именно сейчас мы начинаем превращать этот опыт в реальность. Часто бывает, что одно требование превращается в целый набор элементов интерфейса. Скажем, Вивьен, нашему персонажу проекта интерфейса для смартфона из главы 6, необходимо звонить людям, записанным в телефонной книге. Вот некоторые функциональные элементы, обеспечивающие ее такой возможностью:
Повторим: очень важно вернуться к контекстным сценариям, целям персонажей и их ментальным моделям, чтобы убедиться, что ваши решения подходят к рассматриваемым ситуациям. Именно на данном этапе процесса принципы и шаблоны проектирования начинают приносить пользу, способствуя отысканию эффективных решений и избавляя от необходимости изобретать колесо. Здесь проектировщик должен проявить свои творческие способности и применить логику проектирования. Каждое выявленное требование имеет обычно несколько вариантов решения. Какое из возможных решений с наибольшей вероятностью: Общая инфраструктура пользовательского интерфейса 167
Продукт как человеческое существо Как вы уже знаете из главы 6, существует мощный способ представить идеальный опыт пользователя (который необходимо отразить в контекстных сценариях концептуального уровня) - притвориться, что инструмент, продукт или система - волшебные. Точно так же, притворившись, что система - это человек, мы получим мощный инструмент для структурирования деталей уровня взаимодействия. Подробно мы обсудим этот простой принцип в главе 12, а в двух словах - взаимодействие с цифровой системой должно по тону и приносимой пользе напоминать общение с вежливым и внимательным человеком (Cooper, 1999). Определяя варианты взаимодействия и поведения наряду с функциональными элементами и группами, спросите себя: что сделал бы человек, который рад помочь? На что похоже тщательно продуманное и взвешенное взаимодействие? Гуманно ли продукт поступает с ключевым персонажем? Какими способами программа может информировать пользователя, не мешая ему при этом работать? Как она может свести к минимуму усилия персонажа в достижении его целей? К примеру, мобильный телефон, ведущий себя, как вдумчивый человек, знает, что после завершения разговора с абонентом, отсутствующим в телефонной книжке, возможно, потребуется записать туда его телефонный номер, и потому предоставляет простой и очевидный способ это сделать. Невнимательный к человеку телефон вынуждает пользователя записывать номер на тыльной стороне ладони, после чего лезть в телефонную книгу и создавать новую запись. Применяйте принципы и шаблоны Для перевода требований в форму функциональных элементов (а также для группировки этих элементов и детального исследования поведения с помощью сценариев и раскадровок) предельно важным является использование общих принципов взаимодействия и конкретных шаблонов взаимодействия. За этими инструментами стоят годы опыта проектирования взаимодействия. Отказываться от такого знания -значит терять время на проблемы, решения которых уже найдены. Кроме того, отклонение от стандартных шаблонов проектирования может привести к созданию продукта, который заставит пользователей осваивать с нуля все идиомы взаимодействия вместо того, чтобы дать им узнаваемое поведение, знакомое им по другим продуктам и позволяющее использовать прежний опыт (понятие шаблона проектирования мы обсудим в главе 8). Разумеется, иногда уместно изобретать новые 168 |
| Поиск |