Difference between revisions of "Personal Design Sprint"

From Wikicliki
Jump to: navigation, search
 
(2 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 63: Line 64:
 
== DBBD SPRINT ==
 
== DBBD SPRINT ==
  
# GATHERING KEY INFORMATION (1 pom)
+
# Gathering Key Information (1 pom)
# Doodle solutions (1pom)
+
# 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)
 +
 
 +
 
 +
[[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

  1. Gathering Key Information (1 pom)
  2. Doodle solutions (1 pom)
  3. Try some rapid variations (1 pom)
  4. Critique the solutions (1 pom)
  5. Figure out details (1 pom)
  6. Make prototype (2 pom)
  7. Test it with a human (1 pom)
  8. Review (1 pom)