Defeating Babel: 4 Strategies for Better Design Communication in Agile
•Descargar como PPTX, PDF•
4 recomendaciones•3,009 vistas
User experience can make or break new products, and revitalize or kill existing products. Having skilled designers and developers is a start, but they don't naturally speak the same language, which can impede your team's value delivery. Using examples from research and industry, as well as experiences from my own and others’ work with Agile teams, this session delivers strategies and specific techniques that designers, developers, and product owners can apply to build more powerful design communication across disciplines. This presentation is organized around four proven strategies: - Drive priority discussions around value - Speak a shared language of Agile development - Show possibilities, don’t debate principles - Tailor artifacts to meet your teams’ needs
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Defeating Babel: 4 Strategies for Better Design Communication in Agile
Similar a Defeating Babel: 4 Strategies for Better Design Communication in Agile (20)
Último
Último (20)
Defeating Babel: 4 Strategies for Better Design Communication in Agile
- 1. Defeating Babel Four Strategies for Better Design Communication in Agile Jim Carlsen-Landy Director, User Experience Design CA Technologies jim.carlsenlandy@gmail.com Big Design 2015 #bigd15 @JimCL42
- 2. What’s this about? Is intro to or critique of Agile how to reduce or eliminate design details of specific design or coding methods all the answers the only answer Is working better across functional roles applicable to developers, designers, product owners, QA, and managers better communication about design and development during the process
- 3. For the attention span impaired Drive priority discussions around value Speak a shared language of Agile development Show the possibilities, don’t debate principles Tailor artifacts to meet your teams’ needs
- 4. Who am I? How did I get here?
- 5. Who am I? How did I get here?
- 6. Who am I? How did I get here?
- 7. …and you are? Designer Developer Scrum Master Product Owner Quality Engineer Product Manager Team Manager Project Manager You are part of a product team. Your actions and your decisions affect your product. Therefore you are a product designer.
- 8. Why is communication a problem? Design is different from development Years of waterfall thinking have created silos By-the-book Agile is very development-centric Our teams and leaders have different concerns Humans crawl into their comfort zone under pressure Professionals use the secret language of their craft to reinforce their authority and value
- 9. The secret to better communication It depends. Every team, every project, and every organization is different.
- 10. Four things you can do Drive priority discussions around value Speak a shared language of Agile development Show the possibilities, don’t debate principles Tailor artifacts to meet your teams’ needs
- 11. Four things you can do Drive priority discussions around value Speak a shared language of Agile development Show the possibilities, don’t debate principles Tailor artifacts to meet your teams’ needs
- 12. Agile value
- 13. Agile value Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- 14. Value = Priority = What gets done Q: Who decides priority in your sprints? A: Your product owner. Make them your friend. Help them understand the value of a great user experience.
- 15. Value = Priority = What gets done Q: Who decides priority in your sprints? A: Your product owner. Make them your friend. Help them understand the value of a great user experience.
- 17. Different concerns, one goal Developer •Efficient •Maintainable •Implementable Designer •Usable •Modern •Branded Product Owner •Customer needs •Utilitarian •Business ROI DELIVER VALUE
- 18. Usability adds value (the simple version) A feature that cannot be used prevents the user from performing the intended task. If the user is unable to perform the intended task, that feature delivers less (or zero) value. An attribute of the product that interferes with or reduces the value delivered is a defect. Therefore, an unusable feature is a defect. QED
- 19. For your users Efficiency, accuracy, consistency Trust & acceptance Better tolerance for bugs Stay competitive and profitable User-centered design adds value
- 20. For your users Efficiency, accuracy, consistency Trust & acceptance Better tolerance for bugs Stay competitive and profitable User-centered design adds value For your business Reduced support calls Reduced training costs Fewer product returns and more renewals Differentiate in the market Avoid lawsuits
- 21. User-centered design reduces risk Paul Sherman, “Decision Insurance: Iterative Prototyping to Reduce Business Risk”
- 22. User-centered design reduces risk Paul Sherman, “Decision Insurance: Iterative Prototyping to Reduce Business Risk”
- 23. Presentation adds value Edward Tufte, Visual Explanations, 1997
- 24. Presentation adds value Edward Tufte, Visual Explanations, 1997
- 25. Presentation adds value Edward Tufte, Visual Explanations, 1997
- 26. Features aren’t enough anymore Sunday Monday Thanks, Jeremy Johnson!
- 27. Don’t take my word for it Autodesk: “experience design contributes 36% to 40% to motivating users to recommend our product.” That’s NPS for you marketing folks in the room Medallia: compared to users who had the worst experiences, users who had the best experiences: spent 2.4x as much and renewed 6x as often
- 28. Don’t take my word for it Autodesk: “experience design contributes 36% to 40% to motivating users to recommend our product.” That’s NPS for you marketing folks in the room Medallia: compared to users who had the worst experiences, users who had the best experiences: spent 2.4x as much and renewed 6x as often Peter Kriss Harvard Business Review blog 1 Aug 2014 It’s time to stop the philosophical debate about whether investing in the experience of your customers is the right business decision. This isn’t a question of beliefs, it’s a question about the behavior of your customers.
- 29. Don’t take my word for it Design Management Institute, March 10, 2014
- 30. Product Owner value questions What would you ask for if this was the last sprint? What would you ask for if you can only get one thing? After that? After that? What you’re asking for is risky / expensive. Does this lower cost alternative meet your needs? No? Then let’s negotiate something that does.
- 31. The value of happiness @SimonCockayne “Forget velocity, measure value” Ask your customers: “How happy does backlog item x make you?” Super-happy (score 9-10) – You love the backlog item. Ok (score 7-8) – You are satisfied. Unhappy (score 0-6) – You are unhappy (or miserable) about the backlog item.
- 32. The value of happiness @SimonCockayne “Forget velocity, measure value”
- 33. The value of happiness @SimonCockayne “Forget velocity, measure value”
- 34. Perspectives on value Adam Polansky, “Spread It, Split It & Stack It – 3 Methods for Qualifying Content”, Big Design 2010
- 35. Games for getting to value www.innovationgames.com
- 36. Summing up value
- 37. Four things you can do Drive priority discussions around value Speak a shared language of Agile development Show the possibilities, don’t debate principles Tailor artifacts to meet your teams’ needs
- 38. It’s in there Continuous attention to technical excellence and good design enhances agility. Simplicity – the art of maximizing the amount of work not done – is essential.
- 39. Being present in an Agile world
- 40. Design stories, dev stories Design stories Development stories
- 41. Design stories, dev stories Design stories Development stories Research & discovery Epic-level design (e.g. storyboards) Pre-release usability testing
- 42. Design stories, dev stories Design stories Development stories Generic “do GUI” in a separate user story “Apply the look&feel to finished screens” UX defects are “cosmetic” (UX debt)
- 43. Development storiesDesign stories Design stories, dev stories
- 44. Development stories Design stories, dev stories Design stories
- 45. Project stories Design stories, dev stories
- 46. Building a teapot As a user I need a teapot so that I can make tea.
- 47. Building a teapot As a user I need a teapot so that I can make tea.
- 48. Building a teapot As a user I need a teapot so that I can make tea. a tea drinker
- 49. Building a teapot As a user I need a teapot so that I can make tea and enjoy a relaxing hot beverage. a tea drinker Jane Souchong
- 50. Building a teapot As a user I need a teapot so that I can make tea and enjoy a relaxing hot beverage. a tea drinker Jane Souchong needs she “User Stories Don’t Help Users: Introducing Persona Stories”, William Hudson, ACM Interactions magazine, issue XX.6 Nov/Dec 2013
- 51. Building a teapot Jane Souchong needs a teapot so she can make tea and enjoy a relaxing hot beverage.
- 52. Building a teapot Acceptance criteria: Jane Souchong needs a teapot so she can make tea and enjoy a relaxing hot beverage.
- 53. Building a teapot Acceptance criteria: Holds water Can be heated to boiling without breaking Holds tea so it can steep in boiling water Handle to lift the teapot Spout to pour out the tea Washable Attractive on my kitchen shelf … and so on Jane Souchong needs a teapot so she can make tea and enjoy a relaxing hot beverage.
- 54. Jane Souchong needs a teapot so she can make tea and enjoy a relaxing hot beverage. Building a teapot Acceptance criteria: Holds water Can be heated to boiling without breaking Holds tea so it can steep in boiling water Handle to lift the teapot Spout to pour out the tea Washable Attractive on my kitchen shelf … and so on
- 55. Building a teapot Acceptance criteria: Holds water Can be heated to boiling without breaking Holds tea so it can steep in boiling water Handle to lift the teapot Spout to pour out the tea Washable Attractive on my kitchen shelf … and so on Jane Souchong needs a teapot so she can make tea and enjoy a relaxing hot beverage.
- 56. Make users and usability explicit Prototyping and design validation for every product increment Definition of Done includes “UX reviewed” and “Usability tested” “Reviewed and approved by UX” in acceptance criteria (add a task!) “Usability tested” in acceptance criteria (add a task!) “Usable” in acceptance criteria Usability test stories in every sprint Usability test stories in every release backlog Persona names in user stories (“Jane Souchong needs…”, not “As a user…”)
- 57. Even more Agile UX hooks Refactoring Shippable increments No unnecessary documentation Simple design
- 58. Four things you can do Drive priority discussions around value Speak a shared language of Agile development Show the possibilities, don’t debate principles Tailor artifacts to meet your teams’ needs
- 59. Prototype, prototype, prototype Q: What’s the right fidelity of prototype? A: Any fidelity is better than none.
- 60. Prototype, prototype, prototype Paper Wizard of Oz PowerPoint, Keynote InDesign, Axure, InVision Okay, HTML/javascript are good for prototyping, too
- 61. Prototype, prototype, prototype Paper Wizard of Oz PowerPoint, Keynote InDesign, Axure, InVision Okay, HTML/javascript are good for prototyping, too But keep it cheap, light, and fast Can I throw this away without hesitation?
- 62. Prototype, prototype, prototype Obligatory Controversial Content Ahead
- 63. Prototype, prototype, prototype Q: Should designers code their own prototypes?
- 64. Prototype, prototype, prototype Q: Should designers code their own prototypes?
- 65. Prototype, prototype, prototype Q: Should designers code their own prototypes? A: If you can, go ahead. BUT Don’t limit your designs to what YOU can build. Find a developer to pair with – they’re better at it.
- 66. Prototype, prototype, prototype Q: Should designers code their own prototypes? Jesse Weaver “We Don’t Need More Designers Who Can Code” Medium RE:Write, Dec 2014
- 67. Prototyping is cheap, not free Prototypes save time & money Experiments save time & money Plan prototypes into the sprint Do NOT rely on skunkworks Do NOT rely on the team’s willingness to “do the right thing” off the clock
- 68. Spike it out Developers If you don’t know something, spike it If an approach seems risky, spike it If someone thinks another way is better, spike both
- 69. Spike it out = Do. The. Research. Developers If you don’t know something, spike it If an approach seems risky, spike it If someone thinks another way is better, spike both Designers If you don’t know something, research it If an approach seems uncertain, research it If someone thinks another way is better, research both Note: Research = USER research
- 70. Research is expensive, right? Wrong. REALLY wrong. Guerrilla user research Guerrilla usability testing 5-second tests Hallway tests Group sessions $$$$$$$$$$$$$$$$$$$$$$$$$
- 71. Research is expensive, right? Wrong. REALLY wrong. Guerrilla user research Guerrilla usability testing 5-second tests Hallway tests Group sessions $$$$$$$$$$$$$$$$$$$$$$$$$ Less >> Zero Stakeholder interviews Repurpose existing data Fewer participants Remote / unmoderated No lab, no recordings
- 72. One more thing about research Q: What’s the most expensive mistake you can make in a product? $$$$$$$$$$$$$$$$$$$$$$$$$
- 73. One more thing about research Q: What’s the most expensive mistake you can make in a product? $$$$$$$$$$$$$$$$$$$$$$$$$ A: Building a product that nobody wants. Do. The. Research.
- 74. Show design and code often It’s never done, so don’t hang on to it Show in-work design in sprint demos to other designers to your developers (they’ll tell you if it’s insane) Show in-work code in pairing sessions to other developers to your designers (they’ll tell you if it’s off-target)
- 75. Four things you can do Drive priority discussions around value Speak a shared language of Agile development Show the possibilities, don’t debate principles Tailor artifacts to meet your teams’ needs
- 76. Lean UX sez You are in the problem-solving business, and you don’t solve problems with design documentation. You solve them with elegant, efficient and sophisticated software. Jeff Gothelf “Getting out of the deliverables business” Smashing Magazine, March 2011
- 77. What are the right deliverables? It depends.
- 78. What does your team need? Fidelity&Detail Cost Co-construction Conversations & notes Scenarios / Use Cases) Storyboards Wireframes Low-fi mockups Hi-fi mockups Pixel-perfect comps Annotated static mockups Interactive mockups Clickable wireframes
- 79. What are the right deliverables? It depends. How mature is the design team? How mature is the dev team? How mature is the relationship of design, dev, and PO? What is the least fidelity that communicates sufficiently?
- 80. What are the right deliverables? It will change. This is a wonderful kind of magic. Start somewhere in the middle, and see which way you need to adjust. Observe in each sprint. Adjust again. And again.
- 83. Four things you can do Drive priority discussions around value Speak a shared language of Agile development Show the possibilities, don’t debate principles Tailor artifacts to meet your teams’ needs
- 84. Right here at Big Design 2015 “The $1 Prototype: A Modern Approach to UX Design”, Greg Nudelman (Thursday workshop) “Axure Essentials: Beyond Paper Prototyping”, Jo Anne Wright (Thursday workshop) “Rapid Prototyping 2015: It’s a Mad, Mad World”, Marti Gold (Fri 10:00) “Flash Builds: 1 Week Prototyping”, Jessica Keup (Fri 4:00) “Don’t Waste Your Time: Secrets of Minimum Valuable Prototyping”, Philip Likens (Sat noon) “Scrappy Usability: How to Run Faster Than Lean UX”, Josh Hall (Sat 2:30) “Six Ways to Bridge the Distance Between UX and Agile Virtual Teams”, Mary Brodie (Sat 4:00)
- 86. If you remember only one thing Communicating design in an Agile team is about conveying value, not handing off artifacts. So… Know where UX adds value, equip yourself to communicate it clearly, and be prepared to talk about it a LOT. 1. www.linkedin.com/in/jimcl jim.carlsenlandy@gmail.com @JimCL42
Notas del editor
- The basic thesis of this presentation is that we need to stop arguing about whether UX and Agile can coexist effectively. They can, they do, and most of all, they absolutely must. We don’t have a choice if our companies and careers are going to thrive. So I’m not going to make the case that these disciplines work together, just show you ways to do it better.
- If nothing else sticks, remember these highlights. You will go home with - specific techniques you can start using today - high-level principles and guidelines for the long term - ways to improve communication and alignment across disciplines - how to bridge our specialized perspectives so the solutions we deliver are great from every angle - practices that build stronger teams in any software organization
- 30 years in software, mostly GUIs. Developer, designer, manager, change agent. Degrees in philosophy and CS – you’ll see both today. Currently User Experience Director at CA Technologies in Plano. Previously with Sabre Airline Solutions, i2, ObjectSpace, Texas Instruments. Enterprise / desktop apps, not e-commerce. Software for experts and professionals. Former chapter President DFW UXPA.
- Professional Scrum Master, but that just means I can be on a Scrum Team. I’ve been working on and with Agile teams since 2005.
- Lover of great music & great art. 2-channel tube audio, jazz, blues, cubism, and surrealism, to be exact.
- Delivered design is what your customers experience when they use your prdoucts. Everyone makes decisions that affect the final product. Therefore everyone is a designer. This is one of the fundamental principles of Design Thinking. NOW who thinks they’re a designer?
- We all know this. External pressures make it difficult to communicate. We also need to take some personal responsibility for our contribution to the problem. Have you ever been to a mechanic and questioned the estimate? They throw technical terms at you to demonstrate that they know more about the topic than you do, right? Face it – we do the same thing to each other. Image from www.wikipedia.org .
- If there was a simple, universal solution we wouldn’t need presentations like this one.
- But there are things we can each to help improve our corner of the world. This is going to be a really fast ride, folks, so hang on to your phones and remember these four strategies.
- We’ll start by establishing “value” as the common thread in all Agile environments.
- The 12 Principles behind the Agile Manifesto. www.agilemanifesto.org
- There are other principles that apply, but this one is first for a reason.
- From a more practical standpoint, why is it important to talk about value? Because we prioritize based on value, which means that value defines what gets done and what does not. Help your PO understand that value has multiple dimensions. Show the value of solid UX. “Penelope Product Owner” by borisgloger.com .
- Are you a product owner? If so, during this section please raise your hand or shout your favorite supportive word if something resonates with you. We all want to know what gets your attention so we can communicate better. “Penelope Product Owner” by borisgloger.com .
- Why don’t we immediately all agree on what is valuable? We bring different concerns to our decisions at work because of our training and expertise. That affects our perception of the relative cost and benefit of every decision.
- But we all have the same goal: deliver valuable software to our customers.
- We need to talk concretely about value. Here’s a start that everyone should understand. Usability is a quality factor. Poor usability is not something to be “worked around” or a “nice to have”. It’s a defect. Poor usability = poor quality = poor value.
- Some general value-oriented ways of looking at design. Most of these are well-accepted, and some have concrete research behind them. In your business and mine, our users depend on our software for their livelihood, and for the livelihoods of their clients. Do the right thing for them. Support center photo from guardianlv.com .
- In your business and mine, our users depend on our software for their livelihood, and for the livelihoods of their clients. Do the right thing for them. Lawsuits are a real threat when you’re dealing with people’s personal and financial information. Support center photo from guardianlv.com . Money photo from archive.indianexpress.com .
- Thanks to Paul Sherman for this excellent and simple illustration from his actual experience. Agile is often referred to as a risk-reduction framework. UCD is also about risk reduction. Find out sooner whether you’re building the right thing, and find out sooner if you’re building it right. Paul Sherman, “Decision Insurance: Iterative Prototyping to Reduce Business Risk”, at 2015 UX Strategies Summit, San Francisco, CA, June 2015 http://www.slideshare.net/PaulSherman/decision-insurance-iterative-prototyping-to-reduce-business
- Thanks to Paul Sherman for this excellent and simple illustration from his actual experience. Agile is often referred to as a risk-reduction framework. UCD is also about risk reduction. Find out sooner whether you’re building the right thing, and find out sooner if you’re building it right. Paul Sherman, “Decision Insurance: Iterative Prototyping to Reduce Business Risk”, at 2015 UX Strategies Summit, San Francisco, CA, June 2015 http://www.slideshare.net/PaulSherman/decision-insurance-iterative-prototyping-to-reduce-business
- Why do designers fuss over *how* the data is presented as much as they do over how *much* data is presented? January 27, 1986. Scientists from Morton-Thiokol and NASA specialists present this information to the team that will decide whether to launch the shuttle Challenger on January 28. Clever use of rocket shapes to represent launches. All the data you’d need to make a decision is here. Anyone care to interpret this? Image in NASA public records, created by Morton Thiokol, Inc, Jan 27, 1986. Taken from Visual Explanations, Edward Tufte, 1997.
- You have to love this disclaimer. I’m sure it’s in all caps for emphasis. Have any of you ever delivered a presentation to your stakeholders, and NOT been asked for the slides separately? And if we delivered our UIs with this disclaimer, how well do you think THAT would work? Image in NASA public records, created by Morton Thiokol, Inc, Jan 27, 1986. Taken from Visual Explanations, Edward Tufte, 1997.
- The exact same data as the previous slide. What does THIS one tell you? You can add the trendline if you want, but most of us add it automatically just by looking at the chart. Why do you sometimes want to show more chart than the data would indicate? To allow the viewer to extrapolate from the existing data. BTW this was created by Tufte 10 years later. Had this been shown to the NASA team in 1986, would the outcome have been different? Image by Edward Tufte, in Visual Explanations, 1997.
- Credit to Jeremy Johnson for this clear and simple visual concept. What we use when not working is reshaping our expectations of what we use while working. This is IMO the single most disruptive trend to enterprise and traditional software makers today. If you work for a large, established company, or in any enterprise software, your product people may be blissfully unaware that this is happening. iPhone image from www.instagram.com . SAP Assistant image from help.sap.com .
- You want numbers? We got numbers. Autodesk data from Erin Bradner and Jeff Sauro, “Software User Experience and Likelihood to Recommend: Linking UX and NPS”, UPA International Conference 2012. http://www.autodeskresearch.com/pdf/2012%20NPS%20Bradner%20Sauro.pdf Medallia data and charts from “The Value of Customer Experience, Quantified,” Peter Kriss, Harvard Business Review blog, August 1, 2014. https://hbr.org/2014/08/the-value-of-customer-experience-quantified/
- You want numbers? We got numbers. Autodesk data from Erin Bradner and Jeff Sauro, “Software User Experience and Likelihood to Recommend: Linking UX and NPS”, UPA International Conference 2012. http://www.autodeskresearch.com/pdf/2012%20NPS%20Bradner%20Sauro.pdf Medallia data and charts from “The Value of Customer Experience, Quantified,” Peter Kriss, Harvard Business Review blog, August 1, 2014. https://hbr.org/2014/08/the-value-of-customer-experience-quantified/
- Your CFO wants numbers? We got numbers. We can argue about who defines “design-driven”, but most of us would agree about most of the companies in their list. And S&P is S&P – that’s just data. Design Management Institute, “Design-Driven Companies Outperform S&P by 228%”, March 10, 2014 http://www.dmi.org/blogpost/1093220/182956/Design-Driven-Companies-Outperform-S-P-by-228-Over-Ten-Years--The-DMI-Design-Value-Index
- So how do we make our value conversations specific? Value questions This is expensive/risky/time-consuming/etc would you be willing to get this valuable alternative instead, at lower risk/cost/time? What would you ask for if you can only get one thing? Next? Next? … What would you ask for if you knew this was the last sprint? Remember, “Collaboration over contracts”. Prioritize the UX stories know when to push, when to negotiate, when to back down
- It’s hard to tie value directly to a story. So why not ask your customers which backlog items make them happiest? It’s a kind of story-level NPS, that you do *before* you’ve released the feature. From Simon Cockayne’s blog https://simoncockayne.wordpress.com/2014/02/17/forget-velocity-measure-value/ @SimonCockayne Simon is a Product Owner and Agile Coach at CA Technologies.. Masks from www.fanpop.com
- It’s hard to tie value directly to a story. So why not ask your customers which backlog items make them happiest? It’s a kind of story-level NPS, that you do *before* you’ve released the feature. This spreadsheet shows the results – the most happy-making stories pop out. From Simon Cockayne’s blog https://simoncockayne.wordpress.com/2014/02/17/forget-velocity-measure-value/ @SimonCockayne
- Not specific to UX, but if stories that affect the user experience rank high in the list, they should get a high priority. From Simon Cockayne’s blog https://simoncockayne.wordpress.com/2014/02/17/forget-velocity-measure-value/ @SimonCockayne
- Self-interested voting is Adam Polansky’s idea from Big (D)esign 2010. Your product managers vote in the business value column. Your developers vote in the technical ease column. Your UX team votes in the user value column. You weight each column to reflect the overall priorities of the project. Add up the weighted values to get a total for each story. Adam Polansky, “Spread It, Split It & Stack It – 3 Methods for Qualifying Content”, at Big Design 2010. http://www.slideshare.net/AdamtheIA/big-d-052810
- Innovation Games innovationgames.com Some are free & you can play immediately online. Others are paid. You can even become a certified facilitator. They have games for all kinds of Agile and other business activities, not just value. Buy a Feature Bang for the Buck Prune the Product Tree Product Box All games © Conteneo Inc. (formerly The Innovation Games® Company). Images from www.innovationgames.com .
- Image credits (clockwise from top left): bbapply.com www.valeomarketing.com www.rockinrightside.com thetyee.ca
- Just “doing Agile” isn’t enough. We have to be communicating. I’m advocating that designers and PMs learn the language of Agile, and that POs and developers learn to extend the context of Agile to include other disciplines.
- These sure sound like UX values to me. There are also 12 Principles behind the Manifesto that give us hooks into Agile processes. Whether “it” is clean code, thoughtful design, consistent quality, rapid delivery, or good communication, it’s all in there. Image from www.agilemanifesto.org .
- Be on the team, not in the bleachers. A scrum team consists of “all the necessary skills”, so UX, QA, and any other specializations need to participate. This diagram is only about the iteration/sprint – there are lots of touchpoints earlier and later in the product lifecycle for UX, too. That may be the subject of a future talk. Anyone interested in that? Agile process diagram from www.envitia.com (and there are thousands of others out there…).
- Make sure design and development don’t get silo’d. Should you have separate UX stories? Designer photo from www.cabanova.com . Developer photo from cloudcomputingcell.com .
- Sometimes it’s okay to have separate design stories, But only when they’re “pure” design, not directly connected to a dev activity Designer photo from www.cabanova.com . Developer photo from cloudcomputingcell.com .
- Don’t allow these anti-patterns to emerge. A good Agile environment does not allow technical debt to accumulate. Don’t let UX debt accumulate, either. Designer photo from www.cabanova.com . Developer photo from cloudcomputingcell.com .
- Are your design stories in a separate repository or tool than your development stories? NEVER allow your UX stories to be in a separate repository or project. Designer photo from www.cabanova.com . Developer photo from cloudcomputingcell.com .
- Are your design stories in a separate repository or tool than your development stories? NEVER allow your UX stories to be in a separate repository or project. Designer photo from www.cabanova.com . Developer photo from cloudcomputingcell.com .
- If you have separate design and dev stories, they MUST be in the same project, in the same repository. Designer photo from www.cabanova.com . Developer photo from cloudcomputingcell.com .
- While we’re talking about stories, let’s talk about stories. Standard Agile user story format. The Agile story is where we capture what we will do that will provide some amount of value in our product.
- Standard Agile user story format. Before we go any further, let’s get one basic thing taken care of. What’s “a user”? Isn’t that like trying to design a car for “a driver”? Human head outline from psd.fanextra.com .
- “Tea drinker” is a role, like “Administrator” or “Tax Accountant”. Better, but not ideal. Teacup from www.foodphotosite.com .
- Use your persona names. Make the conversation about a human being, not an abstract concept. Human beings have motivations, which define why something is valuable to them. “Jane Souchong” from www.greenteaearth.com .
- And one more tweak. Saying “I” in the story causes some people to think they represent the persona. And You Are Not Your User. Write the story for the persona instead. It makes the story shorter & easier to read, too. See “User Stories Don’t Help Users: Introducing Persona Stories”, William Hudson, ACM Interactions magazine, issue XX.6 Nov/Dec 2013. “Jane Souchong” from www.greenteaearth.com .
- Now THAT is a story about a human being. “Jane Souchong” from www.greenteaearth.com .
- Take about 30 seconds, and write down 3-5 acceptance criteria for your teapot. “Jane Souchong” from www.greenteaearth.com .
- Your list probably looks something like this. “Jane Souchong” from www.greenteaearth.com .
- What is the user’s experience with this teapot? Is this a valuable item to deliver to your user? Sorry, to Jane Souchong. It meets the acceptance criteria, but clearly we overlooked something. Screaming woman from andthatswhyyouresingle.com . “Coffeepot for Masochists” designed by Jacques Carelman, photo by Ayman Shamma, from www.jnd.org/dn.mss/CH00_Prolog.pdf .
- Ah, a USABLE teapot. Screaming woman from andthatswhyyouresingle.com . “Coffeepot for Masochists” designed by Jacques Carelman, photo by Ayman Shamma, from www.jnd.org/dn.mss/CH00_Prolog.pdf .
- There’s enough material here for a whole presentation. Mine is “Agile Power Words for UX Practitioners” on SlideShare. Hands up if you’re doing any of these. A “UX review” task means the story cannot be turned over to QA until UX review is complete - Credit to Kathren Torraca, IXD at Idexx Labs, Maine - This prevents miscommunication from becoming a “UX defect” - We know what happens to “UX defects”
- Also covered in my “Agile Power Words for UX Practitioners” presentation.
- We can debate principles, but remember that each of our professions has different values, techniques, goals, etc. How far does that usually get you?
- Prototyping happens in all industries because it is always true that the value of learning from a prototype is much greater than the cost of building it, and it is far less risky to prototype than to go directly to market. I love MythBusters, because they’re always prototyping and experimenting, failure is always an option, and let’s face it, we all like watching stuff blow up. From a good safe distance. Image credits (clockwise from top left): www.uxmatters.com, ixld.com, www.discovery.com, dribbble.com/FransTwisk, www.drive.com.au .
- Use whatever you have available and are comfortable with. But a prototype should never be a big investment (compared to the product), and you should have no qualms about throwing it away. “Tip Helper” image from Nielsen Norman Group, http://www.nngroup.com/reports/paper-prototyping-training-video/ .
- Use whatever you have available and are comfortable with. But a prototype should never be a big investment (compared to the product), and you should have no qualms about throwing it away. If you can’t throw it away you’re too attached to the prototype. “Tip Helper” image from Nielsen Norman Group, http://www.nngroup.com/reports/paper-prototyping-training-video/ .
- As presenters at most conferences we are required to bring up at least one topic that has generated endless online rants and opinion-laced debate and take a strong one-sided stand about it. Here’s mine.
- Should designers code up their own prototypes? This is a subject of constant debate, and many people disagree with me. It’s okay – they’re allowed to be wrong. Photo from www.fastestonemanband.com .
- Should designers code up their own prototypes? The term thrown around for designers who can code is “unicorn”. Insert rainbows and bunnies joke here. Image from www.dianapeterfreund.com .
- Should designers code up their own prototypes? If you can, sure. BUT Your developers are better at it. Don’t limit your designs to what YOU can build. Let the most skilled technical people bring your ideas to life. Everyone will feel better about it. Photo from cloudaccesssecurity.wordpress.com .
- The argument shouldn’t be about designers coding or coders designing. We should be focused on enough mutual understanding that we communicate as seamlessly as possible. Jesse Weaver, “We Don’t Need More Designers Who Can Code,” in Medium RE:Write, December 17, 2014. https://medium.com/re-write/we-dont-need-more-designers-who-can-code-b81483d2a0e6
- Product Owners, I’m talking to you here. Make sure that when a prototype is needed, it is planned in. Counting on “skunk works” or people’s inherent need to “do the right thing” isn’t scalable or sustainable. Panhandler image from pinterest.com, Charles Haag, pinned from ehow.com.
- Agile developers learn to spike things that are new, unknown, or potentially risky. A bake-off spike can be very effective because it is fast and cheap. Young developers photo from www.issaquahpress.com .
- Why would I put something short & focused like a spike on the same page as something extensive & open-ended like research? Because once you’re inside the dev cycle, research needs to be short & focused. This is about getting things in front of users for validation, not doing fundamental discovery, or looking up more theories to debate. Photo from austin.3daystartup.org .
- There’s a belief that research is expensive, but it can be done relatively cheaply for small projects or if you have a limited budget (don’t we all?). Some of these come from “Doing User Research Faster and Cheaper”, Jim Ross, uxmatters.com May 3, 2010. http://www.uxmatters.com/mt/archives/2010/05/doing-user-research-faster-and-cheaper.php
- And whatever else you have to deal with, remember that some research, even if it’s limited, is better than none at all. Some of these come from “Doing User Research Faster and Cheaper”, Jim Ross, uxmatters.com May 3, 2010. http://www.uxmatters.com/mt/archives/2010/05/doing-user-research-faster-and-cheaper.php
- Let’s talk about value again. When are the least expensive and most expensive times to change your product?
- And the least expensive time of all is BEFORE YOU BUILD ANYTHING. Figure out up front if you’re buildling the right thing for the right people. That’s what user research does for you. Remember the “Decision Insurance” thing? Yeah, that again.
- Design & code reviews are not just about quality. They’re about communicating and aligning on the direction, opening up conversations, and bringing the best ideas to the table. If you work on design or code for more than a day or two without someone else seeing it, you’re off track. This is why it’s important to break work down into small chunks - This is hard for everyone, not just you - Smaller pieces mean faster results - Faster results means faster failing - Faster failing means more learning More learning means better outcomes Designers photo from blogs.solidworks.com . Mac users photo from commons.wikimedia.org .
- What design deliverables should you create for the handoff to development? Is that really even the right question? Why do we think of it as a handoff instead of a collaboration?
- We don’t have time for a full lesson on Lean UX (and I’d leave that to Jeff Gothelf, anyway). Lean UX is founded on these principles: - Design thinking - Agile development - Lean startup Jeff Gothelf, “Getting out of the deliverables business”, Smashing Magazine, March 2011 http://www.smashingmagazine.com/2011/03/07/lean-ux-getting-out-of-the-deliverables-business/
- So if we can’t completely do away with deliverables, but we shouldn’t build extensive, detailed, heavy documentation, what ARE the right deliverables?
- The right level of fidelity depends on your team and your project If you can get results by talking about it, great. But add fidelity as you need it to get consistently good results. As the team settles in you will probably find that the fidelity can decrease – take advantage of that. What’s not on this chart? Value. Because that can only be determined in the context of your team and your work. Credits: dribbble.com/FransTwisk, www.kony.com, ixld.com
- The maturity of the relationship between design and development and PO will guide how much detail is needed. Remember, “No unnecessary documentation” means create the least amount of documentation that still gets the point across to your team.
- So if we can’t completely do away with deliverables, but we shouldn’t build extensive, detailed, heavy documentation, what ARE the right deliverables?
- A technique used by Sheetal Prabhu, Interaction Designer on my team at CA. Of course, a scenario is just one path through the system, so you can’t construct a whole solution from just one scenario, or even a few. But if your goal is to deliver a shippable increment, a minimally viable product/enhancement, or other constrained solution, this is magic. People relate well to stories Write scenarios as stories about personas Interweave the scenario story with wireframes Allows you to focus feature & value discussions: - Does the proposed solution move the story forward? - Is this proposed addition part of the story? - Is everything in the wireframe necessary to tell the story? - If we don’t do this piece, how does that affect the story?
- A technique used by Sheetal Prabhu, Interaction Designer on my team at CA. Of course, a scenario is just one path through the system, so you can’t construct a whole solution from just one scenario, or even a few. But if your goal is to deliver a shippable increment, a minimally viable product/enhancement, or other constrained solution, this is magic. People relate well to stories Write scenarios as stories about personas Interweave the scenario story with wireframes Allows you to focus feature & value discussions: - Does the proposed solution move the story forward? - Is this proposed addition part of the story? - Is everything in the wireframe necessary to tell the story? - If we don’t do this piece, how does that affect the story?
- One last time.
- Clearly these are topics of interest, so dig in more with these workshops and sessions here at Big Design. My apologies for the ones you already missed, but feel free to hunt downt he presenters and corner them with your questions.
- I think this is one thing, but maybe it’s 3? Or 4? In any case, it’s important. Now go forth and be amazing!