标签：#designsystem

For a long time, whenever we hear 'User Experience', we instinctively think of UI/UX designers, product designers, or maybe frontend engineers. Why? Because we tend to think users interact first with a graphical or command-line interface, while the backend engine plays little to no role in how they experience the product. The first half is correct. The second half, incorrect. A user doesn't experience your frontend in isolation. They experience the entire system. As I continue to compound my experience building products as a backend-leaning engineer, I've found it increasingly necessary to think beyond whether an endpoint works or whether an architecture is technically sound. I have to ask: How does this technical decision affect the user's experience? Here's how. 1. API Response Times Become UX A user doesn't care that your endpoint executes 17 database queries, that your service is making five downstream requests, or that your server is experiencing a cold start. They care that they clicked “Pay” three seconds ago and nothing has happened. Eventually, they may refresh the page, click the button again, or abandon the application altogether. The frontend can add a beautiful loading animation, but it cannot completely hide a system that is fundamentally slow. 2. Error Messages Become UX One of the easiest ways to see the relationship between backend engineering and UX is through errors. Imagine trying to make a payment and receiving: 400 Bad Request Technically, something has gone wrong. But the user has learned almost nothing. Compare that with: “Your payment could not be completed because your card was declined. Please try another payment method.” Good backend error handling should therefore answer three questions: What happened? Why did it happen? What can the user do about it? 3. API Design Becomes UX API design can feel very far removed from UX. After all, users don't see JSON responses. But, developers build products using those responses. The decisions we make

How do you usually build a login page in an application? The first project Imagine you are working on a project that needs a login page. Let's call it Aurora (Project A). The login page is the entry point to the application. Users who have access can log in to the application with the permissions they have. We are not going to talk about the details of the login method yet, such as email + password, username + password, phone + password, social login, magic link, or others. Let's say we use email + password for this example. For this, we usually need user data for the application, for example a users table in the database. If we use email and password as the login method, the users table would at least need email and password columns. Of course, the password should be hashed. After the application is developed, users can log in using the email and password registered in the database. During development, we can simply inject user data directly into the database. Adding one or two users manually is still fine. If we need more users, we can create a database script to insert them. Then another requirement appears. We need to manage users directly from the application. Previously, user data could only be accessed directly from the database. Now the application needs to show a list of users, user details, and provide features to create, update, and delete users. We need to build several new pages for this user management feature. Eventually, the feature is completed. Now you can add users whenever you want, and they can immediately use their account to log in to Aurora. At this point, the user requirements for Aurora might be enough. The second project Then you have another project that also needs a login page. Let's call it Borealis (Project B). This is a different project from Aurora, but the login works in a similar way. Since you already built the login feature in the previous project, you can duplicate the existing code into Project B, including the user management

While mass-producing web tools with an AI, I've changed how I lock the design in three stages. The previous post I wrote about that got this comment: "I'd like to see the JSON approach and the design-system approach side by side." Taken at face value, I should just put the two side by side. But first, let me add a short preface. I don't want to frame this as "the JSON approach versus the design-system approach." When I called the JSON approach a "failure" in that post, I didn't mean the method is inferior; I meant it didn't suit my particular set of tools. A page made with the JSON approach does look thin. But where that thinness comes from is easily misread. Whether the design drifts and whether it looks rich are decided separately. What stops the drift is locking the design; whether it looks rich is how much you build out. What locking with JSON removes is drift in the items you specified in the schema. Whether the screen becomes rich, on the other hand, is determined by how much you've built out the machinery that turns that JSON into a screen. So it isn't that locking with JSON is what made it look like a spreadsheet. In the previous post, too, I wrote that fattening the schema and the renderer does increase the expression itself. But that came with a caveat: past a point, it heads toward rebuilding HTML and CSS by hand. What I really want to check is one step past that. If the template sets the ceiling on expression, then building out the JSON side's template as much as the current one should produce the same screen. So what does that build-out demand? I actually built it and measured. I'll share the result, along with the JSON-approach and design-system-approach screens placed side by side under matched test conditions. I'll admit up front: at the time, I chose the design system without running this comparison. So this is me building the road I didn't take, after the fact, and measuring what that cost consists of. Same order, same one-shot So that the comparis

Empirical research from ReWeaver AI. 42 identical prompts, across 5 tools and 8 production dimensions, compared to human baseline. One metric that changes how you see drift. Everyone knows AI-generated code has quality issues. What’s less understood is that the way most teams measure those issues — by how often they occur — systematically understates the risk. We ran a controlled study to find out how badly. The answer surprised us, particularly in one dimension. What We Did We gave five leading AI coding tools (Cursor, Claude Code, Lovable, Figma Make, and VS Code with Copilot) 42 identical prompts: realistic single-component builds — buttons, forms, dashboards, navs, modals, auth surfaces. We scanned every output with ReWeaver, our deterministic drift-detection engine, across eight production readiness dimensions: User Experience Security & Privacy Accessibility Design Consistency Reliability Maintainability Architecture Testability We also scanned six human-authored open-source repositories as a reference baseline. For each dimension, we calculated two things: Drift frequency — the percentage of lines containing at least one drift occurrence. Counts what went wrong. Production Drift Ratio (PDR) . The PDR is a metric that weights frequency by estimated remediation cost on a 0–1 scale. A PDR of 0.30 is roughly 45 minutes of cleanup per component; 0.70 is about 2.5 hours. The Finding That Stopped Us In Security & Privacy , AI tools produced 3× the human drift frequency . That looks manageable — a meaningful gap, but not alarming. The PDR was 22× the human reference . Not 22% more. 22 times more costly to fix. The frequency gap makes Security & Privacy drift look like a minor concern. The PDR reveals it’s the most expensive problem in the dataset. AI-generated security drift (client-side authorization gates bypassable in DevTools, raw PII and credentials passed through props without tokenization) is syntactically identical to safe code. It passes review, but the fixe

