Balkrushn Koladiya
Every design team eventually settles into a rhythm — a mix of discovery calls, wireframes, prototypes, and feedback loops that gets repeated project after project. The mistake we see most often, including in our own early years, is treating that rhythm as sacred. It's not. What matters is the outcome it produces, not how closely the team stuck to the plan.
A client came to us a while back with a dashboard redesign that had already gone through two agencies. Both had followed a textbook UX process — personas, journey maps, the works — and both had shipped something the internal team still avoided using. The problem wasn't a missing step. It was that nobody had sat down with the three people who actually opened that dashboard every morning and asked what made them close it in frustration.
So we skipped half the usual deck-building and just watched them work for two days. That's not a repeatable 'process' in the way agencies like to market it. It's closer to triage.
Process should adapt to the project
A five-page marketing site doesn't need the same rigor as a multi-role SaaS dashboard, and pretending otherwise just burns budget. We scale research, wireframing, and testing up or down based on how much is actually at risk if we get it wrong. For a landing page, that risk is a bounce rate. For an internal tool three teams depend on daily, it's hours of lost productivity, every single day, for as long as the bad decision stays live.
That doesn't mean we skip steps carelessly. It means the depth of each step is a judgment call, not a template. Sometimes a single working prototype answers more questions than three weeks of wireframes ever could. The skill isn't knowing every step in the standard process — it's knowing which ones this particular project can afford to skip.
What a scoped-down process actually looks like
On smaller engagements we've compressed what would normally be a four-week discovery phase into three focused days: one for stakeholder interviews, one for a competitive walkthrough, and one for sketching and rough prioritization. It's uncomfortable at first for teams used to more ceremony. It also gets a working prototype in front of real users two and a half weeks sooner, which is where the actual learning happens anyway.
- Start with the decision the design needs to inform, not the deliverable it's supposed to produce.
- Interview the people who will actually use the thing daily, not just the stakeholders who commissioned it.
- Prototype the riskiest assumption first, not the easiest screen to mock up.
- Treat every artifact — persona, journey map, wireframe — as disposable the moment it stops answering a question.
Validation is the one non-negotiable
The one constant across every engagement, regardless of how loose or structured it gets, is validation: talking to real users, testing with real data, and being willing to throw away work that doesn't hold up — even work we were proud of on day one. It stings a little every time. It's also the difference between a portfolio piece and a product people actually keep using six months later.
We've learned to schedule validation early enough that a bad direction is still cheap to abandon. Catching a flawed assumption in week one costs a afternoon of rework. Catching the same flaw after development has started costs a sprint, a difficult client conversation, and usually some trust that takes longer to rebuild than the feature did to fix.
Where teams get this wrong
The most common failure mode isn't skipping process entirely — it's running the full process on autopilot without asking whether each step is earning its place. Personas built once and never revisited. Journey maps that describe how the team wishes users behaved rather than how they actually do. Usability testing scheduled at the end, as a formality, after every major decision has already been locked in and nobody has the appetite to change course.
We try to catch this by asking, before every phase, what specific decision it's meant to unblock. If nobody in the room can answer that question, the phase gets cut or replaced with something faster that answers a real one.
If there's a lesson worth taking from this, it's that the process itself is disposable. The habit of checking your assumptions against reality isn't. Teams that internalize that distinction ship products people keep coming back to. Teams that mistake the process for the goal ship documentation nobody reads and dashboards nobody opens.
Documenting decisions without freezing them
One habit that's made the scaled-down approach easier to sell internally is keeping a short running log of why each decision was made, not just what was decided. When a stakeholder asks three weeks later why we skipped formal persona documents, we can point to the actual reasoning instead of relitigating it from memory. It also makes it much easier to revisit a decision later without it feeling like an accusation that the original call was wrong — sometimes the project has simply changed enough that a different amount of rigor is now justified.
The log doesn't need to be elaborate. A single paragraph per major decision, written the same day it's made, has been enough on every project we've tried it on. What matters is that it exists before memory starts filling in a tidier story than what actually happened.
Bringing clients along with a leaner process
Clients used to a heavier, more document-driven agency relationship sometimes read a leaner process as a lack of rigor rather than a deliberate choice. The fix isn't padding the process back out for optics — it's being explicit upfront about what's being scaled down and why, and showing the validation checkpoints that replace the missing documentation. A working prototype tested with five real users in week two tends to earn more trust than a fifteen-page discovery report delivered in week four, once clients see the results side by side.
A note on onboarding new team members into this way of working
A leaner, judgment-driven process is harder to hand off to a new hire than a rigid one, precisely because there's no fixed script to follow. What's worked for us is pairing new designers on their first two or three projects with someone who's internalized the decision-making, specifically so they see the reasoning behind why a step got cut or kept, not just the outcome. Documentation alone doesn't transfer judgment. Watching the calls get made a few times, in context, does.
