Defining new product or service requirements is often treated as a tedious task to slog through so that the “real work” — design and development — may begin. But the largest market opportunities usually come from identifying an unmet need that others have overlooked, rather than simply improving interface design or tweaking features. How can we identify these unmet needs? By taking a step back and conducting a more meaningful process. This workshop will address the four high level areas necessary to build a solid base of requirements: business drivers, user needs, technology frameworks and environmental/social impact. We will work through how to ensure user needs are at the heart of your planning, how to craft requirements that can be flexibly adapted to an Agile process, and how to negotiate effectively with your other stakeholders. This is a hands-on, fast-paced workshop that will leave you with tangible tools that you can take back to your organization and share for maximum impact.
2. 2
WHY WE’RE ALL HERE TODAY
Agenda
1:30 Introductions
1:45 Expanding our thinking about requirements
2:45 Break
3:00 Priorities & themes
4:00 Break
4:15 Putting it into action
5:00 Q&A and wrap up
@sparks_kc #UXPA2021
3. 3
WHY WE’RE ALL HERE TODAY
What reaction do you have when you
hear someone talk about requirements
gathering?
@sparks_kc #UXPA2021
4. 4
WHY WE’RE ALL HERE TODAY
What is your organization’s process for
requirements gathering?
@sparks_kc #UXPA2021
Often, the process is:
• Gather a list of features that have been
discarded in the past, executive pet ideas,
and new competitive features
• Jump straight to documentation
• Little cross-disciplinary involvement
• No outside information gathering
5. 5
WHY WE’RE ALL HERE TODAY
Let’s re-think requirements gathering!
@sparks_kc #UXPA2021
6. 6
WHY WE’RE ALL HERE TODAY
Let’s re-think requirements gathering!
We tend to want to get requirements as quickly as
possible so we can get to design (or development),
where we think the magic happens.
@sparks_kc #UXPA2021
7. 7
WHY WE’RE ALL HERE TODAY
Let’s re-think requirements gathering!
But in reality, most of the insights that will
determine success happen during the
discovery/requirements phase.
“Make sure you are building The Right It
before you build it right.”
― Alberto Savoia, Google’s Innovation Agitator,
Author
@sparks_kc #UXPA2021
8. 8
WHY WE’RE ALL HERE TODAY
The BUTI of solid requirements
There are four high level areas we should
consider to build a solid base of requirements:
• Business drivers
• User needs
• Technology framework
• Impact
@sparks_kc #UXPA2021
9. 9
WHY WE’RE ALL HERE TODAY
The BUTI of solid requirements
“Teams that attain a shared understanding
are far more likely to get a great design than
teams who fail to develop a common
perception of the project’s goals and
outcome.”
― Jared Spool, Author and founding Principal of
of User Interface Engineering
@sparks_kc #UXPA2021
10. 10
WHY WE’RE ALL HERE TODAY
The BUTI of solid requirements
And that benefits from input from a diverse group
of people:
• Designers
• Engineers
• Researchers
• Marketing & Salespeople
• Operations
• Customer Service Reps
• Product Managers
@sparks_kc #UXPA2021
11. 11
THE BUTI OF SOLID REQUIREMENTS
Sources of Business Requirements
• Competitive analysis
• Industry trend stories, emergence of new
competition (including indirect)
• Financial analysis (growth, margins, pareto
analysis)
• Brand & marketing research surveys
• Sales & customer service requests &
complaints
• Social media sentiment analyses
@sparks_kc #UXPA2021
12. 12
THE BUTI OF SOLID REQUIREMENTS
Sources of User Requirements
• Sales & customer service requests &
complaints
• Social media sentiment analyses
• Product concept surveys & interviews
• Personas
@sparks_kc #UXPA2021
13. 13
THE BUTI OF SOLID REQUIREMENTS
Sources of Tech requirements:
• Existing tech stack
• Compatible integrations
• Planned upgrades
• Depth of Eng team skills
• User constraints
@sparks_kc #UXPA2021
14. 14
THE BUTI OF SOLID REQUIREMENTS
Impact Considerations
• L – Who are we Leaving out? (other abled,
economically disadvantaged, minorities)
• E - Environmental waste or destruction
• A - Potential for misuse by bad Actors
• V - Disproportionate impact on Vulnerable
populations (LGBTQ, domestic violence
victims, unhoused)
• E – Consequences of Extreme success on
users, communities, workers
@sparks_kc #UXPA2021
16. 16
THE EXERCISE
Farm2Me, a farm-to-table grocery app
@sparks_kc #UXPA2021
A consortium of small produce and dairy farmers
want to create a direct-to-consumer mobile app
that allows buyers to get access to their fresh,
organic specialty foods delivered regularly to
their door.
17. 17
THE EXERCISE
Some business insights
@sparks_kc #UXPA2021
• The most valued brand attributes include
connection to the source of food, quality, and
convenience.
• While this is not a low-cost service, it is not
meant to be exclusive either. We want to
connect more people to locally produced food.
• A new customer has to order at least three
times for us to break even on setup costs.
18. 18
THE EXERCISE
Persona: Sun, 41
• Busy investment professional.
• Married, mother of two children, ages 7 and 10.
• Good cook, but she often has to work late.
Cooks more on weekends.
• Willing to pay for convenience and high quality.
• Lives in a secure high rise building.
@sparks_kc #UXPA2021
19. 19
THE EXERCISE
Persona: Mickey, 26
• Chiropractic assistant.
• Single.
• Still learning how to cook for himself. Trying to
eat less meat, learn vegan options.
• On a budget.
• Shares a small house with two friends. They
occasionally cook group meals together.
@sparks_kc #UXPA2021
20. 20
THE EXERCISE
Persona: Jamal, 35
• Computer science instructor.
• Tends to eat a lot of frozen & deli meals.
• Comfortable financially. Really values speedy
delivery.
• In a long distance relationship, currently lives by
himself in an apartment. Often works late when
he teaches night classes.
@sparks_kc #UXPA2021
24. 24
ARTICULATING REQUIREMENTS
Refining requirements
Why you should avoid being overly
prescriptive during requirements:
• There are many possible solutions to any
problem
• Sprints are the best place to explore those
tradeoffs
@sparks_kc #UXPA2021
26. 26
ARTICULATING REQUIREMENTS
Exercise 2: revise requirements you drafted
Take 1 - 2 requirements that you drafted earlier
• Make sure the What & Why are clearly articulated
• Remove any reference to the How
• Outline several different solutions that would fulfill the requirement as
written
@sparks_kc #UXPA2021
30. 30
PRIORITIZATION
Feature prioritization
@sparks_kc #UXPA2021
This Prioritization Matrix was developed by LA agency Primitive Spark and should be credited when used. Find a sample at https://bit.ly/3gN6bFR
Feature Matrix Value (0-10) . Effort .
Grand Total
>>> Weighting >>> 8 4 7 10 7 1 5 5 1
>>> Column Heading >>> Sun Mickey Jamal Business Impact Value Total Build Maintain Effort Total
Support safe hygiene in delivery 9 6 9 9 10 319 6 4 50 269
Trace product origins 9 6 8 10 10 322 9 6 75 247
Specify personal preferences to get a more
custom-tailored delivery
8 6 10 7 6 270 4 5 45 225
Make allergen information readily available 9 6 3 8 10 267 5 5 50 217
Don't have to remember to order 8 4 8 8 6 258 3 6 45 213
Deliver goods to users’ homes when they are not
present to help them save time
10 4 10 6 7 275 7 8 75 200
31. 31
IN ACTION
Use themes to focus roadmaps & plan sprints
“A theme is a group of features tied together by
a simple, clear benefit, usually to the user.“
Focus on a small number (1 – 3) of overarching
themes oriented around solving customer
problems. Exclude distracting features that don’t
relate to the problem at hand.
@sparks_kc #UXPA2021
Reference articles by Bruce McCarthy & Jared Spool
32. 32
PRIORITIZATION
Feature prioritization
@sparks_kc #UXPA2021
This Prioritization Matrix was developed by LA agency Primitive Spark and should be credited when used. Find a sample at https://bit.ly/3gN6bFR
Theme
Feature Matrix Value (0-10) . Effort .
Grand
Total
Phase
>>> Weighting >>> 8 4 7 10 7 1 5 5 1
>>> Column Heading >>> Sun Mickey Jamal
Busines
s
Impact
Value
Total
Build Maintain
Effort
Total
Delivery Support safe hygiene in delivery 9 6 9 9 10 319 6 4 50 269 1
Safety Trace product origins 9 6 8 10 10 322 9 6 75 247 1
Delivery
Specify personal preferences to get a more custom-
tailored delivery
8 6 10 7 6 270 4 5 45 225 1
Safety Make allergen information readily available 9 6 3 8 10 267 5 5 50 217 1
Delivery Don't have to remember to order 8 4 8 8 6 258 3 6 45 213 1
Delivery
Deliver goods to users’ homes when they are not
present to help them save time
10 4 10 6 7 275 7 8 75 200
33. 33
IN ACTION
Key to success: learn how to say no
Complexity builds up inexorably over time
• Feature creep
• Competitive reactions
• Executive comments
@sparks_kc #UXPA2021
34. 34
IN ACTION
Some ways to say no (and not get fired)
Ways to keep your roadmap from getting unwieldy
• Use themes to enforce focus
• Let your users deliver the bad news
• Measure perceived complexity
• Regularly measure & report on features that are
rarely used
• Enforce a “feature swap” rule
@sparks_kc #UXPA2021
36. 36
IN ACTION
Bring it together
A typical inception/discovery process might
include:
• Background research
• Stakeholder interviews
• Customer research
• Creating a summary package
• One day workshop
@sparks_kc #UXPA2021
37. 37
IN ACTION
Making it Agile
• Continuously share & discuss relevant
external data
• Refine requirements together each sprint
• Validate along the way
@sparks_kc #UXPA2021
Requirements
Sprint planning
Design/Analysis
Implement/Test
Retro/Learn
38. 38
IN ACTION
Continuous validation techniques
Democratizing Research – leveraging other
team members to conduct routine usability
testing
Rolling Research – routinely scheduled
validation windows for each sprint
@sparks_kc #UXPA2021
41. 41
WHAT WE COVERED
Ticketmaster confidential. Do not distribute.
Take aways
• Think big and BUTI-ful! Consider business,
user, tech and impact based requirements
• Use personas to consider user needs in a
detailed way
• Don’t shortcut the creative process with
prescriptive requirements
• Prioritize objectively, group thematically
• Say no more often
• You can move more quickly with user
validation
@sparks_kc #UXPA2021
Introduce myself
Call out twitter info
Have others intro themselves: name, role, experience with requirements definition in their org
Review agenda, breaks, ground rules:
Cell off
Wear mask
Actively participate!
First of all, thank you to all who have joined me today to talk about requirements definition! You guys are either crazy or just insanely dedicated.
What are some words you associate with requirements gathering?
[ASK FOR INPUT]
We view RG as tedious, time consuming.
How long does it typically take at your company?
[ASK FOR INPUT]
And what do we usually do?
[ASK FOR INPUT]
Take a bunch of requests from management, look at what competitors are doing, add some backlog items, and throw it all into a spreadsheet or Jira, and say, “okay, here are the requirements.”
We tend to think of RG as the vegetables that we’re forced to eat before we can get to the dessert (i.e. design or development)
Flip your mindset – THIS is where the magic happens! This our chance to identify something really interesting that could change our business.
I was really struck by this quote when I first saw it, because it encapsulates what I have observed over the years. In an effort to move more quickly, companies end up instead chasing their tails and wasting time and resources. Moving more thoughtfully at the beginning of a project usually results in it proceeding more rapidly and efficiently later.
Jumping to design -- and certainly going straight to development -- too quickly eliminates the opportunity for expanding your POV, brainstorming, and identifying new opportunities. I can honestly say that I can predict how significant your product will be based on how you approach requirements gathering.
Note that I’m not talking about creating a huge amount of documentation here. I’m talking about seeking out information, reframing potential markets, and creatively exploring ideas with your colleagues. Also, let’s set the stage: we’re talking about new products or major releases/upgrades, the kind of project that typically runs at least 6 months to several years, not minor extensions of existing products & features.
So, what does it take to build the Right It? Looking at your business and your company through fresh eyes, in a comprehensive way.
So, what does it take to build the Right It? Looking at your business and your company through fresh eyes.
So, what does it take to build the Right It? Looking at your business and your company through fresh eyes.
So, what does it take to build the Right It? Looking at your business and your company through fresh eyes. Assess the business landscape the way that a strategist would. If you were building the business today, how would you approach it?
[Discuss each point, including Brand]]
Discuss different sources of user requirements in addition to personas
In this workshop we’re not going to spend much time on technical requirements -- that would require more time and a broader group of workshop participants. But understanding the constraints and direction that your tech stack is moving is important, and that’s one of many reasons why it’s valuable to include at least one Engineering lead in your requirements definition group from the start.
But remember that your competitors may not have the same legacy constraints that you have. Don’t make a tech constraint a requirement, it will guarantee that you fall behind.
This is the scenario we’re going to use for our activities today
This is the scenario we’re going to use for our activities today
Farm2Me has defined a couple of personas they wish to target: Sun and Mickey
Have one person each do Business & Impacts, Sun, Mickey & Jamal requirements. Stick with one color post its per person.
Do Impact & Tech as a group
Give 10 minutes for brainstorming, then 5 each for presenting and adding additional ideas.
For each consideration area, you’re going to brainstorm and add each idea as a sticky note. For example, if you are in the Business requirements group, what are the demographic trends impacting the industry? What requirements come to mind? For each one, put them on the small post its, and add them to your section of the board.
There are several dangers to being prescriptive in defining requirements. “Add to wallet” example.
The solution for achieving the how should be initiated in this phase as we assess high level difficulty, but can ultimately best be decided in sprint.
Discuss examples based on requirements so far that could be built in different was with vastly different levels of difficulty.
Pick 2 requirements that you drafted earlier. Rework them to be specific about the what & why, but not include the how.
Review as a group, refine further.
Should have at least 45 minutes by this slide
Once you’ve validated assumptions, you can prioritize
Discuss how to prioritize
https://docs.google.com/spreadsheets/d/1HGSkaqX9rTs7onEPlq-gsxgK09426AS1bR071bXuZ0c/edit?usp=sharing
Or short: https://bit.ly/3gN6bFR
Features to mention:
relative value weights
Alternative scoring systems
How the matrix works
Do a few as a group
Sort, then go to completed example
GROUP EXERCISE:
Prioritize features separately for each persona, and also for us as an organization (highest business value)
How do we help keep our internal users focused?
Bruce McCarthy suggests the use of product themes for roadmaps: http://www.productpowers.com/blog/roadmaps-focus-on-vision-benefits-not-features.html
Jared Spool article on Product Themes to maintain focus: https://articles.uie.com/themes/
If time allows, group into value themes
Can also use
Epics, User Stories
Kanban boards
We normally work from a spreadsheet with verbal descriptions of capabilities initially. We then prioritize these by user persona.
The final step before agreeing on the MVP for launch is to look at level of effort likely for each feature. At that point we will discuss specific ways that a feature might be implemented -- again, more conceptually than specifically. For example, “This might be a fairly challenging 1 month of development effort if it must be custom built, but if we can live with a simple plugin such as this one that’s available for purchase, it would require only a couple of days for integration and testing.”
Next get into the roadmapping or sprint planning process.
SHOULD HAVE AT LEAST 20 MINUTES LEFT AT THIS POINT
As Product Owners, we are constantly under siege with requests for new features.
Sales team sees a competitive feature, thinks we have to match it.
Execs get a random suggestion from their spouse or golf buddy.
A customer requested something, so we assume everyone would like that.
We still have leftover backlog items from a year ago.
However, these additions are almost never offset by a countervailing force to simplify things, so complexity accrues inevitably.
I was really struck by a comment made many years ago, during Nokia’s heyday as a mobile phone manufacturer. He stated that 85% of the Nokia phones that were returned “functioned as designed.” They were not defective in the sense that they didn’t work. They were simply unusable.
It’s important that we continuously reinforce the fact that there are costs to complexity.
Cognitive overload and the perception that something is not easy to use creates a barrier to user adoption.
Additional development time is multiplied many times over by maintenance time.
Increased training to use, customer service support, returns and non-renewals.
Jared Spool suggests forming all requirements in the form of testable hypotheses: https://articles.uie.com/requirements_gathering/
Should have at least 45 minutes by this slide
So, what does it take to build the Right It? Looking at your business and your company through fresh eyes.
So, what does it take to build the Right It? Looking at your business and your company through fresh eyes.
When we set about defining user requirements, we usually jump to asking them to confirm their interest in the features we think or hope that they want, rather than taking a step back and trying to understand their
Needs
Environment
Expectations
Obstacles to trying something new
Jared Spool suggests forming all requirements in the form of testable hypotheses: https://articles.uie.com/requirements_gathering/
Do you validate requirements with users? Surveys, interviews, card sorts?
Do any of you do routine rolling studies or iterative usability testing? What do you do?
What stands out for you about the conversation so far? Any insights or tools you can use?
Questions?
Ask for feedback
Offer up contact info.
Questions?
Ask for feedback
Offer up contact info.