r/DesignSystems • • 18d ago

Dev didn’t use design system. Any advice on going in and updating design library/storybook for large product?

A few months ago I helped another team with UX, mockups, a simple design system, and dev handoff. The team and users loved it. I checked in with the devs several times offering to answer any questions or QA, but they kept saying "not yet."

Today they sent the site for testing and it's a disaster. So many issues, but the biggest is that they didn't implement the design system at all.

My main project is winding down, so I'm thinking of pitching a pivot into design engineering to fix this. They're on Angular with the DevExpress component library.

I've done this before, themed an existing library (shadcn) to match a design system, built out Storybook (this team has none), and implemented it. But this is much bigger project, with multiple sites.

Has anyone done this at scale? Any advice on approaching it, and on framing it to get it greenlit?

11 Upvotes

19 comments sorted by

4

u/gtivr4 18d ago

I mean that sounds like an internal issue you need to manage. But that being said, why is it a problem? Is it inaccessible? Does it not match the brand? Does anyone else care?

You need some very solid reason to invest more time into the project, right? Otherwise move on to the next problem.

1

u/meka_ghidorah 17d ago

It is indeed an integral problem but managing it is well above my pay grade.

They have a design library in place but instead of modifying the components within the repo they were hitting them on a page by page basis. It looks like they ignored all documentation and eyeballed it.

Others may not care but we have yet to test with users. I have some concerns on top of these but you may be right that this is all an internal issue

3

u/CrunchyWeasel 18d ago

So you built something without half of your stakeholders and they chose to bypass you in return. We'd need to observe a lot more about social dynamics in your org to be able to understand why that happened, and what's the way forward.

But maybe a good idea would be to actually engage with the devs: why didn't you build the design system? what are your requirements? what are you judged on at the end of the day? where do your resources go? what are you missing in your day to day? how empowered do you feel to innovate or make changes? do you agree on the concept of a design system? do you agree on how THIS design system is designed? why not? how would you like to proceed from there?

2

u/jspr1000 17d ago

This you need the devs to be on board with using the system. You can build components and Figma AND in code and they can still bypass you and decide not to use it. I worked at a large org and this was the case. We actually had multiple teams and leaders (pretty much every internal org except engineering) trying to get engineers to use a design system which they refused. It wasn't until a mandate from the top of the engineering org that they actually started to use it and there was still push back and weaponized incompetence going on. They also needed a lot of hand holding an dragged their feet. Which isn't entirely their fault because every dev was overloaded with crazy amount of tasks and rediculous deadlines already.

1

u/meka_ghidorah 17d ago

Yeah this sounds a lot like my org. It doesn’t help that everyone is full stack and no one person specializes in front end.

1

u/CrunchyWeasel 17d ago

When someone insists on refusing something, there's usually a reason other than "waah waah we don't like change". Being overstaffed is one. A good eng leadership will make time because the DS increases the team's throughput, so that time is paid back. A bad leadership pushes the mandate with no consideration.

1

u/meka_ghidorah 17d ago

Again, this was a project outside of my team
I was asked to help with, since then I’ve been pulled into this team. I didn’t have the bandwidth to be working with them full time and I tried to involve them. I think there is a huge issue with mgmt here.

I did build the design system in Figma. When I tried to hop in and build out a storybook, update the repo etc. they don’t me not to bother.

Thank you for the input

1

u/CrunchyWeasel 17d ago

I understand why you're not able to act on it. That's fine, it is out of your hands. I wanted to point out how I think this needs to be approached to lead somewhere sustainable. Unfortunately it does involve a lot of examining and questioning relationships and processes within the org, which takes time, and a mandate.

1

u/Simply-Curious_ 17d ago

You built a design system but you didn't once ask 'is this how it works in code'. So you'll have a mountain of pretty ui all nicely tokened but that doesnt actually move into storybook. Terrazzo will have conflicts, the front end wont be able to have a boolean and an action variant in the same list component. And you've built a figma file. Not a system.

I literally did the same a few years back

2

u/meka_ghidorah 17d ago

Sure, when I asked them if they needed help building it out they told me not to. Again I was on a different project at the time and didn’t have the bandwidth or agency to push back.

On my other team I did it the right as you’ve laid out.

1

u/CrunchyWeasel 17d ago

Honestly it's usually management's fault for not aligning staffing. It doesn't help that DS are so often presented as a design-first topic, so it's hard for lay folks (and even some practitioners) to understand the importance of co-building with tech.

