A while ago, I wrote an article about being the only design system designer.

For about 3-ish years, I was at the forefront of design systems at a company. And I was proud. Truly proud. I care deeply about the work I do and how it impacts people. I’m very passionate about work. I breathe it. I talk about it. I dream about it.

Sometimes… a little too much. Like when I’m with my loved ones, and I physically cannot stop thinking about that damn component and how it could be better. (Not ideal, but I’m working on it.)

Writing that article felt good and honest. Saying out loud what it’s like to carry something like that, mostly on your own… was liberating! What I didn’t expect was the response.

So many people reached out saying, “This is me.” So many solo design system designers quietly holding everything together in the back.
So many people building the literal backbone of their product… alone.

That part shocked me.

Because in my head, design systems lived in big teams. In mature orgs. In companies that truly understood their value. I was constantly comparing my work to those companies, studying them, aiming to be like them one day, because, ahem, this girl likes to dream 😂.

Realizing how many of us were solo did something to me. Instead of just feeling proud, I started spiraling a little. I didn’t get it. Why are there so many solo designers when a design system is literally the powerhouse of a product? A design system touches every feature, every team, every release, especially now with AI accelerating everything. With teams shipping faster than ever. With products becoming more complex every quarter. Design systems aren’t a small thing anymore.

They are a whole infrastructure.

And not just “we have some components” infrastructure. We’re talking about a scalable, accessible, tokenized, multi-platform, future-proof systems and even “AI-ready” infrastructure (whatever that ends up meaning because let’s be honest, we’re all figuring that out). That TAKES A WHOLE VILLAGE!

You cannot convince me that one person can sustainably carry that long term and have it truly shine.

I genuinely don’t understand why so many people are still soloing design systems when there is SO much to do. And at some point, I had to admit something that felt uncomfortable: companies that say they “care about design systems” but only hire one person to run them don’t actually care. They like the idea of it. They like saying it in strategy meetings. It sounds mature. It sounds forward-thinking. But if only one person is responsible for governance, adoption, documentation, accessibility, tokens, roadmap, support, alignment, education, evolution, blah blah blah… ehhh that’s not belief. That’s just straight-up optics. A design system that powers an entire product cannot live on one person’s capacity. It’s unrealistic, it’s irresponsible, and it’s one of the fastest ways to burn someone out while pretending you’re investing in quality.

It feels incredibly powerful to collaborate with almost the entire company. To influence everything. To be the go-to person. To build and lead and think big all at once. It’s a constant cycle of doing, improving, shipping, and refining.

But it also feels incredibly lonely.

When you’re the only design system designer, you become the expert by default, not necessarily because you’re the best in the room, but because you’re the only one in the room, haha. That’s a weird place to stand.

I didn’t actually know how good I was… Was I good because I was operating at a high level? Or was I good because no one around me had deeper design system experience? Was I pushing the craft forward… or just operating at the level of understanding the company had?

It’s hard to calibrate yourself when there’s no one to compare to, no one to challenge you, no one to say, “Have you thought about this differently?”

You make decisions alone, you validate them alone, you grow alone. And I started to notice how much I admired people who weren’t alone. People who could casually turn to another designer and say, “What do you think?” People who had teammates to learn from. People who had a design system manager, which, honestly, sounded unreal to me. A manager who actually understands the craft, protects the work, and supports the people doing it? That felt like a dream. And at some point, I realized I didn’t just want to be capable of doing it alone anymore. I wanted more.

That article ended up being more than just a reflection; it was the beginning of me realizing I wanted out. So I started looking for another job (yes, I wrote about that too), and I was incredibly lucky to land in what genuinely feels like a dream team.

A new chapter began for me, and the difference is unreal, so I obviously had to put my thoughts and perspective together and share my experience in this article.

What changed when I joined a real design system team?

When joining a strong design system team, something really beautiful happened: My energy stopped going into surviving the work and started going into elevating it.

One of the most underrated gifts of being on a real design system team is having defined roles. Knowing that someone else owns the documentation deeply. Someone else is thinking about governance. Someone is obsessed with naming conventions. Someone else is driving adoption conversations. You don’t have to hold every layer of the system in your head at once anymore. You can care deeply about your lane while trusting that someone else cares just as deeply about theirs.

That trust and mindset have changed how I work while also giving me time. Real-time.

Time to slow down and make something sparkle instead of just barely functional. Time to go down rabbit holes and find the cracks before they become problems. Time to refine details without feeling guilty for “spending too long” on something. Time to delete something and rebuild it properly because I know it can be better. (Yes, I am looking at you, old Figma library 😂)

Time to take BIG projects and actually finish them! Yes! The ones I used to dream about.

The structural refactors. The foundational improvements. The long-term system investments. When I was alone, I had a running list of those in my head. I could explain why each one mattered, what it would unlock, and what the ROI was. I believed in them so much. But they would start and then stall because something urgent always took priority.

Now they don’t stall, they move, they get scoped properly, they get support, AND they get to see the light at the end of the tunnel. They get implemented… and I get to be proud of them!

Another amazing thing? I don’t overthink in isolation anymore. I used to redo things over and over until I felt fully confident and “perfect”. I had no one to sanity-check me early or late. Now I just turn my chair and ask, “What do you think?” And someone answers. Sometimes they reassure me. Sometimes they catch something immediately. Sometimes we go down rabbit holes together, and we take the idea somewhere better.

Support shows up in small ways, too. I don’t have to attend every single meeting. We swap weeks for office hours and design crits. We rotate support. Some days I’m answering everything. Other days, I’m the one documenting while someone else answers.

There are receipts, and I love receipts.

If something is unclear later, if someone questions a decision, if someone leaves the company, we can go back and read the “receipts”. Yes, that thoughtful documentation that’s clear and not rushed because someone was not juggling five conversations at once. That’s what I call receipts.

And hey, I can step away, and nothing falls apart! If I’m sick, someone has my back. If I’m on vacation, the system continues. That alone is the kind of safety I needed.