For decades, software was designed around one assumption: A human would be the one using it. That...

Most of us treat design systems as a functional problem: consistent colors, consistent spacing, consistent components. That part's solved for most teams now. The part nobody writes down is tone. How should this loading state feel? Should this error feel scary or manageable? Is this confirmation message robotic or human? Here's what I've learned paying attention to that layer. Four moments that carry the emotional weight In any app, four states do most of the emotional work: Loading Error Empty Success Get these four right and the whole product feels better, even if nothing about the actual functionality changed. ** Loading: ambiguity feels worse than the wait itself** jsx // Vague, slightly anxious < Spinner /> // Specific, calmer < div className = "loading-state" > < Spinner /> < p > Fetching your latest data... </ p > </ div > A spinner with no context makes people wonder if something's frozen. A spinner with a short label tells them exactly what's happening. Same wait time, different feeling. Errors: same bug, different emotional outcome jsx // Robotic " Error: Request failed with status 500 " // Human " Something went wrong on our end. Your changes weren't lost, try again in a moment. " The second version does three things the first doesn't: it's plain language, it removes blame from the user, and it tells them what to do next. That's the difference between an error that frustrates and one that reassures. Success: robotic vs genuine jsx // Robotic " Action completed successfully. " // Human " Done! Your changes are saved. " This message shows up constantly across a typical app. If it reads like a system log every time, the product feels cold. A small rewrite makes it feel like a person is on the other end. Micro-interactions: timing is part of tone too `jsx// No feedback during the wait, feels broken <button onClick={handleSave}>Save</button> // Immediate feedback, feels responsive <button onClick={handleSave}> {isSaving ? "Saving..." : "Save"} </button>` A butt

If you're starting a web project, you're probably starting with a CSS reset, and for most of us, that means reaching for a trusted community solution - dropping it in and moving on. If you're building a design system, though, that habit may be working against you. The existing solutions The community reset ecosystem is genuinely good. Each tool approaches the browser compatibility problem from a slightly different angle. Some examples include: Eric Meyer's Reset is a classic: it zeros out margins, padding, and font sizes across every element, giving you a completely blank slate. It's minimal and predictable, which made it influential. Normalize.css smooths over inconsistencies while preserving the ones that are actually useful. sanitize.css and modern-normalize continue that evolution - incorporating contemporary best practices like box-sizing: border-box , improved form element handling, and accessibility-aware defaults. The problem isn't that any of these are bad. The problem is that they're all deliberately, necessarily generic. They can't know anything about your typeface, your color palette, your spacing scale, or how your interactive elements should behave. That's by design - they're tools for everyone, which means they're perfectly tailored for no one. The problem If you're building a design system, generic is exactly what you don't want your reset to be. The moment you drop in one of these resets and start building, you find yourself doing a second round of work. You apply your typeface to body . You reset margins on headings. You make form elements inherit fonts. You define focus styles. You're re-resetting - applying your design language on top of a layer that just cleared out the browser's defaults and replaced them with... more defaults you'll override. Worse, that duplication doesn't stay in one place. Every component you build either re-declares these foundational styles or silently assumes they're already set upstream. You end up with either redundanc

AI design system output is approximate by default. Wrong border radii, raw hex values, inconsistent tokens across 60 components. The fix isn't better prompts. Here's the structural change that made it exact using Figma's REST API. The fourth time I manually corrected the same border radius mistake in an AI-generated component, I stopped and asked why this kept happening. Not "what prompt would fix this?" The deeper question: why does every AI tool I tried get the structure right and the values wrong? The button was correct. The variants were there. The layout matched the Figma spec. But borderRadius: 8 when it should be borderRadius: '8px' . A spacing gap of 8 when the spec said 6 . The color #3B82F6 sitting in the file where semantic.button.primary should be. None of it wrong in a way that breaks the build. All of it wrong in a way that breaks the design system. After hitting this wall enough times, I realized the problem wasn't the AI. It was the question I was asking it. Why AI keeps generating the wrong Figma design tokens When you give an AI tool a Figma screenshot and ask it to produce a component, it does something reasonable: it interprets what it sees. The structure, the layout, the hierarchy - it gets most of that right. What it cannot get right is the token mapping. The AI doesn't know your semantic token file. It doesn't know that #3B82F6 maps to semantic.button.primary in your codebase. It doesn't know that your MUI setup multiplies numeric border radii by 4, which means borderRadius: 8 renders at 32px instead of 8px . So it approximates. Here's what that looks like in practice: What AI produces What the spec requires Why it's wrong borderRadius: 8 borderRadius: '8px' MUI multiplies numeric values by 4 gap: 8 gap: 6 Spacing value not extracted from Figma color: '#3B82F6' semantic.button.primary Raw hex instead of semantic token fontSize: 14 variant="MD_Medium" Typography token not resolved Across one component, these deviations are small. Across 60 comp