Проектированиеинтернет-систем

© 2013 Интернет-агентство Redsoft Москва, ул Расплетина, 24+7 (495) 518 4067info@redsoft.ru

Суть проектирования

1. Мы делим пользователей на группы и пишем сценарии, которые приводят их к запланированной цели, например, к покупке. Сценарии помогают определить структуру сайта и написать правильный контент.

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

3. По сценариям и прототипам создается техническое описание системы (упрощенная форма Технического задания)

1. СБОР ИНФОРМАЦИИ И СОЗДАНИЕ КОНЦЕПЦИИ

● Целевая аудитория (социально-демографические, психологические характеристики и

географическое положение)

● Конкуренты: прямые и непрямые, зарубежные аналоги (список и SWOT-анализ)

● Цели и задачи сайта и цели бизнеса (SMART)

● Пожелания и требования клиента к сайту (дизайн, структура и информация, функционал,

администрирование, CMS, технологии, платформы, верстка, интеграция с системами,

языки и т.п.)

● Какие имеются материалы, кто их готовит и когда будут готовы (если еще нет)

● Кто отвечает за проект со стороны клиента, кто принимает финальное решение (ЛПР) со

стороны клиента

1.1. Сбор требований клиента, видение проекта

● Определить УТП клиента

● Выводы из анализа конкурентов (возможности на рынке, извлеченные идеи и т.д.)

● Определить недостатки и достоинства сайтов конкурентов● Определить недостатки и достоинства существующего сайта (если есть сайт)

● Найти зарубежные аналоги сайтов

● Анализ ЦА- мотивы (потребность),

- ожидания от использования,

- цели,

- область знания.

1.2. Анализ сайта и бизнеса клиента и конкурентов

1.3. Создание концепции (на основе пп. 1.1, 1.2)

● Конкуренты в России / регионе

● Выявленные проблемы сайтов конкурентов

● Основные проблемы текущего сайта клиента

Концепция сайта:● Цели и задачи сайта

● Целевая аудитория

● Цели пользователей

● Описание концепции: "<Название продукта/проекта> это <категория продукта> для <целевая

аудитория> который <основная задача> посредством <уникальность>"

Наше предложение:● Основные принципы сайта

● Главная страница: концепция и структура, примеры дизайна

● Посадочная страница (карточка товара, каталог и т.п.), примеры посадочной страницы

● Карта сайта (предварительная)

● Стоимость и сроки

● Будущее развитие

2. ПРЕДПРОЕКТНЫЙ АНАЛИЗ

2.1. Персонажи и User Stories

● Создать описания персонажей (ключевые представители основных групп ЦА)- имя и фотография,

- цели,

- социальное положение,

- уровень подготовки,

- описание условий взаимодействия с сайтом,

- цели и проблемы

● Составить User Stories - карточки со списками или таблицу "Цель - Проблема - Решение"- Выписать цели пользователей (из карточек персонажей)

- Определить проблемы пользователей

- Решение проблемы (определить что необходимо для решения проблемы - информация, функционал и т.п.)

● Расставить приоритеты по пользователям и их целям

● Отобрать пользователей, наиболее важных для проекта.

2.1.1. Описание персонажа: пример

Проект: электронная библиотека

Проект: социальная сеть владельцев домашних животных

2.1.2. User stories: Задача-Проблема-Решение

Проект: социальная сеть владельцев домашних животных.

Цель: выбрать пса

Проблема: Почти ничего не знает о собаках, не знает что именно хочет

Сценарий: заходит на главную страницу, - находит раздел Зоопедия, - переходит на главную страницу раздела с рубрикатором по животным и породам, а также специальным разделом с общей информацией, - переходит в раздел с общей информацией, где на видном месте есть ссылка на статью о выборе животного, - переходит в статью и читает её, в конце статьи видит блок «Читайте также», в котором видит еще несколько статей с более углубленной информацией, - делает предварительный выбор из 3х пород собак, - переходит на главную Зоопедии и открывает страницы с подробной информацией о выбранных породах, на каждой из страниц он видит ссылки на продавцов этой породы, окончательно определяется с выбором и - переходит в магазин.

