Темы  /  Лучшие практики

10 принципов проектирования портала электронных госуслуг

4 октября 2012
10 принципов проектирования портала электронных госуслуг

Что нужно учитывать, что бы создать успешный сайт электронных услуг? Своими рекомендациями и примерами на основе личного опыта делятся разработчики британского портала госуслуг GOV.UK.

 

1. Начинайте с потребностей пользователей,
а не государства

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

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

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

Легко собирать потребности пользователей помогают липкие листочки)Анализируйте потребности!

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

Будьте ясными!

Эта страница с информацией об НДС на товары и услуги — отличный пример дизайна, отражающего реальные потребности пользователей. Большинство пользователей попадут на эту страницу после поиска информации о размере НДС. Стандартный размер НДС для большинства товаров и услуг в Великобритании составляет 20 процентов, и эта информация специально выделена на странице. Поэтому пользователь может получить нужный ответ, лишь один раз взглянув на страницу.

Страница Data.gov с информацией об НДС на товары и услуги

Для некоторых услуг и товаров (а их явное меньшинство) НДС рассчитывается другим способом. Эта информация менее важна, и, соответственно, подается не на первом плане. Если пользователь случайно попал на страницу, в блоке, расположенном в правом верхнем углу, находятся ссылки, на сайты, которые могут оказаться полезными. Таким образом, страница оформлена просто и ясно, но содержит всю необходимую информацию.

 

2. Делайте меньше, но лучше

Государство должно заниматься только теми вещами, которые находятся в его компетенции. Если какая-то организация выполняет схожие функции, необходимо дать ссылку на ее сайт. Если можно представить ресурсы, которые могут помочь людям при реализации их планов (например, API), нужно сделать это. Повторимся, основная цель при разработке электронных услуг — сосредоточиться на ключевых потребностях.

Чтобы разработать самые эффективные и востребованные электронные услуги, а также сэкономить средства, необходимо сосредоточить все ресурсы там, где это принесет максимальную пользу.

Пример того, как сделать меньше, но лучше

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

Статьям про спасение пчел не место на госсайте

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

 

3. Проектирование с учетом поведения

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

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

Простой пример поведения пользователей

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

Пример для A/B-тестирование A/B-тестирование

Авторы проекта GOV.UK используют A/B тестирование, чтобы понять, как цвет может повлиять на поведение пользователей. В ближайшем будущем они планируют сообщить больше подробностей о том, как изучить поведение пользователей. Чтобы собрать информацию о пользователях, можно обратиться к Google Analytics.

 

4. Добиться простоты — тяжелый труд

Довольно легко сделать так, чтобы дизайн выглядел просто. Гораздо сложнее добиться простоты использования той или иной услуги. Особенно в случае, когда в основании дизайна лежит сложная система. Однако именно это является основной задачей веб-дизайнера.

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

Пример большой работы по упрощению

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

Расчет размер пособия по беременности и родам на основе вопросов

Рубрика GOV.UK «умный ответ» — хороший пример такой политики.

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

 

5. Используйте итеративный подход

Лучший способ для разработки эффективной услуги — это начать с небольшого приложения. Затем выпустить несколько обновлений, постоянно совершенствуя свой проект.

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

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

Примеры важности итераций

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

Выпускайте приложение и продолжайте тестирование

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

Итерации GOV.UK

Изучите конкретные примеры того, как исправляются баги и улучшается бета-версия сайта GOV.UK — 1 день после выпуска, 2 дня после выпуска. Смотрите также сайта INSIDE GOVERNMENT — результаты работы программистов над отзывами и предложениями спустя две недели после выпуска.

Alpha. Beta.

Авторы запустили альфа-версию сайта GOV.UK в 2011 году, и бета-версию в январе 2012 года. Остальные правительственные ведомства в стали извлекать уроки из их опыта и применять их при разработке приложений — смотрите, например, Shropshire WIP и DirectScot.

Альфа и бета GOV.UK, а также скришоты Shropshire WIP и DirectScot

 

6. Стремитесь к доступности

Хороший дизайн — это доступный дизайн. Необходимо выпустить такое приложение, которое было бы как можно более понятным, доступным, интересным. Совсем не страшно, если ради этого придется поступиться изяществом и стилем. Не нужно бояться объяснять вещи, которые кажутся вам очевидными. В то же время, не стоит заново изобретать условные обозначения, используемые в дизайне. Также нужно постараться быть начеку, чтобы своевременно улавливать ожидания публики.

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

Пример доступной информации

