mtsdesign
Бренд МТСНаправленияДизайн-системаМетодологииГайдлайныКоманда и вакансииБлог
mtsdesign
Бренд МТСДизайн-системаМетодологииКоманда и вакансииБлог
НаправленияUX/UI продуктовый дизайнГрафический дизайнПромышленный дизайнИнтерьерный дизайн
behancetelegramvkyoutube
© 2025 ПАО «МТС»
Все права защищены
Политика обработка файлов cookie
18+

Дизайн-процесс

ВСЕ СТАТЬИДизайн-процесс

  • Знакомство
  • Руководство по дизайн-процессу
  • Паспорт продукта
  • Изучение
    • User flow
    • User story
    • Аналитика
  • Визуализация
  • Разработка
  • Ревью

User story

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

Формат написания:

Как <роль или тип пользователя>, я хочу/могу <выполнить действие или получить результат>, чтобы <получить ценность>.

  • Важно указывать ценность, потому что это дополнительная проверка на необходимость разработки, здравый смысл и инструмент для создания метрики.
  • К US нужно указывать критерии приемки.
  • Уровень абстракции определяется внутри команды.

Пример:

Как специалист ОЦОП, я хочу создать карточку кандидата, чтобы зафиксировать его данные и наполнить базу.

Критерии приемки:

  1. Возможность указать персональные данные кандидата.
  2. Возможность вставить скопированные ФИО.
  3. Возможность проверить карточку на дубликат.
  4. Возможность указать данные о вакансии.

 

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

Исчерпывающие руководства есть в интернете, например:

  • Та самая статья на Medium
  • User Story: пора применять правильно
  • Для увлекающихся – Use Case
  • Альтернативный подход – JTBD
Перейти в следующую статьюАналитика

поделиться

поделиться

    telegramvkodnoklassniki