2. Ситуация
• Вы приходите в большой проект с длинной и
запутанной историей
• Ваша задача — развивать его: готовить
интерфейсы новых сервисов, улучшать
существующие
• Организовать команду дизайнеров, которая
будет обладать видением развития
интерфейсов
• С чего начать?
8. Слои /
разделы и
сценарии
Моя
страница
Игры Группы...
Сценарий
загрузки
фото
Сценарий
оплаты
услуги
Сценарий
приглашени
я в друзья…
Иконки и
графика
Элементы
блоков
Блоки
Стили,
типографик
а
Типовые
страницы
Сетка
Подходим системно
9. Что занести в
таблицу
• Крупные куски сайта: разделы
• Основные сценарии, «больные» места
• То, что все менеджеры и дизайнеры
постоянно пытаются модифицировать
• Там, где больше хаоса
10. • В слоях интерфейса находятся группы паттернов
• Нужно выделить группы паттернов (например, сетки для
осн. страниц, для поп-ап слоев, для тулбарных страниц)
• В группе нужно выделить повторяющиеся паттерны и
исключения (например, «на двух страницах сетка
одинакова»)
• Потом нужно уменьшить число паттернов, отбрасывая
незначительные отклонения, не влияющие на сценарии
использования (например, на одной из страниц сетка
незначительно отличается, и приведение ее к единому
виду не повлияет на опыт человека)
• Нужно обосновать исключения и зафиксировать причины
необходимости в них
Многабукоф
11. Рисуем каждый слой на доске,
вместе обсуждаем, пользуемся
таблицей, чтобы ничего не забыть
13. Распределенное
знание
• Каждый дизайнер выбирает, каким слоем интерфейса ему интересно
заниматься
• В случае необходимости дизайнер может проконсультироваться у
коллеги по его специализации
• Рефакторинг основывается не на личном мнении руководителя, а на
рациональных доводах и общем видении
• Его центром становится документация, сборник гайдлайнов — Азбука
• Появляется парное проектирование, когда решение в одном слое
проверяется на жизнеспособность в других слоях
• Рисуются картинки с учетом всех текущих договоренностей - можно
в целом увидеть, как будет выглядеть конечный интерфейс, увидеть
чего не хватает
14. Заносим все в вики
• Структура документа основывается на
слоях интерфейса и группах паттернов
• Есть страничка с ответами на общие
вопросы и рекомендациями по
организации документа (составляется
всеми в процессе работы)
• В спеках есть статусы-бэджи,
описывающие актуальность документа
15. Как добить Азбуку?
• Еженедельные часовые встречи в формате Agile
Demo, все изменения обсуждаются всей командой
• Выделено время на работу над Азбукой —1/5
рабочего времени
• Спеки вне Азбуки линкуем на нее вместо
дублирования информации
• Если принято общее решение об изменении
какого-то паттерна, нужно обновить все страницы,
которых изменение касается, т.о. впервые
проверяется жизнеспособность решения
16. Что получаем в
итоге?
• Польза ощутилась на следующий день после
составления первых спек («О, точно, это уже есть в
Азбуке, а вот это туда точно надо занести!»)
• Область знаний каждого дизайнера распределяется на
весь проект в одном из слоев, а не только на
функциональную часть, которой он занимается
• Улучшаются коммуникации внутри команды
• Упрощается вход в команду новых сотрудников
• Становится понятно, в чем нужно повышать
квалификацию каждого конкретного дизайнера