Engineering and design.
Start at the top building context, find the problem and the people who have it, and work down through structure, design, data, and code until it ships. Then measure and go again. Until the problem is solved and delivery the product.
Why work this way? Because details matter, mistakes happen, and I care about what I'm building. Top down, every detail has a reason above it, so when a mistake shows up I can trace it back to the decision that caused it and fix it there.
Top down, full cycle
The ideal loop, the sweet spot where development feels whole.
Start with the probe
Find the sources of truth first, one for each side of the job.
- Product design: the Mom Test. Ask what people actually did the last time they hit the problem. Their life, not the idea. [Biggest change in my product development].
- Engineering: fit, form, function. A simple but useful philosophy from engineering. What does it plug into, what shape must it hold, and how will I prove it works?
Every step after this answers to those two.
A map of the structure
Information architecture and user flows before any screen. Where does everything live, and how do you get there?
The map isn't the answer. It's a place of comfort, common ground where design and engineering can both stand while we choose a direction.
Design vs. engineering
Screens and data, worked out side by side against the same map. Wireframes, then the design language. Models, normalization, then authorization.
They pull against each other, and that's the useful part. We might be arguing, or confused, but at least we're arguing and confused about the same thing, in the same way.
Produce, release, deliver, then report
Build it, ship it, and bring back what happened.
This is how we reach the end point together: we understand the frictions together and build the team together. A team is the collective knowledge it builds along the way.