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:
- Explore the possibilities
- Define the most promising one
- Prod the biggest risks
- Adapt the idea where needed
- 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:
- Research (what’s the shape of this thing? What’s out there?)
- Sketching (how could it work?)
- Rendering the possibilities in Figma (at two breakpoints)
- Prototyping the riskiest parts of the most promising Figma rendering on CodePen
- Sketching and rendering once more based on what I’ve learned
- Figuring out the last unknowns in the CodePen prototype
- 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.