Мастер-класс

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

О том, как добиться такой преемственности, и рассказывал мастер-класс. Он состоял из трех частей — общих вводных на тему выбора платформ и расстановки приоритетов, серии “обзор конкретной ОС + практическое занятие по ней”, а также обсуждения спроектированных участниками интерфейсов. В ходе него нужно было проработать 3 экрана условного приложения конференции User Experience (стартовый, расписание, информация о конкретном докладе), причем сделать это последовательно для Android, iPhone и Windows Phone. Причем по мере продвижения многие возвращались к уже спроектированным платформам чтобы внести корректировки для обеспечения преемственности. Это и было одной из главных задач — заставить задуматься о наборе приложений как едином продукте, который должен быть последовательным в своих интерфейсных решениях, оставаясь при этом “родным” для ОС.

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

Выставка современных планшетов и смартфонов

В течение всей конференции я также представлял стенд компании Mail.Ru, на котором мы собрали интересную коллекцию современных планшетов и смартфонов. Хотя наша новая интерфейсная команда собралась сравнительно недавно и пока не успела показать готовые продукты, важно было как минимум обозначить направления, по которым мы движемся. Коллекция устройств в этом помогла — любой участник конференции мог подойти и поработать с любым из представленных аппаратов. Особой популярностью пользовался интерфейс Metro (планшет на Windows 8 и смартфон на Windows Phone 7.5 (Mango)), эксперимент Nokia с swipe-интерфейсом и бескнопочным телефоном N950 (платформа MeeGo), а также различные вариации Android-планшетов. Стенд стал также отличным поводом пообщаться и познакомиться со множеством интересных специалистов, так что несмотря на пропущенные из-за него интересные презентации, формат более чем удался.

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

1. Андрей Хвостов
2. Леонид Романов
3. Дмитрий (dp@de…….com)
4. Евгений Лазебный
5. Артем Камнев
6. Александр Ушаков
7. Михаил Фролов
8. Дарья Подрезова
9. Елена (arge…..@g…..com)
10. Рената (vsei………@mail.ru)

Презентация

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

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

Впечатления о конференции

На конференции User Experience я уже во второй раз (компания UI Modeling — в третий) и с каждым годом мероприятие все интереснее. Причем на этот раз удалось послушать вживую западных докладчиков, и в первую очередь — одного из величайших людей в отрасли, Билла Бакстона из Microsoft Research. Видео-записи с ним всегда интересны, но на сцене он еще ярче — то, сколько Билл знает о прошлом и будущем интерфейсов и как он умеет подавать историю и тренды очень впечатляет. Я всегда разделял мнение о том, что универсальных интерфейсов не бывает, но после его выступления можно ссылаться на его тезис “любой продукт идеален для одного применения и ужасен для другого”. Кстати, он готовит к выпуску книгу с описанием старых цифровых устройств — дома у него большой музей из нескольких сотен экспонатов, должен получиться крайне интересный материал для понимания того, как развиваются интерфейсы.

Очень полезным был рассказ Peter Boersma из голландского отделения Adaptive Path — в нем он расширил понимание процесса проектирования за счет планирования и стратегии. Это расширение того видения, которое его коллега Jesse James Garrett дал в книге “Elements of User Experience“. Оно было особенно интересно потому, что тема менеджмента в проектировании интерфейсов всегда актуальна для меня. После выступления удалось пообщаться с Питером на тему процесса в целом и своей завтрашней презентации о презентациях — оказалось, что они также стараются не просто отправлять результаты работ, а лично рассказывать о них.

Очень душевным оказался Eric Reiss из FatDux — и в рамках презентации, и на закрытии конференции. Хотя сама тема была скорее обзорной для начинающих, формат ее подачи получился живым и вовлекающим. Остальных приглашенных послушать не удалось, зато на следующий день попал на большинство интересных отечественных докладов. У меня, кстати, впервые получилось не подготовить не только интересные слайды, но и хорошее выступление. Во-первых, сама структура презентации строилась на нескольких рассказах, а не структурированных данных. Во-вторых, появилось больше иллюстраций и даже физических носителей. В-третьих, удалось более-менее правильно рассчитать объем материала и отведенное на него время. Буду практиковаться и дальше, тем более что ближайший повод совсем скоро — 5го ноября выступаю на украинской конференции Usability.UA 2010 с рассказом о кейсе про Московский Кредитный Банк.

P.S. Другие обзоры и материалы конференции:

• Фото от Юрия Михалыча: день 1, день 2, день 3;
• Фото от Юлии Крючковой;
• Фото от Андрея Зайцева;
• Официальный хеш-тег #uxrussia в Твиттере;
• Отчет от Алекса Федотова: день 1, день 2;
• Отчет от Ольги Горенко;

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

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

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

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

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

Кейс с обучением предмету

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

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

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

Процесс работы пошел следующим образом:

