Open Dribbble. Scroll for ten minutes. Open Behance. Scroll for ten more.

Now ask yourself honestly: did you get an idea, or did you get a feeling that everything looks the same?

I’ve done this loop more times than I’d like to admit. Same gradients. Same glassy cards. Same “clean” dashboards wearing slightly different shades of purple. I was surrounded by design, and I was running out of ideas.

So one weekend, I did something that had nothing to do with design. I went to an art meet in a park in Delhi, hosted by Big Aaaaart Club together with The Art Curry (@the.art.curry).

Under the trees, nobody was networking…

I didn’t know what to expect. What I found was an open garden, with people spread out under the trees on yellow-and-white striped sheets, just… making things. This was a Big Art Club meet, hosted with The Art Curry at Priya Park in Vasant Vihar, and the whole afternoon felt more like a festival than an event. They host these regularly, in different spots around Delhi, so it’s a community that keeps showing up, not a one-off.

There was no stage and no schedule to follow. Nobody was pitching. Nobody was handing out business cards. People had brought their own food and set it out like a shared picnic. Someone was building music live from a handful of small synth boxes, sitting on a cloth painted “Music for Planet, Love, Peace.” A few feet away, a guitar came out and a circle formed around it. Nearby, a cork board with the words “Display Your Art” was slowly filling up with everyone’s pinned-up work. There were small, silly activities too, like bubble-making, that pulled in people who had come to watch and left holding a brush or a bubble wand.

And the people! College students sitting next to working professionals. People from fields I’d never worked in. Different ages, different jobs, different reasons for being there. The only thing they had in common was that they’d all shown up to be creative, with no brief, no client and no deadline.

Why this beats another hour of scrolling

Here’s the uncomfortable truth I took home: if every designer looks at the same places, we all end up making the same things.

Austin Kleon, author of Steal Like an Artist, has a way of describing where ideas actually come from:

“I think the only truly honorable thing to do is to locate yourself in a kind of lineage.”

His point is that creative work is built on what came before it, and on the people around you. In the same conversation, he says it plainly:

“So creative work is always a collaboration.”

(Both from Austin Kleon’s conversation on the TED podcast.)

Dribbble gives you the output of other designers’ work. A garden full of artists, musicians and strangers gives you something better: their thinking. How they get unstuck. What they do when a piece isn’t working. Why they care about the things they care about.

Elizabeth Gilbert, author of Big Magic, describes a creative life like this:

“For me, a lifetime devoted to creativity is nothing but a scavenger hunt where each successive clue is another tiny little hit of curiosity.”

(From Elizabeth Gilbert’s own site.)

A scavenger hunt only works if you leave the house. Curiosity doesn’t come from a feed that was built to show you more of what you’ve already seen.

What a musician can teach a product designer ?

I want to be careful here, because “go outside, find inspiration” can sound like a cliché. So here’s what I actually mean.

Watching someone layer a track one small box at a time is a lesson in building a system from simple parts. When a musician in a jam sits back and lets someone else take the lead, that’s hierarchy and restraint. And when a painter leaves part of the page empty, or a singer holds a silence between two lines, that’s whitespace and pacing.

None of them were talking about design. All of them were talking about design.

That’s the real gift of a mixed crowd. You don’t get answers to your brief. You get new questions about it, from angles you’d never reach on your own.

Does this actually make you better at your job?

Yes, and not in a vague, “feel-good” way. Here’s what I noticed:

• Fresher starting points. When your references come from music, painting and conversation, your first ideas stop looking like everyone else’s first ideas.
• Less fear of rough work. In a place where people share unfinished pieces, “not ready yet” stops feeling like failure. That makes you faster at showing early work at your job, and getting feedback sooner.
• Better conversations with non-designers. Explaining why you made something to a stranger who isn’t in design is great practice for explaining it to a stakeholder.
• A quiet recharge. Making something with no goal reminds you why you started. That energy shows up on Monday.

Rick Rubin, in The Creative Act, puts the idea of a safe, open space this way:

“Create an environment where you’re free to express what you’re afraid to express.”

(From Rick Rubin’s The Creative Act: A Way of Being*.)*

That’s what that afternoon in the park felt like. A place where nothing had to be good, which is exactly why good things started to happen.

What I’m taking back to my desk

I still open Dribbble. I still love good UI. But I’ve stopped treating it as my only source of ideas.

Because the designers who stand out aren’t always the ones with the best taste in design. They’re the ones with the widest taste in everything else: music, food, art, people, stories. That’s what shows up in their work, even when you can’t point to it.

So here’s my challenge for you: this month, spend one evening or weekend somewhere that has nothing to do with your job. Bring curiosity. Leave with one question you didn’t have before.

And if you’re in Delhi, the timing is perfect. Peak winter is the best season for a picnic, a greet-and-meet and an afternoon outdoors with creative people.

Your next great idea might not be on a screen at all.

How to find your own meetup

You don’t need a specific club. You need any open, no-agenda space where creative people with different jobs come together:

1. Look for art clubs, open mics, sketch meetups, park jams or book clubs in your city or online. In Delhi, Big Art Club and The Art Curry (@the.art.curry) host meets regularly in different places, so follow them to catch the next one. Book clubs count too, with pages instead of paint.
2. Go for the format, not the field. Pick something where people make or discuss, not where they pitch.
3. Bring something, even something small. A sketchbook, a snack, a song you like. It’s the easiest way to join in.
4. Don’t talk shop first. Ask what people are working on, or what they love. Design will come up on its own, and it will sound different.
5. Share something unfinished. It’s the best practice for the rest of your career.
6. Go more than once. The first visit is awkward. The second feels like a community.

Remember the Teams message I got at Tedekstra, the screenshot of three different “primary buttons” living in the same product? That was the moment I stopped believing consistency just happens.

What I didn’t tell you is how I found the other eleven.

I opened every live product I’d shipped for our different clients and counted by hand. Fourteen button styles. Nine spacing values that were all “supposed to be” 8px. Several date pickers, each with its own bugs. As the only designer, I did it all myself, one screen at a time, and it was some of the most tedious, important work I’ve ever done.

Looking back, almost every step of that audit is something AI does well today. But when I started using it for design system work, I learned the more interesting part: AI is brilliant at the counting, and quietly dangerous at the deciding.

