Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Behavior-Driven Development for UX Teams

67 views

Published on

Software engineers have a big UX secret: over the last ten years, they've worked out an effective way to (1) describe a user's expectations of what a product should do and (2) ensure that they meet those expectations. Even better: they designed it for non-technical team members to participate as equals.

Maybe user stories are enough to guide your Agile team. Maybe you convey every detail through fully interactive prototypes. If not, it's time to learn about Behavior-Driven Development (BDD).

With BDD, a designer can take an ordinary UX scenario, add a touch of syntactic structure, and make it easier for a development team to understand, implement, and test:

Scenario: When a patient achieves a goal, do something special
- Given a patient care plan with a health goal defined
- When the patient views her care plan
- And the patient marks her health goal as achieved
- Then we should notify her care team of her success
- And display some celebratory confetti

In this workshop, we will take a real product feature from contextual scenario to behavioral scenario to automated test (in a live mobile browser)—and learn how to integrate the Behavior-Driven approach into a product design process.

Along the way, we'll address these topics:
- The basic syntax and best practices of behavioral scenarios
- Engaging a multidisciplinary team in the writing & review process
- Bringing order and reliability to sometimes-messy iterative development
- How developers use automated testing to bring your scenarios to life

In the end, participants should see how the Behavior-Driven approach improves product quality in both the short and long run and makes the entire team happier in the process.

Published in: Design
  • Be the first to comment

  • Be the first to like this

Behavior-Driven Development for UX Teams

  1. 1. BDD for UX Bridging the design/code chasm
 with Behavior Driven Development Jonathan Abbett · @jonabbett UXPA Boston Conference · 19 May 2017
  2. 2. Why are we here?
  3. 3. Why are we here?
  4. 4. 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
  5. 5. How do I know something is useful? How do I know something can be built?
  6. 6. Personas Scenarios Requirements User
 Stories Storyboards Prototypes Wireframes Sketches Mental
 Models Journey
 Maps Goals
  7. 7. Personas Scenarios Requirements User
 Stories Storyboards Prototypes Wireframes Sketches Mental
 Models Journey
 Maps Goals 1010101
  8. 8. ☐ 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
  9. 9. • user stories as requirements • user stories as the basis for acceptance testing
  10. 10. As an Account Holder
 I want to withdraw cash from an ATM
 So I can get money when the bank is closed
  11. 11. "I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test…”
  12. 12. "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."
  13. 13. 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
  14. 14. 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
  15. 15. GIVEN describe an assumption
 create the context WHEN perform an action in the interface THEN confirm the correct outcome
  16. 16. 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
  17. 17. ht: @kitt
  18. 18. IE Firefox Chrome Safari
  19. 19. ??? User
 Stories Acceptance Tests
  20. 20. Behavioral Scenarios User
 Stories Acceptance Tests
  21. 21. Research Goals Personas Context Scenarios Requirements
  22. 22. Research Goals Personas Context Scenarios Behavioral Scenarios User
 Stories Acceptance Tests
  23. 23. • 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
  24. 24. Pause Point Any questions so far?
  25. 25. How to
 BDD + UX
  26. 26. 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
  27. 27. 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.
  28. 28. 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.
  29. 29. 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.
  30. 30. 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.
  31. 31. What’s the goal? What’s its status? What’s our target?
  32. 32. 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
  33. 33. 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
  34. 34. GIVEN describe an assumption
 create the context WHEN perform an action in the interface THEN confirm the correct outcome
  35. 35. 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
  36. 36. 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
  37. 37. When she visits her care plan Navigate to the right screen in the interface
  38. 38. 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
  39. 39. When she chooses a goal status of 'achieved' Find the component for changing the goal’s status Select the new status of “achieved”
  40. 40. 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
  41. 41. ☑ 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
  42. 42. Pause Point Certainly someone has
 a question now.
  43. 43. Make it real.
  44. 44. 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
  45. 45. # 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
  46. 46. ☑ 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
  47. 47. Pause Point Anybody? Buehler?
  48. 48. Be inclusive.
  49. 49. • Who writes them? • Where will they be stored? • How will they be reviewed? • What to review? • What if things change?
  50. 50. 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
  51. 51. Where will they be stored? • Somewhere suited for collaboration? • Close to where context scenarios were written? • (Ultimately code base)
  52. 52. 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?
  53. 53. 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
  54. 54. 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
  55. 55. What if things change? • You will learn as you build. • You will learn as you test. • You will learn after you release.
  56. 56. Pause Point Last chance before end!
  57. 57. ☑ 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
  58. 58. • 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
  59. 59. @jonabbett jonathan@act.md
  60. 60. THANK YOU!
  61. 61. 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

×