The roadmap doesn’t live in my brain anymore either. I’m not constantly calculating whether I can squeeze something into this sprint, this quarter, this year. Roles are defined. Ownership is clear. Decisions are shared. I don’t have to say yes to everything just because I technically could stretch myself thinner, woah am I dreaming? Is this real? 🥺

And the learning.

Oh my God, the learning.

I didn’t realize how much I missed learning from peers.

I’m not the only source of truth anymore. I get to see how someone structures documentation more cleanly than I would have. How someone goes deeper into research. How someone thinks about scalability five steps ahead. I catch things they don’t. They catch things I don’t. Isn’t it beautiful?

All those ideas I used to write down every day, “the system needs this, and that, and here’s why notes… They turned from private ambition to real conversations and proposals with capacity, resources, and alignment. Things I once thought were slightly unrealistic now feel completely possible.

And let me tell you the best 2 parts:

• Having a manager who truly cares about design systems changes everything. Someone who understands that one person cannot and should not carry an entire system. Someone who keeps the system on track strategically. Someone who knows each designer’s strengths and intentionally gives them work that helps them grow. Someone who pushes for quality instead of heroics. Someone who deeply cares about design systems advocates for it and just gets it.
• Being surrounded by designers who are just as passionate as you are! A dream team ♥️. You operate at the same level of care. You challenge each other. You hold the bar high. You don’t have to explain why details matter. Everyone already knows!

Turns out, I wasn’t meant to carry the system alone. I was meant to build it with others.

I love design systems. I love the community. And now I love being part of a design system team.

I hope you find your dream team, my solo design system designer reader. And if you are part of a team, thank you for reading and getting the “aha” moments with me, I hope we get to work and enjoy systems together one day!

Catch ya later.

From Being the Only Design System Designer to Being Part of a Design Team was originally published in Design Systems Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

A couple of months ago, I joined Realtor.com after a long search (I wrote an article about it: Searching for a Design System Role in 2025). Starting a new job always comes with the classics: you get assigned some smaller tickets at first, just to get warmed up, get to know the people, the system, the constraints etc etc.

My manager assigned me one about disabled states across the system. “Perfect! I’ve done a ton of work on disabled states across the system in my past job, this is a project that can help the product be more accessible and inclusive and I love it bc accessibility is something I’m deeply passionate about… I’ll knock this one out by the end of the sprint.”

Except… in design systems one small ticket rarely stays one or stays small.

You start with what looks like a tiny project, maybe a button state, a spacing inconsistency, or a token rename. At first glance, it feels like a quick win. But once you dig in, you realize it’s the tip of the iceberg.

Pretty soon you’re uncovering naming inconsistencies, accessibility issues, rogue variants, mismatched properties, and suddenly… one ticket has become two, then three, then twenty.

Design systems are more than isolated fixes. They’re about patterns, harmony, and rules that span across the product. When you touch one part, it exposes the connections with everything else.

I keep joking with Jarvis Moore, who’s on my team, that we should defo make a ticket just to track how much time we spend creating tickets. 😂

In all of these years I have learned that it takes a village to maintain good design systems:

• You need designers to help identify or confirm use cases.
• You need engineers to validate behaviors and constraints.
• You need managers to weigh in on priorities and resources.

That one “tiny” ticket quickly turns into cross-team conversations, decisions, and alignment. A big part of the job isn’t even solving problems, it’s finding them, documenting them, and getting everyone on the same page.

The Dual Lens of Design System Work

As design system designers, our nature is to operate in two modes at once:

• Microscope → Sweating the details. Making sure a single token, state, or component feels *perfect*
• Telescope → Zooming out to see how that detail plays across the entire product ecosystem.

This dual perspective means I am rarely “done” when a small ticket is “complete.” Each project becomes an opportunity to connect dots and push the system toward more cohesion. And of course, I can’t help but keep finding rabbit holes.

In refinement meetings, when is my turn to share my work, I often start singing: “It’s me, hi, I’m the problem it’s me 😂! Because it’s true I can’t just not bring stuff that I find while I do one of my “small tickets”. What if no one else notices what I am seeing and then I can’t sleep at night because I’m the only one who realizes our spacing scale jumps from 8px to 13px?

Is it you ADHD?

As I have shared in my previous articles, I have ADHD. Which, depending on the day, is either my superpower or my downfall. I get obsessed. I see details nobody else notices. And in design systems, that obsession means every “fix” I touch suddenly reveals five more problems.

I sometimes wonder if this “one thing leads to another leads to another” pattern is just my ADHD brain or if it’s simply the DNA of being a design system designer: noticing everything, following the threads, and refusing to let the little things slide, maybe we all secretly have ADHD and that is why we are so good at this and enjoy this type of work? Dunno.

Looking back, maybe that’s what got me into design systems in the first place. I started in general UX design, but I couldn’t stop obsessing over details no one else cared about, the little details that quietly impacted positively or negatively the overall user experience.

Years ago, I actually had a manager tell me once that I was… wasting my time? Because I was obsessing over nested round corners. Yes, guilty: I love when outer corners have a larger radius that “flows” into the inner one, when I see that, I stop and enjoy them like other people stop and smell flowers. I was literally creating a system of outer corners, making sure every scenario had the right spacing and corner roundness. For those who don’t know, you make nested corners when you subtract the gap (or padding) between two nested elements from the outer element’s corner radius to get the correct, perfect, visually pleasing inner radius. (Outer radius 50px minus padding 25px = inner radius 25px. You can play with this demo to understand what I am talking about).

How would that be a waste of time? Those tiny details are the secret spice that turns meh sloppy UI into a chef’s-kiss experience, that makes the product spark joy, IMO.

That obsession with details, combined with the joy of untangling messy systems and creating order, is what eventually landed me in design systems. I can’t help it; it’s like pulling a rope just to see how long it really is. So maybe it’s ADHD. Or maybe it’s just who we are as design system designers.

See? Just like the tickets, even this story can’t stay small, I’m already off into other topics. Back to the ticket, Chela! 😂

