Without baseline metrics, UX improvements are invisible. Here's how to measure design impact—and why AI coding tools need a design stack to deliver it.
Design teams across Southeast Asia are shipping faster than ever — AI-assisted coding tools, component libraries, and agile sprints have compressed timelines that once took quarters into weeks. The uncomfortable irony: most of those teams still can’t tell you, with any precision, whether their work actually moved the needle.
Two separate threads from the UX community this week converge on the same underlying problem. One is about measurement discipline. The other is about tooling integrity. Both are really about the same thing: making design commercially legible.
The Baseline Problem Nobody Wants to Admit
Nielsen Norman Group makes a case that should feel obvious but apparently isn’t: before you redesign anything, measure what you already have. Taylor Dykes and Pavel Samsonov argue that establishing baseline metrics — task completion rates, time-on-task, error frequency, satisfaction scores — before a project begins is what separates a design team that can demonstrate impact from one that can only describe intent.
The business case is straightforward. If a checkout redesign for a Shopee-integrated e-commerce brand takes the add-to-cart rate from 3.2% to 4.7%, that’s a story you can tell a CFO. If you never measured the 3.2%, you’re left saying “we improved the experience” — which, to a growth lead staring at a revenue dashboard, is not a story at all.
For Southeast Asian brands managing multi-platform presences across Lazada, Shopee, and owned web properties, baseline discipline becomes even more critical. Mobile conversion rates on LINE-integrated storefronts behave differently from desktop web flows. Collapsing those into a single “before” number obscures what you actually fixed — and for whom.
The practical starting point: instrument your most commercially significant user flows first. For most e-commerce teams, that’s the path from product page to payment confirmation. Track it by device type and platform before touching a single component.
Why AI Coding Tools Break Without a Design Stack
As more design and development teams adopt AI-assisted coding environments — Claude Code being a prominent example — a quieter failure mode is emerging. Sen Lin’s analysis on UX Collective identifies it precisely: when you feed an AI coding tool a prompt without grounding it in a design system, you get functional code that is visually and experientially incoherent.
The problem isn’t the AI. It’s the absence of constraints. A design stack — tokens, component specs, spacing scales, accessibility rules, brand guidelines — functions as the guardrails that keep AI-generated UI from drifting into generic, off-brand output. Without it, every AI-assisted sprint compounds design debt instead of reducing it.
For teams building in multilingual environments, which is almost every brand operating at scale in Southeast Asia, this matters doubly. Thai, Bahasa Indonesia, and Vietnamese text behave differently in fixed-width containers. If your design tokens don’t encode those constraints, AI-generated components will break in localised builds — and you won’t catch it until it’s in front of users.
The implementation recommendation is concrete: before onboarding any AI coding assistant, export your design system to a machine-readable format (JSON design tokens, a Figma API integration, or a documented component library the AI can reference). Treat it as infrastructure, not a nice-to-have.
Connecting the Dots: Design as a Measurable Asset
These two ideas — baseline measurement and design system integrity — are not separate best practices. They’re two sides of the same commercial argument.
A design system without measurement tells you nothing about whether your components are working. Measurement without a design system makes it impossible to isolate variables — you can’t know if a conversion improvement came from a layout change, a copy tweak, or the fact that you finally fixed a broken CTA on mobile.
Together, they form what a monetisation-minded design team actually needs: a feedback loop. You establish baselines on the current system, ship changes within the constraints of a documented design system, and measure delta. Repeat. Over time, this is how design transforms from a cost centre into a documented revenue driver — which is a conversation that lands very differently in a budget meeting.
Grab’s super-app interface is instructive here. The consistency of its UI across ride-hailing, food delivery, and financial services isn’t just a brand decision — it’s a measurement strategy. A unified design system means any conversion experiment in one vertical can be benchmarked against a stable baseline, not a moving target of ad-hoc component variations.
The Stakeholder Buy-In Problem Is Actually a Data Problem
Design leaders often frame the challenge of getting executive support as a communication problem. It’s more accurate to call it a data problem. Stakeholders don’t resist investing in design because they don’t understand it — they resist because design teams historically haven’t produced the evidence that justifies the investment.
Establishing baselines and maintaining design system discipline are both, at their core, acts of institutional credibility-building. A team that can say “our checkout redesign reduced drop-off at the payment step by 18% on Android, based on a four-week pre-launch baseline” is a team that gets budget for the next project.
The timeline implication is real: proper baseline collection typically requires two to four weeks of instrumented observation before a project kicks off. That’s a hard sell to a product manager under delivery pressure. The counter-argument — that shipping without a baseline means you’ll never know if the work succeeded — is usually enough, once framed in terms of commercial accountability rather than UX orthodoxy.
Key Takeaways
- Establish device-segmented, flow-specific baselines two to four weeks before any significant UX project begins — or the results will be commercially indefensible.
- Export your design system as machine-readable tokens before integrating AI coding tools, or every sprint will compound visual and localisation debt.
- Frame baseline measurement and design system discipline to stakeholders as revenue accountability tools, not UX process requirements.
The broader question worth sitting with: as AI accelerates the rate at which interfaces can be built, does the design profession’s value proposition shift entirely toward measurement and constraint-setting — away from craft, toward architecture? That might be the more interesting conversation for design leads in Southeast Asia to be having right now.
At grzzly, we help brands across Southeast Asia build the measurement infrastructure and design system foundations that make UX work commercially visible — from baseline instrumentation to design token architecture that holds up across Shopee, LINE, and owned channels. If your team is shipping fast but struggling to prove the impact, that’s exactly the kind of problem we find interesting. Let’s talk
Sources
Written by
Inkblot GrizzlyCrafting dashboards that tell the truth, and monetisation frameworks that make that truth commercially useful. Turns abstract data assets into revenue-generating products for publishers and brands alike.