And there’s a bigger shift underneath that. For years, I wrote my design system for people: developers, teammates, the next designer who’d join. Now there’s a second reader in the room, and it doesn’t skim, guess, or ask a colleague what I meant. It reads exactly what’s there. That changes how a system should be built, and it’s what the rest of this article is about.

What AI is genuinely great at…

Here’s where I’d put it to work first, in the order I’d do it:

1. The audit. Appoint a coding assistant like Claude Code or Cursor at a codebase and ask it to list every button variant, every hard-coded color, every spacing value that isn’t on your scale. This is pattern-matching across thousands of lines, exactly what it’s built for. My hand-counted spreadsheet becomes a one-prompt report.

2. Drafting tokens. Once you know the chaos, AI can propose a clean token structure (color, spacing, type, radius) and map your messy existing values onto it. It gives you a first draft to argue with, which is far easier than a blank page.

3. Documentation. Nobody loves writing component docs, which is why they’re usually stale. AI can draft usage notes, states, and accessibility requirements straight from the component itself, for a human to correct.

4. Catching drift. After launch, systems rot quietly. AI is a tireless reviewer that flags the new developer’s fifteenth button before it merges.

None of this replaces taste. It replaces the part of the job that made me dread opening the spreadsheet.

The catch: Your system now has two audiences…

This is the shift I find most interesting. A design system used to be written for humans. Now it’s also read by machines.

Diana Wolosin, speaking about Indeed’s design system, put it bluntly:

“Our docs are written for humans. The new user, AI, needs structured metadata, not documentation prose.”

And Pierre Bremell was just as direct about what happens when you skip that work:

“If the structure of your system is not consistent and machine-readable, tools like Cursor will fail to understand it.”

(Wolosin’s quote is from Into Design Systems; Bremell’s is from Supernova’s AI-ready design systems guide.)

I read that and winced, because it described my early work exactly. Same blue named three different ways. A “Primary” in Figma that was “btn-main” in code. A human could muddle through. A machine can’t. The unglamorous truth is that AI makes naming discipline matter more, not less.

Which tools help most (by job, not by hype)

I stopped asking “which AI tool is best” and started asking “which job is this?”

One practical tip from the Supernova piece worth following: keep token values identical in Figma and code, and serve them somewhere tools can query directly, instead of leaving them locked in a design file. If the machine and the human are reading different truths, you’ve built the fourteen-buttons problem all over again.

The measures that actually matter…

You don’t need fancy dashboards. Here is how I’d decide whether AI is helping or just making noise:

• Duplicate count: how many near-identical components exist before versus after?
• Token coverage: what share of hard-coded values now reference a token?
• Naming consistency: does a token, prop, and variant have the same name in design, docs, and code?
• Time to first screen: how long does a new project take to reach a real, on-system screen?
• Review corrections: how often do humans have to fix what AI drafted? If it’s constant, your system’s structure is the problem, not the AI.

What I’d never hand over…

The Into Design Systems write-up suggests setting AI permissions by action, not by tool: let it make low-risk fixes directly, have it propose medium-risk changes for review, and keep high-impact calls, like breaking changes or new APIs, as suggestions only.

I’d go a step further. Romina Kavcic put it simply:

“Some decisions will never go past level three because they’ll always need human judgment.”

At Tedekstra, the hardest moment was never finding the fourteen buttons. It was deciding which one was right when a client’s brand conflicted with accessibility, and writing down why, so I wasn’t re-arguing it on the next project. No tool can own that. It’s governance, and governance is a human act.

TJ Pitre of Southleft said it best, in just six words:

“AI just turns the lights on.”

It shows you the mess faster. It doesn’t tell you what to do about it.

If you’re about to start

1. Audit first, with AI. Let it count. You decide.
2. Fix names before you generate anything. Consistent naming is the cheapest way to make AI useful.
3. Start with one slice. One component, one token group. Expand once it works.
4. Write down the why. Machines need structure; your next teammate needs reasoning. Capture both.
5. Keep the final call. Let AI draft, flag, and fix small things. You own the decisions that change what the system means.

My three buttons eventually became one. AI would have found them in a minute. But the conversation that made them one, about who decides and why, was always going to be a human one.

Your Design System Now Has Two Readers. Only One of Them Is Human. was originally published in Design Systems Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Nobody warns you that a design system doesn’t fail loudly. It fails in small, forgivable ways — a slightly-off button here, an ignored component there — until one day you’re maintaining three products that all claim to share the same system and don’t, really, at all.

I built mine solo, across three unrelated clients at once, with no one to catch these failures but me. Here are the five that actually happened, and the quote or book that helped me name — and fix — each one.

1. Nobody agrees on what “consistent” even means.

The first failure looked like fourteen different button styles living across three client projects, each one built by someone who was being perfectly reasonable in the moment. Nobody was careless. There just wasn’t a shared definition of “the same.”

Brad Frost’s ‘Atomic Design’ gave me the fix, and it wasn’t a rule — it was a sequence: make a thing, show that it’s useful, make it official. I stopped trying to define consistency in the abstract and started defining it one real, proven component at a time. The button didn’t become official because I said so. It became official because three separate screens had already needed it.

2. Nobody uses the system, even after you build it.

I learned the hard way that a beautifully documented system is worthless if people quietly route around it. This isn’t a communication problem, and more email reminders won’t fix it either.

Designer Victoria Vilariño named the real cause better than I could: teams adopt a system not because it exists, but because it makes their work genuinely easier — it reduces the cognitive load of working on a complex product at scale. My system only got used once it started saving people time on their worst, most rushed day — not when it was merely well-organized on my best one.

3. Nobody knows who’s allowed to change what.

The third failure was quieter: a slow, low-grade tension over who got the final say when a client’s brand guidelines disagreed with our own spacing rules. Without an answer, everyone just built their own workaround.

Alla Kholmatova’s Design Systems reframed the whole problem for me in five words: consistency helps to build trust. I stopped treating governance as a rulebook and started treating every documented decision as a promise to whoever touched it next — a developer I’d never meet, a client’s future in-house team. Once ownership was framed as “who’s keeping this promise,” not “who’s in charge,” the tension mostly dissolved on its own.

4. The documentation is already wrong by the time anyone reads it.

The fourth failure crept in slowly. A component would get quietly reworked mid-project, and the documentation describing it stayed exactly as it was — accurate the day I wrote it, misleading three weeks later.

