Перевод С. Черникова

 

Дженифер Тидвелл, Чарли Брюэр , Эйнн Валенсия

Разработка интерфейсов. Паттерны проектирования. 3-е изд.. — СПб.: Питер, 2022.

 

ISBN 978-5-4461-1646-1

© ООО Издательство "Питер", 2022

 

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

 

Предисловие к третьему изданию

«Чем сильнее меняются вещи, тем больше они остаются прежними».

Приближается 15-летие со дня публикации первого издания книги «Разработка интерфейсов». А со дня выхода второго издания прошло уже 10 лет. Стоит взглянуть на то, что изменилось, а что осталось прежним, и как это отразилось на подходе к проектированию интерфейсов и пользователях.

Самым значительным изменением стало бурное развитие технологий. И эта тенденция сохраняется. Мы используем программы практически везде: на работе, на отдыхе, во время учебы, в кругу общения, совершая покупки и т.д. Разнообразие устройств и вещей, которые можно подключить к Сети, ошеломляет: автомобили, умные колонки, телевизоры, игрушки, часы, дома. Размеры и типы экранов устройств также чрезвычайно разнообразны, и все большую популярность приобретают продукты с технологией управления жестами или голосом. Доступ в интернет есть более чем у половины населения планеты. Наконец, программы становятся более производительными и аналитическими. Они способны предлагать умные решения и работать самостоятельно. Одним словом, они все больше походят на нас.

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

Как появилась эта книга

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

Момент для этого тоже был выбран правильно. Скорость изменений в технологиях и цифровой сфере жизни резко возросла, так же как и в дизайне. Книгу необходимо было обновить. У нас было две цели: выдвинуть на первый план то, что делает эту книгу особенной, а затем заострить внимание на важных деталях.

Мы сошлись на необходимости в новом руководстве, которое помогло бы разобраться в современном состоянии разработки программного обеспечения. Мы хотели написать подробный путеводитель, который всегда был бы под рукой у дизайнеров всех мастей, от новичков до опытных разработчиков. Несмотря на то что в одной книге уже невозможно охватить все новые цифровые каналы и направления, мы все же хотели составить руководство, которое раскрывало бы основы проектирования взаимодействий так, как мы понимаем его сегодня. По этой причине мы решили сосредоточиться на проектировании экранного взаимодействия для веб- и мобильных устройств. О том, что не вошло в новое издание, вы узнаете ниже. Наконец, мы хотели предложить нестандартную точку зрения. Паттерны проектирования в первую очередь делают руководство «Разработка интерфейсов» уникальным и актуальным. Мы добавили несколько собственных паттернов, в частности учли те факторы человеческого познания и поведения, которые влияют на результаты разработки. Мы надеемся, что наша книга откроет паттерны проектирования для новой аудитории.

Паттерны проектирования все еще востребованы

Мы спросили себя: почему дизайн и наша книга все еще востребованы? Ответ заключается в паттернах проектирования. Они основаны на способах восприятия и использования программных инструментов. Чувства людей и психология не меняются, и эти паттерны работают с ними, а не против них. Кроме того, они основаны на задачах, крупных и второстепенных, которые люди стремятся выполнять с помощью программ: ввод данных, создание цифровых объектов и управление ими, управление финансами и обработка платежей, а также отправка и получение сообщений и файлов. Паттерны образуют фундамент любого пользовательского интерфейса. Более того, осмысление в терминах паттернов и поиск новых паттернов во многом соответствует тому, как сегодня осуществляется проектирование программ и взаимодействия.

ПО — это система

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

Сервисы и межплатформенные средства, которые обеспечивают функционирование программ, чаще всего представляют собой интеграцию отдельных управляемых инструментов. Зачем разрабатывать собственную систему регистрации, если можно зарегистрироваться в Google, Facebook и на других платформах? Зачем разрабатывать собственное ПО для анализа и создания отчетов, когда можно интегрировать подходящий набор надежных, настраиваемых платформ бизнес-аналитики? Зачем создавать собственную мобильную платформу, если у нас уже есть Amazon Web Services? То же касается HR-процессов и IT-инфраструктуры. Мы все чаще пользуемся готовым, а не создаем новое.

Фокус: проектирование экранного взаимодействия для веб- и мобильных устройств

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

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

Что не вошло в третье издание

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

Голосовое управление. Мы говорим с телефонами, автомобилями и умными колонками, чтобы они делали то, что нам нужно. Мы ведем диалог с машинами. Чтобы узнать больше о разработке голосовых интерфейсов, рекомендуем прочесть книгу Кэти Перл «Designing Voice User Interfaces: Principles of Conversational Experiences» (издательство O’Reilly, 2017).

Соцсети. Социальные сети уже давно не просто способ поддерживать связь с друзьями и членами семьи. Это обязательный уровень коммуникации, обсуждений и взаимодействия почти для всех программ. Соцсети произвели революцию в сфере делового общения и производительности. Подробнее об этом можно узнать в книге «Designing Social Interfaces: Principles, Patterns, and Practices for Improving the User Experience» Кристиана Крамлиша и Эрин Мэлоун (издательство O’Reilly, 2015).

Стриминговые сервисы. То, что мы привыкли называть телевидением, теперь представляет собой стриминговые площадки для просмотра видео на любом устройстве по нашему выбору. Интерфейс в этой сфере давно используется не только для поиска и просмотра. Телевизор теперь тоже своего рода приложение, имеющее доступ ко всем функциям и возможностям наших устройств. Чтобы узнать больше об этой сфере, прочтите книгу «Designing Multi-Device Experiences: An Ecosystem Approach to User Experiences across Devices» Михала Левина (издательство O’Reilly, 2014).

Виртуальная/дополненная/смешанная реальность. Интерфейсы и программы становятся дополнением физического мира или же самостоятельной новой реальностью. Очки виртуальной реальности и другие устройства позволяют нам дополнять цифровой мир тем, что мы видим перед собой. Чтобы узнать больше, прочтите книгу Эрин Пангилинан и др. «Creating Augmented and Virtual Realities: Theory and Practice for Next-Generation Spatial Computing» (издательство О’Reilly, 2019).

Чат-боты и голосовые помощники. Голосовые помощники, очень похожие на людей, теперь ежедневно разговаривают с нами в мессенджерах или в чатах. Эти чат-боты понимают разговор и реагируют на него самым естественным образом. Благодаря программам, которые распознают закономерности в данных и речи, а затем обучаются и совершенствуются, чат-боты способны обрабатывать практически любые простые информационные запросы и выполнять базовые задачи. Чтобы достичь подобного результата, дизайнеры организуют совокупность исходных данных, а также фреймворки и сценарии для обучения и практического применения. Если вы захотите узнать больше о разработке ботов и диалогов, вам пригодится книга «Designing Bots» Амира Шевата (издательство O’Reilly, 2017).

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