• Получение общего представления. В процессе первичного наблюдения за темой — запоминания наиболее значимых источников, компаний и авторов, сохранения всего самого яркого и интересного в закладочные сервисы — появилась необходимость в классификации этого потока. В попытках разложить входящую информацию по полочкам, поиске закономерностей и группировке похожего начал ставить к закладкам осмысленные теги. Не всегда правильные, но обучение двинулось вперед.
• Детальное изучение. Агрегатор FriendFeed оказался идеальным средством для сбора базы регулярных источников информации по теме. Постоянно добавляя новые обзорные сайты, галереи и блоги (не забывая при этом отключать оказавшиеся неинтересными), я смог собрать отличнейший новостной канал по теме визуализации и инфографики — сейчас туда попадает если и не все, то большая часть из появляющегося в известных открытых источниках. Самым сложным моментом оказалась работа с архивами этих сайтов — важно было пройтись по всем старым материалам в поисках интересного. Хотя такое копание заняло приличное количество времени и сил, оно здорово упростило работу с источниками дальнейшем, да и вложение было единоразовым. Во-первых, это лучшее испытание для системы классификации — справляется ли она с огромным потоком разнообразного контента? Во-вторых, в потоке нового очень много повторов, которые теперь можно на автомате удалять из ленты даже не открывая.
• Структуризация знания в виде статьи. Первым делом потребовалась классификация — описав свой опыт и наблюдения, перебрав часть собранной коллекции и посмотрев чужие классификации, у меня получился именно тот срез типов инфографики, который удобен и востребован в работе. Общение с коллегами помогло скорректировать неточности, а сбор примеров для статьи еще лучше отполировал структуру и описания методов.

Не считая главных итогов исследования — более глубокого понимания дисциплины и удобной справочной статьи — получились и дополнительные приятные выхлопы:

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

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

Процесс изучения предметной области

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

В прошлом году я писал о таком брейншторминге — мы как раз начинали работу над новым сложным проектом. Общий процесс понимания предмета выглядел так:

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

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

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

P.S. Кстати, на сайте появился рубрикатор статей — на одной странице собраны и классифицированы по темам все полезные материалы. Это куда более удобный способ навигации, чем теги.

Примеры из практики

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

Статистика и отслеживание метрик

	Динамика котировок в деловом портале BFM.ru. Показывает в виде линейного графика и столбиковой диаграммы изменение стоимости акции, индекса, валюты или товара, а также объем торгов ими.
	Эффективность рекламы одной из услуг (проект в стадии разработки). Показывает в виде линейного графика соотношение затрат на продвижение услуги и отдачу от него.
	Мониторинг стабильности работы хостинг-провайдеров (проект закрыт, работал в 2003 году). Показывает в виде столбиковой диаграммы процент успешно прошедших запросов к размещенным на площадках хостера сайтам.
	Динамика рейтинга пользователя в социальном медиа (проект в стадии разработки). Показывает в виде столбиковой диаграммы изменение значения рейтинга пользователя.
	Динамика показателей качества проекта в системе проект-менеджмента EPAM PMC. Показывает в виде линейного графика количество новых и закрытых в проекте багов.
	Статус прохождения компанией опросников в специализированном продукте биржи London Stock Exchange. Показывает в виде комбинированного индикатора выполнения процент уже отвеченных вопросов, а также то сколько останется неотвечено после ответа на указанный опросник.

Картография

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

Отображение процесса

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

Отображение времени

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

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

Использование в веб-сервисах

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

