The Design Spike

A structured approach to solving problems…or deciding not to

Here at Convoy, we live and breathe our values. Each value has its own hashtag, and we use them liberally, even in casual conversation.

Of all the values, one of my personal favorites is Love Problems Not Solutions (#LPNS).

“Problems are evergreen, but the best solution changes over time. We don’t get so attached that we can’t let a solution go when a better one arises. We work as hard to define and understand problems as we do to solve them.” — Convoy Values

In the engineering discipline, this philosophy is especially important. It’s easy to start implementing the first solution that comes to mind when presented with a problem. But it’s almost always better to take a more measured approach, and avoid this type of tunnel vision.

A design spike is a lightweight structure for intentionally designing a solution to a problem. It emphasizes considering the problem and requirements in depth first, and then generating and evaluating potential solutions second. It combats the tendency to “solutioneer”: to start with and become attached to a single solution idea and retroactively figure out what problem it solves.

“Recognize that decision making is a two-step process: First take in all the relevant information, then decide” — Ray Dalio, Principles

A design spike document invites and supports collaboration by providing a framework that helps structure and shape discussion. Such a document is usually drafted first by one person and then reviewed by the rest of the team in a Design Review meeting. In this way, one person does the “legwork”, but the whole team gets to have input on the decision.

Template

This template outlines the sections to include in your design document. It should give a sense of structure. However, every spike is different, and any of these sections might or might not apply.

Regardless of your personal process in delving into the design spike, try to shape the final document with readers in mind.

Goal

Describe the ultimate goal of the spike. Is it just to investigate some kind of new technology, or is it to define a bunch of solution options, pick one, and define actionable work?

Problem

Clearly define the problem(s) to be solved.

For extra credit, start by Reframing the Problem. The best solution is realizing you don’t have to solve the problem at all, and the next best is realizing you can solve a different, easier problem.

Example

• Problem: People are complaining elevators are too slow
• Reframed problem: People are annoyed by waiting for the elevators

Requirements

Define any requirements that constrict the solution space.

Example

• Requirement: improvements must costs less than $500

Solutions

Ideate solutions that solve the stated problems. Often it takes the form of several options that the team as a whole can decide between.

Example

• Option 0: Do nothing.
  Tip: Always consider “Option Zero”. Sometimes the best solution is not to change anything — to intentionally choose not to solve the problem. Always make sure such an option is listed (if possible) and weighed against the others.
• Option 1: Make elevators faster
  (Here you might flesh out the solution and list some pros and cons)
• Option 2: Decommission elevators and force people to take the stairs
• Option 3: Install mirrors so people are distracted from the wait time

Always consider “Option Zero”. Sometimes the best solution is not to change anything — to intentionally choose not to solve the problem

Proposed Work

Once a solution has been selected, a design spike should end with a “Proposed Work” section that explicitly breaks down the chosen solution into the work that needs to get done to implement it.

Context (optional)

It can be helpful to have a “context” section early in the doc (or as an appendix) that makes sure everyone has the context necessary to make informed contributions and decisions.

Status (optional)

Consider having an explicit “status” section that describes where you are in the design spike process, to help visitors know how to interact with the document. It might say that the spike is:

• In a rough, early state
• Ready for review
• Complete, agreed upon by the relevant team & archived (if it was converted to tasks in a tracking system, include a link to those)

Process: How the sausage gets made

(Spoiler: it’s not pretty)

Writing a design spike is an involved and sometimes messy process, and design documents usually don’t spring from the aether fully-formed. This is not always obvious when looking at completed Design Spikes for inspiration.

A large and in-depth design spike might have a process that looks like this:

1. Frame the problem: write out draft Goals/Problems/Requirements
   Review meeting to agree on the problem framing. Potentially try “Reframing the problem” or explicitly listing things that are “Out of Scope”
2. Ideate solutions: write out draft Solutions section
   Review meeting to select a solution, or to ideate more solutions
3. Propose work: Break down the chosen solution into Proposed Work
   Review meeting to agree on the breakdown of proposed work
4. Do the work!

A smaller design spike might still follow this general shape, but skip most review meetings, or have them asynchronously.

Don’t follow the letter of the law

I have written design spike documents that are 10-page Google Docs reviewed with extensive team discussion, and I’ve written some that are 3-item lists in Slack signed off with an emoji poll. I’ve written some that exactly follow this template and some that had completely different sections. I’ve spent weeks on spikes and held multiple rounds of review meetings, and I’ve written some up in minutes, live during a meeting.

Many of these started as a confused jumble of notes, and only slowly coalesced into a coherent story.

The common thread through each was a commitment to starting by framing the problem, considering a variety of options for how to solve it (including Option Zero!), and deliberately selecting a solution.

Over and over again I’ve found the design spike to be a powerful and versatile tool. Its gentle structure is a comforting starting point when I’m delving into unknown territory. Along the way it unlocks better teamwork because everyone is on the same page about what we’re doing and why. And ultimately, it helps in picking better solutions, and perhaps more importantly, in picking better problems to solve.

I hope you, too, find the design spike to be a valuable tool for your toolbelt.