So, what happened with the ticket and why am I writing this story?

Ok fiiine, I’ll tell you what happened.

So… I started tackling the ticket, looking at disabled states in all components across the design system, but then… the rabbit holes:

First: making sure disabled states were consistent across the product and “accessible” (whatever that means, because disabled states are the most inaccessible states ever. SMH!).

Then: disabled vs. read-only states. Do we need both? Which components actually need them? Why don’t select controls have read-only states?

Later: realizing some disabled states could be avoided altogether, for example, pagination! Why disable “previous” on the first page, or “next” on the last? Why show something you can’t use? Better to build guardrails, remove those states, and create variants for start, middle, and end so designers don’t even have to think about it.

Amazing! Let me just gather some wireframes from designers using the pagination component so I can show my proposal.

What? Designers are creating a “pager” element next to pagination to control results per page?

Damn. Now I need guidelines so they use it correctly. Okay fine, I’ll turn the pager into a component. But if I don’t combine pager + pagination, people will misuse them separately. So I need to create a pattern.

Great! But… what about mobile when there’s no space? Easy: remove button labels, just use arrows, tighten spacing. Done.

Oh wait, to support those changes I need new props in the pagination component.

At this point: What?! I’ve written 23,523 tickets and I haven’t finished the “one” original disabled state ticket? Shit.

Welcome to my day-to-day work. Or better said, welcome to inside my brain. 😂 My “simple” accessibility ticket had multiplied into an entire backlog of audits, variations, and proposals for new components.

Beyond the Ticket

Why is this a thing in design systems or at least in my brain? Design system work isn’t even about the tickets. It’s the decisions hiding inside them.

Every time I take a decision, I’m not just deciding for myself. I’m weighing the impact it has across the product. Does this change fit within our visual language, spacing system, or token structure? Are people using this in real flows, or detaching components to do something else? Will this addition or subtraction blow up properties, code patterns, or performance? Is this a breaking change? How will this impact current or future user flows, accessibility, and overall consistency?

That is actually the hardest part. Which decisions and proposals are worth dying on a hill for, cause I will… and which ones I just… let go. Not everything can be perfect, even if my brain desperately wants it to be.

Sooo, all this to say is: a ticket may never end. In design systems, it rarely does. Cliché an all, but each ticket is a starting point, not a finish line, and if it takes endless tickets, countless audits, and way too many tabs, I’ll take it. Because this is the type of stuff I signed up for, and the thing I actually love, not everyone does but I do!

Ah and on disabled states? Not done yet. I am still working on it 😂 I am deep into it. Maybe I’ll write an article about it. Spoiler alert, it’s the dilemma between disabled and read-only states.

But that’s for another day, my friends, it’s Saturday and I need to stop thinking about this dang ticket.

Catch ya later!

Design System Designer Diaries: The Ticket that Never Ends. was originally published in Design Systems Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Looking for a job right now is no joke. There’s more competition than ever, lots of talented designers out there, lots of peeps laid off and applying for the same roles. And when it comes to design system jobs is even harder. There are only a handful of open roles at any given time.
That said, my experience probably mirrors what a lot of UX/Product/Graphic Designers are going through too.

This year, I went through this whole job search journey myself. But I wasn’t in a rush, and I wasn’t trying to escape a bad situation. Thankfully, I was actually happily employed, but I was just ready for my next adventure. I wanted to see what was out there (which, honestly, we should all do every now and then, even if we’re not in a rush). My goal wasn’t just to get any job. I wanted to find the right job where I could join a company that gets the value of design systems, invests in them, and genuinely cares about them, but the most important thing for me was to find a job where I could be part of a design system team, I was done being the only design system designer at a company.

So, I started my journey. I won’t lie, I was dreading it. Job hunting as a designer is honestly hell. We don’t just need a solid resume and LinkedIn like everyone else. Nope. We need a beautiful, updated portfolio with multiple case studies, AND a portfolio presentation that tells a compelling story, SMH….

But along the way, I learned a few things that I think other designers could benefit from. And honestly, I’m one of those people who doesn’t really enjoy things unless I’m sharing them, or sharing the experience I had, so keep reading if you are interested to know my strategy to land a role!

👏 Build 👏 Relationships 👏

In my opinion, the hardest part of the interview process, is getting your foot in the door, getting someone to actually look at your resume and portfolio.

In a sea of hundreds of applicants, it’s hard to even get noticed unless you’re lucky enough to be contacted by a recruiter or already know someone at the company. Cold applying is getting harder and harder to pull off and the days of hitting “Easy Apply” and magically getting a response are pretty much gone. I’ve landed a job that way in the past too…. but ohhh, those days are long gone, my friend.

That’s why my first advice to you, is to build those relationships! Get out of your shell or comfort zone and get to talk to people!

I know it can feel cringey to start messaging strangers, especially people at big-name companies where everyone wants to work. And no, I’m not saying spam people on LinkedIn with cold messages that have no context. Personally, when I get a message like that, I usually ignore it. It just comes off as transactional. That’s not how you build meaningful relationships, in my opinion.

What I recommend instead is reaching out with intention. Message recruiters. Reach out to hiring managers. Ping someone on the team. Ask for a referral if it makes sense. Even just introducing yourself and saying, “Hey, I’m really interested in this role and this is why I would be an amazing fit” can go a long way, it might feel awkward at first, but most people understand. And more often than not, they’re open to helping or at least pointing you in the right direction.

Reaching out to people isn’t magic, but it does make a difference. A personal connection can push your name to the top of the pile in a way that an application alone never will.

So if you’re in the middle of the search, don’t rely only on submitting resumes into the void. Talk to people. Build those relationships. That’s the stuff that opens doors.

Talking About Design Systems is Hard

For me, the one of the hardest part of the whole process wasn’t landing interviews. My response rate was actually pretty good, especially once I refined and iterated my resume, LinkedIn, and portfolio through some interview rounds.