• Статистика и отчеты. Чаще всего это либо специализированные сервисы анализа статистики посещений и трафика вроде Google Analytics, ClickTale, Alexa, Google Trends или FeedBurner, либо встроенные в обычные веб-сервисы модули отчетности о популярности пользователя и его контента — например, в Flickr, Google Reader, ЖЖ или Free-Lance.ru. Для отображения данных они используют линейные графики, столбиковые и круговые диаграммы, гистограммы. В последнее время все больше таких продуктов применяет тепловые диаграммы для показа наиболее кликабельных мест на странице — например, ClickDensity и CrazyEgg.
• Картография и привязка данных к географии. Обычно это карты городов и стран, показывающие их географию, топографию, дороги и конкретные объекты — например, Яндекс.Карты, Google Maps, Yahoo! Maps или MapQuest. В последнее время многие из таких сервисов предоставляют инструменты для создания собственных тематических карт, благодаря чему есть справочники вроде Cost2Drive и Banki.ru на карте. Сюда же можно отнести недавнюю тенденцию геотегирования контента, когда новости или пользовательские материалы в социальных медиа привязываются к месту где они созданы или которое описывают — примеры такого подхода можно увидеть в специальном режиме просмотра Flickr, карте военного конфликта в Конго, Trulia Snapshot и Dopplr; либо когда географические перемещения самих пользователей отображаются в системе и могут служить поводом для рекомендаций, как это делают BrightKite, Nokia Friend View, Yahoo! FireEagle и Google Latitude. Чуть в стороне стоят карты метро — их можно увидеть в Яндекс.Картах Метро и РусАвтобусе.
• Отслеживание метрик. В основном это упрощенные отчеты — сервисы наглядно показывают изменения ключевых параметров в виде встроенных в обычные страницы изображений. Хотя обычно для этого используется текст или простая инфографика вроде индикаторов выполнения, некоторые продукты применяют графики и диаграммы — например, burndown-диаграммы в инструментах управления agile-проектами вроде Acunote и RallyDev. Также в эту группу можно включить инструменты для работы с биржевой информацией, массовые вроде Yahoo! Finance, Google Finance, BFM.ru или TIKR.ru и специализированные — E*Trade, TradeKing, Quote.ru.
• Привязка событий ко времени. Как правило, это использующие временную шкалу сервисы. Например, пользовательский контент в порядке его появления показывают Plurk, Dipity, This Moment и Flickr Clock. Сюда можно отнести и классические инструменты управления проектами, использующие диаграмму Гантта, такие как KommandCore или МегаПлан (хотя смысл этой диаграммы и шире простой привязки ко времени).
• Отображение процесса. Сервисы, которые используют формализованные и неформализованные блок-схемы для управления неким процессом. Такое представление хорошо подходит для создания различных информационных фильтров, как это делает Yahoo! Pipes и Google Analytics. А может использоваться как навигация по рабочему процессу и его наглядное отображение, как это делают в Target Process. По хорошему сюда нужно отнести и отображение текущего шага в мастерах (wizards) вроде оформления покупки в интернет-магазине, но это не самый яркий пример визуализации.
• Отображение связей. Чаще всего это дерево связей между объектами либо ментальная карта какого-то явления или понятия. Многие из таких сервисов показывают связи между людьми — либо в виде генеалогического древа в Geni, либо внутри другой социальной сети — например, Bacardi B-Live Share. А поисковик Quintura работает, по сути, как ментальная карта, хотя и имеет внешний вид скорее облака тегов.
• Сложные статистические данные. Как правило это специальные проекты газет и журналов, некоммерческих организаций, государственных ведомств, отображающие сложные политические или экономические данные. В них совмещается сразу несколько инструментов визуализации — например, карты и диаграммы. Наиболее известна команда New York Times Visualization Lab, которая регулярно выдает интереснейшие интерактивные приложения к газете. Похожие вещи делают и другие крупные издания — например, Washington Post, USA Today. Среди других проектов по сбору статистики — GapMinder, Akamai Real-Time Web Monitor, Every Moment Now, Daytum.
• Экспериментальная навигация. Практического смысла такая визуализация не несет, зато хорошо запоминается благодаря необычности. Например, в виде дерева показывается портфолио компании OLIN, а рекламное агентство Venables Bell & Partners использует комбинацию временной шкалы и некого подобия площадной диаграммы для отслеживания упоминаний своего рекламного ролика. Интересный вариант отображения связей между страницами в вики-системе предложен Ronald The и Benedikt Gross.

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

Источники информации по теме

В последнее время количество ресурсов, специалистов и проектов на тему визуализации в интернете все больше и больше. Два ключевых сайта, которые стоит просматривать регулярно — Infosthetics и Flowing Data. Первый собирает обширнейшую коллекцию любых примеров визуализации, второй имеет более практическую направленность.

Другие хорошие обзорные сайты и коллекции — Visual Complexity, Infographic News, Cool Infographics, News Page Designer. Много интересного собирается во Flickr-группах, других веб-сервисах и сообществах — Diagram Diaries, Everyday Information Achitecture, dataviz.tumblr.com, ru_infodesign. Некоторые компании и специалисты публикуют подборки своих и чужих работ — например, Density Design, CatalogTree, DataVisualization.ch, Tableau Software, Juice Analytics.

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

P.S. Спасибо за помощь в написании статьи моим коллегам и друзьям — Александру Хмелевскому, Льву Эйдинову, Юрию Шиляеву, Глебу Калинину, а также остальным помогавшим в вычитке, сборе материала и консультациях по теме.

Специально для Эксперимент.ру. В издании материал выйдет в немного другой компоновке.

Все части материала:

• Визуализация данных. Наглядный и компактный способ отображения информации, часть 1. Классификация
• Визуализация данных. Наглядный и компактный способ отображения информации, часть 2. Процесс
• Визуализация данных. Наглядный и компактный способ отображения информации, часть 3. Примеры из практики

Процесс создания

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

