Agile Team Empathy Drives Inclusive Design Approach Under 40 Characters
•Als PPTX, PDF herunterladen•
3 gefällt mir•859 views
The document discusses using empathy and an inclusive team approach to software development. It advocates developing empathy with real users through field visits where the entire team interacts directly with users to understand their tasks. This helps inform rapid prototyping and development that results in a product meeting user needs. This approach led to the team successfully replacing their mobile product ahead of competitors and growing their business.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Ähnlich wie Agile Team Empathy Drives Inclusive Design Approach Under 40 Characters
Ähnlich wie Agile Team Empathy Drives Inclusive Design Approach Under 40 Characters (20)
Mehr von UCD UK Ltd
Mehr von UCD UK Ltd (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Agile Team Empathy Drives Inclusive Design Approach Under 40 Characters
- 1. Aggressive inclusivity a truly team approach to empathetic design Kevin Fitzsimons - October 2014
- 2. Icebreaker
- 3. Adversarial relations… “Fight your corner… never let up or they’ll crush you” “Stand your ground…” “Make sure you keep arguing the UX case… don’t let them browbeat you…” “Daily struggle… keep on the front foot…” “They might get it eventually…”
- 4. What did we want the team to be like? • All about: – Avoiding assumed consensus – Gelling the team from Day One – Rapidly moving in the right direction – Establishing empathy with users • It’s NOT about: – Specs – Requirements docs – Detailed plans – Detailed designs – Documentation is risk, not risk management
- 5. Bad old days • PM Spoke to ‘the customer’ • This meant the person who signed the cheques • Resulted in us building a major new feature • How many users actually used this feature when it was delivered?
- 6. Empathy with users… Engineer – Product Manager – Account Manager – Buyer – Supervisor – User • Don’t just ‘study’ or ‘understand’ customers – Need to really EMPATHISE – Real user input NOT ‘user proxies’ or buyers or personas – Engineers talk DIRECTLY to the users – Engineers ALWAYS attend field visits
- 7. Personas…
- 8. Use their key touchpoints Definition of done…
- 9. The WHOLE team goes into the field • Working with the real users on real jobs
- 10. And we do mean the WHOLE team… • Left to right: – Graphic Designer – Software Dev Lead – User – Technical Architect • …on a freezing morning in Chatham, England
- 11. Some context • What is Confirm? – Highways asset maintenance management – Manages over $1bn of infrastructure assets globally – Over 20 years old • Existing Confirm Mobile – Field based extension of Confirm desktop • What we were doing – Replacing Confirm Mobile – Being first to market with a smartphone and tablet offering – Expanding the customer base
- 12. Existing Confirm Mobile • Some deeply horrible UX issues • Runs only on specialised devices
- 13. Field research - in
- 14. Field research - out
- 15. Up close and personal…
- 16. TRULY understand the task…
- 17. Field context - empathies
- 18. Empathy in action: once I see it…
- 19. The empathy thing writ large
- 21. Empathy-driven development • …the team’s workspace lived and breathed the customer… photos of real users (not personas), their artefacts… their desks…
- 22. Making it real • JEDUF© – Just Enough Design Up Front to make a start • Prototyping was key • Prototype had several roles: – UX validation – User research – Demos – Sales briefings – Communication shared understanding of vision – ‘Spec’ – supports on-going discussion with Product Manager
- 23. Full-team design
- 25. …and we iterated from there
- 26. The secret sauce • We empathise with users • And we trust each other • And we make decisions together • And all this allows us to be truly lean (as in eliminating waste, for example, personas and throwaway prototypes) • And that’s it, really
- 27. Final result… • Standing start to market leader in 9 months • 18 months ahead of the competition • Users of competitors’ products requesting demos • Significant pull-through sales of desktop solution • Confirm business grew 25%+ in 2013
- 28. Side benefits… • Huge PR side benefits • Customers see the process happening • Industry perception of activity and progression – Clients see progress rather than early announcement followed by radio silence for 18 months • See responsiveness • Engenders trust • Feel valued • They spread the word • Happier to take the product earlier • Discussions about features fade away
- 29. Inclusivity learning points • Understand the culture • Speak the language • Be subversive; bottom up not top down • Find the hot buttons • Don’t try to change development practice • Evangelise by doing • Be visible • Make allies • Be inclusive • Share ownership of artefacts • Explain & accommodate… don’t dictate • They want to learn • Have ground rules
- 30. Developer quote • “This has really opened my eyes… I can’t believe I’ve been developing for seven years without doing this… this is the first time I’ve really understood why I’m coding something… previously if I hit a problem and needed guidance, I’d ask the product owner and he’d tell me how to solve it but I still wouldn’t understand why it had to be done like that… now I’ve been part of this I can’t imagine how we ever managed to build anything useful before…”
- 31. Take a bow… the team • John Castle • Kevin Fitzsimons • John Gomersall • David Haynes • Keith Manning • Liz McKenzie • Paul Miller • Rob Savage • Vaughn Stanworth • Adam Taroni
Hinweis der Redaktion
- Rule: tech & design staff will come on field visits to see things first hand
- Confirm is software used to manage physical infrastructure assets such as roads, bridges, street lights, drainage assets and whole lot more. Put very simply Confirm stores information on what the assets are, where they are, what condition they are in, what works needs to be done on them and when, who should be doing that work, how much that work costs, can create invoices, has contract management rules built into it. It is an extremely comprehensive and scalable system with over 140 components to chose from. It is predominantly sold in the UK and Australia although we have clients further afield such as Philippines, Fiji, New Zealand who use it to manage their road networks and related assets. It is the market leader in the UK which over 100 public and private sector clients gained over the last 20 years. Confirm Mobile is our existing mobile extension of Confirm for site based working, allowing staff to access and collect information in the field. Today’s presentation focusses on the process we went through to replace the existing Confirm Mobile application with the goal of being the first to market with the next generation of mobile asset management software.
- So here you can see the existing Confirm Mobile user interface and a range of devices which by today’s standards look rather outdated.
- Observe the minutiae of the daily tasks What’s a gully in American?
- Rule: tech & design staff will come on field visits to see things first hand
- Observe the minutiae of the daily tasks What’s a gully in American?
- Artefacts are revealing
- Early visualisation – ideas worked out collaboratively using inputs from field visits – start building straight from this
- So this is an example of how the design evolved, not in a document or on a white board, but in the product First picture was an HTML5 mock up to just help have a conversation Next we see our first stab. We thought an analogy with email would help, so you have an inbox, drafts (work in progress) and an outbox (stuff being sent back to the server) We then needed to introduce symbols to differentiate between different types of task We decided that it was a bit disconcerting for something to move from the inbox to the drafts tab when you started to edit it so we merged it into the Inbox but now with some status indicators to show where you were up to with each task It took a few iterations with colour and symbol to get something that users found intuitive. So we have the ides of read and unread (with the *) We introduced alerts on the Outbox if there were problems Eventually we found that the Email analogy wasn’t working so we switched to “Transfers” which might not work for everyone but was a term our users were comfortable and immediately familiar with Most recently we started incorporating urgency into the icons. Users didn’t really need a symbol for unread, although we still use bold styling It might seem like it was wasteful to make all these changes, but if we’d tried to do the design up front we would have probably had just as many iterations, it’s just we would have wasted a whole load of time NOT getting the software into the hands of users
- Waterfall is a symptom of a lack of trust… “I don’t trust you to revisit my requirements in the future, so I will write down everything that I might possibly need in a specification and I won’t pay you until you deliver everything”. You have to earn that trust with customers and users and the easiest way to do that is to give them something, listen to their feedback and then give them something better. But trust has to happen internally too. The Product Manager has to trust the Engineering team (including UX) to meet his stated goals in the best way that they see fit. A list of Features on a roadmap shows a lack of trust A UX team designing the entire screen flow for an application before the first line of code is written also shows a lack of trust – “I don’t trust that you are willing to change things when we get feedback” A Salesman needs to trust the whole team so that when he says to the customer “don’t ask me for features, trust me, this will solve your business problem” that it really will! So what happens when you build trust…
- Waterfall is a symptom of a lack of trust… “I don’t trust you to revisit my requirements in the future, so I will write down everything that I might possibly need in a specification and I won’t pay you until you deliver everything”. You have to earn that trust with customers and users and the easiest way to do that is to give them something, listen to their feedback and then give them something better. But trust has to happen internally too. The Product Manager has to trust the Engineering team (including UX) to meet his stated goals in the best way that they see fit. A list of Features on a roadmap shows a lack of trust A UX team designing the entire screen flow for an application before the first line of code is written also shows a lack of trust – “I don’t trust that you are willing to change things when we get feedback” A Salesman needs to trust the whole team so that when he says to the customer “don’t ask me for features, trust me, this will solve your business problem” that it really will! So what happens when you build trust…