Кому будет полезна эта книга

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

Структура книги

Эта книга состоит из 12 глав — новых или значительно обновленных. Сами главы в основном содержат две части.

Введение и обсуждение модели дизайна

Первая половина каждой главы посвящена введению в тему и ее разбору. Она включает обсуждение теории и практики проектирования интерфейса, который относится к теме главы. Здесь рассматриваются принципы проектирования, руководства и рекомендуемые практики. Первая часть задает контекст для второй половины главы.

Паттерны

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

Каждый паттерн структурирован следующим образом:

Что это

Определение паттерна.

Когда использовать

В этом разделе рассматриваются различные сценарии использования паттерна, объясняется контекст использования, а также особые случаи и исключения.

Зачем

В этом разделе анализируются назначение и преимущества паттерна и указывается, кому этот паттерн будет полезен и каким образом.

Как

Этот раздел касается дизайна самого паттерна и средств его реализации. Здесь в общих чертах обрисовываются способы сделать паттерн отвечающим всем требованиям пользователя.

Примеры

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

Заключение

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

Программы и приложения стали неотъемлемой частью жизни потребителя. Люди проводят небывалое количество времени, работая с ними. Эти средства призваны делать жизнь проще.

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

— Дженифер Тидвелл, Чарли Брюэр и Эйнн Валенсия

Условные обозначения

В этой книге используются следующие условные обозначения:

Курсивный шрифт

Для названий паттернов, новых терминов, URL-адресов, адресов электронной почты, имен файлов и расширений файлов.

Моноширинныйшрифт

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

Благодарности

Мы благодарим наших технических рецензентов: Эрин Мэлоун, Кейт Раттер, Фрэнсис Клоуз, Кристи Эннис Клоут, Мэтью Рассела и Джорджа К. Абрахама.

Спасибо Кристиану Крамлишу за предоставленную возможность выпуска этой книги.

И большое спасибо Анжеле Руфино и Дженнифер Поллок из O’Reilly.

Эйнн Валенсия: Я хотела бы поблагодарить отличных преподавателей курса IxD@CCA и студентов, которых я обучала в SFSU, CCA и GA на протяжении многих лет: вы — мой постоянный источник вдохновения и вселяете в меня большие надежды на будущее. И больше всего я благодарю своего мужа, Дона Брукса, за то, что он был моим партнером в путешествиях и за то, что всегда был согласен на все.

Чарли Брюэр: Я хотел бы поблагодарить сотрудников издательства O’Reilly за предоставленную возможность попробовать что-то новое в профессиональном плане, продакт-менеджеров SpaceIQ за гибкость и особенно свою семью и друзей, которые поддерживали меня все это время.

От издательства

Для всех паттернов в книге приведены как оригинальные названия на английском языке, так и эквиваленты на русском.

Чтобы посмотреть некоторые рисунки в цветном варианте, воспользуйтесь QR-кодом, расположенным рядом с рисунком.

Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

Глава 1. Проектирование для людей

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

Почему? В конце концов, возможно, именно поэтому вы и взяли эту книгу в руки.

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

• общие цели использования сайта или приложения;

• сортировка задач для выполнения этих целей;

• что пользователи думают о конкретном предмете или предметной области;

• язык, который они используют, чтобы описать их;

• в какой степени они обладают навыками, необходимыми для выполнения работы;

• их отношение к предмету.

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

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

Эта структура выглядит так:

• Контекст — кто составляет вашу аудиторию?

• Цели — чего они хотят?

• Исследование — способы понимания контекста и целей.

• Паттерны — знание и поведение, связанное с дизайном интерфейса.

Контекст

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

Узнайте свою аудиторию

UI-дизайнеры1 часто говорят: «Дизайнер — не пользователь».

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

Взаимодействие как диалог

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

Вот ключевые моменты:

• в разговоре два участника: человек и программа;

• происходит постоянный обмен информацией в обоих направлениях;

• обмен — это серия запросов, команд, прием, обработка и ответ;

• человек в разговоре нуждается в непрерывной обратной связи, которая подтверждает, что все работает нормально, входные данные обрабатываются, участники успешно движутся к цели;

• чтобы этот цикл обратной связи работал, программное обеспечение, которое не может быть таким же спонтанным и отзывчивым, как человек (по крайней мере, пока), должно идеально имитировать собеседника. Оно должно быть понятным партнеру по диалогу, демонстрировать активность (когда выступает в роли «слушателя»), и его ответы должны быть очевидными. Еще один важный аспект — умение подсказать последующие шаги или дать рекомендации, точно так же, как отзывчивый человек проявляет внимание к другому.

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

Соотнесите контент и функционал с потребностями аудитории

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

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

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

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

Поэтому вам нужно определить степень свободы действия для пользователей. На одном полюсе может находиться мастер установки программного обеспечения: пользователь взаимодействует с ним, не имея возможности использовать что-либо, кроме кнопок «Далее», «Назад» или «Закрыть». Он предельно ограничивает свободу действий, но довольно эффективен, быстр и удовлетворяет требованиям пользователя. На другом может быть приложение, такое как Excel, интерфейс типа «открытая планировка», который содержит огромный набор функций в одном месте. В любой момент времени пользователю доступны сотни вариантов дальнейших действий, и это для него несомненный плюс, поскольку самостоятельные, опытные пользователи могут сделать очень многое с этим интерфейсом. И он тоже удовлетворяет их требованиям, но по совершенно другим причинам.

Уровень подготовки

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

Кто-то может использовать его ежедневно на работе и очевидно со временем станет опытным пользователем. Но даже незначительные несоответствия ожиданиям начнут все больше и больше раздражать. Возможно, кто-то будет использовать его время от времени и изучит только в той степени, которой достаточно, чтобы добиться необходимого результата. В таком случае терпимость к недостаткам будет выше. А кто-то воспользуется им только один раз. Признайтесь честно: ждете ли вы, что большинство пользователей станут опытными или экспертами или подразумеваете, что они так и останутся вечными новичками?

Вот примеры программ, предназначенных для пользователей среднего и профессионального уровня:

• Photoshop;

• Excel;

• среды разработки кода;

• инструменты системного администрирования для веб-серверов.

Напротив, вот некоторые продукты, предназначенные для использования от случая к случаю:

• информационные панели в туристических центрах или музеях;

• элементы управления Windows или macOS для настройки фона рабочего стола;

• страницы интернет-магазинов;

• мастеры установки;

