When Should Visual Design Precede Implementation?
First published April 2016
As a programmer, I hate getting a wire frame and having to reproduce it with code. I never had a good way to be empathetic with those who want to work in that style. I now have an explanation for when it makes sense.
Welcome new sponsor Augment! Their CEO (and my friend) Igor Ostrovsky walked me through their chat-based programming assistance & previewed their sexy new agentic tools. I love writing programs that modify programs & now I can do it with all the benefits of a tool embedded in VS Code.
Some things Augment Agent can do:
Add new features spanning multiple files
Queue up tests in the terminal
Open Linear tickets, start a pull request
Start a new branch in GitHub from recent commits
The limitation is your imagination. Build something real—Augment Agent is standing by to help. Sign up and start building with Augment Agent.
Distilled essence of convexity
[ed: I’d call this Explore now, but I was just on the verge of minting those words at the time of writing]
In early product development, everything is in flux (I would say it is highly convex—small chance of a big success). Even the vision may or may not be useful, pending feedback. We can’t say which activity should precede which other, because they all swirl around as you discover and learn. We hop between activities without a predictable sequence.
Now the vision has been validated—people really do want last minute tickets to nearby live concerts and there are empty seats to be filled [<- pulled from thin air]. We no longer iterate on the vision unless it starts running out of gas.
How are we going to make money/create engagement/connect people? We keep iterating Strategy, Design, Engineering, & Product together until we have a strategy that stands up to feedback.
What’s the product? We keep iterating–is it a web site, an app, a bot, a VR location? Eventually we find a product that supports the vision and strategy. Now the product stops wiggling but we still need rapid iteration between design & implementation.
We need to iterate because we’re still not quite sure how the product should look. Sometimes small changes in appearance can result in large savings in engineering. It’s worth iterating.
Once we have the look & initial implementation nailed down [ed: I’d call this Extract now], then it’s worth taking a careful up-front look at the design.
There you have it. Or rather, there I have it. Late in concavity [ed: during Extract], the exploitation [ed: see? I was getting close to the words] of a successful product, the efficiency and consistency wins offered by design-first implementation make sense. The reason I never saw this before is that I am a tree shaker, not a jelly maker (tx Jesse Jackson), so I’m long gone before reaching this stage.
This is quite similar to the product operating model as explained by Marty Cagan (you two should be on a podcast together!). However, there (at least) one senior engineer, a designer and a product manager iterate on the solution together, the engineer doing prototypes and thinking about what is just now possible in tech, the PM caring that the soltution is valuable to the user, customer and the business and the Designer caring that users will actually use it once they bought it, so they can experience the value.
That might actually resolve the knot: there are engineers that just want to build the stuff others came up with - they want to solve the implementation details or care that the design of the software enables the current set of features and opens the pathway for future features, while others want to be actively working on the (wholistic) design of the solution we want to deliver to our users.