• Определение задачи и целевой аудитории. Важно понимать, что и кому хочет показать автор своей инфографикой. Будет ли это отчет о результатах деятельности, иллюстрация к аналитической статье или другая задача из тех, что описаны в первой части материала. Читателя и его бекграунд также полезно держать в голове. Знаком ли человек с описываемой темой или ему нужны дополнительные пояснения, увидит ли он графику саму по себе или вместе с другой тематической информацией? Здорово, если сообщение будет не только рассказано целевой аудитории, но и понято ей.
• Сбор данных для визуализации. Какие-то из них будут основными, какие-то — вспомогательными. Полезно иметь в загашнике как можно больше исходных данных на всякий пожарный — могут и не понадобиться, но в подходящем случае здорово подчеркнут смысл. Если визуализация будет динамически генерируемой или интерактивной, понадобятся соответствующие источники информации. Полезно проработать этот момент заранее — при работе со сторонними поставщиками данных часто возникает много подводных камней.
• Выбор типа визуализации и инструмента разработки. Внешний вид итоговой картинки определяется задачей и собранными данными. Нужно ли сравнить их, показать связи между ними, изменение их значений с течением времени или что-то другое? В предыдущей части статьи описаны основные типы инфографики — это наиболее распространенные подходы к отображению данных, которые подходят для большинства случаев. Есть также хорошая памятка от Andrew Abela, которая может подсказать подходящий вариант. Если визуализация будет динамически генерируемой или интерактивной, неплохо бы к этому моменту также выбрать инструмент разработки — технические ограничения могут осложнить полет фантазии.
• Создание набросков и проверка на реальных данных. Полезно предварительно смоделировать будущую картинку в виде рисованного на бумаге скетча или чернового наброска в электронном виде. Это позволит заранее увидеть многие из потенциальных проблем и, если нужно, подкорректировать изначальный план. Крайне желательно использовать для набросков реальные данные — их может либо не хватить для выбранного типа визуализации, либо наоборот, картинка получится слишком перегруженной.
• Отрисовка в дизайне и программная реализация. Оформление визуализации зависит от контекста использования итоговой картинки. Будет ли это самостоятельное изображение или часть другого документа или программы; будет ли она показана на бумаге, компьютере или мобильном; нужно ли предусмотреть элементы управления в случае интерактивной инфографики? Все это накладывает ограничения на внешний вид создаваемой визуализации.

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

Кем и чем создается инфографика

Специальных инструментов для создания комплексной статической инфографики нет — используются обычные графические редакторы вроде Adobe Illustator или Xara Xtreme. Причем для сложных изображений может понадобиться приличное количество времени и сил — вот, например, интересный кейс создания сложной иллюстрации, занявший порядка 80 часов работы. Причем половина из них ушла на предварительную проработку. Хотя в примере скорее иллюстрация, чем работа по визуализации данных, подходы и процесс очень похожи.

Для более простых прикладных задач вроде построения стандартных графиков и диаграмм или стандартизованного описания процессов подходят специализированные инструменты — MS Visio и Excel, Smart Draw, OmniGraffle, Concept Draw или любой графический редактор. При творческом подходе можно пойти дальше стандартных средств — например, много интересных приемов работы с Excel есть в блоге компании Juice Analytics. Есть также инструменты для построения отдельных типов визуализации вроде ментальных карт в MindManager, UML-диаграмм в Rational Rose, диаграмм Сэнки в e-Sankey или Гантта в MS Project. Причем многие из таких продуктов в последнее время все чаще запускаются в виде веб-приложений — например, Lovely Charts или Gliffy.

Большинство стандартных задач по созданию динамической инфографики в вебе решаются библиотеками скриптов на JavaScript, Java и Flash — например, amCharts или JS Charts. Есть аналогичные платные и беслатные продукты вроде Google Chart, позволяющие генерировать графики и диаграммы через специальный API или с помощью виджетов, как Fusion Widgets.

Для более сложных визуализаций существуют экспериментальные инструменты и веб-сервисы. Например, одна их исследовательских групп IBM развивает проект Many Eyes — он позволяет построить полтора десятка типов инфографики на основе любого набора данных. Свои эксперименты в этой области выкладывают в общий доступ команды некоторых сайтов, таких как Digg Labs, Yahoo! Research и MSNBC, а также сторонние разработчики, использующие данные популярных сервисов вроде Del.icio.us и Last.FM. Существует также много университетских работ в этом направлении — например, немецкий Synoptic.

Если идти от практических задач в сторону алгоритмического или генеративного искусства, широко используются такие инструменты как язык программирования Processing и Context Free Design Grammar. Многие пишут скрипты самостоятельно — например, в 3D Max.

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

Специально для Эксперимент.ру. В издании материал выйдет в немного другой компоновке.

Все части материала:

• Визуализация данных. Наглядный и компактный способ отображения информации, часть 1. Классификация
• Визуализация данных. Наглядный и компактный способ отображения информации, часть 2. Процесс
• Визуализация данных. Наглядный и компактный способ отображения информации, часть 3. Примеры из практики

Применение

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

• Статистика и отчеты. Самодостаточный жанр, когда данные за некий период времени показываются вместе. Например, статической картинкой в приложении к отчету или настраиваемым графиком в сервисе статистики, с возможностью изменения параметров его отображения.
• Справочная информация. Дополнение к основному тексту, наглядно иллюстрирующее его упоминаемыми данными. Скажем, дать общее представление о динамике одного из показателей, либо отобразить какой-то процесс и его этапы; может быть — показать структуру некого явления.
• Интерактивные сервисы. Продукты и проекты, в которых инфографика является частью функциональности. Так, в качестве средства навигации по сервисам со сложным workflow может являться диаграмма процесса. Почти все, что связано с работой с картами и вовсе редко обходится без микса инфографики и интерактивности, не говоря уже о специализированных системах вроде диспетчерских и большей части компьютерных игр.
• Иллюстрации. Не совсем чистый жанр — скорее, использование практик и подходов красивого отображения данных для создания самостоятельных иллюстраций. Они несут некий смысл, но это не основная их задача — основной ценностью является качество исполнения.
• Чертежи и схемы. Специализированные документы, показывающие структуру и процесс работы сложных инженерных и природных систем. Помимо различных карт, зачастую это редко использующиеся в повседневной жизни вещи вроде схем печатных плат.
• Эксперименты и искусство. Визуализация данных без особого практического смысла, скорее в качестве экспериментов или инсталляций. Чаще всего это сложные и громоздкие изображения, которые сложно “прочитать” бегло — объем данных и взаимосвязей между ними таков, что нужно разбираться с картинкой по частям; либо просто абстрактные изображения, автоматически сгенерированные. В последнее время направление все более популярно и периодически выходит за рамки компьютерной графики — например, в виде графиков-скульптур.