• автоматические кассовые аппараты.

Различия между этими двумя группами огромны. Эти интерфейсы основаны на предположении о степени знакомства пользователя с инструментом, выражающейся в том, как он использует экранное пространство, сложные ярлыки и виджеты, места, где предлагается (или не предлагается) помощь.

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

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

Теперь, когда мы познакомились с двумя крайностями, рассмотрим золотую середину:

• Microsoft PowerPoint;

• почтовые приложения;

• Facebook;

• инструменты для написания блогов.

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

Возможно, когда-нибудь вам придется выбирать между двумя полюсами этой шкалы. Естественно, вы хотите, чтобы люди могли использовать ваш продукт с ходу, но вы можете захотеть включить в него инструменты и для более продвинутых пользователей. Найдите подходящий баланс. Организационные паттерны, описанные в главе 2, такие как справочные системы, могут помочь вам удовлетворять потребности обеих групп.

Интерфейс — лишь средство для достижения целей пользователя

У каждого, кто использует инструмент — программу и т.д., — есть свои на то причины. Это цели пользователя. Например:

• поиск фактов или объектов;

• изучение чего-либо;

• заключение сделки;

• контроль или мониторинг;

• создание чего-либо;

• общение с другими людьми;

• развлечение.

Известные идиомы, поведение пользователей и паттерны проектирования могут поддерживать каждую из этих абстрактных целей. UX-разработчики2 выяснили, например, как помочь людям среди огромного количества информации в интернете искать нужную. Они научились представлять задачи так, чтобы их было легко выполнять. Они изучают способы поддержки создания документов, иллюстраций и кода.

Спросите пользователей

Первый шаг в разработке интерфейса — понимание того, что на самом деле пытаются сделать пользователи. Заполнение формы, например, почти никогда не является самоцелью — люди делают это только потому, что они пытаются купить что-то в интернете, обновить водительские права или установить программу. Они заключают сделку.

Задавая правильные вопросы, вы можете связать цели пользователя с процессом разработки. Пользователи и клиенты обычно говорят с вами на языке желаемых функций и решений, а не потребностей и проблем. Когда пользователь или клиент говорит вам, что ему нужна определенная функция, спросите, почему именно она ему нужна, определите его ближайшую цель. А потом, получив ответ на этот вопрос, еще раз спросите почему. И еще. Продолжайте спрашивать, пока не выйдете далеко за рамки непосредственной задачи проектирования3.

Ценность дизайна: решите правильную проблему, а затем решите ее правильно

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

Так что не слишком увлекайтесь проектированием форм. Если можно избавить пользователя от заполнения формы, избавьте. Это приблизит пользователя к цели быстрее и с меньшими усилиями с его стороны (и, возможно, с вашей тоже).

Давайте используем подход «зачем», чтобы глубже рассмотреть некоторые типичные сценарии проектирования:

• Зачем менеджеру среднего звена почтовое приложение? Правильно, чтобы читать электронную почту. Но зачем они вообще читают и отправляют электронную почту? Чтобы общаться с другими людьми. Конечно, другие средства могут достичь тех же целей: телефон, разговор в коридоре, официальный документ. Но, по-видимому, электронная почта удовлетворяет какие-то потребности, для которых другие способы не подходят. Что это за потребности и почему они важны для этого менеджера? Удобство выбирать, когда отправлять или отвечать? Конфиденциальность? Возможность сохранить историю разговора? Социальная условность? А что еще?

• Отец заходит на сайт турагентства, выбирает город, в котором его семья будет отдыхать летом, и пытается найти цены на билеты на самолет на разные даты. Он получает информацию из того, что находит, но его цель — не просто просматривать и исследовать различные варианты. Спросите зачем. Его целью на самом деле является сделка: купить билеты на самолет. Опять же, он мог бы сделать это на многих других сайтах или поговорив по телефону с живым турагентом. Чем этот сайт лучше других вариантов? Это быстрее? Удобнее? Больше шансов найти выгодное предложение?

• Иногда анализа цели действительно недостаточно. Сайт, посвященный сноу­бордингу, может содержать в себе информацию (для обучения), интернет-магазин (для сделок) и набор видеоклипов (для развлечения). Предположим, что кто-то заходит на сайт для покупки, но отвлекается на информацию о трюках на сноуборде — он переключил внимание с заключения сделки на просмотр и обучение. Может быть, он снова начнет что-то покупать, а может быть и нет. И действительно ли раздел, посвященный стилю жизни и развлечениям, интересен как 12-летним, так и 35-летним? Перейдут ли 35-летние люди на другой сайт, чтобы купить новую доску, если им некомфортно на этом, или им все равно? Полезно расширить рамки целей, чтобы включить в них понимание специфического цикла покупки. У вашего клиента будут разные цели на разных этапах этого цикла. С другой стороны, возможно, вы захотите разработать способ установления долгосрочных взаимоотношений между брендом и клиентом. Это можно реализовать с помощью контента и функционала, которые помогают формировать идентичность, создавать сообщества и определяют стиль жизни.

Обманчиво легко представлять пользователей как единую безликую сущность — «пользователя», проходящего через набор простых вариантов использования инструмента с одной целью. Это не всегда будет отражать реальность. Чтобы разработать хороший дизайн, вам нужно учитывать множество «мягких» факторов: ожидания, внутренние реакции, предпочтения, социальный контекст, убеждения и ценности. Все они могут повлиять на дизайн приложения или сайта. Среди этих «мягких» факторов вы можете обнаружить критическую функцию или фактор дизайна, который делает ваше приложение более привлекательным в глазах пользователя.

Так что будьте любопытны. Сосредоточьтесь на выяснении того, кем являются ваши пользователи на самом деле и что они действительно думают и чувствуют.

Исследование: способы понимания контекста и целей

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

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

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

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

В частности, вам понадобится узнать:

• с какой целью они используют ПО или сайт;

• конкретные задачи, которые они решают, чтобы достичь этих целей;

• язык, который они используют для описания своих действий;

• их навыки использования программ, подобных той, что вы разрабатываете;

• их отношение к тому, что вы разрабатываете, и как варианты дизайна могут повлиять на это отношение.

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

Как бы трудно это ни было, постарайтесь описать свою потенциальную аудиторию с точки зрения того, как и для чего они могут использовать вашу программу. У вас могут получиться разные ответы для разных групп пользователей, это нормально. У вас может возникнуть искушение развести руками и сказать: «Я не знаю, кто мои пользователи» или «Каждый может быть пользователем». Но без точного и верного описания аудитории ваш проект не будет иметь опоры в реальности.

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

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

Прямое наблюдение