Cyrille Martraire’s Living Documentation reframed documentation itself for me: it’s about knowledge and decision-making happening continuously, not a PDF frozen in time. I stopped treating documentation updates as a separate task to schedule and started treating them as part of shipping the component itself — no component was “done” until its doc page matched it, in the same sitting.

5. The system is either too rigid or too loose, and never both at once.

The last failure was the hardest to see coming: a system strict enough to frustrate a genuinely new client need, or loose enough that every one-off request quietly became a new “official” pattern nobody agreed to.

The clearest fix I found wasn’t from a book — it was a simple working motto from design-systems writer Jon Daiello: one is an outlier, two is something to watch, three becomes a pattern. I stopped debating flexibility in the abstract and started literally counting repeats before promoting anything into the system. It turned an emotional argument about taste into a small, calm, countable rule.

What actually changed in how I think

Looking back, none of these five fixes were really about better tooling. They were about catching myself asking the wrong question. “Is this consistent?” became “has this been proven useful more than once?” “Will people adopt this?” became “does this make someone’s worst day easier?” “Who’s in charge here?” became “whose trust am I keeping?”

That shift — from rules to evidence, from authority to trust — is the actual skill nobody puts in a design-system job description. The components were never really the hard part. Noticing which question I was quietly asking myself, under deadline pressure, always was.

Last month, I applied to five roles in the same week. All five said “Product Designer” in the title. Not one of them was asking for the same job.

One wanted someone fluent in prototyping and technical feasibility, closer to a UX engineer than a visual designer. Another wanted a design-system owner who’d mentor junior designers and carry direct reports. A third — an “AI Experience Designer” wearing a UI Architect badge — wanted someone exploring what design even means when AI generates half the interface. A fourth wanted pure visual craft: typography, spacing, taste, nothing else. A fifth wanted a researcher first, someone who’d spend most of the week talking to users on an AI-native platform.

Same two words on every job post. Five almost unrelated jobs underneath them.

This isn’t just me being unlucky

I went looking for whether this was a personal pattern or something bigger, and it turns out designers have been saying the quiet part out loud for a while now.

Jakob Nielsen — about as established a voice as UX has — has a name for it: UX vocabulary inflation. His point is blunt: the field’s terminology has grown faster and looser than the actual distinctions it’s supposed to describe, which is exactly why “Product Designer vs. UX Designer” arguments never really resolve. Nobody’s wrong. The words just don’t mean one thing anymore.

A recent essay that made the rounds put the hiring-side confusion even more sharply: a single “Product Designer” listing now routinely asks for strategy, front-end code, research, and “a builder’s mindset,” all in one person, and the same title means something different almost everywhere you look. The writer’s diagnosis stuck with me — companies aren’t being coy about it. Many of them genuinely haven’t worked out what they need design to be, so the job post ends up describing a role that doesn’t have a name yet.

Tom Scott, a designer who’s spent over a decade on the hiring side, drew a clean before-and-after on LinkedIn earlier this year: 2018 to 2023 was the “process, process, process” era of design hiring. 2024 through now is “show, don’t tell” — output over narrated methodology.

That shift alone would be enough to make job titles slippery. Layer title inflation on top of it, and it’s no wonder half the “Product Designer” posts I’m reading feel like they were written by three different departments who never spoke to each other.

Even the recruiting side admits it. One executive recruiter, quoted discussing Figma’s own hiring research, said hiring managers keep hunting for unicorns because they misunderstand how multidisciplinary design is — asking for five specialists’ worth of skill inside one junior-to-mid salary band, under one increasingly meaningless title.

My actual take, as someone living inside this right now…

Here’s the uncomfortable part: I don’t think this is temporary chaos that settles once the industry “figures it out.” I think the title was already too small for the job, and AI just made that visible faster than anyone expected.

What I’ve had to do, practically, is stop reading job titles at all and start reading the second paragraph — the one that actually lists what you’d do on a Tuesday. A “Product Designer” role that spends three bullet points on component libraries and Git workflows is a different application than one that spends three bullet points on user interviews and success metrics, even if the header is identical. I’ve started tailoring not just my resume’s language to match a title, but genuinely asking myself whether the actual day-to-day being described is one I want, regardless of what it’s called.

The oddly hopeful read, and the one I keep returning to on the harder days: if companies can’t even agree what the title means, then the title isn’t really what’s being evaluated. What’s being evaluated is whether the actual described work matches what you’ve actually done — which, for anyone who’s built real range on purpose rather than by accident, is an advantage hiding inside the confusion. A flattened, overloaded title is annoying to search against. It’s also easier to walk into on your own terms, because nobody can tell you you’re “not technically a Product Designer” when nobody agrees what that means in the first place.

I’m not going to pretend that reframe makes five rejections in a week feel good. But it does change what I’m optimizing for in the search itself: not the cleanest title match, but the clearest signal that the actual work described is work I can point to and say — yes, I’ve done exactly this, under whatever name it happened to have at the time.

Sources

• Jakob Nielsen on “UX vocabulary inflation” — widely cited across UX literature, including designstudiouiux.com’s breakdown of the Product Designer vs. UX Designer debate.
• “Nobody knows what a designer is right now” — Liron Tocker, Substack, July 2026.
• Tom Scott’s “process vs. show, don’t tell” hiring-era distinction — shared on LinkedIn, January 2026, referenced in The Fountain Institute’s “What Actually Gets Senior Product Designers Hired in 2026.”
• Executive recruiter commentary on hiring managers “hunting for unicorns” — via Figma’s design hiring research, cited in the same Substack piece above.

There’s a specific kind of exhaustion that comes from being the only designer at a fast-moving service company. At Tedekstra, I wasn’t assigned to one product. I was assigned to whichever client was loudest that week — a fintech dashboard on Monday, a meal tech app on Wednesday, a booking platform’s redesign crammed in before Friday’s client call. Three teams, three timelines, one me.

So when I first opened Google Stitch to draft a mobile flow for a client presentation, it felt less like adopting a new tool and more like being handed a second pair of hands. I typed a rough description of a booking confirmation flow. In under a minute, I had five linked screens — list view, details, payment, confirmation, tracking — all sharing the same visual language, something that would have taken me the better part of a day to sketch by hand.

I was, for about ten minutes, thrilled.

Then I opened the client’s actual brand file next to it, and my stomach sank a little. The buttons were rounded where our system used sharp corners. The spacing was close but not our 8px grid. It was, unmistakably, not our design system — it was Google’s best guess at a design system, generated from the patterns Stitch had learned elsewhere. Good UI. Wrong UI, for this particular client, in this particular brand.