Классификация

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

Графики

Показывают зависимость данных друг от друга. Строятся по осям X и Y, хотя могут быть и трехмерными.

Линейный график (line chart, area chart). Наиболее распространенный случай. Объединяет линией набор точек, соответствующих значениям по осям. Например, ежедневная посещаемость сайта за месяц. Может показывать сразу несколько наборов данных — например, статистику просмотров для 3 наиболее популярных страниц. Примеры: © BFM.ru, SmartMoney, TeleGeography Research Другие примеры в галерее паттернов

График рассеивания (scatterplot). Показывает распределение ограниченного набора точек, соответствующих значениям по осям. Между точек часто рисуется линия тренда — она наглядно показывает закономерности среди значений. Например, связь между стажем работы и производительностью труда среди 50 сотрудников компании (просто соединить полученные точки в виде линейного графика нельзя — и смысл искажается, и линия будет будет дерганой). Примеры: © Statcon Другие примеры в галерее паттернов

Диаграммы сравнения

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

	Столбиковая диаграмма (bar chart). Показывает один или несколько наборов данных, сравнивая их между собой. Существует два варианта отображения в случае нескольких наборов — либо в виде нескольких стоящих рядом столбиков, либо в виде одного, но поделенного внутри в соответствии с долями значений. Например, ежегодная прибыль трех компаний за последние 5 лет или доли рынка трех компаний за это же время. Примеры: © SmartMoney Другие примеры в галерее паттернов
	Гистограмма (histogram). Показывает распределение набора данных внутри выборки в виде столбиков. Например, количество сотрудников компании в нескольких возрастных группах. Примеры: © Студия Артемия Лебедева, Большая Советская Энциклопедия Другие примеры в галерее паттернов
	Круговая диаграмма (pie chart). Отображает процент, занимаемый каждым значением внутри набора данных, в виде разбитого на части круга. Например, доли рынка сотовых операторов. Может отображать сразу несколько наборов данных — в этом случае диаграммы наложены друг на друга, причем каждая из них меньше предыдущей. Например, доли рынка сотовых операторов за последение 3 года. Примеры: © Candy Chang, Density Design, GraphJam Другие примеры в галерее паттернов
	Площадная диаграмма (bubble chart). Микс графика и диаграммы — по двум осям расставлен набор точек, соответствующий значениям. При этом сами точки не соединены и имеют различную величину, которая задается третьим параметром. Например, сравнение количества купленных товаров, общей стоимости покупки и величины общего бюджета покупателя. Примеры: © (автор неизвестен), Секрет Фирмы, Коммерсантъ.Деньги Другие примеры в галерее паттернов
	Кольцевая диаграмма (ring chart). Показывает процент от максимального количества, которое занимает одно из значений в наборе данных, в виде частично закрашенного кольца. Например, количество завоеванных на чемпионате медалей относительно максимального. Часто используется сразу несколько таких диаграмм, сравнивая разные значения. Примеры: © Wired, New York Times Другие примеры в галерее паттернов
	Диаграмма разброса (span chart). Показывает минимальную и максимальную величину значений внутри набора данных в виде урезанной столбиковой диаграммы. Начало столбика лежит не на горизонтальной оси, а в точке минимального значения по вертикали. Например, разброс стоимости квадратного метра жилья в разных районах города. Примеры: © Potsdam University of Applied Sciences Другие примеры в галерее паттернов
	Лепестковая диаграмма (radar chart). Сравнивает величины нескольких значений, каждая из которых соответствует точке на оси. Количество осей соответствует количеству значений, а точки объединены линями. Например, сравнение рентабельности каждого из 8 направлений деятельности компании. Примеры: © Секрет Фирмы, Pedro Monteiro, Main Library at Queen Mary (University of London) Другие примеры в галерее паттернов
	Облако тегов (tag cloud). Сравнивает ключевые слова или фразы (значения), содержащиеся внутри фрагмента текста (набора данных), задавая каждому из них свой размер шрифта. Размер шрифта зависит от величины параметра. Например, 25 самых часто упоминаемых в газетах слов за декабрь 2008 года. Примеры: © Flickr, Martin Ignacio Bereciartua Другие примеры в галерее паттернов
	Тепловая диаграмма (heat map). Сравнивает значения внутри набора данных, закрашивая их одним из цветов в заранее выбранном спектре. Основой является изображение или другая диаграмма, на которой расставлены значения. Цвет зависит от величины параметра и чаще всего накладывается в виде пятен. Например, страны мира с наиболее высоким атмосферным давлением или элементы главной страницы сайта, по которым пользователи кликают чаще всего. Примеры: © Dylan Vester, CrazyEgg Другие примеры в галерее паттернов

