Ценность информационной архитектуры

62 вебинар UX RussiaДмитрий Сатин и Андрей Сикорский

18 февраля 2010 года

Обновленный Юзабилити Бюллетень

Usability-Bulletin.RU

Ценность информационной архитектуры

62 вебинар UX RussiaДмитрий Сатин и Андрей Сикорский

18 февраля 2010 года

Вопросы

• Обзор статьи К. Лаферьер– Что значит ИА для

заказчика?– Видит ли он ее

ценность?– Что происходит с

проектом, когда он меняет однажды принятое решение?

– Может ли ИА помочь управлять процессом изменений?

Три пояснения

• ИА включает в себя требования, цели и сценарии поведения пользователей– Цель продукта– Маркетинговые цели– Источники трафика

• ИА удерживает проект от расползания– Структура проекта– Структура требований– Изменение ИА – изменение сроков и бюджетов

• ИА контролирует цели и задачи сайта– После сбора требований и фиксирования структуры любое

изменение дизайна будет требовать пересмотра сроков

Фазы работы

• Исследовательская– Анализ контента– Персонажи– Пути пользователей– Сценарии и use-cases– Первые wireframes

• Дизайн и разработка– Развертывание

сценариев– Wireframes

• Сдача/приемка

Перечень документов

1. Исследование контента2. Карта контента3. Детальный аудит

контента4. Карта сайта5. Навигационная схема6. Определение

персонажей7. Список требований,

сценариев, use-case8. Прототипы (wireframes)

1. Исследование и первичные документы

1. Исследование контента

• Что?– Высокоуровневая

оценка– Какие блоки контента

есть/будут на сайте?– Определить объем

задач• Кто?– Все участники– Наибольший вклад – со

стороны заказчика

2. Карта контента• Что?– Графическое

представление разделов контента и их связей

– Преобразуется в карту сайта и навигации

• Кто?– Эксперт в предметной

области со стороны заказчика

• Потребители?– Разработчики ПИ

3. Детальный аудит контента

• Что?– Инвентарь контента– Описание страниц с

присвоением идентификаторов

• Кто?– Подрядчик

• Потребитель?– Эксперты в предметной

области– Разработчики– Команда QA

4. Карта сайта

• Что?– Отражение комбинации

функциональности и информации

– Прописывание путей пользователя на сайте (максимально детальное)

• Кто?– Проектировщики

• Потребитель?– Основное руководство для

всех членов команды

5. Навигационная схема• Что?

– Навигация и связь между интерактивными элементами

– Учет разных представлений и уровней опыта взаимодействия

• Кто?– Проектировщик

• Потребитель?– Эксперты со стороны

заказчика– Команда дизайнеров и

разработчиков

6. Определение персонажей• Что?

– Описание пользователей, их мотивации

• Кто?– Заказчик– Проектная команда– Юзабилити-эксперты– Разработчики– Эксперты со стороны

заказчика

• Потребитель?– Команды разработчиков и

специалистов по юзабилити

7. Требования, use-cases, сценарии

• Что?– Список требований и

задач для проектирования

• Кто?– Бизнес-аналитики– Эксперты предметной

области

• Потребители?– Бизнес-аналитики– Менеджеры проектов– Эксперты заказчика– Команда ИА

8. Прототипы

• Что?– Схема/структура

экранов• Кто?– Проектная команда

• Потребитель?– Заказчик

• Примечание– Прорабатывать прототип с

экспертами, специалистами по Ю– Не вмешивать в процесс заказчика

2. Разработка и эволюция документов

Контент

• Исследование контента– Статично, не обновляется

• Карта контента– В процессе разработки

изменяется– Новые требования

должны вноситься максимально оперативно

• Детальный аудит контента– Обновляется в случае

включения нового контента

Навигация

• Карта сайта– Добавление новые

пользовательские пути– Внесение справочной

информации о взаимодействии страниц

• Схема навигации– Внесение изменений по

результатам теста– Все изменения должны

учитывать особенности дизайна и функциональных элементов.

Требования

• Определение персонажей– Неизменны по

завершению фазы 1– Специалисты используют

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

• Use-case/список требований– Развертывание сценариев– Определение реальной

функциональности

Прототипы

• Базовые шаблоны не изменяются– Любая задача

прототипирования вписывается в существующие шаблоны

– Введение нового шаблона – дорогостоящий процесс

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

Сдача-приемка – как управлять?

Анализ контента

• Исследование контента– Утверждение при передаче всего контента– Добавление нового контента может значительно повлиять на

разработку

• Карта контента– Согласование после получения списка основных требований– Изменения в карте контента влекут изменение требований

• Детальный аудит контента– Согласование перед документированием требований– Делается достаточно редко– Для управления изменениями применяется карта сайта и

карта контента

Навигация

• Карта сайта– Любое изменение после основного согласования

должно подвергаться дополнительному согласованию– Необходимо поддерживать ее всега в актуальном

состоянии и информировать о любых изменениях• Схема навигации– Утверждается после соглашения по карте сайта и

таксономии– Внесение изменений в этот документ на продвинутых

стадиях проекта может привести к изменению цикла разработки

Требования

• Список персонажей– Утверждение происходит ДО разработки– Необходимо валидировать схему навигации, проведя

персонажей по ней• Список требований/use cases– Утверждение – жизненно-важный момент– ДО разработки!– Любо изменение меняет объем задач

Прототипы

• Утвердить основные шаблоны как можно раньше.

• Прежде, чем вносить изменения определить какого уровня изменения:– шаблон, – Страница– и т.д.

Спасибо за внимание