That gap — between “good” and “ours” — became the actual subject of the next year of my working life.

Three tools, three very different relationships with “your system”

Working solo across multiple clients meant I couldn’t afford to learn one AI tool deeply and call it done. I needed to understand, fast, which tools respected a design system and which ones just politely ignored it.

1. Google Stitch — fast, fluent, brand-blind

Stitch is genuinely remarkable at what it’s built for: describe a flow in plain language, and it generates multiple coherent, production-plausible screens in roughly a minute, exportable straight to Figma or as working code. For early client pitches — the moment where you need something on screen to react to, not a polished system — nothing I tried was faster.

Its shortcoming is exactly what tripped me up that first week: Stitch generates from its own trained sense of “good UI,” not from a specific client’s actual component library. It doesn’t know your button radius or your spacing scale unless you painstakingly describe every token in the prompt — and even then, it’s approximating, not enforcing.

How I tackle it now: I treat Stitch strictly as a conversation-starter, never a deliverable. It’s where I go to pressure-test an idea with a client in real time — “is this the right shape of flow at all?” — before a single pixel touches our actual system. Once the shape is agreed, I rebuild it by hand inside our real component library. Fast idea, slow craft. Never the reverse.

2. Figma Make — closer to home, still needs a leash

Figma Make was the first tool that genuinely understood the assignment: point it at your existing file, and it generates new UI using your actual components, tokens, and spacing rules, not generic ones. For a solo designer bouncing between three brand systems in the same week, this mattered enormously — I could stay inside one file, one context, and let Make draft variations of my own system instead of a stranger’s.

The catch, and reviewers across the industry have flagged the same thing: it’s genuinely strong at structure and shockingly weak at personality. It can place your components in a technically correct layout that still feels like nobody made a decision. One industry review put it plainly, noting that the AI matches colors and fonts but not the feel of a brand — the designs are technically correct but often lack personality.

How I tackle it now: I let Make own layout logic — grid structure, responsive reflow, component placement — and I reserve every decision that involves taste for myself. If a layout needs a reason to feel like this specific client and not the client before them, that reason has to come from me.

3. UXPin Forge — the strictest, and the most honest about it

Forge takes the most uncompromising position of the three: it refuses to generate anything outside your connected component library. Andrew Martin, UXPin’s CEO, has described the whole premise bluntly — building AI that’s constrained to your component library, so it can’t go off-brand. No pixels pretending to be your button. Only your actual button, with your actual props and states.

For client work specifically, this is the closest thing to a safety net I’ve found. When a junior developer on one of our rotating teams picked up Forge output, there was no “which shade of blue did the AI mean” conversation, because the AI was structurally incapable of inventing a new one.

The tradeoff is setup cost. Forge is only as good as the component library you connect to it — and for a solo designer juggling three clients, building and maintaining three clean, code-connected libraries is real, unglamorous infrastructure work. It’s not a tool you casually try on a Tuesday afternoon; it’s a tool you commit to.

How I tackle it now: I don’t connect Forge for every client — only the ones I know I’ll be building for repeatedly. A one-off landing page doesn’t earn the setup cost; a client I’ll be shipping features for over months does. Once connected, though, I stop double-checking component usage entirely. That trust is the whole point — I spend the saved time on the work Forge can’t do.

The pattern underneath all three

By the third client project, I stopped asking “which AI tool is best” and started asking a better question: how far will this tool let itself be constrained by something I already built? That’s exactly what I’d learned building a design system by hand, long before AI entered the picture — a system that’s easy to ignore gets ignored, whether by a rushed developer or a rushed model. The tools that respected ours did so because it was rigorous enough to hold them to it.

Figma’s own product team put it well: deciding which generated version is actually right is still the real design job — there’s just more to react to now, and less to assemble by hand.

Working three clients at once used to mean three mental contexts, rebuilt from scratch daily. What changed isn’t that AI did my job — it compressed the assembly part, freeing up hours for the part no tool touches: knowing what a nervous first-time user needs to see first, and which “technically correct” layout actually feels considered rather than generic.

The gap between good UI and our UI never fully closed. It just moved — from redrawing the same button for the fifth client, to making sure the system those tools draw from is worth constraining them to in the first place.

I still remember the Teams message that started it. One of our developers, working late to match a client’s deadline, sent me a screenshot of three different “primary buttons” living in the same live product. Three different corner radii. Two different shades of blue that were both, technically, “brand blue.” None of them wrong on their own. All of them wrong together.

I was the only designer at Tedekstra, a service-based company that took on very different clients at the same time — a B2B fintech dashboard for one client, a B2C mealtech app for another, a booking platform for a third. No design team to lean on, no second opinion two desks away. Just me, moving between projects that had almost nothing in common except that I was the one designing all of them, and a rotating cast of developers who each inherited whatever decisions I’d made under deadline pressure.

For a long stretch, my process looked like most solo designers’ does: a fresh Figma file per project, a component built here, a slightly different version rebuilt there, and a quiet assumption that consistency would just… happen, because I was reasonably careful and had reasonably good taste.

It doesn’t happen. Not on its own, and definitely not across three unrelated client codebases. That Teams message was the moment I stopped believing it would.

The word I kept avoiding: governance

Somewhere early on, I’d absorbed the idea that a “design system” meant a tidy component library — buttons, cards, a color palette, sitting neatly in a shared file. So that’s what I set out to build. It took maybe three weeks of actual client work before I realized the library wasn’t the hard part. The hard part was deciding who was allowed to change what, and when — especially when “who” sometimes meant a different developer on a different client project every single week.

Nathan Curtis, a design systems consultant who’s spent years advising teams on exactly this problem, describes a system as something closer to a shared language and a framework for making design decisions across an organization — not merely a UI kit. That distinction rewired how I approached the whole thing. A button component doesn’t govern anything by itself. A rule for who decides when a new button variant is genuinely needed, versus when someone’s just impatient on a Friday deadline, governs something.

Once I stopped thinking “component library” and started thinking “decision-making framework,” the actual questions I was asking changed. Not “what should this dropdown look like,” but “when a client’s brand guidelines conflict with our accessibility standards, who has the final call, and how do we document that so I’m not re-litigating it on the next project?”

The real work: building it with developers, not just for them

