Сбор требований для разработки дизайна интерфейса кратко

Привет, Вы узнаете о том , что такое сбор требований для разработки дизайна интерфейса, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое сбор требований для разработки дизайна интерфейса, перечень функциональности, user stories, features , настоятельно рекомендую прочитать все из категории Дизайн программных UI и Web дизаин.

Видение проекта (vision)

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

Назначение

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

В каких процессах участвует документ?

• Проектирование и дизайн интерфейсов

  Пять этапов, в ходе которых происходит сбор требований к продукту, проектирование и дизайн его интерфейса.

• Юзабилити-консалтинг

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

Описание целевой аудитории (персонажи)

Описание целевой аудитории (персонажи) — это серия документов, которые дают представление о ключевых типах пользователей системы. Целевая аудитория продукта анализируется и группируется в 3–4 основных персонажа. Каждый персонаж характеризуется контекстом и целями ее использования системы, ожиданиями от нее, а также общим описанием.

Примеры документов

Назначение

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

В каких процессах участвует документ?

• Проектирование и дизайн интерфейсов

  Пять этапов, в ходе которых происходит сбор требований к продукту, проектирование и дизайн его интерфейса.

• Юзабилити-консалтинг

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

Сценарии взаимодействия, краткие и подробные

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

Сценарии взаимодействия пересекаются с перечнем функциональности (user stories). Разница в том, что первые помогают в понимании того, как работают функции и система в целом, а вторые — в точном учете требований. User stories говорят о том, что нужно сделать, а сценарии взаимодействия — как это работает.

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

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

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

Подробный сценарий взаимодействия (выдержка из основного пути сценария)

1. Пользователь нажимает на ссылку на профиль одного из пользователей.
2. Система открывает страницу, которая помимо прочего содержит следующие интерактивные элементы:
   1. Название ВУЗа пользователя (ссылка);
   2. Добавить в друзья (ссылка).
   3. Блок «Конспекты пользователя». Об этом говорит сайт https://intellect.icu . Блок состоит из списка элементов. Каждый элемент помимо прочего содержит следующие интерактивные элементы:
      1. Название конспекта (ссылка).
   4. Остальные конспекты (ссылка);
   5. Блок «Книжная полка пользователя». Блок состоит из списка элементов. Каждый элемент помимо прочего содержит следующие интерактивные элементы:
      1. Название книги (ссылка).
   6. Остальные книги (ссылка);
   7. Блок «Учебные планы пользователя». Блок состоит из списка элементов. Каждый элемент помимо прочего содержит следующие интерактивные элементы:
      1. Название учебного плана (ссылка).
   8. Остальные учебные планы (ссылка);
   9. Блок «Информация о пользователе». Блок помимо прочего содержит следующие интерактивные элементы:
      1. Имя пользователя (ссылка);
      2. Название ВУЗа пользователя (ссылка);
      3. Специальность пользователя (ссылка);
      4. Добавить в друзья (ссылка);
      5. Блок «Материалы пользователя». Блок помимо прочего содержит следующие интерактивные элементы:
         1. Конспекты (ссылка);
         2. Книжная полка (ссылка);
         3. Учебные планы (ссылка).
   10. Блок «ВУЗы и специальности». Блок помимо прочего содержит следующие интерактивные элементы:
       1. ВУЗы (ссылка);
       2. Специальности (ссылка);
       3. Города (ссылка);
       4. Пользователи (ссылка, заблокирована).
   11. Блок «Друзья пользователя». Блок помимо прочего содержит следующие интерактивные элементы:
       1. Список друзей. Список элементов. Каждый элемент помимо прочего содержит следующие интерактивные элементы:
          1. Имя пользователя (ссылка).
       2. Все друзья пользователя (ссылка).
   • Альтернативный сценарий: Пользователь уже находится в друзьях у пользователя. Система заменяет ссылки «Добавить в друзья» ссылками «Удалить из друзей». Перезагрузка страницы не производится.
