Done but subject to change

Here’s how I find the design and development process working best on my own projects:

Have the idea properly realised and rendered before committing to code.

It doesn’t mean a perfect mockup followed by a slog of coding. It means something like this:

  1. Explore the possibilities
  2. Define the most promising one
  3. Prod the biggest risks
  4. Adapt the idea where needed
  5. Go down the hill of decreasing risk

#3 and #4 are cyclical: you do them until you have high confidence that you can execute the idea. In other words, the idea is properly realised and rendered.

#5 is the commitment to code. It’s a downhill slide1 (in a good way) because you’ve done the hard work already in #3. It’s just putting the parts (predictably) together.

The idea has likely changed by #5. Something that turned out to be harder than thought in #3 may have spurred prototyping, which may have spurred a happy accident or two.

Here’s that 1–5 process again, spread apart in the context of my most recent 68 Bits noodling:

  1. Research (what’s the shape of this thing? What’s out there?)
  2. Sketching (how could it work?)
  3. Rendering the possibilities in Figma (at two breakpoints)
  4. Prototyping the riskiest parts of the most promising Figma rendering on CodePen
  5. Sketching and rendering once more based on what I’ve learned
  6. Figuring out the last unknowns in the CodePen prototype
  7. Making the real thing

It isn’t just the most efficient way of working for me. It’s also the most open to happy accidents. For example: I came up with Magic 8-Ball Mode only after realising, whilst prototyping, that the original idea didn’t have legs.

  1. I’m borrowing this hill analogy from Shape Up: a much more thorough philosophy on making good work. ↩︎