I have seen design systems that looked excellent in the design file and became much less convincing once they reached the build. The colours were defined, the buttons were named, the spacing looked consistent and the components all appeared to belong together. Then development started, real content arrived and the system began to show where it was more presentation than structure.
That is not a criticism of design systems. I think they are useful. The issue is that a design system only becomes valuable when it survives contact with the website. It has to work with real content, CMS restrictions, responsive layouts, editor behaviour, performance concerns and future changes that nobody has fully planned yet.
That is the point where the design system stops being a file and becomes part of the way the site operates.
Components Need To Know What They Are For
A component that only describes how it looks is incomplete. A card might have an image, title, excerpt and button, but that does not explain when it should be used, how much content it can tolerate or what happens when the image is missing. Without those details, the component is easy to present but harder to maintain.
I like components to have a reason for existing. A case study card is not the same thing as a blog card just because the layout looks similar. The content source, editor expectations and user intent may be different. If those differences matter, the system should acknowledge them instead of forcing everything into one generic pattern.
This becomes especially important in WordPress. Editors do not experience a design system as a tidy page of components. They experience it through blocks, patterns, fields and templates. If those pieces are not mapped properly, the design system becomes harder to use than it looked during planning.
The Build Reveals The Missing Rules
Development often reveals decisions the design file did not need to answer. What happens when a heading wraps to three lines? Can this section appear without a button? Is the image decorative or meaningful? Does the pattern still work when there are five items instead of three? How does this behave when translated or edited by someone who has not seen the original design?
These questions can feel like implementation details, but they are really design system details. A system that cannot answer them will produce inconsistent work later. Developers will make local decisions to finish the build, and those decisions may not match the original design intention.
That is why I prefer design and development to overlap earlier. It is much easier to decide the rule while the component is being shaped than to patch inconsistencies after several templates have already been built.
Tokens Are Useful, But Behaviour Matters Too
Design tokens are useful for colours, spacing, typography and other repeated values. They help keep the visual layer consistent and make future changes safer. But tokens do not explain how a component should behave. They do not decide when content should wrap, when a layout should change or which parts an editor should control.
That behavioural layer is where many systems struggle. A button token might define the colour and radius, but the CMS still needs to know where buttons are allowed, what styles editors can choose and how those choices affect the page. A spacing scale might exist, but the templates still need sensible rules around when sections can be tightened or expanded.
The most useful systems connect those two sides. Values are consistent, but the behaviour is also understandable. Developers know how to build the component, and editors know how to use it without accidentally creating a new design language on every page.
Testing The System With Real Content
I do not trust a design system until it has been tested with real content. Placeholder text hides too much. Real titles are longer. Real images have awkward crops. Real case studies do not all fit the same neat pattern. Real editors make choices that the design file did not predict.
This is where the system either becomes stronger or starts producing exceptions. If a component fails with ordinary content, the answer is not always to blame the content. The component may need a clearer rule, a more flexible structure or a tighter editorial constraint.
That feedback is valuable because it stops the system from becoming theoretical. The goal is not to protect the design file. The goal is to create a website that can keep producing good pages after launch.
Retrospective Thoughts
A design system should reduce repeated decisions. It should not create a second project that only designers understand. For a website, the system needs to be visible in the code, the CMS, the editor experience and the way future pages are assembled.
That is why I care less about whether a design system looks complete at the start and more about whether it behaves well during the build. The build is where assumptions become rules. If the rules are missing, development will invent them.
The best systems I have worked with are not the ones with the most components. They are the ones where design decisions, development decisions and content decisions support each other well enough that the site can keep growing without slowly losing its shape.