The real challenge for me was the screener interviews. You may be thinking, “What? That’s the easiest part!” Well, not for me, I was having a really hard time explaining my experience because when a recruiter asked, “What’s your experience with design systems?” I didn’t even know where to start. Design systems are a niche within a niche. It was hard to gauge how technical I should be when explaining my experience in those early conversations with recruiters. Do I go into technical details? Do I assume they understand what design tokens are? Do I explain like they don’t know anything about systems? Should I keep it high-level and strategic, or show how deep in the weeds I can go?

Additionally, my experience is as a solo design system designer, I’ve done a lot of design system things: tokens, documentation, adoption, governance, accessibility, component libraries, naming conventions, etc, etc. If I say all of that upfront, it sounds like I’m just reading their job description back to them. And if I say too little, I undersell my experience.

This was where I tripped up the most. I overthought it constantly, and that indecision killed me in some interviews.

Iteration was Everything

The best advice I can give to anyone looking for a job right now is simple: iterate.

If you’re not landing interviews, it probably means your resume and/or portfolio need some love. If you’re not passing recruiter screens, your elevator pitch might need work. If you’re getting stuck after the portfolio presentation, it’s time to refine that. You get the idea, every step gives you clues for what to tweak next.

This whole process was a constant loop of tweaking, rewriting, and updating. I changed my elevator pitch many times, and I probably rewrote my resume and LinkedIn like a dozen times. Each version got a little sharper, better language, clearer framing, more aligned keywords, and supposedly more ATS-friendly (whatever that even means 😂).

I obsessively refined my portfolio. I spent months making sure my portfolio sparked joy, that it could set me apart, and that it actually represented what I care about, how I work, and the type of design system work I love doing. I wanted my portfolio to be easy to scan and understand for someone without a lot of design system knowledge, aka recruiters, while still impressing the design system nerds that had time to read a little bit more.

One thing that helped me the most was to always work on my portfolio. Even when I’m employed. Every time I start a project at work, I start documenting a bit of everything in my personal notes so that I can reference later on, I take screenshots at a time, and just write the whole process as I am doing it. I never want to have what I call portfolio debt anymore, that moment where you need your portfolio, and have a rush to update it, but everything is outdated, and you barely remember the details. Every designer knows that feeling, and it sucks, it’s probably our biggest nightmare as a designer.

If you want to peep my portfolio, here it is 👀.

And then there were the portfolio presentations. That sucker drained my soul. For the first portfolio presentation, I spent like 2 weeks designing it, and the day before the interview, I only slept 2 hours because I spent way too long designing it and wanting it to be “perfect”. Spoiler alert: it wasn’t perfect, and I did not get that job. 😂

Every time I updated anything, I’d think, this is it, this version is the one. Until I made the next version. And the next. And the next...

The Portfolio Presentation Dilemma

Usually, portfolio presentations are 45–60 minutes long to show “impactful work.” Cool. But… what does that even mean for a design systems role?

Should I show how I built components? How I created a token system from scratch? Should I talk about strategy? Cross-functional collaboration? Governance? Adoption? Accessibility? What are the specific things I should showcase? I know you say, “Just reference the job description,” but every design systems job description lists like… everything, and it’s really hard to predict what each team values most just from the job description.

How could I possibly pick one or two case studies that represent everything I bring to the table and share it under 45 min?

In my early attempts, I tried showing two long, detailed case studies, and while I thought they were really good and compelling… they didn’t work, they were too boring. Then I tried two different case studies. Still didn’t work still long and boring. I was stuck in this loop, constantly second-guessing what to include, and it killed me not knowing why I didn’t pass some interviews, especially when no one ever sent feedback, even after I asked. Was it the content? Was it my experience? Was it the way I communicated? I may never know 🙃

So I tried something new.

My friend Diana Wolosin | Design Systems suggested I create a bunch of shorter case studies, each one around 10 to 15 minutes touching on different aspects of design system work, and then let the interviewer decide what they wanted to dive into.

At first, I said, “Nah, that’s too much work.” 😂 But as time passed (and after a few painful interviews), I decided to give it a try anyway. Even if it was a lot of work, I knew I wanted to put all my energy into making my portfolio presentations as strong as possible. And once I did that, it totally changed the game.

The presentations felt more interactive and flexible. I could actually show the range of my work without overwhelming anyone or guessing what they’d care about.

My portfolio presentation ended up being over 200 slides. Not because I was trying to be extra, but because I wanted it to be visual, rich, and engaging. I didn’t want to talk over a static screen for 30 minutes. I wanted the visuals to help tell the story. I’m a super visual person (and I have ADHD), so if I start zoning out after five minutes of a static screen, I assume others do too.

That ended up being a big differentiator. I got a lot of compliments on how clear and thoughtful the presentation was. But it definitely didn’t happen overnight. After every interview, I tweaked things. I practiced with friends. I recorded myself on Zoom to catch filler words, pacing, awkward transitions , you name it. And I learned something new every single time.

Now, I know this approach isn’t realistic for everyone. It takes a lot of time and energy. And trust me… I get it. I’m a new mom with a toddler. I don’t have any time outside of working hours either. But I made the effort. I stayed up late most nights working on it because I wanted to create something I was proud of. And in the end, it was so worth it.

That presentation was my ticket to the exact job I had been looking for a long time. ❤️

Everyone Wants Something Different Yet Very Specific

What one company loves, another won’t even look at. It leaves you constantly second-guessing what to show and what to lean into for each interview. Some companies want niche experience like B2B or SaaS. Others are focused on soft skills, hard skills, or whatever the hot topic of the month is, and let’s not forget AI AI AI 😅

It’s exhausting.

What I think is that a lot of companies are just trying to hire a clone of the last person who had the role. Same background, same experience, same vibe. So if you don’t already look like what they expect, is tough.

It’s important to keep iterating, but don’t let conflicting feedback send you into a spiral, which is so easy to fall into, trying to please everyone is just hard. You can’t. Yes, iterate and get better at interviewing and making your portfolio and portfolio presentation better every time, but just make sure what you’re showing reflects you and the work you want to keep doing.

