62 ub-overview
Post on 22-May-2015
259 Views
Preview:
TRANSCRIPT
Ценность информационной архитектуры
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– Утверждение – жизненно-важный момент– ДО разработки!– Любо изменение меняет объем задач
Прототипы
• Утвердить основные шаблоны как можно раньше.
• Прежде, чем вносить изменения определить какого уровня изменения:– шаблон, – Страница– и т.д.
Спасибо за внимание
top related