Интервью и работа с пользователями на местах погружают вас в мир пользователей. Вы можете спросить их о том, каковы их цели и какие задачи они обычно выполняют. Интервью обычно проводятся «на месте», где люди используют программу (например, на работе или дома), и могут быть структурированными — с заранее определенным набором вопросов — или неструктурированными, когда вы задаете вопросы на любую тему. Интервью дают вам гибкость, вы можете провести их много или всего несколько, подробных или кратких, официальных или неофициальных, по телефону или лично. Это прекрасная возможность узнать то, чего вы еще не знаете. Спросите «зачем?». Спросите еще раз.

Изучение примеров из практики

Анализ примеров из практики позволяет получить глубокое, детальное представление о типичных представителях пользователей или группы пользователей. Иногда эту технику можно использовать для изучения «нестандартных» пользователей, которые расширяют возможности программного обеспечения, особенно когда целью является новый дизайн существующего ПО. Ее также можно использовать в долговременных исследованиях, изучая, как используют продукт в течение месяцев или даже лет. Наконец, если вы разрабатываете специализированный инструмент под одного заказчика, вы захотите узнать как можно больше о реальном контексте его использования.

Опросы

Письменные опросы помогают получать информацию от пользователей. Благодаря им можно сформировать статистически значимую выборку респондентов. Хотя из-за отсутствия прямого контакта с человеком вы упустите много дополнительной информации — вы не узнаете о том, о чем не спросите, — вы можете очень ясно представить некоторые характеристики своей целевой аудитории. Тщательное планирование исследования чрезвычайно важно. Если вам нужны наглядные цифры, а не «ощущение» целевой аудитории, вам просто необходимо правильно сформулировать вопросы, отобрать подходящих респондентов и верно проанализировать ответы, и это целая наука.

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

• Writing Good Survey Questions (oreil.ly/P5o1n)

• Questionnaire Design Tip Sheet (oreil.ly/7vbqD)

Создание персоны пользователя

Создание персон — это не метод сбора данных, но оно поможет вам понять, что делать с ними после того, как вы их получите. Это дизайнерская техника, которая моделирует целевую аудиторию. Для каждой значимой группы пользователей вы создаете вымышленного ее представителя, или «проточеловека», которому присваиваете наиболее важные свойства пользователей в этой группе: задачи, которые они пытаются выполнить, их конечные цели и уровень их опыта в предметной области и владения компьютером в целом. Персоны могут помочь вам сохранить верное направление. В ходе работы вы можете задавать себе, например, такие вопросы: «Действительно ли этот вымышленный человек выполнит действие X? Или он сделает что-то другое?».

Исследования в процессе разработки дизайна — это не маркетинг

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

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

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

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

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

Паттерны: познание и поведение, связанные с разработкой интерфейсов

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

Поэтому, когда вы наблюдаете за людьми, использующими вашу программу или делающими что-то, для чего вы хотите создать новый программный инструмент, вы ожидаете от них определенных моделей поведения. Следующие паттерны часто наблюдаются в поведении пользователей. Велика вероятность, что вы их тоже увидите, особенно если будете искать.

Примечание

Для всех любителей паттернов: эти паттерны не похожи на те, что будут обсуждаться в следующих главах нашей книги. Они описывают человеческое поведение, а не элементы дизайна интерфейса, и они не являются предписывающими, как те, что рассматриваются в других главах. Вместо структурного представления, как это сделано для других паттернов, здесь дано их краткое описание.

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

• Safe Exploration (Безопасное исследование).

• Instant Gratification (Мгновенное вознаграждение).

• Satisficing (Разумная достаточность).

• Changes in Midstream (Изменения на полпути).

• Deferred Choices (Отложенный выбор).

• Incremental Construction (Пошаговое построение).

• Habituation (Привыкание).

• Microbreaks (Микроперерывы).

• Spatial Memory (Пространственная память).

• Prospective Memory (Проспективная память).

• Streamlined Repetition (Упрощенное повторение).

• Keyboard Only (Только клавиатура).

• Social Media, Social Proof, and Collaboration (Социальные сети, социальное подтверждение и коллаборация).

Safe Exploration (Безопасное исследование)

«Дайте мне возможность исследовать без потерь и неприятностей».

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

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

Этот паттерн включает в себя несколько основных рекомендаций по грамотной организации интерфейса, основанных на исследованиях отраслевого эксперта Джейкоба Нильсена4:

• видимость состояния системы;

• соответствие системы реальному миру;

• пользовательский контроль и свобода.

Вот несколько примеров «безопасного исследования».

• Фотограф пробует несколько фильтров в программе для обработки изображений. После этого он решает, что ему не нравится результат, и нажимает кнопку «Отмена» несколько раз, чтобы вернуться к началу. Затем он пробует другой фильтр, а потом еще один, каждый раз имея возможность отменить результат (о том, как это работает, рассказывается в главе 8, в описании паттерна «Многоуровневая отмена»).

• Новый посетитель домашней страницы сайта компании щелкает на разных ссылках, чтобы увидеть, что вообще есть на сайте, и уверен, что кнопка «Назад» всегда вернет его обратно на главную страницу. Никакие дополнительные окна или всплывающие объявления не открываются, и кнопка «Назад» работает предсказуемо. Можно представить себе, какая неразбериха получится, если веб-приложение начнет делать что-то другое или если в приложении будет кнопка, выглядящая как кнопка «Назад», но работающая совсем по-другому. Пользователь будет дезориентирован и может вообще отказаться от приложения.

Instant Gratification (Мгновенное вознаграждение)

«Я хочу сделать это прямо сейчас, а не потом».

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

Паттерн «Мгновенное вознаграждение» необходим в различных областях разработки. Например, если вы способны предположить, с чего начнет новый пользователь, вы разработаете интерфейс так, чтобы это первое действие оказалось максимально простым. Если цель пользователя — создание чего-то нового, например рисование объекта, то можно сразу же открыть новый холст как призыв к действию, а рядом поместить палитру. Если пользователю ­необходимо выполнить какую-либо задачу, то подскажите ему, с чего начать.

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

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

Satisficing (Разумная достаточность)

«Меня это устраивает. Я не хочу тратить время, чтобы изучать что-то еще».

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

Термин satisficing — разумная достаточность — образован от двух слов: «satisfying» (удовлетворительный) и «sufficing» (достаточный). Он был придуман в 1957 году социологом Гербертом Саймоном, который использовал его для описания поведения людей во всевозможных экономических и социальных ситуациях. Люди предпочитают довольствоваться достаточно хорошим, а не наилучшим, если изучение всех альтернативных вариантов может требовать много времени или усилий.