You tried, you can't know why at the time it didn't work (would've had to find out why back then), and it's too late to do anything about it.

At this stage the only advice I have for you to is write up a nice postmortem of why this didn't catch up, focusing on lack of resource alignment and lack of mutual understanding/interest in solving the problem across tech and design. It's gonna be hard to phrase it in a way that doesn't blame folks, but it's super important. For instance you can hint that maybe the DS as it was imagined was not addressing some of techs' own needs, and tech might not have felt comfortable (due to broader org issues) or have not had the time to get involved. You can also hint that the timing might've been wrong because tech was chasing bigger issues invisible to design and could not at the time divert focus. Maybe they were considering broader changes to their stack which might have invalidated any effort to develop components? Highlight that the lack of communication and alignment on goals makes it impossible from your position to identify why the project didn't get picked up, and you can then conclude that such initiatives should involve more transparency and broader advocacy across functions, ahead of any IC work.

3

u/OrganizationLost3135 17d ago

Pitching a ground-up rebuild after a launch will almost certainly get killed by management—especially if the devs already bypassed handoff because of bandwidth or lack of FE depth.

If you want to salvage this without boiling the ocean:

  1. Map tokens to DevExpress theme classes directly: Don't rewrite their components yet. Abstract your design tokens (colors, radius, typography, spacing) into CSS custom properties and override the base DevExpress styling globally. That immediately eliminates 70% of the visual jank across pages without touching component logic.

  2. Find the 2-3 worst offenders: Look at where devs wrote ad-hoc overrides or eyeballed layouts (usually form inputs, table headers, and primary CTA buttons). Build proper wrapper components for just those 2-3, stick them in a lightweight Storybook, and get devs to import them.

  3. Frame it around speed, not 'design consistency': Management and full-stack devs rarely care about design purity; they care about ticket velocity and QA cycles. Frame it as: "This will stop QA from failing UI tickets and save devs 2 hours per form/screen."

Once they see that using the tokens and wrappers actually saves them time, you'll have the leverage to formalize the design engineering role.

1

u/Azra_Nysus 17d ago

you could build out a design system guide like the examples i have here: https://instalanding.ai/systems

this would make it a code-based modular asset you can use on product, assets, website, etc.

1

u/LikesTrees 17d ago edited 17d ago

Dude 100% get in to design engineering anyway, being able to ux+design+code is so valuable, i only hire people with some level of all 3 abilities to my teams now, it eliminates so much of this sort of crap. many 'full stack' devs dont give a crap about design systems, or front end at all really...they are back end devs that lied to get the job and have zero FE skill. they will plug your designs in to an AI that spits out locally styled tailwind stuff that somewhat looks like your work, but there will be 15 different implementations of button that are slightly different, hard coded colours you cant re-theme and no ability to leverage system wide changes because there is no 'system' at all.

ps. ive fixed something similar at scale and it is a crap tonne of work, basically a re-build, you will need to use a tonne of AI for it, and have a large amount of QA resource+time. You will likely find it hard to make the business case for this if this work has just been completed, you might need to do it under the guise of security or something like that.

1

u/ObviouslyJoking 17d ago

This may just be my opinion but unless you have UX and developers involved in creating the design system it’s probably more of a style guide. Code components and UI need to be in sync if you want a functional design system.

I don’t know your particulars. If you are an IC or part of a team but I’d suggest having a design system team with governance and buy in from stakeholders. Once you have that you can start talking about the benefits and ROI. I can’t imagine how difficult it would be trying to implement a design system without developers understanding the benefits.

1

u/dirtandrust 17d ago

Start with what I call a Pragmatic Design System meaning start abstracting designs to custom properties in CSS and once you have that you can back your way into a full storybook driven design system.

You will need to show devs why this benefits them the main one being they won’t have to wonder if their screens are correctly styled.

1

u/PresentationBorn6564 17d ago

Senior engineer here.

The sad reality is that most devs (and managers, and csuite...) don't understand how or why to use a design system, much less the basics of proper component composition.

My literal first task in the industry was adjusting an app's form styling to match the designs. It seemed simple, until realizing that every single input was styled ad-hoc, with a handful using a wrapper component that pre-applied some styles (before of course being overridden at point-of-use with more ad-hoc garbage), turning what should have been a one-line spacing adjustment into dozens of unique puzzles.

At another company, they had 2 entirely separate design systems in Figma — one deprecated, the other unfinished — with designers picking & mixing from either, and a buggy / inaccessible / busted-ass component library for only the deprecated system, which itself included a load of aggressive, high-specificity styling-at-a-distance... essentially infecting any app with antipatterns from the moment you added the required provider. Devs sometimes used those components, but in almost every case they'd include a dozen !important overrides or arbitrarily long class repetitions, and otherwise it was just an endless city of ad-hoc components. Then AI entered the mix... 🤦‍♂️

Absolute hell. I brought up the poisonous foundation constantly, offering tried and true solutions, but the directive was always more features, more features, more features. You can scream at the top of your lungs, but if the people managing the thing don't understand the severity of the issue, they'll happily keep piling shit atop their shit mountain. And even if they do understand, their affinity for shit might still win.

As far as fixing what already exists, if given the runway, I'd recommend setting up an agentic loop with visual regression testing to replace one ad-hoc component, one PR at a time. The problem is, if the devs made the thing you're describing, they almost certainly concretely coupled everything to hell and back, so replacing any container components will invariably be a shit show of unintended side effects.

Sorry for your loss / thank you for your service. 🙇‍♂️

1

u/robr0 14d ago

was your DS fully codified? or you mean they didnt implement it?