Who Owns a Component Search: Code or Design
Seven UI component searches, checked result by result on 11 September 2026. Some are owned by component libraries, some by design writing, and the split is predictable.
Written ByVlad Hrynchuk
Searching a UI component by name returns one of two kinds of page. For accordion, five of the top eight results are component library documentation — Material UI, shadcn, jQuery UI, Carbon, Semantic UI. For form design, not one result is library documentation. What decides it is how much of a component's demand comes from developers implementing it rather than designers deciding it.
Key takeaways
- The suffix does not predict the results. Both "accordion ui" and "tabs ui" carry the same suffix and return very different pages.
- Components that are primarily a coding task are owned by library docs. Components that are primarily a design decision are owned by design writing.
- Accordion is the extreme case — five of eight results are library documentation, and design articles are squeezed out entirely.
- Form design is the opposite extreme — zero library results, with a personal blog ranking seventh.
Search a UI component by name and you get one of two kinds of page: documentation from a component library, or writing about how the component should behave.
Which one you get is not random, and it is not decided by the wording of the search. It is decided by the component.
Here's what this guide covers:
- Seven component searches, classified result by result
- Why accordion and form design land at opposite extremes
- What the suffix predicts, and what it does not
- How to check a component yourself before writing about it
The data
Seven searches, run in the United States in English on 11 September 2026, first page of organic results classified by hand. Figma UI kits are counted as code, since the searcher is downloading an artefact rather than reading guidance.
| Search | Volume | Library / code results | Design / gallery results |
|---|---|---|---|
| accordion ui | 1,300 | 5 — Material UI 2, shadcn 4, jQuery UI 5, Carbon 10, Semantic UI 11 | 3 — Dribbble 6, Wikipedia 8, NN/g 9 |
| form design | 1,000 | 0 | 8 — Dribbble 1, NN/g 3, heyflow 5, designlab 6, andrewcoyle 7, Pinterest 8, Canva 10, Medium 11 |
| breadcrumbs ui | 880 | 2 — Material UI 4, Tailwind 9 | 6 — NN/g 2, Wikipedia 5, Dribbble 7, pencilandpaper 8, navbar.gallery 10, setproduct 11 |
| tabs ui | 480 | 3 — Material 2, shadcn 7, MUI 11 | 5 — Dribbble 1, NN/g 3, Pinterest 5, setproduct 8, designsystems.surf 10 |
| dropdown ui | 390 | 3 — Semantic UI 1, Figma kit 7, Material 9 | 5 — Dribbble 3, Mobbin 5, NN/g 8, Pinterest 10, Eleken 11 |
| pagination ui | 320 | 4 — MUI 3, Figma kit 6, daisyUI 8, shadcn 10 | 5 — Dribbble 2, Medium 4, Mobbin 7, Eleken 9, setproduct 11 |
| toggle switch ui | 260 | 2 — uiverse 3, Apple HIG 10 | 6 — NN/g 2, Dribbble 5, setproduct 6, uxtweak 8, Mobbin 9, sarasoueidan 11 |
What decides it
What decides the results is not how the search is worded. It is how much of a component's demand comes from developers implementing it rather than designers deciding it.
An accordion is a solved interaction. There is a correct implementation, the accessibility requirements are settled, and most people searching for it want working code. So the libraries own it, and they deserve to.
A form is a set of judgements: which fields exist, what order, when validation fires, what the error says. No library answers those, so writing about them ranks.
Breadcrumbs, toggles and tabs sit between. An implementation exists, and the decision of whether and how to use them is genuinely contested — which is also true of dropdowns and pagination, both of which split their results almost evenly.
The suffix is a red herring
accordion ui and tabs ui carry the same suffix and return very different pages — five library results against three.
Suffixes move search volume a great deal. The same topic can measure 4, 14 or 2,632 depending on the wording. What they do not move is who is on the page, because that follows the nature of the component rather than the phrasing of the question.
Anybody planning content from volume alone, without opening the results, will pick the biggest number and land on the page they cannot win.
The practical reading
On a library-owned search, a design article loses. Not because it is worse, but because the searcher wanted code, and Material UI or shadcn/ui answers that directly with far more authority behind it.
Dribbble and Pinterest appear on almost all of them. Whatever the component, some share of searchers wants to look at examples rather than read. Seven of the seven searches have at least one gallery result, and three have one in the top three.
NN/g ranks on four of seven. Twenty years of writing about interface conventions, still the reference. Apple's Human Interface Guidelines turn up too, on toggle switch.
Small publishers rank on the design-owned searches. andrewcoyle.com at 7 on form design, sarasoueidan.com at 11 on toggle switch, pencilandpaper.io at 8 on breadcrumbs, setproduct on three separate searches. Where the search is a design question, authority is not the gate.
What to do with it
Before writing about a component, run the search and count. If more than half the first page is library documentation, the topic is a coding task and the article will not rank however good it is. If none of it is, the topic is a design decision, and a small publisher can take it.
That test is what we applied before building out the component half of our glossary, and it is the reasoning behind our design system decision guide and the dashboard design work: pick the surfaces where judgement, rather than implementation, is what the reader is missing.
Free to quote or reproduce with a link back. Results move, so re-run any search you plan to act on rather than trusting a snapshot from September.
If you are building a component library and want it to survive contact with production, we're here.