Here’s the part I’m proudest of, and also the part that nearly didn’t happen: the system only worked because I built it alongside our developers, project by project, not as a polished handoff document I threw over a wall and hoped would be followed.

I started with something almost embarrassingly simple — an audit. I opened every live product I’d shipped across our different clients and just counted. Fourteen button styles across three unrelated codebases. Nine different spacing values that were all “supposed to be” the same 8px grid. Multiple separate implementations of a date picker for booking flows, each with its own bugs, each requiring its own QA pass every time a client asked for even a small tweak.

That audit became my argument. Not “trust me, a design system will help” — a hard sell to any developer under deadline pressure — but a literal spreadsheet showing how many engineering hours were being spent rebuilding the same dropdown for the fifth time, for three different clients who’d never even talk to each other.

Chris Jacobs, a principal product designer who’s spoken about this exact dynamic, put it simply: once engineers and designers are finally speaking the same language, it changes how a team ships, not just how a file looks.

That was precisely it. My design system’s real success metric was never “does it look cohesive in Figma.” It was: how many messages do I not have to send anymore, explaining to a new developer which shade of blue is actually correct.

Together, we built tokens for color, spacing, and typography that lived in code, not just in a design file — so “primary blue” was one value, referenced everywhere, changeable in one place regardless of which client project pulled from it. We agreed on a lightweight rule: any new component needed one real usage case from an actual project, and a quick sign-off between me and whichever developer would be maintaining it. Small governance. Not bureaucracy — just enough friction to stop the fourteen-button-styles problem from quietly happening again.

What changed, concretely

Within about four months, the effect was hard to argue with:

• New client work started faster, because the first sprint stopped being “design fifty basic components from zero” and started being “adapt the existing system to this client’s brand.”
• QA time dropped noticeably, because a bug fixed in the shared date picker component was fixed everywhere it was used — not re-discovered client by client.
• Handoffs got shorter and less personal, because disagreements stopped being “I think your button looks better than mine” and became “does this fit our documented spacing scale, yes or no.”
• New developers rotating onto a project ramped up faster, because there was finally one place — not scattered emails, Teams messages, and my own memory — that explained why things were built the way they were.

That last one surprised me the most. I hadn’t set out to build an onboarding tool. But a real design system, done with any rigor, ends up teaching whoever joins next the reasoning behind decisions, not just the decisions themselves — which mattered enormously when I couldn’t rely on a stable team to carry that context forward.

The book that named what I was actually building

I found Brad Frost’s Atomic Design a little after I’d already stumbled into most of these lessons the hard way, and reading it felt like someone had been quietly watching over my shoulder the whole time. His advice for getting a system adopted inside a real organization, rather than left to rot in an unused Figma file, is refreshingly unglamorous: make a thing, show that it’s useful, make it official. No grand governance rollout on day one. No permission slip. Just proof, first.

That’s almost exactly the order I stumbled into by accident — the audit spreadsheet, then the first shared button component quietly saving someone real time, then, only after people wanted it, the lightweight contribution rules. Governance that gets imposed top-down before anyone’s felt the pain it solves tends to get quietly ignored. Governance that shows up right after everyone’s already annoyed at the chaos tends to stick — even when “everyone” is just you and whichever developer is on call that week.

If you’re a solo designer about to build one

A few things I’d tell the version of myself who got that Teams message about three different primary buttons:

1. Start with an audit, not a component. You need the evidence before you need the solution — it’s what gets developers on your side, especially when you don’t have a design team to back you up.
2. Decide who owns decisions before you decide what the decisions are. A beautiful button library with no clear owner will drift back into chaos on the very next project.
3. Build the governance rules as light as they can possibly be. Enough friction to prevent chaos; not so much that a busy developer routes around you.
4. Treat developers as co-authors, not downstream recipients. As a solo designer, they’re often the only continuity you have across projects — the system only survives if they actually believe in it too.

The three buttons eventually became one component with clearly documented variants. More importantly, the conversation changed — from arguing about a shade of blue, to agreeing on who gets to decide the next time a genuinely new shade is needed. That’s not a component library. That’s governance. It just happens to be wearing a Figma file as a disguise.

Design Systems as Governance, Not Just Component Libraries… was originally published in Design Systems Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

I remember the exact moment the fear hit me. I typed one sentence into an AI design tool — “a clean onboarding flow for a health insurance app” — and in about eleven seconds, it handed me four full screens. Typography, spacing, a color palette, even placeholder copy that didn’t sound half bad.

I sat there for a second, genuinely unsettled. I’d spent years learning to see — to notice when a line height was fighting a font size, to know why a button needed six more pixels of breathing room. And a machine had just skipped past all of it in the time it takes to sip coffee.

If you’re a designer reading this in 2026, you’ve had some version of that moment too. The question underneath it isn’t really “will AI take my job.” It’s quieter and harder than that: if a machine can produce the screens, what am I actually for?

The panic is real. The framing is wrong.

For a while, the design internet split into two camps: the ones insisting AI is “just a tool, nothing to worry about,” and the ones quietly polishing their resumes. Both, I’ve come to think, are missing the more useful question.

Julie Zhuo, former VP of Product Design at Facebook, put words to something I’d been feeling but hadn’t articulated: AI can supercharge creativity and productivity, but it does not replace “the human intuition that makes design truly impactful.” That distinction — supercharge versus substitute — is the whole article, honestly. Everything else is detail.

But intuition alone isn’t a strong enough shield if I can’t explain why my intuition matters more than a model’s output. That took me longer to work out, and it took a real project to teach me.

The project where I actually learned the difference.

A few months ago, I was redesigning a quote confirmation flow — the exact kind of unglamorous, high-stakes screen where a user is about to commit real money. I fed the brief into an AI design tool to get a fast first draft, mostly to save myself the blank-canvas paralysis.

What came back was clean. Genuinely well-organized. It also made a decision I never would have made: it buried the total premium amount — the single number a user cares most about — inside a collapsed “view details” accordion, because visually, a shorter confirmation screen “looked” more elegant.

Technically, nothing was wrong with it. It followed every spacing rule, every hierarchy convention. But it had no idea that hiding a price on an insurance confirmation screen creates suspicion, not elegance — because it had never sat across from a nervous user hovering over a “Confirm” button, unsure if they were about to be charged something unexpected.

That’s the gap. AI can pattern-match to “clean.” It cannot yet sit with why a specific user, in a specific emotional state, needs a specific piece of information visible. That’s not a data problem. That’s judgment.