The Real Growth was in the Practice

Interviewing is a skill.

You can be the most talented designer in the world, but if you haven’t practiced explaining your work in 30 minutes to strangers with very different backgrounds, you’re gonna blow it.

My first few interviews were rough. I rambled. I rushed. I missed key points. But I kept going. I kept practicing. And it got better. Way better. By the end, I felt like I could actually tell my story, whether I had 5 minutes or 45. I was having really solid conversations with great companies. My resume and portfolio were working. The difference was just time, practice, and reflection, which gave me a lot of confidence.

Lastly, if you’re in it Right Now…

Ugh, I feel you! I feel you so much. It’s painful, but you have to keep going. I know it’s exhausting. But the truth is: your stuff is probably not done yet, and that’s okay.

You’ll update your resume, tweak your slides, and rewrite your case study intros a million times. You’ll do five interviews and realize only after the sixth one that you finally know how to explain that project clearly.

Don’t feel bad because you got a few rejections, in fact, don’t pay attention to the rejections and keep going, if you internalize them, it’s going to hurt your confidence and that’s a real problem. You’re probably going to interview with a lot of companies over several weeks (or months). That’s normal. You just need ONE yes. ONE team that gets it.

And until then, keep iterating. Keep making it sharper. Keep telling your story a little better each time and keep trusting in yourself.

If you are getting tons of rejections, that doesn’t mean you are a bad designer, or that you are a failure. You’re just in the thick of it. You’re doing great, this market is tough, but so are you! 😀

Thanks for reading, and if you are looking for a job, I hope you get one soon!

Searching for a Design System Role in 2025 was originally published in Design Systems Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most design system advice that I have been reading all of these years comes from big and well-established companies with big design system teams with many designers, engineers, managers, and even… directors?

But what if you’re… not that? What if you’re the only design system designer? No squad. No fancy tooling. Not many ENGs dedicated to the design system, just a few ENG peeps who pitch in when a ticket gets assigned or when something is needed for a release or a pickle.

That’s been my reality for the last three years, where I’ve been doing just that at Unqork, a no-code platform that enables enterprise companies to create applications without any code. When I joined, the company was in the middle of migrating from Angular to React and implementing the newly built React design system across the platform. I would say the design system was on stage 2 on the Design System Maturity Model, so basically: “Hey look, we have a button!”, and adoption was ramping up. So yeah, no presh for me joining there 😬

I quickly jumped in, worked closely with cross-functional teams, and helped implement the design system into every feature we could, and over time, we leveled up to stages 3 and 4: teams using the system consistently, contributing back, and relying on it to build stuff.

And as much as being the only design system person sounds like a lonely island, it’s actually been the best crash course in… everything. Tokens? Yep. Figma libraries and components? All me. Governance, documentation, adoption strategy? Still me. Mentor other designers, ah yeah me, me, & me. You learn fast when there’s no one else to pass things off to, and that’s not the worst thing in the world.

And because I haven’t seen a lot of articles written about this, as I said at the beginning of the article, I thought I could share some of my experience and what I have learned along the way!

Don’t start from scratch

There’s no reason to reinvent the wheel or every component; that is the point of the design system, right? No need to create a button from scratch when there are solid UI libraries already out there! Many with built-in accessibility, interaction states, and responsive behaviors. Use 👏 them 👏. Customize them to fit your brand and platform needs and keep going!

Building a text field from zero might take a few days. Building it with states, variants, accessibility support, and documentation? That can take weeks. That’s time you could spend solving higher-impact problems.

Keep your brain (and your system) in check

As a designer with ADHD, one of the hardest parts for me is keeping momentum without hyper-focusing on one thing and completely ignoring everything else. I’ve definitely spent hours tweaking a token name or nudging a button by 1px… while forgetting I had two deadlines and a Slack thread blowing up.

What’s helped me:

• Using the Pomodoro techinque to work in short bursts with real breaks

• Blocking big chunks of time every day to go deep without interruptions

• No-meeting Fridays (blocking the whole day on Fridays to really dig into work)

• Having set days or times for different types of work, like documenting, exploring, or cleaning up Figma.

• Keeping my daily to-do list short and realistic (like, actually possible to finish in one day)

All of these little tricks have helped me to keep moving forward without getting completely lost in the weeds (As we do 😅). If your brain also tries to do 523572 things at once (or freeze from trying), I promise you’re not the only one.

Manage expectations like it’s your full-time job (because sometimes it is)

When you’re the only design system person, everyone comes to you. Designers, Engineers, PMs, everyone needs something and fast: a new variant, a new property, a new token, a quick review, “just a small tweak”, a bug, etc etc. And because you care (and probably want to help), it’s sooo easy to say yes to everything.

But the truth is, you can’t. And if you try, you’ll burn out fast, it has happened to me before.

I’ve learned to be realistic and upfront about what I can actually take on. I prioritize what brings the most value to the system or unblocks the most people, and I’ve gotten more comfortable saying “no” or “let’s add it to the backlog.”

I know that that’s not just a solo designer problem; it's probably all Design Systems teams in general, big or small. We can become request factories, but the difference is that in bigger teams, you can divide the load, and when it’s just you, there is no one to lean on. It’s you and only you in the room.

Build relationships and partnerships, not just components

No design system works if it’s just one person. It’s called a system for a reason. The relationships you build with designers, engineers, PMs, and leadership will shape your system’s success way more than any Figma or documentation file ever will. Know your go-tos. Rely on them. Ask them how their day is going. Personal connections go a looong way, I learned that from Articulating Design Decisions by Tom Greever, I highly recommend that book to any designer!

Anyways, my way of building relationships and keeping communication going might look a little different, but the goal is the same, I make sure there are clear, open channels, so I have dedicated Slack channels for designers and engineers, weekly Design System office hours, and regular one-on-ones with the engineers building the system.