Деревья и структурные диаграммы

Показывают структуру набора данных и взаимосвязи между его элементами.

	Граф и дерево (graph, tree). Показывает иерархию набора данных, в которой элементы являются родительскими или дочерними по отношению друг к другу. Выстраивается в виде соединенных линиями узлов либо сверху вниз, либо из центра композиции. Узел обычно отображается кругом или прямоугольником. Например, карта сайта. Примеры: © Concept Draw, Karen Leech, (автор неизвестен) Другие примеры в галерее паттернов
	Ментальная карта (mind map). Показывает состав и структуру явления или понятия в виде графа, в котором каждый узел имеет один или несколько дочерних элементов. Это частный случай графа, с той разницей что ветви обычно симметрично расходятся из узла, расположенного в центре изображения. Например, конспект книги по управлению проектами, который отражает ее содержание и основные понятия. Примеры: © Adaptive Path, Ethan Hein, Comic vs Audience Другие примеры в галерее паттернов
	Формализованные структурные диаграммы. Показывают состав и структуру системы или ее части в виде карточек, которые описаны с разной степенью детализации и связаны друг с другом как родительские и дочерние. Отображается в стандартизованном виде — например, с помощью UML (Unified Modeling Language) или IDEF1X (Integration Definition for Information Modeling). Например, все сущности, необходимые для работы одного из модулей программной системы. Примеры: © Concept Draw, Wikipedia Другие примеры в галерее паттернов
	Диаграмма Венна/Эйлера (Venn/Euler diagram). Показывает отношения между значениями набора данных в виде накладывающихся друг на друга кругов (чаще всего трех). Область, в которой пересекаются все круги, показывает общее между ними. Например, пересечением соблюдения сроков, бюджета и поставленных задач является успех проекта. Примеры: © Phil Glockner, Dan Saffer Другие примеры в галерее паттернов
	Плоское дерево (tree map). Показывает иерархию набора данных, в которой элементы являются родительскими или дочерними по отношению друг к другу. Отображается в виде набора вложенных прямоугольников, каждый из которых является ветвью дерева, а находящиеся внутри него — дочерними элементами и ветвями. Прямоугольники различаются по размеру в зависимости от параметра и имеют цвет, который задается другим параметром. Например, детальная структура бюджета компании, в котором цветом показан процент изменения каждого пункта по сравнению с предыдущим годом. Примеры: © Tableau Software, Panopticon, Panopticon Другие примеры в галерее паттернов

Диаграммы визуализации процесса

Показывают процесс, состоящий из последовательности действий. Может включать один или несколько сценариев развития событий.

	Формализованная блок-схема (block diagram). Показывает ключевые шаги, которые проходит процесс, в виде связанных друг с другом однонаправленными стрелками блоков. Отображается в стандартизированном формате, где вид блока зависит от его роли в процессе. Например, схема процесса утверждения и публикации статьи внутри редакции. Примеры: © Density Design, Allen Holub, Concept Draw Другие примеры в галерее паттернов
	Неформализованная блок-схема (block diagram). Показывает ключевые шаги, которые проходит процесс, в виде связанных друг с другом стрелками блоков. Отображается в свободной форме, когда шаги показаны произвольными фигурами, а стрелки могут быть двунаправленными или вообще не иметь направления. Кроме того, блоки могут быть объединены в группы. Например, упрощенная схема передвижения средств при SMS-платежах. Примеры: © Tapulous, Секрет Фирмы, David Armano Другие примеры в галерее паттернов
	Диаграмма циклического процесса. Показывает ключевые шаги процесса, который содержит набор повторяющихся действий. Циклическая часть отображается в виде кольца, которое образуют соединенные стрелками шаги. А начало и окончание процесса — входящей и выходящей из круга стрелками. Например, последовательность процесса проверки качества, который проходит во время работы над программным продуктом. Примеры: © Fruitful, eStrara, Idiagram Другие примеры в галерее паттернов
	Диаграмма Сэнки (Sankey diagram). Показывает ключевые шаги процесса и интенсивность его протекания на каждом из участков. Отображается без узлов, в виде соединяющихся и разветвляющихся линий разной толщины (в зависимости от величины параметра). Имеет любое количество начальных и конечных точек, а значит и множество сценариев развития. Например, процесс передачи тепла от ТЭЦ к бойлерной станции, включая его потери по различным причинам. Примеры: © World Resources Institute, Sankey-diagrams.com, IBM Другие примеры в галерее паттернов

Матрицы

