Об авторе

Поиск по сайту:

GUI.ruПерепроектируйте это немедленно!

Проектировать взаимодействие это вам не орешки щелкать

Алексей Копылов
04.05.2007Алексей Копылов

Комментариев:

4

Проектирование от Microsoft. Современное состояние дел

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

На сайте лаборатории Microsoft Research можно насчитать около двадцати основных направлений исследований в области HCI с сотнями проектов внутри них. Компания решила получить лучших исследователей в обмен на раскрытие информации о том, что происходит внутри. Потратив совсем немного времени и усилий можно узнать, что для нас готовит Microsoft уже в ближайшем будущем. Не сказать, что конкуренты закрыты наглухо, например, у Google тоже есть ряд проектов под крылом Google Labs. Но все же, все же, другие ИТ-корпорации (пока) не столь прозрачны, как Microsoft, как это ни удивительно.

Но давайте перейдем к более конкретным вещам и поговорим о проектировании интерфейсов корпоративных продуктов.

Специфика корпоративных продуктов

При проектировании сложных корпоративных продуктов (класса CRM/ERP) проектировщики сталкиваются с рядом специфических сложностей. Рассмотрим их подробнее.

Универсальность корпоративных продуктов

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

Большое количество ролей и задач

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

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

Связь с другими программными продуктами

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

Груз унаследованного кода

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

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

Опыт Microsoft

Посмотрим, каким образом решаются вышеперечисленные проблемы компанией Microsoft. При написании данной части статьи были использованы материалы, которые компания Microsoft выложила в свободный доступ (DOC, 4.4М).

Груз унаследованного кода

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

То есть компания смело приняла решение ломать унаследованный интерфейс.

Связь с другими программными продуктами

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

Большое количество ролей и задач

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

  • Широко распространенное разбиение на отделы (и взаимодействие между ними);
  • Типичные процессы, происходящие внутри отделов;
  • Типичные сотрудники, работающие в данных отделах;
  • Типичные задачи сотрудников.

То есть исследователи произвели полную декомпозицию деятельности самых типичных компаний.

На выходе получилась диаграмма с описанием типовых предприятий (2 типа), их внутренней структуры (5 отделов), внутренних процессов (33) и работников (61). Работники представлены в виде персонажей.

Получается интересная такая картина (эту и последующие иллюстрации можно вынуть из документа Microsoft в более качественном виде).


Mодель потребителя MS Dynamics © Microsoft Corporation, 2007

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

Универсальность корпоративных продуктов

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

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


Декомпозиция структуры и синтез решений © Microsoft Corporation, 2007

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


Стартовая страница пользователя © Microsoft Corporation, 2007

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

Комментарии (4)

RSS feed for comments on this post | TrackBack URI

Артемий05.05.2007 17:32
2

спасибо, хорошая статья, позновательная

3

Александр, спасибо, недавно этот ролик обсуждали в жж комьюнити:
http://community.livejournal.com/ru_ucdesign/330221.html

SmartDevel06.10.2007 12:12
4

Почти все дела Microsoft Corporation как на ладони, автору спасибо!

Оставить комментарий