Requirement Gathering at ZS
January 2022
Hypothesis
Requirements are currently a one-way
channel from client to PMs/ Design/ Dev
team
Confluence provides a single source for all
requirements!
But the documents can be made better.
• What if the customer does something that's
not documented? How do we design?
• I have a question that the PMs don’t have
answers to yet. How can I find them?
• How can I reduce the back and forth
discussions we keep having?
Challenge we face
We talked to designers in various teams
across SPM, Verso, Revo & IC to see if they
have access to everything they need to follow
a standard Design process.
• There is some uncertainty in requirements that increases
number of calls between PM & Designers
• I want to know about research findings & personas more.
Where can I find them?
• Handing over/ starting over is very difficult to a new
designer. They have a lot of questions & not everything is
in the documents
• How can I say what I design works? Acceptance criteria is
too broad for design
• Sometimes Discovery extends even after designs are
handed over
• I want to know more about the feature lead users
• Too much technical information and too little user
expectations
Existing
structure - IC
•
•
•
•
•
•
•
•
•
•
Objective
Background & Strategic Fit
Problem Statements
Market Research & competitor
Summary
User Personas
Business scenario
Assumptions
Requirements
Supporting Documents
Open questions
Existing
structure - Revo
• Executive Summary
• Mission statement
• Competitor Analysis
• User Personas
• Business scenario
• Assumptions
• Requirements
• Meeting Notes
Existing
structure Deployment
• Objective
• Background & Strategic Fit
• Problem Statements
• Market Research & competitor Summary
• User Personas
• Business scenario
• Assumptions
• Requirements
• Supporting Documents
• Open questions
Existing structure
Pros
Cons
• Flexibility for unique requirements
• Inconsistency across groups
• Gives a (possible) source of truth for all
designers/ Developers
• Not all required information for designers are
easily accessible
• Space to mark more requirements
• Prevents future handoff without enough
design context
• Delays release plan with multiple parallel
discussions
• Possibility of critical information being missed
out on
Ownership
Product mangers drive requirement gathering &
hands off them to Designers
Feedbacks Through
Reviews
Product Owners/ Managers
Design/Development
Suggested
Ownership
Designers CO-Create Confluence documents with
the Product Managers
Feedbacks Through
Reviews
Designers & Product Managers
Design/Development
What would we need?
Product Manager
•
•
•
•
•
•
•
•
•
•
Objective
Executive summary
Background & Strategic Fit
Market Research
Competitor Summary
Success Metrics
User Personas
User Journey Mapping
User interaction/ VD specific callouts
User research Findings
•
•
•
•
•
•
•
Use cases & Assumptions
Requirements
Tech Stack Limitations
Supporting Documents
Open questions
Meeting Notes
Road Maps
* Yellow : Co ownership between PM & Designer *Green : Designers Ownership
Proposed structure
Pros
Cons
• Closer collaboration between product & design
• Increased initial effort
• All design & business requirements are documented consistent
• Standardising quality across teams would be challenging
• Easier Handoff with single source of truth
• Easy discoverability
• Increased efficiency and reduced turnaround time
Expected Challenge
• Only 40% -45% PMs agree on the distinction between UX & PM,
as most of the roles & responsibilities overlap.
• But research has proved, collaboration between PM & UX can
validate requirements much earlier than post design validation.
• Only 9% PMs in the world believe communicating voice of the
customer needs any ux support
• Bringing the clear distinction between Ownership, Support and
clear roles/ responsibilities while improving collaboration will be
an organisational change that needs clarity, vision & time to
achieve maturity in