Somewhere in CRED Cashflow’s routing logic sits a decision nobody claimed: if a user qualifies for two interventions at once, which one do they see?
No brief assigns that to design. It gets made anyway, by whichever engineer builds the routing table, using whatever default ships fastest.
That’s not a gap in the spec. It’s the norm. Decisions about the user experience don’t stop at the interface. Someone still has to decide what happens when two signals overlap, what a constraint actually means, or who owns the fallback.
I’ve built my process around a different belief: if a decision materially changes what a user experiences, design should have a point of view on it, regardless of which layer it lives in. A screen, a PM’s priority call, an engineering constraint, a routing table, or a document nobody reads twice.
Context
’m building Thryve, an app to help people be more mindful of frictionless UPI spending, BNPL/EMI hooks, and pricing patterns that exploit impulse around something as mundane as groceries.
The eventual product needs to be a standalone UPI app. That would give Thryve the access to actually intervene. But that also means NPCI certification and PSP partnerships before a single hypothesis gets tested.
So instead of a blank slate, I tested the idea against a platform that already carries those constraints. I designed it as CRED Cashflow, because CRED already has the UPI context and the regulatory reality. If the idea couldn’t survive CRED’s constraints, it wasn’t going to survive Thryve’s future ones either.
I proactively contributed to three conversations that would normally happen without me: a PM review, an engineering audit, and the routing logic itself, as if the feature were really shipping.
Each one tested a different part of the belief.
One of them didn’t survive.
Room One: The stakeholder lens
Before showing the first prototype to anyone, I modeled how a CRED PM would read it.
The lens was different from mine: acquisition metrics over feature completeness, cautious around vague AA consent language, and looking for legal defensibility before evaluating the experience itself.
Running the prototype through that lens surfaced ten product level issues.
One was a CTA that apologized for a platform limitation. From the user’s perspective, that framed a constraint as something CRED couldn’t do rather than something the product could help them understand or act on.
That changed how I framed the interaction.
The exercise wasn’t a substitute for a real stakeholder review. It was a way to arrive with sharper questions instead of asking someone else to find every ambiguity for me.
Room Two: The 8 to 10 week assumption
The engineering review returned a Hard No on pre payment Spend Pause:
“Payment flow interception. CRED Pay platform team. 8 to 10 week runway.”
My first instinct was to accept it. Payment interception sounds like exactly the kind of change that should require a platform team.
It held until I traced where NPCI’s involvement actually starts: not at “Confirm amount,” but at PIN entry.
Everything before that is CRED’s own UI.
The initial framing suggested an 8 to 10 week platform dependency. Tracing the boundary more precisely turned it into a mobile sprint item using an endpoint that already existed.
That didn’t settle the question, though.
The negotiated outcome was to move pre payment Spend Pause to V1.1 and ship the post payment card first. The simpler interaction could validate the underlying signal before introducing a more disruptive interrupt into the payment flow.
The architecture and the rollout order turned out to be two different decisions.
Room Three: When the routing logic broke
The persona routing hierarchy, P3 → P2 → P4 → P1, decides which persona’s card a user sees when they qualify for more than one signal at once.
P3, the most specific signal, matches first. P1 catches everyone else by default.
Nobody assigns that ordering to design.
I claimed it anyway and put it through the same review as everything else.
That’s where it broke.
Legal found that P3 couldn’t ship at all. There were three unresolved regulatory blockers.
That didn’t just remove a persona from the roadmap. It broke the routing branch I was most confident about.
I chose to let P3 qualified users fall through to the P2 experience rather than create a dedicated holding state. A second fallback would have added scope without changing what users actually saw during the beta.
The legal review didn’t add a footnote to the routing model. It changed the decision itself.
The branch I was most confident about was the first one to break.
What a decision record is actually for
Each room produced a document that cross references the others.
The PM review names the screens. The engineering assessment names the open questions. The legal audit specifies who else has to sign off.
That’s not proof the work happened.
It’s continuity.
Why does the product look like this? What was decided? What remains uncertain? And who has to agree before it changes?
A decision record gives the next person enough context to challenge the decision without having to reconstruct the entire conversation.
Distilled Principles
1
Decisions that shape the user experience need an owner, even when implementation sits elsewhere.
2
Trace constraints before accepting them. The constraint can be real while the framing is wrong.
3
Technical feasibility and rollout order are different decisions. A simpler test can still come first.
4
Let evidence change the decision. Good judgment includes knowing when the original assumption no longer holds.
Whats Still Uncertain
Room Three showed that the belief doesn’t always survive intact. Legal’s finding forced a real revision rather than validating the decision.
The open question is whether I can recognize that point quickly enough on my own, or whether it takes someone with actual authority to force the rethink.
That’s something Thryve still has to test on infrastructure I actually have to build, not borrow.
Design doesn’t end at the interface. It means claiming the decision, making the trade off visible, and letting the people with actual authority tell you when you’re wrong.