Видео, Матчасть

Человеко-ориентированное проектирование сайтов

1 октября 2013 года состоялась кейс-конференция «Как мы делаем такие сайты», организованная аналитическим порталом рынка веб-разаработок CMSMagazine.

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

human centered design

Согласно этому подходу, проектировать следует в таком порядке:

  1. Стратегия дизайна
  2. Портрет потребителя (персонаж)
  3. Сценарий взаимодействия
  4. Прототип (макет)
  5. Проверка (тестирование) прототипа

При этом в стратегии дизайна следует рассмотреть, четко прояснить и зафиксировать следующие вещи:

  1. Цели
    Для чего это все делается?
  2. Целевая аудитория
    Для кого это делается?
  3. Маркетинг (откуда они узнают?)
    Какие каналы и способы привлечения внимания будут использоваться?
  4. KPI (показатели успеха)
    Количественные и качественные, отслеживаемые результаты работы сайта

Портрет потребителя формируется из:

  1. Профиль
    Возраст, пол, место проживания и т.д.
  2. Потребности (мотивы)
    Какие у него проблемы?
    К чему стремимся?
    Жизненная ситуация
  3. Цели (образ результата)
    Что ему нужно, чтобы решить проблему?
  4. Поведение
    Как он решает проблему без нас?
    Как выглядит его день (жизнь)?

Для разработке сценария взаимодействия необходимо

  1. Выписать шаги решения задачи при помощи сайта
    Что спрашивает потребитель?
    Что отвечает сервис (поставщик)?
  2. Думать о людях, а не сайтах!

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

Какие проблемы ждут потребителя?
Что может не хватать потребителю для получения услуги?

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

Любой жаждущий более подробных нюансов процесса человеко-ориентированного проектирования может углубится в ГОСТ Р ИСО 9241-210—2012 «ЭРГОНОМИКА ВЗАИМОДЕЙСТВИЯ ЧЕЛОВЕК—СИСТЕМА. Часть 210: Человеко-ориентированное проектирование интерактивных систем» (ISO 9241-210:2010 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems (IDT)).

***

Для всего мира отличным примером присутствия правительства в интернете являются госсайты Великобритании.

Благодаря специально созданной структуре Government Digital Service, в этой стране формируется и культивируется правильное взаимодействия человека и государства в цифровой среде. Чего только стоят разработанные этой командой принципы дизайна!

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

UPDATE: Сайт Минкомсвязи о планах по повышению качества жизни на 2012-2018 годы.

***

P.S. Бонус для самых терпеливых, для тех, кто смог осилить пост до конца. Собственно, само видео выступления Дмитрия Сатина, а также еще 11 докладов из секции Как мы делаем государственные сайты 🙂

Стандартный
Практика

3.12 Дополнительные сценарии

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

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

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

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

Если со сменой тарифа всем более-менее понятно, то бизнес-логику и ограничения бонусной программы компании «Сибирские Сети» стоит описать более подробно.

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

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

Дополнительные сценарии

Исходя из представленных ограничений, составим дополнительные сценарии:

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

17. Иван является активным пользователем пиринговой сети провайдера и регулярно получает приличное количество бонусов. Зайдя в биллинговую систему, он выбирает один из вариантов списания бонусов.

Иван предпочитает покупать ежемесячную скидку в 10% для своего тарифа. Система ежемесячно (перед списанием средств со счета) в автоматическом режиме списывает необходимое количество бонусов.

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

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

Люся тратит бонусы на розыгрыши и другие цели. Она не использует их как средство оплаты интернета.

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

Стандартный
Практика

3.10 Контекстные сценарии взаимодействия

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

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

У нас есть основной персонаж Иван и два дополнительных персонажа: Люся и Евгений. Создадим контекстные сценарии взаимодействия Ивана с биллинговой системой. После чего расширим их за счет шаблонов использования системы дополнительными персонажами, учитывая, что они имеют меньшее значение при вынесения решений по проектированию.

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

Контекстные сценарии использования

  1. Иван становится клиентом компании «Сибирские Сети». При заключении договора в офисе компании (или сдаче приемке монтажных работ у Ивана дома) сотрудники провайдера сообщают ему о существовании биллинговой системы и ее преимуществах.
  2. При подключении Иван вносит свой первый платеж на свой счет в биллинговой системе. Если его подключение попадает под действие какой-либо промо-акции, он не вносит деньги на счет и пользуется определенный период времени услугами провайдера бесплатно.
  3. Провайдер выдает Ивану некий ключ доступа к системе. Иван может поделиться этим ключем со своей семьей или друзьями напрямую или опосредованно, разрешая им доступ к системе.
  4. Находясь дома, Иван знакомится с системой, получая от нее контекстную полезную помощь для новичков. В процессе знакомства система осуществляет собственную настройку для работы с Иваном самым удобным и предпочтительным для него образом.
  5. Система предлагает настроить автоматическое списание средств с любого стороннего счета Ивана за услуги провайдера. Иван указывает параметры своей зарплатной карты. Евгений разрешает системе доступ к своему интернет-кошельку в платежных системах Яндекс.Деньги и WebMoney. Люся ничего не указывает, поскольку предпочитает платить наличными.
  6. Проходит определенный период использования услуг и наступает момент, когда баланс счета Ивана начинает приближается к нулю.
  7. Первым делом система пытается самостоятельно сделать платеж, пытаясь списать средства с банковской карты Ивана. Эту операцию она совершает заблаговременно, рассчитывая, что для конца оплаченного периода остается не менее 3 дней.
  8. Списываемая сумма зависит от тарифного плана и равна ежемесячному платежу. Платеж проходит успешно, и система оповещает Ивана о переводе денег.
  9. У Евгения эта операция не завершается успехом, поскольку ни на одном из его электронных кошельков, проверенных системой последовательно, не оказывается достаточной суммы денег для списания. Система оповещает Евгения о невозможности совершить автоматический платеж и ожидает от него дальнейших действий.
  10. Евгений очень занят делами и не успевает вовремя внести деньги на счет в биллинговой системе, в следствии чего интернет у него отключается. Заметив отсутствие связи поздно вечером, Евгений решает совершить обещанный платеж, чтобы внести требуемую сумму на следующий день. Он заходит на страницу биллинговой системы и совершает обещанный платеж.
  11. На следующий день Евгений пополняет свой счет в одном из интернет-кошельков, снова заходит на страницу биллинговой системы и гасит задолженность. Система принимает платеж и сообщает экранным сообщением, что все прошло успешно.
  12. Когда баланс Люси подходит к критической границе, она получает уведомление о том, что скоро интернет может быть отключен. При этом она также сообщает ей, что мультикасса, через которую Люся привыкла вносить деньги, временно не работает.
  13. Люся обращается к системе за информацией о текущем состоянии счета и за помощью в поиске альтернативных путей оплаты. Система предлагает Люсе другую ближайшую мультикассу, которая точно работает. Люся узнает адрес и совершает внесение средств при помощи предложенной точки отплаты. Сразу же после проведения платежа система уведомляет Люсю, что ее он совершен успешно.
  14. Однажды летом Иван решает поехать в отпуск на целый месяц. Он обращается к биллинговой системе и указывает срок своего отсутствия. В указанный период система переходит в режим ожидания и не производит списание средств, а доступ к услугам провайдера блокируется.
  15. Иван возвращается немного раньше, чем планировал. Он вновь обращается к системе и переводит ее в нормальный режим функционирования.

***

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

P.S. Если у тебя, мой дорогой читатель, есть замечания или дополнения к предложенным сценариям, смело пиши свои умные мысли в комментарии к этому посту.

Стандартный