RITE Fight!

Going rounds between stakeholders and assumptions.

Presented at Product Tanks Paris, May 2014,

Transcript

1. RITE Fight Going rounds between Assumptions and Users
2. Every design is a hypothesis
3. Every stakeholder has their assumptions
4. RITE lets you challenge those assumptions…
5. …and roll with the punches
6. Do you test?
7. How often?
8. Who does it?
9. Who sees it?
11. Why do you test?
12. What happens next?
13. The problem with tests…
21. vs
22. So, what do we do?
23. RITE
24. Rapid
25. Iterative
26. Testing
27. Evaluation
28. Rapid Iterative Testing and Evaluation
29. What is it?
31. Plan Test Analyse Report Modify(?)
32. Plan Test Analyse repeat repeat repeat Modify Solve & Decide
33. Plan Test Analyse Modify Solve & Decide Test Analyse Modify Solve & Decide Test
34. Plan Test Analyse Modify Solve & Decide Test Analyse Modify Solve & Decide Test Analyse Modify Solve & Decide Test Analyse Modify Solve & Decide Test
35. How it works
36. Buy-in starts here Plan
37. Cross-team Assemble
38. Required attendance See it
39. Realtime debrief Discuss
40. Debrief - Prioritisation 1. Quick Fix 2. Big fix 3. WTF? 4. Other
41. Fix collaboratively Solve
42. Integrate validation Decide
43. Modify for next session Act ∆
44. Do it again! Repeat
45. RITE in a nutshell • Plan: Commit, schedule, recruit, define • Assemble: Bring someone from every relevant team • See: Stakeholders required to attend • Discuss: Realtime debrief • Solve: Collaboratively explore design fixes • Decide: Integrated choice validation • Act: Modification between sessions • Repeat: That’s why they call it “iterative”
46. Why it’s good
47. Why it’s good • Gets the user in • Team engagement • Team alignment • Transparent decision-making • Guaranteed* buy-in • Rapid problem and solution identification
48. When it’s good
49. When it’s good • During the design phase (early and often) • In agile environments • As a reality check • When teams are divided • When time is short
50. When it’s risky
51. When it’s risky • Lack of commitment or schedule flexibility • Without key stakeholders • Highly complex flows (difficult to modify) • In place of a proper redesign • When you shift from live site to pro to • With a limited marge de manoeuvre
52. A few variations
53. M T W R F 2 tests debrief solutions ∆ 2 tests debrief solutions ∆ 2 tests debrief solutions ∆ 2 tests debrief solutions ∆
54. M T W R F 4 tests debrief solutions ∆ 4 tests debrief solutions ∆ 4 tests debrief
55. M T W R F 6 tests debrief debrief solutions ∆ 6 tests debrief debrief solutions
56. M T W R F 6 tests debrief solutions ∆ 6 tests debrief solutions M T W R F ∆ 6 tests ! 6 tests
57. Do’s • Work during tests • Bring your killers • Track issues you can’t solve • Bring clean, modifiable protos • Take breaks • Crowd control • Timebox
58. Don’ts • Act when the cause is unclear • Push too many changes • Accept too large of a test perimeter • Try to be exhaustive • Be too attached to your ideas
59. Questions?