But honestly? My favorite way to connect with anyone is with a simple “QQ.” Sometimes it’s just a quick async DM. Other times it’s code for, “Hey! Quick question, got a min to hop on a call?” It’s my favorite way of clearing things up fast and keeping it human. I like this approach because messaging can get tricky. Tone gets lost. Long messages get skimmed (I’m guilty too 😅). A quick call or a short QQ keeps things clear and way more efficient.

Don’t let perfection slow you down

This one hits home hard. I’m a perfectionist. I want every token to make sense, every component to spark joy, every doc to feel complete.

But the truth is: perfect is the enemy of progress. I’ve learned to ship things when they’re “good enough,” even though it kills me a little bit on the inside, because even a rough version of something helps more than none at all. You can always iterate. What matters is unblocking others and creating momentum.

Reuse what you can… but be thoughtful

I’ve seen and done over-complicated components with tons of properties no one understands how to use, just me 😂 . But just because you can make something configurable doesn’t mean you should.

Think systematically. Ask: is this component solving for common use cases? Is it easy to understand? Can someone pick it up without asking a dozen questions? Do I really need all these props? Yes, I am talking to you data tables in the back 😂

The key is to balance flexibility with clarity.

Documentation 👏 doesn’t 👏 have 👏 to 👏 be 👏 fancy

I used to feel pressure to create a big beautiful documentation site like the design systems that I admire the most. But the truth is that for most people a simple reference and examples they can copy is enough for them to use the component correctly. I have also spent a long time documenting components or use cases in a very detailed way just to realize that some people don’t even bother to read or look for the documentation, big hit on the heart 💔

Don’t compare your system to others

It’s easy to look at systems from Shopify, IBM, or Google and feel like yours is shit 😬, I get it, been there, done that, but I realized that those systems have entire teams behind them and what I was feeling wasn’t failure… It was a mix of imposter syndrome and perfectionism getting in the way of my own progress.

So, yes, look at other big, amazing design systems, but use them for inspiration, but don’t let them make you feel like your work isn’t good enough. Your system doesn’t need to be everything to everyone. It just needs to work for your team, your platform, and your product’s unique constraints.

So, if you’re building a system alone, it’s easy to feel like you’re doing it wrong, but let me tell you, you’re not. You’re just doing it with the few resources you can, be proud of yourself, and share all that amazing work you are doing!

Learnings of a Solo Design System Designer. was originally published in Design Systems Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

What even are Snowflake Components?

Snowflake Components are those one-off custom components we all end up designing when the official design system doesn’t cover what we need. Maybe it’s a very specific banner, or a variation of a button that only one team is using in the moment. They’re not part of the design system (yet), but they exist because there are real product needs that don’t wait.

Now, instead of letting those snowflakes live in mystery land (aka someone’s personal Figma file that no one else will ever find), I started documenting them. Why? Because if multiple designers/teams end up making their own version of the same thing, we have just multiplied inconsistency across the whole product, and design systems are all about the opposite, help products get consistent. Plus, if the component ever gets implemented, we know exactly where it was implemented so we can swap those with the official component.

So that’s where a Snowflake Components Library comes in, and that’s what this article is about!

Why I’m Writing This?

This whole initiative came from something I see happen all the time as a design system designer in a company where things move fast: Designers making local components that live only inside their file, totally unaware that someone on another team built almost the exact same thing two months ago. And sometimes when *ahem* I’m lucky enough, they bring it up during design system office hours, and I can connect the dots between teams/designers. But honestly? That’s not always the case. Most of the time, these snowflake components never see the light of day again.

Also, I’m a solo design system designer, and keeping all of this in my head just isn’t scalable, there is so much I can do and remember. So I wanted to document these snowflake components in a clear, shared space so everyone has the context, not just me. It makes consistency, collaboration and adoption much easier, and governance smoother. Plus, this way, designers feel empowered to create their own things without the DS police (me haha ) watching over them and telling them what not to do.

And also: I haven’t really seen people document snowflakes this way in other systems. So maybe I’m starting something new here. Pioneer vibes only 😂.

Wait, if you create components and put them in a shared published library, what is the difference between official DS components and snowflake ones?

Well, good question my friend, good thing I am here to explain:

👉 Official design system components are the real deal. They’re well documented, tested, reviewed, accessible, consistent, and meant to be reused everywhere. They have been stress tested, approved and widely used, they get updated and maintained often. Long story short story, they receive a lot of love ❤️.

👉 Snowflake components on the other hand are more like “hey, we needed this yesterday, and the DS didn’t have it, so we made it.” They are often a one time thing, created to solve immediate needs, and not polished or universal. That doesn’t make them bad, it just means they are not meant to be permanent unless they prove themselves over time.

But Chela, where do you put these components?

You basically have two options:

Option 1: A Page inside your official DS component file

✅ Pros:

• Everything’s in one place, so it’s easier for designers to find and reuse snowflakes.

⚠️ Cons:

• The DS file can get bloated fast, especially if a lot of snowflakes pile up.
• It’s easy for people to confuse snowflake components with official ones, especially if they’re not clearly labeled.
• You’ll probably need stricter rules and organization to avoid the whole thing becoming messy.

Option 2: A Separate Figma file just for Snowflakes

✅ Pros:

• Keeps your main DS file clean and focused , no snowflake clutter.
• Designers can explore, build, and document freely without worrying about breaking anything official.
• It’s easier to give access to more people without stressing over who’s touching the core DS.

⚠️ Cons

• If the file isn’t well shared, people might not even know the snowflake library exists.
• There’s a bigger chance of duplication if teams don’t check the snowflake

This is what I do. I made a separate file called the Snowflake Components Library, each component has its own page. Having a separate library makes governance easier. Designers can come in, add their stuff, and browse what’s already there. It’s open, lightweight, and way easier to manage rather than jamming everything into the core library.

How do I document snowflakes?

Plain and simple! I don’t overdo it. If documentation was a requirement, no one would do it (myself included) because that defeats the whole point of them. Snowflakes aren’t official DS components, so I don’t treat them like they are. No extra layers of process, just enough context so anyone can jump in and understand what’s going on.

Here’s how I build my snowflake library:

