How I work frameworks defended in interviews.
Four areas I've shipped real outcomes in, across Mobcoder, Vaipratech, SpeakX, and Dalvoy. Each section is a defensible POV: the framework I use, why I use it, and one shipped example.
Tokens are decisions. Components are defaults. Governance is everything.
Most design systems fail not at the component level but at the governance level. Teams build a component library, publish it to Figma, and then watch it drift within six months as individual contributors make one-off decisions under deadline pressure. The system decays because no one owns the contract.
My POV: a design system is not a UI kit. It is a decision framework made tangible. Every token is an encoded design decision: "this is our primary surface background at rest." Every component is a default that saves a designer from making that decision again under pressure. Governance is the process that keeps decisions from silently forking.
The order matters. You cannot build robust components without a sound token layer, and you cannot ship a token layer without an audit that maps existing values to semantic roles. Skip the audit and you're encoding the mess.
- Audit: Catalog all existing visual values and map them to semantic roles. Expose every divergence.
- Tokens: Define a semantic token layer (primitive → semantic → component). Document the decision behind every token, not just the value.
- Primitives: Build base components that consume tokens and nothing else. No hardcoded hex values, ever.
- Patterns: Compose primitives into opinionated patterns that encode product-specific decisions (e.g. how a form validates, not just how an input looks).
- Governance: Establish a contribution model, a deprecation protocol, and a weekly sync. Assign an owner per surface. Without this, repeat from step one in six months.
"A token layer without a decision rationale is just a spreadsheet. The rationale is the system."
Friction is a tax on intent. Every screen past 90 seconds costs you 3%.
Conversion problems are almost never what they appear to be. Teams look at a leaky funnel step and reach for the obvious fix: shorten the form, reduce the fields, add a progress bar. Sometimes that works. More often it doesn't, because the friction isn't the cause. It's a symptom.
My process is to go upstream before I go to Figma. I spend the first days in the funnel data, support tickets, and user sessions, looking for the pattern in the drop-off. Is it a specific device type? A time-of-day cluster? A specific error state hitting 12% of users? The root cause shapes the intervention. You cannot design your way out of a trust problem by shortening a form.
The framework I use: Funnel analysis to locate the cliff. Hypothesis formation to name the root cause. Variant design to address the root cause, not the symptom. Measurement against a pre-agreed metric with a clearly defined minimum detectable effect. If you don't agree on the metric before you design, you'll argue about it after.
- Funnel: Map the drop-off precisely. Which step, which device, which segment. Don't skip this.
- Hypothesis: Name the root cause in one sentence. "Users are dropping because they distrust the app with their documents, not because the flow has too many steps."
- Variant: Design the intervention that addresses the hypothesis. Keep it surgically targeted. One variable per test when possible.
- Measurement: Agree on the primary metric, the minimum detectable effect, and the sample size before any pixel is committed to code.
"The root cause was distrust, not friction. Shortening the form would have moved the metric by 3%. Addressing trust moved it by 32%."
Retention is a story problem, not a notification problem.
The most common retention play is a push notification campaign. It is also the most frequently wrong one. Notifications do not create habits. They interrupt users who have already stopped caring, which makes the problem worse over time as users opt out or tune out entirely.
Real retention is earned at the product level. It is a function of whether the product reliably delivers on its core value loop fast enough, clearly enough, and often enough to become part of a user's existing routine. If D7 retention is poor, the problem is almost always in the activation experience: users never reached the aha moment, so there is no habit to retain.
The habit loop framework: Trigger (the cue that prompts action), Action (the simplest behavior in anticipation of reward), Variable Reward (the reward that keeps users returning, it must be variable, not constant), Investment (the user puts something into the product that makes future value greater). Every low-retention product I've worked on has a broken link in this chain. Find the break; fix the break.
- Map the habit loop: Draw the trigger, action, reward, and investment for your core loop. Be specific about what each is for your actual users.
- Diagnose the break: Where does the chain fail? Missing trigger? Too much friction before reward? No investment mechanism? Session replay and cohort analysis reveal this faster than surveys.
- Intervene at the break: Don't redesign the whole product. Precisely address the single weakest link. One intervention, one metric.
- Measure D1, D7, D30: Retention curves tell a different story at each horizon. A D1 lift that vanishes by D7 means the problem shifted downstream.
"Notifications are a tax on trust. If you're sending them to rescue a retention metric, the problem is upstream."
Engagement without intent is vanity. DAU is not a strategy.
DAU is a metric that tells you how many people opened your app. It tells you almost nothing about whether those people did something meaningful. Engagement design that chases raw session counts produces dark patterns: infinite scroll, notification spam, artificially induced urgency. These inflate the number and erode the product.
The engagement I care about is intentional engagement: users returning to do the thing the product exists to help them do, and doing it more successfully over time. That requires designing the path from first session to activated user, from "I just downloaded this" to "this is now part of how I work."
The activation-to-habit arc: Activation (first meaningful action, the one that proves to the user the product can deliver). Aha moment (the specific moment the user understands the core value promise). Habit formation (the user builds a predictable pattern of use). Loop (the product creates triggers that sustain the pattern without feeling manipulative).
- Define activation: What is the single action that signals a user has experienced the core value? Make this the north star metric for engagement design.
- Instrument the aha moment: Track time-to-aha and correlation with long-term retention. If users who reach aha within 3 minutes retain at 2× the rate, design everything to accelerate that path.
- Design for habit: Reduce friction on the core action. Introduce the variable reward. Build the investment mechanism. Remove everything that doesn't serve the loop.
- Audit for dark patterns: Before shipping, ask: if this feature were removed, would real users notice and complain? If not, it's probably inflation, not engagement.
"If the engagement is real, removing the prompt doesn't change the behaviour. That's the test."
Want to dig deeper into any of these?
I'm happy to walk through frameworks, trade-offs, and specific decisions in a conversation. Email is the fastest way in.