Behavior-Driven Development for UX Teams
•
1 like•641 views
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.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Behavior-Driven Development for UX Teams
Similar to Behavior-Driven Development for UX Teams (20)
Recently uploaded
Recently uploaded (20)
Behavior-Driven Development for UX Teams
- 1. BDD for UX Bridging the design/code chasm with Behavior Driven Development Jonathan Abbett · @jonabbett UXPA Boston Conference · 19 May 2017
- 2. Why are we here?
- 4. Why are we here?
- 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
- 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
- 19. GIVEN describe an assumption create the context WHEN perform an action in the interface THEN confirm the correct outcome
- 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
- 21. ht: @kitt
- 28. • Persona tells us who (really well, in fact) • Activities in a scenario tell us what • Context in the scenario (from persona goals) tells us why
- 29. Pause Point Any questions so far?
- 30. How to BDD + UX
- 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.
- 37. What’s the goal? What’s its status? What’s our target?
- 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
- 40. GIVEN describe an assumption create the context WHEN perform an action in the interface THEN confirm the correct outcome
- 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
- 48. Pause Point Certainly someone has a question now.
- 49. Make it real.
- 51. Python Behave pythonhosted.org/behave Java JBehave jbehave.org Ruby on Rails Cucumber Spinach cukes.info codegram.github.io/spinach JavaScript Yadda github.com/acuminous/yadda .NET Specflow specflow.org PHP Behat behat.org
- 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
- 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
- 56. Be inclusive.
- 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?
- 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.
- 65. Pause Point Last chance before end!
- 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
- 69. THANK YOU!
- 70. Photo Credits • Grand Canyon: NNNN • Chasm: NNNN • Binary heart: https://www.neuronsnotincluded.com/products/linux-mouse-pad-for-geeks-nerds-and- scientists • Dan North: NNNN • XP process: NNNN • Automate all the things: NNNN • Alan Cooper: NNNN • “Vivian” Persona: https://www.flickr.com/photos/127713902@N07/34332189000