There is a standard process with web projects – Brief, Information Architecture, Wireframes, Design, Build, Testing, Launch. It’s established for a reason, it works well in the majority of cases. But there are hidden issues with this process. The concept of ‘throwing it over the wall’ for example, where the developers are only involved once the design is approved and thrown over the wall by the design team. Another potential issue is where project members are not involved and consulted throughout and this can create more work when problems are discovered later on.
Fortunately, there’s a better way. And it’s more fun.
Start Scrappy, Finish Strong
The best websites I’ve worked on didn’t start with a perfect design. They started with designers and developers in the same room (or video call), sketching ideas, building rough demos, and throwing most of them away.
This feels inefficient. It’s actually the opposite.
When designers and developers work in tandem from day one, you discover the problems early. “This animation will tank performance on mobile.” “That layout breaks with real content.” “This feature sounds simple but it’s actually a nightmare to build.” These conversations happen in week one, not week ten.
Why This Works
Problems surface when they’re cheap to fix. A layout issue caught during a quick prototype costs an hour. The same issue discovered after the design is signed off and half-built costs days, plus difficult conversations with the client about timeline and budget.
Everyone stays engaged. Designers see their ideas come to life immediately. Developers have input on what they’re building. Nobody is working in isolation, handing off documents and hoping for the best.
You find solutions you’d never have planned. Some of the best features I’ve seen came from a developer saying “what if we tried this?” during a prototyping session. When you’re in exploration mode, people experiment. When you’re in execution mode, people just build what’s specified.
Get the Client in the Room
Here’s where it gets really interesting: invite the client into this phase.
Most clients see their website twice—once when the design is presented, once when it launches. They’re essentially spectators in their own project.
But when you bring them into the prototyping process, something changes. They see options, not a finished proposal. They can say “I like that direction, but what if…” and actually see the answer twenty minutes later. They feel ownership over the decisions because they were part of making them. It also fends of future questions and issues as you can explain rationale for design decisions early.
This doesn’t mean design by committee. You’re still the expert. But there’s a difference between presenting a solution and exploring solutions together.
What This Actually Looks Like
A typical prototyping phase might run one to two weeks. You’d have:
- Rough sketches and wireframes a more fluid ideation stage, where ideas can be created and scraped
- Quick HTML/CSS/JS demos to test layouts with dummy content, to ensure these things are possible in a real world example
- Working prototypes of any complex interactions, so everyone understands what they’ll actually feel like
- Regular check-ins with the client, even if it’s just fifteen minutes to show progress and get reactions. Sometimes I favour a screen recording rather than a meeting if it’s just demoing concepts.
The output isn’t a finished design. It’s a shared understanding of what you’re building and why.
The Real Benefit
By the time you move into full production, the guesswork is gone. The design has been tested. The technical approach has been validated. The client has seen enough iterations that there are no surprises.
You’ve front-loaded the uncertainty into a phase where it’s safe to be uncertain.
The rest of the project runs faster, smoother, and with far fewer of those painful “actually, can we change…” conversations.
Everyone is involved from day one, collaboration is better and it’s fun you can make things without the pressure and try out innovative solutions rather than relying on established patterns
