Difference between revisions of "Personal Design Sprint"
From Wikicliki
(3 intermediate revisions by the same user not shown) | |||
Line 6: | Line 6: | ||
http://www.gv.com/sprint/ | http://www.gv.com/sprint/ | ||
+ | http://www.fastcodesign.com/1672887/how-to-conduct-your-own-google-design-sprint | ||
Why use a Sprint? | Why use a Sprint? | ||
Line 22: | Line 23: | ||
* ask experts to share knowledge. | * ask experts to share knowledge. | ||
* pick a target: an ambitious but manageable piece of the problem that you can solve in one week | * pick a target: an ambitious but manageable piece of the problem that you can solve in one week | ||
− | |||
* Why are we doing this project? | * Why are we doing this project? | ||
Line 29: | Line 29: | ||
* Get pessimistic. Ask: How could we fail? | * Get pessimistic. Ask: How could we fail? | ||
* Turn these fears into questions you could answer this week. | * 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 | * 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. | * 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. | * Ask obvious questions. Pretend to be naive. Ask “Why?” a lot. | ||
* Decide and move on. Slow decisions sap energy and threaten the sprint timeline. | * Decide and move on. Slow decisions sap energy and threaten the sprint timeline. | ||
+ | |||
+ | |||
=== DAY 2 === | === DAY 2 === | ||
Line 54: | Line 60: | ||
* with the prototype, interview customers and learn by watching them react to your prototype. | * 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. | * 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) | ||
+ | |||
+ | |||
+ | [[Category:Productivity]] |
Latest revision as of 00:41, 25 November 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.
http://www.gv.com/sprint/ http://www.fastcodesign.com/1672887/how-to-conduct-your-own-google-design-sprint
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)