Сопоставляют между собой значения внутри набора данных в виде таблицы.

	Таблица (matrix). Показывает набор данных в виде заполненных его значениями ячеек, которые образуют собой строки и столбцы. Каждому столбцу и строке соответствует параметр, который определяет конкретную ячейку для значения. Например, бюджет отделов компании за каждый год ее существования. Примеры: © Известия, PresseBox, Elliance Другие примеры в галерее паттернов
	Календарь. Частный случай таблицы. Показывает календарный месяц по номерам и дням недели. Примеры: © thenonhacker, Yahoo! UI Patterns Library Другие примеры в галерее паттернов

Диаграммы времени

Показывают распределение данных в зависимости от времени.

Временная шкала (timeline). Показывает значения из набора данных на горизонтальной оси, которая соответствует времени. Отрезки между значениями могут быть любой величины. Например, линия годов XX века, на которой отмечены крупные военные конфликты. Примеры: © Секрет Фирмы, Rodrigo Ronda Leon, GOOD Magazine Другие примеры в галерее паттернов

Диаграмма Гантта (Gantt diagram). Показывает последовательность, длительность, а также время начала и окончания этапов и конкретных задач, необходимых для выполнения проекта. Отображается в виде “водопада” из одного или нескольких каскадов — соединенных стрелками блоков, выстроенных по диагонали сверху вниз, слева направо (т.е. “лестницей”). Причем длина блока зависит от необходимого для выполнения времени. Например, задачи, которые нужно выполнить для написания, подготовки к печати и выпуска книги. Диаграмму можно также отнести и к группе визуализирующих процесс, но обе ее части (длительность и последовательность действий) одинаково важны, поэтому тут уже дело вкуса. Примеры: © MS Project, Todd R. Warfel Другие примеры в галерее паттернов

Карты

Показывают данные, зависимые от географии или архитектуры некого объекта.

	Географическая карта. Показывает в схематичном виде состав и расположение частей географического объекта. Например, мир в целом или остров. Примеры: © Google Maps, TeleGeography Research, Flowing Data Другие примеры в галерее паттернов
	Фотографическая карта. Показывает географический объект в виде фотографии со спутника или самолета. Например, мир в целом или город. Примеры: © Google Maps, Яндекс.Карты Другие примеры в галерее паттернов
	Дорожная карта. Показывает в схематичном виде трассы, магистрали, железные и другие дороги, наложенные на очертания географических объектов. Например, автомобильная карта дорог области. Примеры: © MapQuest, Яндекс.Карты Другие примеры в галерее паттернов
	Тематическая карта. Показывает различные объекты в виде маркеров на карте мира, страны или города. Объектами чаще всего являются те, что построены человеком: дома, магазины, памятники, объекты инфраструктуры и т.п. на карте города; либо города на карте страны; либо страны на карте мира. Основой может являться практически любая карта, но обычно используются географическая, фотографическая, дорожная или топографическая карты. Например, расположение офисов компании на карте города. Примеры: © Яндекс.Карты, Автокадабра Другие примеры в галерее паттернов
	Картограмма (cartogram). Показывает в виде схематичной карты набор данных, каждое из значений которого привязано к географическому объекту. При этом размер и форма объекта зависит от величины значения. Например, карта мира, на которой величина страны зависит от количества ее населения. Примеры: © Density Design, (автор неизвестен), Manuel Marino Другие примеры в галерее паттернов
	Архитектурный план (floor plan). Показывает в схематичном виде форму и внутреннее строение одного из этажей здания или другого архитектурного сооружения. Также может показывать расстановку мебели и других предметов наполнения помещений. Например, план помещений двухкомнатной квартиры. Примеры: © Christian’s of Bucks Point, (автор неизвестен), (автор неизвестен) Другие примеры в галерее паттернов
	Схема маршрутов общественного транспорта. Показывает остановки общественного транспорта в виде одной или нескольких пересекающихся линий разного цвета. Линия соответствует заранее определенной последовательности станций. В некоторых случаях накладывается на упрощенную географическую карту. Например, карта метро. Примеры: © New York Subway, Rhein-Main-Verkehrsverbund GmbH, Penguin Group Другие примеры в галерее паттернов

Диаграммы связей

Показывают связи внутри набора данных, как правило достаточно большого.

	Круговая диаграмма связей (network diagram, arc diagram). Показывает связи внутри набора данных в виде кольца, на котором расставлены значения. Значения связаны дугами или линиями, находящимися во внутренней области круга. При большом количестве значений они могут находиться и внутри кольца, хотя это менее наглядно. Связи также могут иметь направление. Например, являются ли взаимными друзьями участники группы в социальной сети. Примеры: © Ethan Hein, Ethan Hein, Josef Muller-Brockmann Другие примеры в галерее паттернов
	Линейная диаграмма связей. Показывает связи внутри набора данных в виде линии, на которой расставлены значения. Значения связаны дугами, находящимися сверху и снизу линии. Связи также могут иметь направление. Это альтернативный вариант отрисовки круговой диаграммы связей — смысл и задачи у них одинаковые. Примеры: © Martin Dittus, Andreas Koller & Philipp Steinweber, TeleGeography Research Другие примеры в галерее паттернов
	Связи на карте. Показывает связи внутри набора данных в виде земного шара или географической карты, на которой расставлены значения. Значения связаны дугами, если изображение трехмерное, или линиями, если карта плоская. Связи также могут иметь направление. Например, маршруты всех находящихся сейчас в воздухе самолетов. Примеры: © National Science Foundation, Ensci, MIT Senseable City Lab Другие примеры в галерее паттернов
	Дендрограмма (dendrogram). Показывает близость значений набора данных по одному из параметров, используя ось Y для расстановки самих значений, а ось X — величины параметра. Отображается в виде набора соединяющихся друг с другом горизонтальных линий, которые соединяются, если значения совпадают по параметру. Причем чем раньше совпадение значений находится по оси X, тем ближе они друг к другу. Например, сравнение годовой выручки 30 предприятий. Примеры: © GUI.ru, New York Times, Kate Jones Другие примеры в галерее паттернов