Разумная достаточность в действительности очень рациональна, если оценить всю ту умственную работу, которая необходима для анализа сложного интерфейса. Как заметил Стив Круг в своей книге «Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability» (New Riders, 2014)5, люди не любят думать больше чем необходимо — это лишняя работа! Но если в интерфейсе предусмотрена пара вариантов, которые пользователь замечает сразу же, то он попробует оба. Высока вероятность, что выбор окажется верным, но даже если нет, то вернуться назад и попробовать что-то еще будет несложно (предполагается, что интерфейс поддерживает паттерн «Безопасное исследование»).

Дизайнеры могут сделать из сказанного несколько выводов.

• Используйте в интерфейсе «призывы к действию». Давайте пользователям четкие указания: введите текст здесь; перетащите изображение сюда; коснитесь этой кнопки, чтобы начать работу, и т.д.

• Делайте ярлыки короткими и используйте простые слова, позволяющие их быстро прочитать (это относится к элементам меню, кнопкам, ссылкам или любым другим текстовым компонентам). Пользователь пробегает их глазами и делает выводы об их значении, поэтому пишите так, чтобы первое предположение всегда оказывалось верным. Если пользователь ошибется несколько раз, то он будет разочарован, а это плохо для вас обоих.

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

• Продумайте простой способ навигации; особенно это касается возвращения в точки, где второпях можно легко сделать неправильный выбор. Преду­смотрите «аварийные выходы» (см. главу 3). На стандартных веб-сайтах легко использовать кнопку «Назад», поэтому разработать простую навигацию назад-вперед важно и для веб-приложений, десктопных приложений, мобильных устройств.

• Помните, что сложный интерфейс предъявляет высокие когнитивные требования к новым пользователям. Визуальная сложность часто склоняет новичков к тому, чтобы довольствоваться малым: они ищут первое, что успешно заработает.

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

Changes in Midstream (Изменения на полпути)

«Я передумал, пока делал это».

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

Для дизайнера это означает, что он должен дать пользователю возможность изменить поставленную цель. Предоставьте ему право выбора. Не запирайте пользователя в среде с ограниченным выбором и без глобальной навигации либо связи с другими страницами или функционалом, если только на это нет веских причин. А такие причины могут найтись: см. примеры в паттернах под названием Wizard (Мастер) (глава 2) и Modal Panel (Модальная панель) (глава 3).

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

Для поддержки возможности повторного входа запрограммируйте в диалоговых окнах и веб-формах запоминание введенных ранее значений и не делайте диалоговые окна модальными; если окно не модальное, то пользователь может перетащить его в угол экрана, чтобы продолжить работу в нем позже. Приложения в стиле компоновщика — текстовые редакторы, среды для разработки программного кода и программы для рисования — позволяют пользователю работать одновременно над несколькими проектами и откладывать в сторону любое их количество во время работы над каким-то одним. Подробнее об этом рассказывается в главе 2, в описании паттерна Many Workspaces «Несколько рабочих столов».

Deferred Choices (Отложенный выбор)

«Я не хочу отвечать на этот вопрос прямо сейчас, позвольте мне закончить!»

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

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

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

Иногда дело просто в нежелании отвечать на вопрос. В других случаях у пользователя может быть недостаточно информации, чтобы дать ответ прямо сейчас. Что, если приложение для написания музыки запросит у вас название, тональность и темп новой песни еще до того, как вы начнете ее писать (пример такого «чудесного» дизайна вы найдете в Apple GarageBand)?

Выводы для дизайнеров интерфейсов очевидны, хотя им и не всегда легко следовать.

• Не заваливайте пользователя избытком вопросов и вариантов выбора с самого начала.

• В формах для заполнения четко помечайте необходимые поля и не делайте слишком много обязательных полей. Позвольте пользователю продолжать работу, не тратя времени на необязательные вопросы.

• Иногда можно отделять несколько важных вопросов или настроек от остальных, менее значительных. Выводите на экран короткий список и прячьте длинный.

• По возможности используйте паттерн Good Defaults (Хорошие варианты по умолчанию) (глава 10), чтобы дать пользователям несколько подходящих вариантов ответа по умолчанию, с которых удобно начать работу. Однако помните, что заранее подготовленные ответы все равно требуют их проверки пользователем на случай, если их понадобится изменить. Им тоже нужно уделять внимание.

• Обеспечьте пользователю возможность вернуться к заполнению отложенных полей позже и сделайте к ним простой и понятный доступ. Иногда в диалоговых окнах помещают краткие подсказки вроде «Вы всегда сможете изменить эти данные, нажав кнопку “Редактировать проект”». Некоторые веб-сайты сохраняют наполовину заполненные пользовательские формы или другие постоянные данные, например содержимое корзин с еще не приобретенными товарами.

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

Incremental Construction (Пошаговое построение)

«Дайте мне это изменить. Нет, опять не то. Попробую еще раз. Вот так-то лучше».

Когда пользователи создают что-то, они обычно не выполняют четкую последовательность действий. Даже у эксперта не получится приступить к работе, последовательно пройти весь процесс создания и получить в конце нечто завершенное и идеальное.

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

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

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

Плохие инструменты гарантированно будут отвлекать пользователя от работы. Если ему приходится ждать хотя бы 30 секунд, чтобы увидеть результат только что внесенного небольшого изменения, то концентрация нарушается и поток ослабевает.

Если вам интересно больше узнать о потоке и концентрации внимания, обратите внимание на книги Михая Чиксентмихайи (Mihaly Csikszentmihalyi), одна из них — Flow: The Psychology of Optimal Experience (Harper Row, 2009)6.

Habituation (Привыкание)

«Этот способ работает везде, почему же он не работает здесь?»

Когда человек постоянно работает в одном интерфейсе, некоторые манипуляции становятся рефлекторными, например нажатие сочетания клавиш Ctrl+S, чтобы сохранить документ, щелчок кнопки «Назад», чтобы покинуть веб-страницу, нажатие клавиши Enter, чтобы закрыть диалоговое окно, использование определенных жестов для развертывания и свертывания окон и даже нажатие на педаль тормоза в автомобиле. Пользователь не осмысливает эти действия — они входят в привычку.

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

Миллионы людей уже знакомы с командами в Microsoft Word и других текстовых редакторах:

• Ctrl+X: вырезать выделенный фрагмент;

• Ctrl+V: вставить выделенный фрагмент;

• Ctrl+S: сохранить документ.

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

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