On my snowflake component library file, I created a simple template page that any designer can copy and fill out when they create a snowflake component. No need to start from scratch, no heavy documentation, just a few key things that give everyone enough context.

Here’s what’s in the template:

• Component Page: A page where the new component will live that includes a clear name and a quick explanation of what the component is and what it does and the component itself so others can see it, reuse it, or build from it.
• Project Info: This page includes the name of the project where it’s being used, the name of the designer (so we know who made it), and a link to the Figma file where it’s being used. If someone needs more context, they know where to go.
• Wireframe: A wireframe or screen that shows where and how the component is being used in the actual product.

That’s it. When someone else adds a new snowflake, they follow the same pattern. It keeps things clean and easy to scan without needing a full spec or 20 annotations.

When does a snowflake become a real component?

I have a rule of thumb, if a component is used by three or more teams and it brings a lot of value to the system, then it becomes eligible for review. From there, I look at consistency, accessibility and scalability. If it passes, it might get added to the official DS. If not, it can stay a snowflake, or evolve over time.

So… why even bother?

Snowflake components are not the enemy. They’re just a natural part of building fast, flexible products. But if we don’t document them, we lose visibility, duplicate efforts, and create design debt.

Giving them simple home and just enough structure, has given me good results and I have been able to keep things organize and scalable, plus it has helped with adoption as components are made with purpose and an actual need.

Again, I haven’t seen this kind of documentation out in the wild. So maybe I’m the first? (I hope so, look mom no hands 😂)

If you’re doing something similar, totally different or if you like the idea and you will plan to implement it with more additions to make the process better, I would love to hear!

The Components We Don’t Talk About Enough: Snowflake Edition ❄️ was originally published in Design Systems Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

I want to share my experience as a Latina in the tech world, where I often find myself as the only woman in a room full of white peeps 😬

I was born and bread in Bogotá, Colombia, and moved to the U.S. eight years ago. I’m a product designer working in tech, with a focus on design systems and accessibility. It’s been a journey full of challenges, but it’s also brought a lot of personal and professional growth.

One of the biggest challenges I have faced is having an accent and how that affects the way I’m perceived.

When people hear my accent, they often ask where I’m from. They may not mean anything bad, but deep down that reminds me I’m different, and people don’t notice is a micro-aggression… It highlights the challenges of navigating a workplace where my background and language set me apart.

Woooah I started strong didn’t I? Lol well let me share with you how I got here!

I started learning English in school, I didn’t have the chance to attend a bilingual school, I thought I had a good english, “enough to get in trouble” but when I first arrived to the US, I realized I couldn’t even get into trouble cause I didn’t even understand people talking to me, ha! That made me realize how much I still had to learn. I met my husband on that trip, and we were talking though Google Translate the whole time! It was funny, but it really pushed me to learn more english.

Learning another language as an adult is way harder than when you are a kid, but I wasn’t going to let that stop me, I started learning English more seriously by watching lots of “Learn English” YouTube videos and using Duo-lingo every day. I had the chance to move to Canada for a bit, and “I learned English in the streets” That’s a Colombian saying meaning that I learned English by just practicing and listening to it all around me, since there is not a big population of Spanish speaking there, I just had to do it, I didn’t have another chance.

After that, I moved to the U.S. The transition was amazing but also challenging. In Colombia, I was never the different one. There isn’t much diversity in terms of language or accents; everyone speaks Spanish, so I never had to worry about standing out for the way I spoke. But when I arrived here, I was suddenly the one with the accent, the one who sounded different. It made me feel ashamed at first. I wasn’t used to feeling like I didn’t belong or like I wasn’t capable because of how I spoke. I say this because that experience taught me a lot about myself and others. I’ve become better at including others. I realize now that there were times where I was part of the problem and maybe dismissive without meaning to. I now try to be inclusive in every way I can. This is one of the many reasons I love about accessibility and why I fight so hard to build accessible user interfaces. I want everyone to feel welcome and valued.

Anyways, in my first few jobs here, I was the only Latina and the only one with an accent. I felt a lot of different emotions — in one hand, I felt incredibly fortunate for having a high paying job and being “the only one” but in the other, I felt intensely isolated and not well represented. I often thought about myself as less capable than my colleagues, and because of this, I became a workaholic.

I was convinced that working overtime and consistently saying yes to projects despite not having sufficient time to complete them within a 40-hour work week, was the only way to prove my value to others and to achieve professional growth. I was trying to overcompensate for not speaking “perfect” English and for other challenges that reflect the complex nature of diversity and inclusion in the US. This mindset to overwork along with the encouragement to do so, ultimately led me to experience burnout and had a significant impact on my well-being and self-confidence.

Here is the kick… What people don’t see behind bilingual people is the extra mental work that comes with speaking another language. I am constantly overthinking everything! Making sure what I am saying makes sense, rewriting slack messages over and over, and hoping people understand what I meant. During presentations, for example I’m often not only the only woman, but the only woman with an accent, therefore I am not just focused on what I’m saying; I’m also focused and ahem let’s be real, worried about mispronouncing something and then spending the rest of the presentation stuck in that thought, hoping it won’t throw me off or ruin the rest of what I have to say, and for the rest of the day I am thinking about how I sucked and that people is going to think less about me or my knowledge because I f***ed it up.

And on top of that, people sometimes try to explain things I already know, either because they think I didn’t understand or for other reasons, like gaslighting or mansplaining. It doesn’t happen often, but it does happen. And I am left wondering if that happened because of my accent, because I am a woman, or both? ha!

It’s hard to fully recognize my own value when, despite my seniority, experience, and skills, I often feel like I have to keep proving myself over and over again.

But I am constantly trying to fight the good fight and embrace my cultural identity, acknowledging that being a Latina and knowing 2 languages, is a source of strength and power and not weakness.

The most important lesson I’ve learned is that diversity isn’t something to shy away from, it’s something to embrace and celebrate. I know that diversity brings unique perspectives to the workplace, and I have learned to give myself grace and celebrate my cultural background instead of trying to hide it. I used to feel pressure to blend in and sound just like everyone else, but now I see that my accent is part of who I am. It represents my journey, and I’m proud of it.