Jenny Wen, who leads design for Claude at Anthropic, said something in a recent interview that’s stuck with me since: “taste without accountability is decoration, but taste with accountability is leadership”.

AI could generate the “elegant” version of that screen all day. It couldn’t be the one accountable for a confused, overcharged-feeling user calling support the next morning. I was.

What this means for junior designers, honestly

Here’s where I try not to be glib, because I know this is the part that actually keeps people up at night. If AI can produce four polished screens in eleven seconds, what happens to the designer who’s supposed to spend two years learning to produce one?

Ben Anthony, a design director at Dentsu Creative who used to teach at Shillington, said something blunt about this that I think about often: “AI isn’t a shortcut to taste”. You can prompt your way to a mockup. You cannot prompt your way to the thousand small, half-conscious judgment calls that let you recognize when a mockup is actually good — because that recognition only comes from having made those calls yourself, badly, a few hundred times first.

This is where I think the “AI is coming for junior roles” fear gets the diagnosis half-right. The entry-level tasks — laying out a grid, producing color variants, writing filler copy — are genuinely shrinking. But the entry-level job, if a studio is doing it right, was never really about those tasks. It was about the apprenticeship: sitting next to someone senior, watching them reject the “pretty good” option for reasons that take years to fully absorb. That apprenticeship still has to happen somewhere. The task disappearing doesn’t mean the training disappears — it means teams have to be more deliberate about protecting it, instead of assuming it happens automatically the way it used to.

The book that gave me the older, calmer version of this argument.

Long before AI made this urgent, Ken Kocienda was writing about the exact same tension inside Apple during the iPhone’s early years, in his book Creative Selection. His definition of taste has stayed with me since I first read it: taste is “developing a refined sense of judgment” that finds balance and produces something integrated, not just correct.

What I find almost eerie is that Kocienda was describing humans disagreeing with each other — engineers, designers, Steve Jobs himself — arguing over a single shade of blue, long before generative AI existed. The tension was never really “human versus machine.” It was always “correct versus considered.” AI has just made that distinction impossible to ignore, because now the “correct” option is available instantly, for free, without any of the friction that used to force us to slow down and actually think.

So what does “collaborator, not replacement” actually look like day to day?

For me, it’s stopped being a philosophical question and become a fairly practical workflow:

• I let AI own the blank page. First drafts, layout variations, copy scaffolding — all fair game. The blank canvas was never where my judgment added the most value anyway.
• I own the “why.” Every AI suggestion gets one question before it survives: why would this specific user, in this specific moment, actually want this? If I can’t answer that in a sentence, it doesn’t ship.
• I treat AI output like a very fast, very confident junior designer. Talented, tireless, occasionally has no idea what it doesn’t know. Exactly the kind of collaborator you want — as long as someone senior is still in the room.

That confirmation screen shipped with the price visible, right where a nervous user’s eyes would actually land first. AI got me to a draft in eleven seconds. It took a designer who’d sat with real users’ anxiety to know that draft was wrong.

That, I think, is the actual answer to the fear I felt that first day. AI didn’t make my years of noticing line heights and nervous cursor-hovers obsolete. It just made it a lot more obvious which parts of my job were never really about the pixels in the first place.

Early in my career, I was a UI/UX designer at an insurance company, quietly owning a landing page nobody in leadership thought twice about. Term insurance, home health insurance — pages people land on mid-panic, usually after Googling something they didn’t fully understand, trying to protect a parent or a newborn or their own future. I designed those pages the way I’d been taught: clean hierarchy, brand colors, a hero image, a button that said “Get a Quote.”

And then someone from the growth team sent me a number.

0.8%. That was our conversion rate on that page. Not 8%. Zero-point-eight.

I remember staring at that number the way you stare at a typo you’ve read past ten times. It didn’t feel real. I had designed that page. I’d made design decisions I could defend in a portfolio review — the spacing, the typography, the CTA placement. And yet, out of every 1,000 people who landed on it, roughly 992 left without doing the one thing the page existed for.

That was the day I stopped thinking of myself as someone who makes things look right, and started thinking of myself as someone who has to prove things work. That shift — quiet, a little humbling — is basically the whole story of what conversion rate optimization did to my design thinking.

What CRO actually is(once you strip the jargon out)?

Conversion Rate Optimization, or CRO, gets thrown around like it’s a marketing buzzword, but at its core it’s disarmingly simple: it’s the practice of improving the percentage of users who take a desired action, using evidence instead of opinion.

Sign up. Buy. Submit a form. Start a trial. Whatever that action is for your product, CRO is the discipline of asking: of everyone who almost did this thing, why didn’t they? And then testing your way to an answer instead of guessing your way to one.

For a designer coming from a purely visual background — which is exactly where I started — this was a genuinely uncomfortable reframe. Design school (and most junior design jobs) reward you for taste. CRO doesn’t care about your taste. It cares about your evidence.

The insurance page that taught me to stop trusting my gut

Back to that 0.8% number.

My first instinct, embarrassingly, was to redesign the entire page. New hero section, new illustration, a bolder CTA — the kind of sweeping, satisfying overhaul that feels like “real design work.”

My manager at the time stopped me before I shipped it. Her question was simple: “Which one of these ten changes do you think is actually moving the number?”

I didn’t have an answer. That’s when I learned that a redesign isn’t a hypothesis — it’s ten hypotheses stacked on top of each other, shipped at once, with no way to know which one worked, which one hurt, and which one did nothing at all.

So instead, we picked one thing. Just one. The form on that page asked for name, phone number, email, date of birth, and — bafflingly, in hindsight — annual income, all before a single quote was shown. We hypothesized that asking for income upfront, on an insurance page people land on when they’re anxious, was quietly scaring people off.

We didn’t remove it and hope. We tested it.

Why A/B testing became the most honest tool in my kit

A/B testing, for anyone who hasn’t lived inside one, is straightforward: you show version A of a design to half your users and version B to the other half, at the same time, under the same conditions, and you measure which one actually performs better against a specific goal.

What nobody tells you until you’ve run a few is how humbling it is. As a designer, you go in fairly sure you know which version will win. I was sure. I’d designed version B — the one without the income field upfront — and I was certain it would crush version A.

It won.

But only by 1.4 percentage points. Not the triumphant redesign-worthy leap I’d imagined. Just a small, real, statistically meaningful nudge — the kind of number that doesn’t make for a flashy portfolio slide but absolutely makes for a better business.

