The document discusses using Behavior Driven Development (BDD) to bridge the gap between design and development. It begins by establishing the goals of understanding user needs and technical constraints. Common UX artifacts like personas, scenarios, and user stories are presented as a way to specify requirements. The document then introduces BDD as a way to write user stories and acceptance tests in a natural language format. An example is provided to demonstrate how to structure BDD tests around a persona and scenario. Benefits of the BDD approach include reducing ambiguity and improving engagement between teams. The presentation argues that BDD can help validate the user experience over the long term by keeping design and development in sync.
5. We want to design
useful things that
are possible to build
• Understanding users’ desires,
needs, motivations, and contexts
• Understanding business, technical,
and domain opportunities,
requirements, and constraints
• Using this knowledge as a
foundation for plans to create
products whose form, content, and
behavior is useful, usable, and
desirable, as well as
economically viable and
technically feasible.
—Cooper, About Face 3
6. How do I know something is useful?
How do I know something can be built?
11. ☐ Decrease ambiguity
☐ Increase dev focus on users & goals
☐ Improve quality
☐ Guarantee UX for the long term
☐ Engage more of team in the design/dev process
12.
13. • user stories as requirements
• user stories as the basis for acceptance testing
14. As an Account Holder
I want to withdraw cash from an ATM
So I can get money when the bank is closed
15. "I kept coming across the same confusion
and misunderstandings. Programmers
wanted to know where to start, what to
test and what not to test…”
16. "If we could develop a consistent
vocabulary for analysts, testers,
developers, and the business, then we
would be well on the way to eliminating
some of the ambiguity and
miscommunication that occur when
technical people talk to business people."
17. FEATURE: Account Holder withdraws cash
Scenario: Account has sufficient funds
Scenario: Account has insufficient funds
Scenario: Card has been disabled
Scenario: The ATM has insufficient funds
18. FEATURE: Account Holder withdraws cash
Scenario: Account has sufficient funds
Given the account balance is $100
And the card is valid
And the machine contains enough money
When the Account Holder requests $20
Then the ATM should dispense $20
And the account balance should be $80
And the card should be returned
20. FEATURE: Account Holder withdraws cash
Scenario: Account has sufficient funds
Given the account balance is $100
And the card is valid
And the machine contains enough money
When the Account Holder requests $20
Then the ATM should dispense $20
And the account balance should be $80
And the card should be returned
32. 1. Start with a persona & context scenario
(and usually a wireframe or prototype)
2. Name your feature
3. Name your behavioral scenarios
4. When you write steps, maintain texture
33. Vivian is a chronic care patient
whose goal is to keep active in her
family, her work, and her community
while keeping her disease under
control.
It's easy for her to get discouraged
when permanent relief from her
symptoms is unlikely.
34. Once Vivian was diagnosed with Type 2 diabetes, she
and her endocrinologist set a goal in her care plan
to get her hemoglobin A1c under 7% after 3 months.
To do that, Vivian must carefully monitor her blood
glucose.
35. She logs into her care plan each week and marks
whether her goal is on-track or off-track.
Her endocrinologist gets notified and reaches out
with encouragement or advice as necessary.
36. Finally, Vivian can report that she's met her HbA1c
target. She visits her care plan, and marks her
HbA1c goal as achieved.
The system notifies her care team of the
achievement, and Vivian is delighted to see confetti
fill the background of her screen, after so many
weeks of hard work.
38. MANAGING A CARE GOAL
Requirements
• Set a due date on a goal
• Mark a goal as on track
• Mark a goal as off track
• Mark a goal as achieved
• Notify team members when a goal’s status changes
39. Feature: MANAGING A CARE GOAL
Requirements Scenarios
• Set a due date on a goal
• Mark a goal as on track
• Mark a goal as off track
• Mark a goal as achieved
• Notify team members when a goal’s status changes
41. Feature: MANAGING A CARE GOAL
Scenario: Mark a goal as achieved
Given Vivian is a patient with a goal in her care plan
When she visits her care plan
Then she sees her goal displayed within it
When she chooses a goal status of 'achieved'
Then she now sees her goal has a status of 'achieved'
And the system notifies her care team of her success
And she sees celebratory confetti, which makes her smile
42. Given Vivian is a patient with a goal in her
care plan
Create a patient
Create a care plan for the patient
Create a goal within the care plan
Create another care team member to be notified
Log me in as the patient
43. When she visits her care plan
Navigate to the right screen in the interface
44. Then she sees her goal displayed within it
Confirm that the goal we set up in the ‘Given’
step appears on the screen before we continue
45. When she chooses a goal status of 'achieved'
Find the component for changing the goal’s status
Select the new status of “achieved”
46. Then she now sees her goal has a status of
'achieved'
Now that we’ve made the change, confirm we can
see that our change is reflected in the interface
47. ☑ Decrease ambiguity
☑ Increase dev focus on users & goals
☐ Improve quality
☐ Guarantee UX for the long term
☐ Engage more of team in the design/dev process
52. # Fill in a form field
fill_in 'Name', with: 'Brady Doverspike'
# Find something by its CSS selector and click it
find('.selector').click
# Check a checkbox/radio
check('I agree')
# Click a button by its name
click_button('Submit')
# Check if the page shows some text
has_text?('Order prescription')
# Confirm the page doesn't show some text
has_no_text?('Should not see this')
# Confirm the page has some link
has_link?('Log Out')
# CAPYBARA SYNTAX
53.
54. ☑ Decrease ambiguity
☑ Increase dev focus on users & goals
☑ Improve quality
☑ Guarantee UX for the long term
☐ Engage more of team in the design/dev process
57. • Who writes them?
• Where will they be stored?
• How will they be reviewed?
• What to review?
• What if things change?
58. Who writes them?
• Synthesis-by-receiver confirms understanding
• Draws out ambiguities sooner
• Starts transition from design to implementation
• Writing gives sense of ownership
• Collaboration vs. throwing over wall
59. Where will they be stored?
• Somewhere suited for collaboration?
• Close to where context scenarios were written?
• (Ultimately code base)
60. How will they be reviewed?
• Depends on your process.
• Right point for a broad stakeholder review?
• Sales, Accounts, Customer Support, etc.
• One-on-one iteration?
• Is your team co-located or remote?
61.
62. What to review?
• Feature fully covers context scenario
• Each scenario focuses on single activity
• Givens define just enough context, not more
• Whens are not so implementation-specific
• Thens reflect persona’s goals & challenges
• Identify “non-functional” requirements
63. Feature: MANAGING A CARE GOAL
Scenario: Mark a goal as achieved
Given Vivian is a patient with a goal in her care plan
When she visits her care plan
Then she sees her goal displayed within it
When she chooses a goal status of 'achieved'
Then she now sees her goal has a status of 'achieved'
And the system notifies her care team of her success
And she sees celebratory confetti, which makes her smile
64. What if things change?
• You will learn as you build.
• You will learn as you test.
• You will learn after you release.
66. ☑ Decrease ambiguity
☑ Increase dev focus on users & goals
☑ Improve quality
☑ Guarantee UX for the long term
☑ Engage more of team in the design/dev process
67. • Natural language descriptions of functionality
• Easy for non-developers to write, update
• Collaborate through existing tools
• BDD frameworks available in every language
• Cloud services for scalable cross-browser testing
• Stays in sync and validates UX over time