Working from home has been such a blessing because it gives me the time to think about what I want to say and how to communicate it clearly without sounding like I don’t know what I am talking about. I also appreciate tools like ChatGPT, which help me check if the message I wrote makes sense and help clarify my statements. Thank goodness for that!

I’m not a writer by any means, but I’m challenging myself to share my experience, and be proud of myself and all that I have achieved with my “broken English” even though people say I speak very well, I am often my hardest critic. But who isn’t really?

Now that I have a daughter, I am trying to teach her Spanish and help her being proud of being half Colombian, and deep down I am just secretly waiting for her to start correcting me when I say things “in a funny way”.

Yep that’s it. I said it! Cheer’s y’all!

Hey there, my fellow designers!

As my first story, I want to talk about a topic that’s been on my mind a lot lately — the use of well-known patterns for our own projects.

We’ve all experienced that rush of inspiration when we come across successful design patterns used by big companies or patterns that seem to perfectly solve our current problem. The temptation to follow the same path can be strong because if it works for them, it must work for us, right? Right?

It’s natural to feel tempted to follow the same path because we also have Jakob’s Law that reminds us to match our designs to our users’ mental models and improve their experience by enabling them to easily transfer their knowledge from one product or experience to another.

We all know that users don’t like to learn how to use yet one more thing and they prefer using something that feels familiar, but it’s essential not to get caught up in blindly replicating patterns. Blindly copying every pattern might not lead to the desired outcome.

In this article, I’ll explore why it’s essential to avoid being copycats and how balancing design originality, Jakob’s Law, and accessibility can lead to an exceptional user experience that can check all the boxes, — fulfilling user needs, business goals, and having great UI.

Here are some of the things to have in mind when using well-known patterns:

1. Patterns aren’t one-size-fits-all
   Design patterns are like puzzle pieces. While they might fit perfectly in one context, they might not align as smoothly with our unique projects, companies, business goals, and users’ needs. Just because something works brilliantly for a well-known company doesn’t mean it’s the right fit for our projects. As designers, it’s essential to be more judgmental and take the appropriate time to consider our specific use cases.
2. Finding inspiration without imitation
   While it’s natural to seek inspiration from successful design patterns out there, (and we all do it) it’s equally important to use our discernment, creativity, and uniqueness in our work. Don’t be afraid to think outside the box and add your magic to a well-known pattern. Let the patterns from well-established companies be your starting point rather than a blueprint for replication. Maybe it is time for you to start a new pattern in the design world that others can start implementing as well!
3. The vital importance of accessibility
   Designing with accessibility in mind is crucial, it should not be just a nice-to-have, it should be a must. Some widely used patterns may lack consideration for different abilities, failing to adhere to accessibility guidelines and standards. In some cases, it might be a lack of awareness or simply a trade-off between aesthetics or priorities and accessibility.
   I know what you may be thinking “But if they do it and they can get away with that, so do we!” But hey, as designers, it’s our responsibility to ensure that our designs are inclusive and accessible to ALL. Incorporating accessibility into our designs requires minimal effort compared to the ongoing challenges faced by people with disabilities when accessing digital products every single day.
   
   By simply adopting a broader perspective and considering the needs of all users, we can significantly improve the lives of many. Just because a pattern looks cool doesn’t mean that it serves well for people with disabilities.
   
   For example, here are some widely used patterns that might unintentionally exclude users with disabilities.

• Icon buttons or icons without labels
  Relying solely on icons for actions without incorporating clear labels, tooltips, or aria tags, can present significant barriers for users with visual impairments who depend on screen readers. The absence of proper labels in icons may also adversely affect users with cognitive disabilities, as they might struggle to understand the function or meaning behind them, resulting in a frustrating and inaccessible experience. Additionally, it’s essential to recognize that icons can carry diverse meanings across cultures, and their universal understanding cannot be assumed. Different icons might be used for the same purpose in various parts of the world.
  So, it’s really important to have clear labels with icons, either in tooltips or right next to the icon. But, in some situations, it might be better to skip the icons altogether and just use labels. This way, we can make sure everyone has a user-friendly experience!
• Patterns that aren’t keyboard navigable-friendly
  Lots of patterns out there are not keyboard navigable-friendly, and they can be problematic for users who rely on keyboards or assistive technology for navigation.
  Some individuals with motor impairments, for example, may find it challenging to use mouse-based interactions leaving them unable to access certain features.
  Ensuring that all interactive elements are accessible via keyboard navigation is crucial for inclusive design, plus every product has its power users who rely on keyboard navigation. So implementing keyboard navigation is a win-win!
• Cool hover effects are not cool for accessibility
  While hover effects may look cool, they can cause challenges for users with motor impairments or touch-based devices. Hover interactions often require precise mouse movements, which can be challenging for some users.
  In addition to the cool hover effects, some companies hide essential actions behind hover effects, like menu buttons or floating buttons. This can create frustration and confusion for users who cannot access the actions as easily as you thought.
  
  Instead of relying solely on hover-based interactions, it’s better to make essential actions visible and available to all users. Although clearing up the UI is sometimes needed, it’s super important to keep those interactions available to everyone!

To wrap up, let’s consider both Jakob’s Law and accessibility, while also keeping our user's and business goals front and center. Striking the right balance involves understanding our users’ needs, preferences, and pain points. Aligning our designs with the objectives of the organization ensures that our work contributes to overall success.

Designers, we’ve got the power to create outstanding user experiences that stand out from the crowd. We can create designs that resonate with our users and align with our project’s vision by balancing between inspiration from recognized patterns and crafting our own solutions.

Remember, your designs have the potential to leave a lasting impact. So, let’s break away from the copycat syndrome and let our creativity shine!

Additionally… Together, we can design a world where everyone feels included and empowered. So, let’s design high and create experiences that leave a positive mark on the lives of our users!

Cheers y’all!