Downloaded 74 times
Uploaded byAndrea Neuhoff
UX in a Dual Track Agile World
The document discusses dual-track agile, which balances the exploration of new ideas and the delivery of releasable code within a scrum team. It emphasizes the importance of iterative testing and learning in the design process, encouraging designers to test assumptions rigorously. Key practices include A/B testing, prototyping, and a focus on user experience aligned with business goals.
More Related Content
Similar to UX in a Dual Track Agile World
UX in a Dual Track Agile World
- 1. UX in a Dual-Track Agile World Andrea Neuhoff @neuhoffa Senior UX Designer, Deepfield MWUX 2014
- 2. Kid in aKitchen
- 3.
- 4. Should you shareyour hunch?
- 5.
- 6. Goals • Understandbasics of dual-track agile • Role of UX • What to expect
- 7. What is agile? Iterative and incremental approach to software development
- 8. What is agile? Iterative and incremental approach to software development UX
- 9. What is DualTrack Agile? • Splits the work between exploring new ideas or improvements and building releasable code • One scrum team
- 10.
- 11. Dual-Track Agile DiscoveryTrack Delivery Track
- 12. Discovery Track What’sthe right think to build?
- 13. Driven by businessand user experience goals
- 14. Discovery Cycle Build Learn Measure
- 15.
- 16.
- 17. Design the smallesttest possible Ideas: ● A/B tests ● Live data prototype ● 404 Test ● Guerilla User Testing ● Paper Prototypes ● 404 Test ● 5 second tests
- 18. Design like you’reright. Test like you’re wrong. Jeff Patton
- 19.
- 20.
- 21.
- 22. Experiments and datado not make decisions. You do.
- 23. Be prepared questionthings you didn’t test.
- 24. Repeat and Iterate. Iterate Iterate Iterate
- 25. Dual-Track Agile DiscoveryTrack Delivery Track
- 26. Dual-Track Agile DiscoveryTrack Delivery Track
- 27. Dual-Track Agile DiscoveryTrack Delivery Track
- 28. Dual-Track Agile DiscoveryTrack Delivery Track
- 29. Thank you AndreaNeuhoff @neuhoffa andrea.neuhoff@gmail.com Senior UX Designer, Deepfield References and Resources Marty Cagan - Silicon Valley Product Group Jeff Patton - Agile Product Design Susan Weinschenk -100 Things Every Designer Should Know About People
- 30. What are youcooking up?
Editor's Notes
- #3 I’m like a little kid in the kitchen. Most of the time I ritually follow the recipes that I know, but sometimes I get a thought, a hunch.
- #4 Maybe should I combine my favorite foods to combine one super food! about a possible new take on an old recipe. What if I add arugula to my spaghetti and meatballs? What if I put another one of my favorite sauces on spaghetti, like cranberry sauce? What if I snack on dried ramen or bullion cubes? What if I added cocoa powder to my yogurt? I like hunches like these. It tells me brain is awake, its observing things, its learning, paying attention, and trying to create new things from that which I already know. For me it is never a question of whether or not I personally should follow try it out and see what the results are.
- #5 see what they personally like before making a large quantity. You might make a small bit and serve it to some friends or bring it to work for your coworkers.
- #6 It’s low stakes and no one’s big event or reputation is on the line. It’s an experiment and every one knows. Dual-Track Agile is a style of agile that translates this small amount of effort, low risk experimentation you might do in the kitchen for an agile environment. It gives the research and design processes we know so as user experience professionals a place in agile that allows us to do best what we do: design, research, and understand. It’s geared toward creating and improving software and websites . This talk is about how dual-track agile does this--how it translates this low risk need to experiment and explore potentially better experiences into an agile friendly environment
- #7 My goals: You can explain the basics of dual track agile to others How UX is a critical component and what is contributes What to expect if you take on dual-track? Aspirational: Spread some hope that UX can be a real, integral part of agile.
- #8 What is Dual-Track Agile ? Agile (not dual track) incremental and iterative approach to software development. work in short, defined periods of time (sprints) and the goal of each sprint is to release or complete releasable software. Might recommend defining what you mean by Dual Track Agile immediately after introducing this kitchen metaphor Where is UX in this process?
- #9 UX is often set apart. Rationale: You need to know what you’re building before you can build it.
- #10 Dual-Track is a style of agile that: splits the work building releasable software and exploring the what features to build during each sprint through continual and up front validated learning (test kitchen)…. Two simultaneously work streams (two different tracks) Still one agile team Super important. Involve your developers, your QA, your project manager, ….
- #11 Each track has a very different goal Delivery Track Generating releasable software or feature.
- #12 Discovery Track Discovering what makes the best user experience and quickly generating validated features to build or change. Upfront and continual validated learning (Validating features, validating assumptions, validating ideas.) to reduce the risk. This is about learning, not necessarily producing a feature at the end of each track. Still ONE TEAM that puts on two different hats.
- #13 Discovering what makes the best user experience and quickly generating validated features to build or change. Which to go back to the beginning of my talk is about working through hunches without blindly following or dismissing them completely. A way to acknowledge the potential in your* intuition** without dismissing them or completely buying in. * “Your” here includes your personal hunches, your co-workers ideas, your boss’ ideas, your ceo or president’s ideas, etc. ** Hunches/intuition are the product of observation, knowledge, research, and experience, which have not necessarily been put into explicit words or explicitly explained. Explore ideas from a user experience design and research perspective
- #14 Driven by Business goals and Key Performance Indicators (KPIs) (explicitly defined goals) that set by the organization or your team. Example: We want to increase content accesses by X% And remember: to figure out what releasable features should the team develop without wasting time on building unused releasable software. Why? This where we avoid building a product we think is good, but turns out not to meet user needs and business goals (KPIs )
- #15 The basic discovery cycle is akin to the lean startup method, which is described as build, measure, learn. You build something quick and dirty You measure what you build. You learn something. Repeat. You may run through this cycle a few times during a sprint, one time during a sprint, or have one particular idea that takes a couple of sprints. Reminder: Involve as many people as you can. You’re a team.
- #16 Hypothetical Situation: You’re tasked with redesigning or fixing the current search results page You need to get more to view a certain product or brand. How do you do it? How do you know your idea will move the needle ? And move it enough?
- #17 Build Pick an idea and figure out what hypothesis or assumption this idea is relying on. This is what you will test. Explicitly connect to your KPIs or scorecard. Design and implement the smallest possible experiment that will confirm or disprove your idea.
- #18 Different ways to test and not all of them involve coding (usually the most limited resource) A/B Test: Compare your current interface to a new one or different through hack implementation released to a small percentage of your traffic. Comparing the groups on a few KPIs. Paper prototype. Make a paper version and show it to users (at a usability test or through guerrilla user testing). Pro tip: Bring in the rest of your team. It’s great when your QA and dev people know more. They’ll catch some amazing things. Live data prototype in usability testing. 404 Test. Put a button out there and see if people click it. Five Second Tests (can users find the button).
- #20 Measure : Predict what you will see. What metrics will you use to measure whether or not your experiment is successful? What happened? What did the data show? What didn’t it show? How much data do you need? This is not your mother’s or your stat’s prof’s test. Statistical significance is nice, but that takes time and money.
- #21 Pro tip: Know your system. What is the baseline? How can you make any predictions if you don’t know what’s going on?
- #22 Learn: Analyze the data and communicate what you’ve learned to the team. Not all experiments will have quantitative information. For qualitative experiments, you will want to gather and analyze your information in other ways. If you’re interested in this, ask me at the end. You will learn things that are not always relevant to your experiment. Put those things in the opportunity backlog.
- #23 This hard for organizations that are trying to become more data literate/data driven.
- #24 Examples: like your metrics/kpi’s are good Discover other good ideas to build and iterate on…. Put those away for later
- #25 Repeat & Iterate: Needs to be seen in context as well. You won’t just run a discovery cycle and then pass the work on to the delivery track to build.
- #30 Conclusion: Like any agile software development, there are no hard and fast rules. You need to be adapt it to your team, your company’s culture, and each individual project. When I think of Dual-Track Agile this is what I take away: UX can fit into agile dev cycles, if you plan for it. Limit scope to make your experiments and learning more manageable (ie. more valuable).