По этой же причине диалоговые окна с подтверждением операции часто не помогают защитить пользователя от случайных изменений. Когда всплывает модальное диалоговое окно, пользователь может легко закрыть его, просто нажав кнопку OK или клавишу Enter (если кнопка OK является кнопкой по умолчанию). Если диалоговые окна появляются постоянно, пока пользователь вносит намеренные изменения, например удаляет файлы, то подобный быстрый ответ входит в привычку. А когда в диалоговом окне действительно возникает необходимость, толку от него уже никакого, так как пользователь привык не обращать на него внимания.

Примечание

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

Microbreaks (Микроперерывы)

«Я жду поезда. Неплохо бы сделать что-то полезное в оставшиеся пару минут».

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

Данный паттерн относится главным образом к мобильным устройствам, которые в такой ситуации легко вытащить из кармана. Огромный успех соцсетей в немалой степени обусловлен именно этим. Facebook, Instagram, Snap... о них вспоминают именно в микроперерывах.

Вот что обычно пользователи делают во время микроперерывов:

• проверяют электронную почту;

• просматривают ленту новостей и каналы (паттерн Streams and Feeds (Лента новостей и каналы)) (см. главу 2), например в Facebook или Twitter;

• заходят на новостные сайты, чтобы узнать, что происходит в мире;

• смотрят короткие видеоролики;

• ищут что-то несложное в сети;

• читают книгу в интернет-библиотеке;

• играют в короткую игру.

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

Что касается ленты новостей и каналов, загружайте свежее содержимое как можно быстрее и выводите его на первом же экране, который увидит пользователь. Другие приложения, такие как игры, видео, сетевые библиотеки, должны запоминать, где пользователь остановился, и восстанавливать предыдущее состояние без запроса (то есть поддерживать повторную входимость).

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

Отдельно стоит упомянуть о времени загрузки. Если содержимое загружается слишком долго — можете не сомневаться, пользователь не станет заходить в ваше приложение (особенно во время микроперерывов!). Убедитесь, что страницы легко читаются, самое полезное содержимое загружается в первую очередь и с минимальной задержкой.

Spatial Memory (Пространственная память)

«Клянусь, эта кнопка была здесь секунду назад! Куда она пропала?»

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

Рассмотрим, например, рабочий стол Windows, Mac или Linux. Многие люди используют его, чтобы размещать там документы, ссылки на часто запускаемые приложения и т.п. Выясняется, что для поиска нужных объектов люди пользуются пространственной памятью, и это очень эффективно. Они придумывают собственные варианты группировки или вспоминают, что нужный документ «был в самом верху прямо над тем значком». (Естественно, можно подобрать аналогии и в реальном мире. На рабочих столах множества людей постоянно царит «художественный беспорядок» — для стороннего человека это просто куча барахла, в которой, однако, его владелец может мгновенно найти нужную вещь. И боже вас упаси сделать там уборку!)

Во многих приложениях кнопки диалоговых окон (OK, Cancel и т.д.) размещаются в предсказуемых местах отчасти потому, что пространственная память на такие элементы управления очень сильна. В сложных приложениях люди также могут находить объекты, запоминая, где они находятся по отношению к другим элементам: инструментам на панелях инструментов, объектам в иерархических списках и т.д. Поэтому следует с большой осторожностью применять такие паттерны, как Responsive Enabling (Отзывчивое обнаружение) (см. главу 4). Добавление чего-либо в интерфейс обычно не вызывает проблем, но перемещение существующих элементов управления может нарушить работу пространственной памяти и затруднить поиск объектов. Однако это зависит от многих обстоятельств, так что, если вы не уверены, испытайте изменения на пользователях.

Многие мобильные приложения и игры состоят всего из нескольких страниц. Часто стартовая страница и есть то место, где пользователи проводят все свое время. Возможно, никакой навигации и не понадобится. Но пользователи привыкли водить пальцем влево, вправо, вверх или вниз, чтобы перейти к другим страницам (таким, как сообщения или настройки). Они расположены чуть в стороне. Snap — хороший пример мобильного приложения, «заточенного» под пространственную память пользователей.

Пространственная память, как и привыкание — еще один довод в пользу единообразия как среди разных программ, так и в пределах одного приложения. Люди ожидают найти определенный функционал в привычных местах. Пример вы найдете в описании паттерна Sign-In Tools (Инструменты регистрации) в главе 3.

Пространственная память объясняет, почему полезно предоставлять место для хранения документов и объектов, где порядок может наводить сам пользователь, как, например, на вышеупомянутых рабочих столах. Это не всегда практично, особенно когда объектов очень много, но для небольшого их количества работает довольно хорошо. Когда пользователи сами упорядочивают объекты, они легче запоминают, куда и что поместили. (И не меняйте выбранный ими порядок, пока они сами не попросят об этом!) Один из способов сделать такую структуру описан в разговоре о паттерне Movable Panels (Перемещаемые панели) в главе 4.

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

Кстати, верхние и нижние области списков и меню — это особые места в ко­гнитивном смысле. Люди чаще замечают их и лучше запоминают, чем элементы в середине меню. Так что, если вы хотите привлечь внимание к одному или двум элементам, поместите их вверху или внизу.

Prospective Memory (Проспективная память)

«Оставлю это здесь, чтобы не забыть заняться им позже».

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

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

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

Некоторые программы поддерживают проспективную память. В Outlook и на большинстве мобильных платформ, как упоминалось выше, эта поддержка реализована напрямую; в этих системах есть календарь, и они могут подавать звуковые сигналы. Еще один пример — Trello, использующая доски канбан. Вот какие еще приемы используют люди:

• заметки для себя, например на виртуальных «стикерах»;

• открытые экраны приложений;

• примечания прямо в документах (например, «Допиши меня!»);

• закладки в браузере для сайтов, которые нужно просмотреть позже;

• документы, сохраненные на рабочем столе, а не в привычных папках на диске;

• электронные сообщения, которые оставляют во входящих (и, возможно, помечают флажками), вместо того чтобы отправить в архив.

Люди используют любые типы средств идентификации, чтобы поддерживать пассивное проспективное запоминание, но обратите внимание, что ни один из перечисленных приемов не создавался специально для этого! То, для чего они в действительности были придуманы, — это гибкость и возможность организовать свои данные без вмешательства системы. Хороший клиент электронной почты позволяет создавать папки с любыми именами и не заботится о том, что вы делаете со своими входящими сообщениями. Текстовым редакторам все равно, что вы вводите и что для вас значит текст, написанный огромными пурпурными буквами; редактору программного кода без разницы, добавите вы комментарий «Дописать это!» в заголовок метода или нет. Браузеры не знают, зачем вы сохраняете определенные закладки.