3. Пользователь нажимает ссылку «Добавить в друзья».
   • Альтернативный сценарий: Пользователь нажимает на ссылку с названием ВУЗа пользователя. См.: “UC1-04 Yellow pages” — «Основной сценарий» шаг 6.
   • Альтернативный сценарий: Пользователь нажимает на одну из ссылок списка конспектов пользователя. См.: “UC1-02 Workbooks” — «Основной сценарий» шаг 6.
   • Альтернативный сценарий: Пользователь нажимает на ссылку «Остальные конспекты пользователя». См.: «Альтернативный сценарий» шаг 2.2.1.
   • Альтернативный сценарий: Пользователь нажимает на одну из ссылок блока «Книжная полка пользователя». См.: “UC01-01 Library” — «Основной сценарий» шаг 8.
   • Альтернативный сценарий: Пользователь нажимает на ссылку «Остальные книги пользователя». См.: «Альтернативный сценарий» шаг 2.2.2.
   • Альтернативный сценарий: Пользователь нажимает на одну из ссылок блока «Учебные планы пользователя». См.: “UC01-03 Learning plans” — «Основной сценарий» шаг 8.
   • Альтернативный сценарий: Пользователь нажимает на ссылку «Остальные учебные планы пользователя». См.: «Альтернативный сценарий» шаг 2.2.3.
   • Альтернативный сценарий: Пользователь нажимает на ссылку с именем пользователя. См.: «Основной сценарий» шаг 2.
   • Альтернативный сценарий: Пользователь нажимает на ссылку с названием специальности пользователя. См.: “UC1-03 Learning plans” — «Основной сценарий» шаг 4.
   • Альтернативный сценарий: Пользователь нажимает на ссылку «Конспекты» блока «Материалы пользователя». См.: «Альтернативный сценарий» шаг 2.2.1.
   • Альтернативный сценарий: Пользователь нажимает на ссылку «Книжная полка» блока «Материалы пользователя». См.: «Альтернативный сценарий» шаг 2.2.2.
   • Альтернативный сценарий: Пользователь нажимает на ссылку «Учебные планы» блока «Материалы пользователя». См.: «Альтернативный сценарий» шаг 2.2.3.
   • Альтернативный сценарий: Пользователь нажимает на ссылку «ВУЗы» меню раздела «ВУЗы и специальности». См.: “UC1-04 Yellow pages” — «Основной сценарий» шаг 4.
   • Альтернативный сценарий: Пользователь нажимает на ссылку «Специальности» меню раздела «ВУЗы и специальности». См.: “UC1-04 Yellow pages” — «Основной сценарий» шаг 8.
   • Альтернативный сценарий: Пользователь нажимает на ссылку «Города» меню раздела «ВУЗы и специальности». См.: “UC1-04 Yellow pages” — «Основной сценарий» шаг 12.
   • Альтернативный сценарий: Пользователь нажимает на одну из ссылок блока «Друзья пользователя». См.: «Основной сценарий» шаг 2.
   • Альтернативный сценарий: Пользователь нажимает на ссылку «Все друзья пользователя». См.: «Альтернативный сценарий» шаг 2.2.4.
   • Альтернативный сценарий: Пользователь нажимает на ссылку «Удалить из друзей». См.: «Альтернативный сценарий» шаг 2.2.5.
4. Система вносит изменения в базу данных.
5. Система добавляет выбранного пользователя в список друзей пользователя. Система выводит сообщение об успешной операции. Система отсылает пользователю уведомление о том, что он был добавлен в друзья. Перезагрузка страницы не производится.

Назначение

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

В каких процессах участвует документ?

• Проектирование и дизайн интерфейсов

  Пять этапов, в ходе которых происходит сбор требований к продукту, проектирование и дизайн его интерфейса.

• Юзабилити-консалтинг

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

перечень функциональности (user stories) (features)

Перечень функциональности (user stories) — это подробный список того что пользователь может делать в системе. Вся функциональность будущего продукта разбивается на простейшие возможности в виде «<кто> <что делает> <с чем>». Каждая из функций имеет приоритет, определяющий важность для общего успеха продукта. Кроме того, для функции описываются критерии приемки — реакция на действия пользователя, при которых она считается правильно работающей.

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

Назначение

• Точный сбор функциональных требований. Благодаря максимальной детализации все требования к системе учитываются и не забываются.
• Точная оценка сроков и стоимости проекта. Планирование и учет трудозатрат более точен, когда работа над функцией занимает часы, а не дни.
• Постановка заданий разработчикам. Реализовывать функции небольшими порциями проще.
• Помощь в управлении проектом. User stories — один из главных инструментов управления проектами по гибким методикам (agile). Эти методики дают более предсказуемый и качественный результат.

Спецификация

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

Примеры спецификаций

Назначение

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

В каких процессах участвует документ?

• Проектирование и дизайн интерфейсов

  Пять этапов, в ходе которых происходит сбор требований к продукту, проектирование и дизайн его интерфейса.

Вау!! 😲 Ты еще не читал? Это зря!

• техническое задание , спецификация задания , бриф , тз ,

Выводы из данной статьи про сбор требований для разработки дизайна интерфейса указывают на необходимость использования современных методов для оптимизации любых систем. Надеюсь, что теперь ты понял что такое сбор требований для разработки дизайна интерфейса, перечень функциональности, user stories, features и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Дизайн программных UI и Web дизаин