Personal Design Sprint - Revision history

WikiSysop at 00:41, 25 November 2016

2016-11-25T00:41:01Z

WikiSysop at 17:13, 30 August 2016

2016-08-30T17:13:13Z

WikiSysop: /* DBBD SPRINT */

2016-08-30T17:13:02Z

‎DBBD SPRINT

WikiSysop at 17:10, 30 August 2016

2016-08-30T17:10:27Z

WikiSysop at 17:04, 30 August 2016

2016-08-30T17:04:56Z

WikiSysop: Created page with "'''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. h..."

2016-08-30T17:01:47Z

Created page with "'''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. h..."

New page

'''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/

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 ===

* 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.

* Reframe problems as opportunities. Listen carefully for problems and use “How might we” phrasing to turn them into opportunities

* 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.

← Older revision		Revision as of 00:41, 25 November 2016
Line 72:		Line 72:
	# Test it with a human (1 pom)		# Test it with a human (1 pom)
	# Review (1 pom)		# Review (1 pom)
		+
		+
		+	[[Category:Productivity]]

← Older revision		Revision as of 17:13, 30 August 2016
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 63: @@
 == 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)
 # Critique the solutions (1 pom)
 # Figure out details (1 pom)
-# Make prototype
+# Make prototype (2 pom)

← Older revision		Revision as of 17:04, 30 August 2016
Line 12:		Line 12:

	=== DAY 1 ===		=== 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.		* start at the end, determine the long-term goal.

@@ Line 22: / Line 22: @@
 * 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?
@@ Line 29: / Line 28: @@
 * Get pessimistic. Ask: How could we fail?
 * Turn these fears into questions you could answer this week.
 * Reframe problems as opportunities. Listen carefully for problems and use “How might we” phrasing to turn them into opportunities
 *  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 ===
@@ Line 54: / Line 59: @@
 * 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.