That’s the real gift A/B testing gave me: it separated my ego from my output. My job stopped being “make something I’m proud of” and became “find out what’s true, then be proud of that.” Some weeks that meant my design won. Some weeks it meant a version I thought was ugly and boring outperformed my “better” one, and I had to ship the ugly, boring, better-converting one anyway.

A few things I now build into every project because of that early lesson:

• Test one variable at a time, even when it’s tempting to redesign everything — otherwise you learn nothing about why something worked.
• Let the sample size finish talking before you do. Calling a test early because the early numbers look good is the fastest way to ship a false win.
• Treat a “losing” design as data, not failure. The insurance form redesign that flopped taught me more about our users’ anxiety than the one that won.
• Pair quantitative results with qualitative context. A number tells you what happened; a five-minute user interview tells you why — and CRO without the “why” turns into blind number-chasing.

The part nobody warns junior designers about

Here’s what surprised me most, months into doing this work: CRO didn’t make me a less creative designer. It made me a more disciplined one.

Constraints, it turns out, are where good design ideas get sharper. When I couldn’t just add another beautiful illustration because I felt like it — I had to justify it with a hypothesis, test it, and let the data either back me up or humble me — my instincts actually got better over time. I started predicting test outcomes more accurately, not because I’d become psychic, but because I’d finally started designing with users instead of for an art director in my head.

That single insurance landing page eventually went from 0.8% to just under 2.1% conversion, across about six months and a dozen small, unglamorous, evidence-backed changes.

No single change was dramatic. Together, they meant thousands more people each month actually got the coverage they came looking for — which, on the days I forget why any of this spreadsheet-and-percentage work matters, is the thing that brings me back to why I wanted to be a designer in the first place.

If you’re a designer who’s never run a real A/B test

Start small, and start humble:

1. Pick one page or flow with real traffic and a clear goal — not vanity metrics.
2. Write down your hypothesis before you design the variant. “I believe removing X will increase Y because Z” — one sentence, no hiding.
3. Change one meaningful thing, not everything.
4. Let it run long enough to mean something, and resist peeking every hour.
5. When it’s done, write down what you were wrong about. That list will teach you more than the wins will.

Design taste will always matter. But the designers I respect most now aren’t the ones with the boldest opinions in the room — they’re the ones most willing to find out, quietly and rigorously, whether their opinion was even right.

Mine wasn’t, that first time. I’m glad I found out.

Think about the last time you opened a streaming app just to “watch something.” Twenty minutes later, you’re still scrolling. Nothing’s wrong with any of the shows. There are just too many of them, and somewhere in all that scrolling, your brain quietly gave up trying to pick and switched to just… browsing forever.

That feeling has a name in design: design fatigue (you might also see it called decision fatigue). It’s what happens when a person is asked to make one too many small decisions in a row, and their mental energy for choosing simply runs out. Not because they’re lazy or indecisive. Because choosing, itself, costs something — and every extra option you hand someone is a tiny withdrawal from an account that isn’t unlimited.

Designers hand people this bill more often than we realize. Every dropdown, every filter, every “just one more field, it might be useful” adds up. And unlike a streaming app, where the cost is just a wasted evening, in a lot of products that cost is a user quietly closing the tab.

I didn’t understand any of this in theory-speaking way when I first ran into it. I understood it because I caused it.

The screen that taught me the hard way

A year into my career, I landed my first real ownership as a UI/UX designer — a full page ecosystem for an insurance platform, PolicyX.com. Landing pages, category pages (life, term, health, etc.) , all the supporting flows in between. For a young designer, that kind of scope feels like a dream. I said yes to everything it demanded, which, it turns out, was exactly the problem.
Insurance is a category built on choice — coverage amount, policy term, riders, family vs. individual plans, waiting periods. Every option felt necessary. Legal wanted it visible. Business wanted it featured. I wanted to seem thorough. So the pages grew, field by field, each addition perfectly defensible on its own.
Then we sat people down for usability testing, and I watched the bill come due.

Users would land on the term insurance page fully intending to buy. Then, right around the rider selection step, something would shift. They’d open one plan, compare it to another, reopen the first, go quiet for a while, and eventually say something like, “let me think about it,” and close the tab. On the home health insurance page, people kept flipping back and forth between family and individual coverage, unsure which they’d even already picked two steps earlier.

At first I thought it was a labeling problem. I rewrote copy. Added tooltips. Explained things more. It barely moved the needle — because I was treating the symptom, not the actual cause. These weren’t confused users. They were tired ones. I’d handed them so many small decisions that by the time it mattered — the moment we actually needed them to commit — they had nothing left to decide with.

What actually changed things

The shift for me came from deliberately studying how sharper, more experienced product designers thought through exactly this kind of problem — not reacting stakeholder request by stakeholder request, the way I’d been doing, but designing the sequence of decisions on purpose.

That’s when Hick’s Law finally clicked, not as an interview flashcard but as an explanation for the exact screen I kept watching people struggle with: the more choices you put in front of someone, the longer — and harder — every single one of those choices becomes to make. My rider-selection screen wasn’t giving users eight small decisions. It was giving them one enormous, exhausting one.
So we changed the shape of it. Instead of showing every rider with equal weight, we pre-selected sensible defaults based on what the user told us about their life stage, and tucked the rest behind a simple “customize” step for the smaller group who actually wanted to dig deeper. On the health insurance flow, we replaced a confusing mid-form toggle with one guided question asked upfront — “who are you insuring?” — and let that single answer quietly shape everything after it.

Same products. Same options underneath. Just far less for the user to carry at once.

Where it left me

I still think about that year often. It wasn’t a portfolio critique that taught me the cost of too many choices — it was a real person, in a real research session, quietly giving up on something I’d built. You don’t forget that.

These days, whenever I catch myself adding “just one more option” to a screen, I ask the same question that year gave me: is this here because the user needs it, or because I wasn’t willing to decide for them?

Most of the time, honestly, it’s the second one. And learning to tell the difference is what actually turned me from someone who kept adding fields into someone who now removes them — on purpose.

If you’ve ever built a screen you were proud of, only to watch someone quietly abandon it mid-decision — I’d love to hear that story too.