Иллюстрации

Показывают процесс или явление в неформализованном виде.

Иллюстрация. Показывает ключевые шаги, которые проходит процесс, в виде изображенного на картинке сюжета. Либо структуру явления в виде визуальной метафоры. По сути является аналогом графика, диаграммы или неформальной блок-схемы. Например, изображение круговорота воды в природе в книге по природоведению. Примеры: © Athletics NYC, Christian Montenegro, журнал «Популярные Финансы» Другие примеры в галерее паттернов

Комикс. Показывает ключевые шаги последовательного процесса или явления в виде набора картинок, каждая из которых показывает один из его этапов в виде небольшого сюжета. Например, три этапа процесса параллельной парковки в инструкции для водителей. Примеры: © Scenic Valley Driving School, Elliance Другие примеры в галерее паттернов

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

Специально для Эксперимент.ру. В издании материал выйдет в немного другой компоновке.

Все части материала:

• Визуализация данных. Наглядный и компактный способ отображения информации, часть 1. Классификация
• Визуализация данных. Наглядный и компактный способ отображения информации, часть 2. Процесс
• Визуализация данных. Наглядный и компактный способ отображения информации, часть 3. Примеры из практики

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

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

И все-таки есть характеристика, с которой можно выйти из тупика — это глубина проработки интерфейса. Со временем мы нашли хороший баланс, разбив работы над проектом на три фазы:

1. Концепция

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

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

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

2. Прототип

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

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

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

3. Детальная спецификация

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

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

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

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

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

Все части материала:

• Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 1. Четыре слоя проектирования
• Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 2. Спираль повышения качества
• Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 3. Ранние результаты

1. Бизнес-анализ

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

2. Проектирование интерфейса

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

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

3. Дизайн

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

Дизайнер, как человек со свежим взглядом на проблему, может предлагать свои решения. И если они окажутся лучше предварительно спроектированных — почему бы не воспользоваться ими? Еще более важно то, что он может заметить ошибки и нестыковки. Дизайнеру также может понадобиться объяснить те вещи, которые проектировщик забыл описать. И этот очередной уровень проверки интерфейсных решений дает 60% точности.

4. Интерактивный прототип

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

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

5. Разработка

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

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

6. Пользовательское тестирование

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

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

7. Реальная работа системы

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

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

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

8. Развитие продукта

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

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

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

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

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

Все части материала:

• Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 1. Четыре слоя проектирования
• Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 2. Спираль повышения качества
• Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 3. Ранние результаты

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

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

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

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

1. Модель продукта, которая описывает концепцию системы. Как должен быть построен интерфейс, чтобы решать задачи именно так, как это наиболее привычно и удобно целевой аудитории? Как при этом акцентировать внимание пользователей на тех вещах, которые важны для соответствия продукта бизнес-задачам? Этот слой определяет, какие функции и процессы системы являются ключевыми. Те, на которые “нанизывается” все остальное.
2. Информационная архитектура, которая определяет структуру системы. Какова карта функциональности продукта, как выглядит дерево его возможностей? На какие страницы (экраны) нужно разбить всю функциональность и как эти страницы должны соотноситься друг с другом? Какая основная информация и элементы управления должны быть на каждой странице? Этот слой определяет архитектуру системы на общем и частном уровнях.
3. Эргономика “малых форм”, которая определяет качество исполнения конкретных элементов интерфейса. Какие способы подачи информации лучше всего подходят в каждой конкретной ситуации? Какие элементы управления наиболее удобны в каждом конкретном случае? Что лучше поставить — кнопку или ссылку? Нужны ли разные цвета для разных типов ссылок? Этот слой определяет внешний вид конкретных элементов и страниц в целом.
4. Проектирование взаимодействия, которое определяет реакцию системы на действия пользователя. Нужно ли информировать пользователя о том, что система реагирует на его запросы? Нужны ли разные способы реакции и как выбрать оптимальные? Должен ли всплывающий слой появляться с красивым эффектом или просто без задержек показываться пользователю? Этот слой определяет сценарии выполнения пользователем конкретных задач.

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

Все части материала:

• Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 1. Четыре слоя проектирования
• Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 2. Спираль повышения качества
• Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 3. Ранние результаты