Во многих случаях такая гибкость и невмешательство — это именно то, что вам действительно нужно. Дайте людям инструменты для создания собственных систем напоминаний, но не пытайтесь разработать систему, слишком умную саму по себе. Если окно приложения бездействует какое-то время, не следует делать вывод, что оно никому не нужно и что его можно закрыть. В целом не стоит с благими намерениями удалять файлы или объекты, которые система может посчитать бесполезными; возможно, кто-то специально оставил их здесь. Также не упорядочивайте и не сортируйте объекты автоматически, если пользователь не просит систему об этом.

Что вы можете сделать как дизайнер для поддержки проспективной памяти? Если кто-то оставит форму наполовину заполненной и временно ее закроет, то можно сохранить данные до следующего посещения — это поможет напомнить пользователю, на чем он остановился (паттерн Deferred Choices (Отложенный выбор)). Подобным образом многие приложения запоминают несколько последних объектов или документов, которые в них редактировались. Также можно предложить пользователям списки «наиболее интересных объектов» — как прошлых, так и будущих — в стиле закладок и сделать эти списки легко доступными для чтения и редактирования. Можно использовать паттерн «Несколько рабочих пространств» (глава 2), позволяющий пользователям оставлять открытыми незаконченные страницы, пока идет работа над чем-то другим.

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

Streamlined Repetition (Упрощенное повторение)

«Сколько раз мне нужно это повторить?»

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

Хороший пример — диалоговые окна Find and Replace (Найти и заменить), часто присутствующие в текстовых редакторах (Word, редакторах электронных сообщений и т.д.). В них пользователь вводит старую фразу и новую, а затем для каждого вхождения этой фразы во всем документе всего лишь нажимает кнопку Replace (Заменить). И это в случае, когда пользователю нужно проверить и подтвердить или отклонить каждое изменение; если он знает, что действительно необходимо заменить все вхождения, то может просто нажать кнопку Replace All (Заменить все). Одно движение — и работа сделана.

Вот более общий пример. Photoshop позволяет записывать действия, чтобы затем выполнять некоторые произвольные последовательности операций всего одним щелчком мыши. Если нужно обработать 20 изображений, изменив их размеры, применив кадрирование, усилив яркость и сохранив их, то эти шаги можно записать, работая над первым файлом в последовательности, а затем просто нажимать кнопку Play (Воспроизвести) для каждого из оставшихся 19. См. паттерн Macros (Макрос) в главе 8, где об этом говорится подробнее.

Среды для написания сценариев еще более универсальны. Unix и ее разновидности позволяют вносить в сценарий все, что только можно ввести в оболочке. Можно заново вызывать и выполнять отдельные команды, даже очень длинные, всего лишь нажимая Ctrl+P и Ввод. Можно собрать любой набор команд из командной строки, поместить их в цикл for и запустить, один раз нажав клавишу Ввод.

Или же сохранить их в сценарии командного процессора (или в цикле for сценария командного процессора!) и выполнить как отдельную команду. Написание сценариев — очень мощный инструмент, и по мере усложнения он превращается в полнофункциональное программирование.

Прочие варианты включают возможность копирования и вставки (устраняющую необходимость повторно вводить одно и то же миллионы раз), пользовательские ярлыки для приложений на рабочем столе (позволяющие не искать каталоги этих приложений в файловой системе), закладки в брау­зере (чтобы не вводить URL-адреса вручную) и даже сочетания клавиш на клавиатуре.

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

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

Keyboard Only (Только клавиатура)

«Пожалуйста, не заставляйте меня использовать мышь».

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

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

Вот несколько стандартных приемов для работы только с клавиатуры:

• можно задать сочетания «горячих» клавиш, клавиши быстрого вызова и клавиши выбора для операций, вызываемых из меню, например Ctrl+S для сохранения документа. Обратитесь к списку стандартных операций в руководстве по стилю оформления для платформы, на которой вы работаете;

• выбор нужного пункта в списках, даже поддерживающих множественный выбор, обычно возможен при помощи стрелок на клавиатуре в сочетании с модификаторами (такими как клавиша Shift), хотя это зависит от используемого набора элементов;

• клавиша Tab обычно перемещает клавиатурный фокус (выбор элемента управления, на который действует ввод с клавиатуры в данный момент времени) с одного элемента управления на следующий, а обратный переход осуществляется при помощи сочетания клавиш Shift+Tab. Это иногда называется «обход по клавишеTab». Многие пользователи ожидают, что эта техника будет работать в интерфейсах, содержащих формы;

• большинство стандартных элементов управления, даже переключатели и комбинированные поля, позволяют пользователям менять выбранное значение с клавиатуры путем нажатия стрелок, клавиши возврата или пробела;

• в диалоговых окнах и на веб-страницах обычно предусматривается кнопка по умолчанию, сигнализирующая: «Я закончил работу». На веб-страницах чаще всего это кнопки Submit (Отправить) или Done (Готово), а в диалоговых окнах — OK или Cancel (Отмена). Когда пользователь нажимает на такой странице или в диалоговом окне клавишу Enter, выполняется именно эта операция. После этого система переводит пользователя на следующую страницу или возвращает в предыдущее окно.

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

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

Social Media, Social Proof, and Collaboration (Социальные сети, социальное подтверждение и коллаборация)

«Что остальные думают об этом?»

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

Советы членов сообщества, прямые или косвенные, влияют на выбор людей, когда они принимают решения. Осуществляя поиск в интернете, совершая сделки (покупать ли этот продукт?), играя в игры (что тут делали другие игроки?) и даже создавая вещи, люди могут быть эффективнее, когда им помогают другие. Если нет, то они, по крайней мере, будут больше довольны результатом.

Мы с гораздо большей вероятностью будем смотреть, читать, покупать, подписываться, делиться, комментировать или предпринимать любые другие действия, если увидим, что кто-то из наших знакомых рекомендовал, сделал это или сейчас делает. Это называется социальным одобрением.

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

Вот несколько примеров социальной функциональности:

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

• Все является социальным объектом. Посты, фотографии, видео, отметки — почти все, что пользователи создают в социальных сетях, становится объектом, вокруг которого люди могут виртуально собираться. Им можно поделиться, его можно оценить, прокомментировать и т.п.

• Сотрудничество. Программное обеспечение для бизнеса и коммуникации трансформируется в средства, которые позволяют людям, находящимся на расстоянии и даже в разных часовых поясах, вести обсуждения, делать обзоры документов, проводить видеоконференции, отслеживать состояния, поддерживать живую и асинхронную коммуникацию и многое другое.

Социальное одобрение мотивирует людей к действию. Социальная групповая идентичность, участие и признание приносят людям удовлетворение.

