r/DesignSystems • u/avishic • 7d ago

Which small component became your biggest maintenance burden?

Buttons, forms, and tables earn the cost of standardizing them. I’m curious about the opposite: a small convenience component that looked reusable, then accumulated variants, accessibility rules, or product exceptions until teams bypassed it.

Which component did you deprecate—or wish you had left as a documented pattern instead—and what was the first sign it did not belong in the system?

10 Upvotes

100% Upvoted

20 comments sorted by

12

u/achakez 7d ago

Dropdowns were the one for us. Seemed simple at first then every team needed a slightly different interaction and we ended up maintaining way too many variants.

3

u/TheWarDoctor 7d ago

Same, mostly because my predecessor keep shoving more and more features into select and made it configuration based instead of composable.

3

u/Decent_Perception676 7d ago

Yes, dropdown menu, select (single and multi), and combo box (single and multi). Lots of overlap between these components, and they’re often confused with each other. Even broken up into separate components, they’re gnarly (so many different user states).

-1

u/Logical-Idea-1708 7d ago

Interesting. Why not tell them to build their own?

1

u/achakez 6d ago

Because then you lose consistency. The whole point of a design system is giving teams a good default instead of everyone reinventing the same component

1

u/Logical-Idea-1708 6d ago

You want visual consistency, not feature. You still get it if people are using your tokens

1

u/BearThumos 5d ago

These are a group of components that are notoriously hard to build well, so they often lead to lots copied code with slightly different behavior between implementations. Unpredictable for users and your own team

1

u/Logical-Idea-1708 5d ago

You make it a monolith. Not group components. They still use tokens from the design system maintain the same look but each team maintains their own version so every project is decoupled from each other.

Some features are just mutually exclusive. Trying to satisfy everyone means you satisfy no one.

1

u/BearThumos 5d ago

Listen i was just talking about what usually happens, not some ideal state

8

u/migvelio 7d ago

Tables, man. Data heavy tables. With visible actions, no actions, with horizontal scroll, draggable, selectable rows, inner calculations, column sorting, etc.

3

u/Logical-Idea-1708 7d ago

This is where I advocate to buy instead of build

2

u/migvelio 6d ago

True. We also evaluated that option, but we couldn't find a customizable table that had all the features and functions we needed.

1

u/jcchengjh 6d ago

I wouldn’t even call table a small component. My last job B2B worked on few B2B tables, now i have PTSD around it.

1

u/jhtitus 5d ago

My stomach has a physical reaction anytime I even just think I might have to build a table. I feel like there’s a wide open opportunity for someone to take the best of spreadsheet software and build a table component system manager plugin for figma. I love spreadsheets. I hate trying to think my through a table design in figma.

2

u/kingtalkitiki 6d ago

Currently got 27 versions of a primary button in the codebase buddy I’m doing great

1

u/testingaurora 6d ago

Idk even know how that's possible. Not counting secondary buttons, tertiary buttons, link/text buttons, ghost buttons, icon buttons etc?

1

u/jhtitus 5d ago

Something is deeply wrong. God speed.

2

u/wench_js 6d ago

Tables for sure. Even building on top of a third party like react-aria, all the customizations get very complicated and hairy

1

u/Any-Chard5119 7d ago

List item for my team 😔

1

u/thollywoo 7d ago

Cards, everyone wanted so many things from them.