I still remember the exact shade of yellow I used to make sunflowers bloom on handmade paper. Turmeric-dyed, thick with symbolism, painted in unbroken lines that my grandmother taught me never to lift the brush from. That was Madhubani — a 2,500-year-old traditional art from Bihar, where every fish, every peacock, every triangle of a woman’s sari carries a meaning passed down, not invented. For years, that was my entire design vocabulary: sacred geometry, natural pigment, and a canvas that never once asked me what the user wanted.

Fast forward to 2023… I found myself in a UX workshop, staring at a whiteboard that said “Empathize → Define → Ideate → Prototype → Test,” and feeling like I’d wandered into a temple where I didn’t know the prayers.

What saved me wasn’t a bootcamp or a Figma tutorial. It was books. Specifically, five books that, one at a time, took the instincts I already had as a traditional artist — patience, observation, respect for a visual language shared by others — and pointed them at a completely new audience: the user. This is the story of how each stage of the design process cracked open through a single sentence in a single book, and how a Madhubani artist quietly became a product designer without ever really leaving the artistic roots behind.

Empathize: The Design of Everyday Things — Don Norman

Madhubani art is communal. You don’t paint in isolation; you paint what your community already recognizes — a fish for fertility, a sun for life, a bamboo for prosperity. So when I read Don Norman’s line —

“User-centered design means working with your users all throughout the project.”

— it didn’t feel foreign. It felt like someone had translated something I already believed into a language the tech industry understood. My grandmother and Guru Bimla Dutt never asked her collectors for “feedback,” but she absolutely watched how people look twice at the figurines she painted , which motifs made them pause, which one they move past from.

Norman gave that instinct a name and a method. I stopped treating research as a checkbox before “real design” started, and started treating it the way I’d been taught to treat a paper before painting it — the quality of paper the size of it an will it be able to capture all of my imagination and interpretation on it. My first real empathy interviews felt less like a corporate ritual and more like sitting with the women in my family sketching borders — quiet, observational, in no hurry to conclude anything.

Define: Don’t Make Me Think — Steve Krug

Traditional Madhubani painting has almost no negative space. Every inch is filled — with fish scales, with dots, with vines. It’s beautiful, but it is not efficient communication. It assumes the viewer will spend time decoding it, the way you’d spend time with a poem.

Digital products don’t get that luxury. Steve Krug’s book handed me the sentence that broke that habit for good:

“If you can’t make something self-evident, you at least need to make it self-explanatory.”

I remember applying this almost too literally in my first onboarding flow — I had designed it like a Madhubani border, dense with icons and micro-illustrations I thought were “delightful.” A senior designer looked at it and asked, “What is this screen actually asking the user to do?” I couldn’t answer in one sentence. That was the problem.

Krug’s book taught me that Define isn’t about writing a beautiful problem statement — it’s about writing the smallest possible true sentence about what’s broken. Once I could say “new users don’t understand where their data is stored” in eight words, the design got simpler almost automatically. Definition, I learned, is compression, not decoration.

Ideate: 100 Things Every Designer Needs to Know About People — Susan M. Weinschenk

Here’s something nobody tells you about traditional art training: it is not built for divergent thinking. You learn the correct way to paint a peacock’s tail. You don’t experiment with forty versions of a peacock’s tail and pick the best one later. Every stroke is meant to be right the first time — precision over exploration.

So ideation, the deliberately messy, quantity-over-quality part of design thinking, felt almost disrespectful to my training at first. What unlocked it for me was a small, half-forgotten anecdote from Weinschenk’s book about how invention actually works:

“Edison is a great example of someone who used deliberate and cognitive creativity.”

Weinschenk’s larger point — that creativity isn’t a lightning bolt but a trainable, repeatable cognitive process — gave me permission to be bad on paper before being good on screen. I started running brainstorms the way Edison ran experiments: dozens of filament ideas, most destined for the bin, because the goal wasn’t the tenth idea, it was surviving long enough to reach the fortieth. I began sketching twenty thumbnail layouts for a single screen instead of one “correct” one — a radical, almost uncomfortable act for someone raised to paint each fish exactly once, exactly right.

Prototype: About Face — Alan Cooper

Madhubani art doesn’t really have a “draft” stage in the way software does — there’s a sketch in charcoal, sure, but the final piece is committed the moment ink touches paper. Prototyping, in the UX sense, was the single hardest habit for me to build, because everything in my training told me low-fidelity work was unfinished, even embarrassing.

Alan Cooper’s About Face reframed prototypes for me not as unfinished art, but as instruments for finding solutions:

“Usability’s strength is in identifying problems, while design’s strength is in identifying solutions.”

That line separated two jobs I’d been fusing together out of anxiety — diagnosing what’s wrong, and proposing what’s right. A prototype, I realized, doesn’t have to be correct; it has to be diagnostic. It exists to expose a problem before it’s expensive to fix. Once I let go of the idea that every artifact I made had to be gallery-ready, I started building rough, clickable, even ugly prototypes in half the time — and they told me more, faster, than any polished mockup ever had.

Test: Lean UX — Jeff Gothelf & Josh Seiden

The last shift was, in some ways, the most personal. In folk art, the artist’s authority is rarely questioned — the painting is considered complete when the artist says it’s complete. Handing my work to a stranger and asking them to struggle with it in front of me, on purpose, went against everything my training had instilled about craftsmanship and quiet confidence.

Then I read Gothelf and Seiden’s now-famous instruction, condensed into three words:

“Get out of the building.”

It’s blunt, almost rude, and exactly what I needed. Lean UX doesn’t treat testing as a validation lap at the end of a project — it treats it as the engine of the whole process, something you do constantly, cheaply, and early. I started sitting quietly next to real users the way I used to sit and watch people react to a mural — except now I was allowed to ask questions, take notes, and change the painting based on what I saw. Watching someone hesitate on a button I was proud of taught me more in ten minutes than a week of internal design reviews ever had.

Same Hands, New Language

None of these five books taught me something entirely new — they taught me to redirect something I already had:

• Empathy was already in my hands, from years of painting for a community, not for myself.
• Definition was already in my discipline — the habit of never wasting a brushstroke.
• Ideation and iteration already existed in folk art, just compressed into generations instead of sprint cycles.

What changed was the audience. Madhubani art speaks to people who already share its symbols. Product design speaks to people who’ve never met you and owe you nothing — not their time, not their patience, not their trust. That shift, more than any tool or software, is what these five books helped me make.

If you’re a traditionally trained artist eyeing a career in UX, here’s the only advice I’d underline twice: You’re not starting over. You’re translating what you already know into a new dialect.