Внедрение этих возможностей в интерфейс позволяет социальной динамике повысить вовлеченность, удовлетворенность и рост аудитории.

Из всех паттернов, описанных в этой книге, паттерн Help Systems (Cправочные системы) (см. главу 2) наиболее подробно раскрывает эту идею. Поддержка онлайн-сообщества является важной частью полной справочной системы для некоторых приложений.

Погрузиться в проектирование социальных сетей вы сможете, прочитав книгу «Designing Social Interfaces: Principles, Patterns, and Practices for Improving the User Experience» Кристиана Крамлиша (Christian Crumlish) и Эрин Мэлоун (Erin Malone) (O’Reilly, 2015).

Заключение

Вы познакомились с важнейшим условием успешного проектирования интерфейса взаимодействия: пониманием того, кто будет использовать ваш инструмент. Это понимание лежит в основе разработок, которые соответствуют цели и легко понятны. Чтобы достичь его, используйте фундамент из четырех составляющих. Во-первых, поймите контекст. Это значит — четко представьте, для кого вы разрабатываете дизайн, предметную или рабочую область, и оцените уровень квалификации пользователей. Во-вторых, выясните цели своей аудитории, то есть структуру рабочих потоков, задач и результатов, для достижения которых вы будете разрабатывать свой инструмент. В-третьих, изучайте аудиторию — это полезно и вдобавок ко всему научит вас понимать пользователей и их цели. Мы привели примеры исследовательских техник, которые вы можете применять. Наконец, мы рассмотрели ряд паттернов человеческого поведения, восприятия и мышления, имеющих отношение к проектированию интерфейсов. Эти четыре элемента составляют основу процесса разработки. В главе 2 мы рассмотрим, как правильно организовать наполнение программы или приложения.

Глава 2. Организация контента: информационная архитектура и структура приложений

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

• что такое информационная архитектура;

• как организовать информацию и задачи, чтобы они были понятны и в них было удобно ориентироваться;

• различные методы организации контента и данных для их эффективного использования;

• как организовать инструменты и функции для эффективной работы;

• как разрабатывать системы повторяющихся шаблонов или экранов;

• паттерны для представления контента и функционала, а также для доступа к ним и навигации по ним.

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

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

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

Такова информационная архитектура. Давайте разберемся в ней, взглянув на преимущества и масштабы ее проектирования.

Цель

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

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

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

Что это значит на практике?

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

• предвидело желания пользователя;

• организовывало и описывало информацию так, как это удобно пользователю;

• представляло информацию ясным и простым способом;

• использовало слова, которые понимает пользователь;

• предлагало четкий план действий;

• сообщало пользователю, где он находится и что с ним происходит;

• подтверждало, что задача успешно выполнена.

Определение

Информационная архитектура (ИА) — это совокупность способов организации и маркировки информационного пространства для его лучшего понимания и использования. В частности, ИА использует знания о пользователях для разработки таких элементов, как:

• структуры или категории для организации контента и функциональных элементов;

• различные способы навигации в зависимости от опыта пользователей;

• интуитивно понятные или многоступенчатые процессы для выполнения задач;

• ярлыки и языковые средства для передачи информации;

• инструменты поиска, просмотра и фильтры, помогающие пользователям найти то, что они ищут;

• стандартизированные экраны, шаблоны или макеты для единообразного представления информации и максимального удобства использования.

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

Проектирование информационного пространства для пользователей

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

Подход

Полезно рассмотреть приложение с точки зрения его основных данных и задач. Не задумывайтесь на этом этапе о конкретных способах их представления. Подумайте более абстрактно:

• какие данные и какие инструменты вам нужно предоставить пользователю?

• исходя из ожиданий пользователя и его текущего положения, когда вам нужно их предоставить?

• как их классифицировать и упорядочить?

• что пользователю нужно с ними сделать?

• сколько существует способов их представить? Одного может быть недостаточно.

• как сделать их полезными с точки зрения пользователя?

Этот план поможет вам творчески представить ИА, которую вы разрабатываете.

Разграничение информации и способов ее представления

Очень важно представлять себе ИА отдельно от ее визуального оформления, поэтому остановимся на этом подробнее. Задача проектирования становится более понятной, когда вы решаете ее поэтапно. Полезно представить разработку как процесс последовательного наложения слоев друг на друга.

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

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

 

Рис. 2.1. Многоуровневое проектирование: от уровня содержимого до уровня представления (на основе работы Джесси Джеймса Гаррета «The Elements of User Experience: User-Centered Design for the Web and Beyond New», Riders, 2011)

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

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

Принцип ВИСИ

Ваш контент и инструменты должны быть организованы таким образом, чтобы быть полезными аудитории. В процессе организации данных и контента по основным категориям или разделам учитывайте полезное правило: ВИСИ7.

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

Эти категории составят основу вашей навигационной системы, которая более подробно рассмотрена в главе 3.

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

Способы организации и классификации контента

Вероятно, вы уже использовали какие-то общие методы организации и классификации информации для своего сайта или приложения. Они особенно полезны при планировании способов отображения больших объемов структурированных данных в таблицах. Они также важны для планирования того, как пользователи будут искать, просматривать и фильтровать данные, сортировать и уточнять результаты поиска. Мы опишем шесть таких методов. Этот список основан на работе Ричарда Сола Вурмана из его книги об информационной архитектуре «Information Anxiety 2» (Que, 2001) и книге Эбби Коверт и Николь Фентон «How to Make Scene of Any Mess» (Covert, 2014). Я рекомендую прочесть их обе.

Вурман предлагает удобный способ объединить основные методы организации в акрониме LATCH (Location — местоположение, Alphabet — алфавит, Time — время, Category — категория, Hierarchy — иерархия). Давайте рассмотрим эти и другие способы организации более подробно.

Алфавитный способ

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

Числовой способ

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

Хронологический способ

Хронологический порядок — еще один полезный способ организации содержимого. Он часто используется в лентах социальных сетей, где распространен обратный хронологический порядок — самый последний элемент идет первым в списке, а более старые элементы — за ним. Информация может быть организована по дате, времени или продолжительности в порядке возрастания или убывания. Данные также могут быть упорядочены по частоте — от низкой к высокой и наоборот, — а также по их последовательности во времени: что произошло первым или должно произойти первым, подобно этапам процесса. Задачи также часто разбиваются на последовательность шагов.

По расположению

Этот способ может включать организацию по географическому или пространственному местоположению. Существует множество систем для определения географического положения, таких как широта и долгота. Географические категории часто являются вложенными или иерархическими, например страны включают области, а области включают города (см. Иерархический способ). Расположение также может включать расстояние от какой-либо опорной точки или до нее и порядок, основанный на этом