При написании этого сценария были придуманы идеи: рубрикатор в Зоопедии, блок «Читайте также», ссылки на продавцов со страницы определенной породы.

2.1.3. User stories: Пример

2.2. Карта функционала и список функционала

● На основе user stories создается карта функционала по разделам, со связями, с учетом

статуса пользователя

● Список функционала составляется для разработчиков

2.3. Карта сайта

● На основе карты функционала создается детальная карта сайта (схема всех разделов)

Качественный предпроектный анализ – гарантия того, что сайт будет сделан именно для целевой аудитории (ЦА), под её потребности, а не так, как придумает разработчик/клиент.

2. Результаты

Набор документов:● Документ с карточками персонажей● User Stories● Карта функционала● Список функционала● Карта сайта

3. СОЗДАНИЕ ПРОТОТИПОВ

● Начать с прототипа посадочной страницы (карточка товара, страница статьи и т.п. - не всегда с главной)

● Согласовать с клиентом первую созданную страницу

● Прототипы главного меню

● Прототип шапки сайта

● Прототипы меняющихся блоков (contextual areas)

● Протестировать прототип по пользовательским сценариям

3. Создание прототипов

Прототип: Экскурсии (Получилось: Дизайн / Сайт )Прототип: Гардарики (Получилось: Дизайн / Сайт )Прототип: ARD (Получилось: Дизайн / Сайт )Прототип: Мобильное приложение

Результаты Примеры прототипов

4. ТЕСТИРОВАНИЕ ПРОТОТИПОВ

● Провести тестирование прототипа на пользователях из ЦА

● Опросить респондентов - что они думают о сайте в целом

● Определить как решить возникшие у респондентов проблемы

● Рассчитать трудоемкость для решения наиболее важных задач

● Внести изменения в прототип

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

Результаты

4. Тестирование прототипов на пользователях

5. ТЕХНИЧЕСКОЕ ОПИСАНИЕ

Техническое описание должно включать:

● Результаты всех предыдущих этапов

● Описание функционала для каждого прототипа

● Информация о технических требованиях к системе

Техническое описание отличается от традиционного технического задания:

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

● содержит больше информации КАК будет сделана система, а не требования к ее работе

Формат документа - PDF Объем - в среднем от 100 до 300 страниц + приложения

5. Техническое описание

1. Глоссарий

2. Общие положения3. Предмет разработки, назначение и цели создания системы4. Требования к дизайну

a. Порядок утверждения дизайн-концепции

5. Бизнес-требования a. Карта сайтаb. Пользователи и сценарии работы с системой

6. Функциональные требованияa. Требования к представлению сайта (функциональная карта, прототипы и описание функционала)b. Требования к системе управления сайтом (структура CMS и способ доступа)c. Требования к разделению доступа (Роли пользователей, их права в системе)d. Требования к видам обеспечения

■ Требования к информационному обеспечению

■ Требования к программному обеспечению

■ Требования к техническому обеспечению

■ Требования к лингвистическому обеспечению

e. Требования к эргономике и технической эстетикеf. Требования к приемке-сдаче проекта

g. Требования к наполнению информациейh. Требования к персоналу

7. Порядок предоставления дистрибутива8. Порядок переноса сайта на технические средства заказчика

5. Структура технического описания

В техническом описании регистрируются как бизнес-требования к системе, так и функциональные требования:

● Бизнес-требования представляют собой описание того, ЧТО должна делать система на языке бизнес-

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

подготовки и опыта.

● Функциональные требования представляют собой описание того, КАК те или иные действия осуществляются в

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

наиболее сложных блоков проекта. Углубление в сложные зоны позволяет снизить риски при последующей оценке

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

диаграммы, и дополняются макетами наиболее сложных экранов.

Пример бизнес-требования:

«Для рекламной кампании важно максимально точно отслеживать лимит показов, чтобы избежать финансовых потерь,

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

баннера одному пользователю, например - не больше N раз в день».

Пример функционального требования:

«Для решения этой задачи предполагается использовать внешний сервис, к которому сервера статистики

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

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

5. Структура технического описания

Спасибо за то, что вы с нами!

© 2013 Интернет-агентство Redsoft Москва, ул Расплетина, 24+7 (495) 518 4067info@redsoft.ru