Difference between revisions of "Personal Design Sprint"
From Wikicliki
(→DBBD SPRINT) |
|||
Line 63: | Line 63: | ||
== DBBD SPRINT == | == DBBD SPRINT == | ||
− | # | + | # Gathering Key Information (1 pom) |
− | # Doodle solutions ( | + | # Doodle solutions (1 pom) |
# Try some rapid variations (1 pom) | # Try some rapid variations (1 pom) | ||
# Critique the solutions (1 pom) | # Critique the solutions (1 pom) | ||
# Figure out details (1 pom) | # Figure out details (1 pom) | ||
− | # Make prototype | + | # Make prototype (2 pom) |
+ | # Test it with a human (1 pom) | ||
+ | # Review (1 pom) |
Revision as of 17:13, 30 August 2016
PROCESS FOR A ONE MAN DESIGN SPRINT!
I was reading Google Ventures' notes on conducting Design Sprints.
Here are my summarised notes and a game plan for the future.
Why use a Sprint?
- According to knapp, "shortcut the endless-debate cycle and compress months of time into a single week"
- Find actionable goals for projects that seem to be stuck
DAY 1
houserules:
- No distractions. disconnect facebook and phone.
- timeboxing. make a tight schedule.
- plan for late lunch to avoid lunch crowd.
- start at the end, determine the long-term goal.
- make a map of the challenge.
- ask experts to share knowledge.
- pick a target: an ambitious but manageable piece of the problem that you can solve in one week
- Why are we doing this project?
- Where do we want to be in six months, a year, or even five years from now?
- Write the long-term goal on a whiteboard.
- Get pessimistic. Ask: How could we fail?
- Turn these fears into questions you could answer this week.
- make a map. list all the actors in the story. write the ending.
- Reframe problems as opportunities. Listen carefully for problems and use “How might we” phrasing to turn them into opportunities
- Write HMW on top left hand corner. Turn interesting statements into questions.
- Always be capturing. all parts of the process must be documented and noted down for future reference.
- Ask obvious questions. Pretend to be naive. Ask “Why?” a lot.
- Decide and move on. Slow decisions sap energy and threaten the sprint timeline.
DAY 2
- review existing ideas which need to be remixed and improved
- sketch out possible solutions
DAY 3
- with a stack of solutions, you need to critique each solution and decide which ones have best chance of achieving the long-term goal.
- in afternoon, take winning scenes from the sketches and weave them int oa storyboard: a step by step plan for the prototype
DAY 4
- "fake it" - realistic facade is all you need to test something with customers, so just make a prototype of it.
DAY 5
- with the prototype, interview customers and learn by watching them react to your prototype.
- At the end of the day, you’ll know how far you have to go, and you’ll know just what to do next.
DBBD SPRINT
- Gathering Key Information (1 pom)
- Doodle solutions (1 pom)
- Try some rapid variations (1 pom)
- Critique the solutions (1 pom)
- Figure out details (1 pom)
- Make prototype (2 pom)
- Test it with a human (1 pom)
- Review (1 pom)