Фундамент требований: от догадок к общему языку
Чтобы команда проектировала платформу от пользователя, а не от интуиции, я собрал фундамент: целевую аудиторию, архетипы, User Stories и сквозные сценарии. Получилась единая карта, по которой работают дизайн, фронт и бэк.
// о проекте
Студия 3DaVinci, где я работаю аналитиком и UX-дизайнером, занимается автоматизацией оптовых продаж с помощью продукта B2B Движение: оптовой компании предлагается сделать собственный B2B-маркетплейс. Компания сотрудничает с большим спектром отраслей: электротехника, сантехника, FMCG, стройматериалы, мебельное производство, сетевая инфраструктура. Это продолжение кейса «Из утилиты — в платформу»: после инсайта идею нужно было превратить в то, что можно проектировать и разрабатывать, — иначе каждый в команде понимал «платформу» по-своему.
// проблема
Требования жили в головах. Проектировали по интуиции, разработка догадывалась, спорили на словах. Не было общего языка, на котором можно точно описать, что именно мы строим.
- B2B-покупатель — не один человек: регулярный закупщик, проектный и инициатор работают по-разному.
- Одни и те же экраны обслуживают и покупателей, и администраторов с совершенно разными задачами.
- Без зафиксированных приоритетов нельзя было решить, что делать в первую очередь, а что подождёт.
// как я подходил к задаче
Описал, кто наши пользователи
Разложил аудиторию на 7 функциональных архетипов: закупщик, проектный покупатель и инициатор — на стороне покупки; оператор каталога, контент-админ, админ бизнеса и «случайный» админ — на стороне управления. У каждого — своя главная потребность.
Перевёл потребности в User Stories
Собрал 79 историй в формате «как [роль], я хочу [действие], чтобы [ценность]» и проставил приоритеты P0–P2. Сразу стало видно, что критично для сделки, а что желательно.
Дописал сквозные сценарии
На каждую ключевую историю — User Case с шагами и реакцией системы, включая альтернативные ветки: товар снят, остатка не хватает, промокод не сработал. 24 сценария, которые ловят боль ещё до релиза.
Связал всё ссылками
Архетип → User Story → User Case, всё перелинковано. Любой в команде проходит цепочку и понимает, откуда взялось требование и зачем оно нужно.
// результат
в головах
для всей команды
Споры «а как правильно» превратились в ссылку на документ.
Любое требование можно пройти по цепочке до его источника.
UX-принципы и UI-архитектура интерфейса держатся на фундаменте: кто пользователь, чего он хочет и насколько это важно. Когда фундамент описан, споры «а как правильно» превращаются в ссылку на документ. На этом фундаменте выросли и принципы продукта, и весь редизайн навигации.