Webdesign

Web Design Trends 2026: Systems Instead of Pages

Q: How do I know if we have more pages or systems?

If new requirements are almost always solved as a 'new page', that's a strong signal. A second sign is that design decisions are constantly discussed anew because there's no shared library. In practice, it also shows in the CMS: If editors have to 'rebuild' a lot of layout instead of placing content, you're working page-centered. A good quick test is our Page Fear Test: Does your team ask about the page or the module first when making a change? That reveals the thinking direction.

Q: Do I need to build a complete design system for a system?

No. A system can start small. It's often wise to begin with the most common modules that truly occur everywhere and secure quality there. It's important that you consider the connection between design, code, and CMS from the start. Otherwise, a 'design system' will only exist in Figma. We usually recommend an iterative build: first stabilize core modules, then expand - with governance so it doesn’t fray.

Q: How much more effort is system thinking compared to a classic relaunch?

The start is often more structured and therefore noticeably more complex, as decisions are made more consciously. However, follow-up costs often decrease because new pages don't create new special cases each time. Without reliable project figures, it would be unprofessional to name a fixed percentage. But what we consistently see: Systems are particularly worthwhile if you regularly publish new content, campaigns, or landing pages. If your website is very static and rarely changes, a smaller system setup may be sufficient.

Q: What roles do we need to prevent a system from deteriorating?

You mainly need clarity, not many people. It helps if a person or a small team takes ownership of the UI system and a contact person exists for the content model. Additionally, a light review routine is advisable: changes are briefly checked for accessibility and performance. If roles are unclear, exceptions develop silently - and the system loses its effect.

Q: How does a building block editor in the CMS fit into a system approach?

Very well, if it remains structured. A building block editor becomes problematic if it offers too many freedoms without guardrails and editors have to make layout decisions that actually belong in the system. A good editor offers modules, limits variants clearly, and makes rules for image formats, spacing, and text lengths visible. We ensure that 'content' and 'layout' do not discreetly stick together again.

Q: What is the most important accessibility gain from systems?

Reusability. When focus styles, keyboard navigation, error messages, and contrast are resolved once correctly, they are correct everywhere. This reduces the risk of individual pages 'slipping through' because they use special solutions. Accessibility also becomes less of an individual check at the end in the team and more a property of your building blocks.

Q: Which tools do you typically use for systematic web design?

In design, we often use Figma for components and documentation. In development, we prefer performant setups like Astro and component-based frameworks like Vue depending on requirements. For CMS setups, we like to use Payload or suitable alternatives depending on project structure. What matters to us: Tool decisions follow your team and your content - not the other way around.