Эта таблица может служить прекрасным примером доступной подачи информации

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

Используйте ARIA

<header role=”banner”>

</header>

<nav role=”navigation”>
<ul>

</ul>
</nav>

<footer role=”contentinfo”>

</footer>

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

Поля форм и метки

<label for=”name”>Name:
<input type=”text” id=”name” placeholder=”For example John Smith”>
</label>

<label for=”yes”>
<input type=”radio” name=”citizen” id=”yes” value=”yes”>
Yes</label>
<label for=”no”>

<input type=”radio” name=”citizen” id=”no” value=”no”>
No</label>

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

Внутренние ссылки и скрытое содержание

<!— In HTML —>
<a href=”#content” class=”visuallyHidden”>Skip to content </a>

/* In CSS */
.visuallyHidden {
position: absolute;
left: -999em;
}

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

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

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

Продуманные ссылки

<a href=”guide.html”>Guide to maternity leave</a>

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

 

7. Подумайте над контекстом

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

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

Примеры учета контекста

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

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

Помните, что основная задача дизайна сайта е-услуг — не создание эстетически привлекательной страницы, но подача информации максимально доступным способом.

 

8. Создавайте электронные услуги, а не сайты

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

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

Пример использования контента GOV.UK на других сайтах

Удачным экспериментом того, как информация, предоставляемая авторами сайта GOV.UK, используется для решения актуальных задач, является плагин для WordPress, который был создан Солом Казенсом. Этот плагин позволяет выводить контент с сайта GOV.UK в любом посте или на любой странице частных сайтов на WordPress.

 

9. Будьте последовательным, но не однообразным

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

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

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

Пример последовательности, но не однообразности

На данный момент авторы GOV.UK уже выпустили бета-версии двух сайтов — GOV.UK и INSIDE GOVERNMENT. Смотрите ниже сравнение дизайна страницы двух этих проектов. Это хорошая иллюстрация того, что имеется в виду под выражением «необходимо быть последовательными».

Сравнение GOV.UK и INSIDE GOVERNMENT

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

 

10. Делайте код и элементы открытыми
и это сделает проект лучше

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

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

Дизайн

Авторы проекта GOV.UK предлагают изучить бета-версию сайта

Авторы проекта GOV.UK предлагают изучить бета-версию сайта, чтобы понять в действии принципы разработки дизайна, перечисленные выше.

Цветовая палитра

Для GOV.UK сознательно использовался широкий спектр цветов: сайт охватывает множество различных проблем, которые необходимо обозначать и выделять. Яркие и насыщенные цвета применяются, если нужно привлечь внимание пользователей к какой-то информации. Вы можете скачать палитру в формате Adobe Swatch Exchange, и затем импортировать ее в Photoshop или Illustrator. Также вы можете скачать палитру в формате pdf, чтобы копировать и вставлять цвета, которые вам нужны.

Шрифты

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

В течение следующих нескольких месяцев авторы GOV.UK планируют тестировать различные шрифтовые оформления своего сайта. В настоящий момент используется Gill Sans для заголовков статей и заголовков разделов. Он применяется в качестве «веб-шрифта»; это решение не лишено недостатков, поэтому шрифт используется аккуратно и от случая к случаю. Он добавляет свой шарм и, если правильно расположить интервалы, выглядит современно и по-британски.

Для основного текста используется Georgia. Этот шрифт является, на взгляд авторов проекта, одним из самых удобочитаемых. Кстати, этот стиль изобрел британец. Для всего остального применяется Helvetica (если он установлен у пользователей) или Arial. Полный список шрифтов и стилей смотрите выше.

Иконки

Для GOV.UK использовались эти иконки

Для GOV.UK использовались эти иконки.

Совместный код

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

Принципы разработки контента

Контент — это король сайта. Здесь вы можете прочитать о принципах и стиле наполнения GOV.UK контентом.

Алгоритмы транзакций

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

Больше информации в ближайшее время

Авторы проекта GOV.UK работают над широким спектром трансакций, чтобы создать список постоянно используемых в их практике шаблонов дизайна

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

Вещи, которых авторы проекта GOV.UK стремятся избегать

Авторы стремятся обеспечить максимальную доступность и ясность своих сообщений.

Авторы GOV.UK стремятся избегать метафор с лампочками, мозгами, пилой, леопардом, хамелеоном, бабочкой и т.п.

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

Оригинал: Government Digital Service Design Principles
Перевод Василия Наумова (Vasil Navumau) специально для e-gov.by

Мнения:

Метки

Книги