Does research and design-system work include development?

Only when development is explicitly in scope. We can carry the work into engineering or hand it to your team, with documented navigation decisions, component states, CMS mappings and acceptance checks. Migration and ongoing operation are separately agreed.

Do we need research if we already know our users?

Often internal knowledge is right about who the users are but wrong about how they look for things. A short round of card sorting and tree testing is inexpensive compared with rebuilding a navigation after launch.

How long does the research and IA phase take?

It depends on the number of sites, languages and stakeholders. Scope and timeline are agreed after a short discovery rather than quoted as a fixed number up front.

Can you build a design system on top of our existing site?

Yes. We can audit existing components, consolidate duplicates and document a system that the current site adopts gradually, without a full rebuild.

Will the design system work with our CMS?

That is the intention. Components are mapped to CMS content types so editors assemble pages from approved blocks. The mapping is defined together with whichever CMS you keep or choose.

Is accessibility part of this work?

Yes. Structure, components and flows are designed and reviewed against WCAG 2.2 AA. We do not issue formal certification; independent audits can be arranged separately.

UX research & design systems

Enterprise UX Research, Information Architecture and Design Systems

Most enterprise website problems that look like design problems are structure problems: people cannot find what they came for, every department wants its own menu item, and each new page is built slightly differently. Research, information architecture and a design system are how that is fixed before it is rebuilt — not after.

Short answer

MadeByCat plans the research, information architecture and design system of an enterprise website as one piece of work. Stakeholder and user research, a content inventory, card sorting and tree testing decide the structure; user flows and usability tests check it; a documented design system and component library carry it into build. The aim is practical: fewer wrong navigation decisions, findable content, less rework and a consistent brand across teams and sites.

From research decisions to a working enterprise website

Yes—research, information architecture and the design system can continue into development with MadeByCat, or be handed to your own engineering team. Decide that boundary early. The handover should connect each important finding to a navigation decision, user flow, component state and CMS content type, so the build does not silently replace tested decisions.

Approve the audience questions and research plan before choosing methods; not every project needs every research technique.
Review navigation and prototype findings with content owners, then record the accepted decisions and unresolved risks.
Validate representative coded templates against the agreed components, keyboard behaviour, content model and critical journeys.
Contract development, CMS integration, migration and ongoing operation explicitly; they are not automatically included in a research-only scope.

Strategy, UX/UI and engineering with one accountable team

Who this is for

This work fits organisations whose website has grown by addition rather than design, and who are about to redesign, consolidate or extend it.

Corporate, holding and financial institutions with many departments publishing to one site.
Groups running several brands or country sites that need a shared structure and component set.
Teams whose content is hard to find in search analytics, support requests or internal feedback.
Organisations whose front-end has drifted into many one-off templates that are expensive to maintain.

Each method, and the risk it prevents

We do not run research as a ritual. Each method is chosen because it removes a specific, costly risk from the project.

User and stakeholder research — prevents a structure designed around the org chart instead of the questions people actually bring.
Content inventory and audit — prevents migrating outdated, duplicated or ownerless content into the new site, and makes the editorial load visible early.
Card sorting — prevents navigation labels that make sense internally but not to customers, investors or candidates.
Tree testing — prevents launching a menu where key tasks cannot be found; the structure is tested before any visual design exists.
Information architecture — prevents page sprawl and conflicting paths to the same content by defining sections, page types and ownership.
User flows — prevents dead ends in forms, applications and contact journeys by mapping the complete route, including error and exit states.
Usability testing — prevents expensive late rework by finding comprehension and task problems on prototypes rather than in production.
Accessibility review — prevents excluding users and later remediation cost by designing against WCAG 2.2 AA from the first wireframe.

Design system and component library

A design system turns decisions into reusable parts: tokens for colour, type and spacing, documented components with their states, and rules for when each one is used. For an enterprise site it is less about visual polish and more about control — every new page is assembled from agreed parts instead of being designed from zero.

The component library is built together with front-end and back-end engineers so design and code describe the same thing. Components are mapped to CMS content types, so editors choose from approved building blocks and brand consistency does not depend on individual discipline.

Multi-brand and multi-site governance

Where several brands or sites share a platform, the design system defines what is shared and what may vary: a common structure and component core, with brand-level tokens and a controlled set of local variations. This prevents both extremes — every site diverging, or every brand forced into the same look.

Typical outputs

Deliverables are agreed per project; a typical engagement produces:

Research summary with stakeholder and user findings, prioritised by impact.
Content inventory with ownership, keep / merge / remove decisions and migration notes.
Card sorting and tree testing results with the revised structure.
Sitemap, page-type definitions and navigation model.
Key user flows and annotated wireframes.
Usability test findings and the changes made in response.
Design tokens, component library and usage documentation, aligned with the CMS content model.

Working model

Research and architecture run first, in short cycles reviewed with your stakeholders. Visual design starts once the structure has been tested. Engineers join early so the component library is buildable, and content owners are involved from the inventory onwards because they carry the editorial load after launch. The work follows the Madebycat Loop: align, discover, architect, design, engineer, operate and evolve.

Scope and what is not included

Included: research planning and moderation, content inventory, IA, flows, prototypes, usability testing, accessibility review, design system and component library, and handover to the build team — ours or yours.

Not included unless agreed separately: large-scale quantitative market research, recruitment of specialist panels at scale, formal accessibility certification, and content writing for every page. We do not promise conversion or ranking results from research alone.

“We do not want to start with visual design”

That is the right instinct for an enterprise website. We start by understanding the organisation, its users and the current site, and only then design screens. Visual design comes after the structure has been agreed.

Stakeholder interviews — goals, constraints and owners across departments.
User research — interviews or sessions with the audiences the site serves.
Analytics and current-state review — what is used, what is searched for and where journeys break.
Information architecture — navigation and content structure tested against real tasks.
User journeys — the key paths written down and agreed before layout.
Wireframes and prototypes — structure and interaction checked before visual polish.
Usability testing — prototypes or builds tried with representative users, where in scope.
Design system and development handoff — documented components that engineers build from directly.

ABCOO — research and information architecture before the bilingual design

Related case evidence

These published case studies show the kind of structural and experience work described here. Each case page states our role and scope.

Frequently asked questions

Does research and design-system work include development?: Only when development is explicitly in scope. We can carry the work into engineering or hand it to your team, with documented navigation decisions, component states, CMS mappings and acceptance checks. Migration and ongoing operation are separately agreed.
Do we need research if we already know our users?: Often internal knowledge is right about who the users are but wrong about how they look for things. A short round of card sorting and tree testing is inexpensive compared with rebuilding a navigation after launch.
How long does the research and IA phase take?: It depends on the number of sites, languages and stakeholders. Scope and timeline are agreed after a short discovery rather than quoted as a fixed number up front.
Can you build a design system on top of our existing site?: Yes. We can audit existing components, consolidate duplicates and document a system that the current site adopts gradually, without a full rebuild.
Will the design system work with our CMS?: That is the intention. Components are mapped to CMS content types so editors assemble pages from approved blocks. The mapping is defined together with whichever CMS you keep or choose.
Is accessibility part of this work?: Yes. Structure, components and flows are designed and reviewed against WCAG 2.2 AA. We do not issue formal certification; independent audits can be arranged separately.

Test the structure before you build it

Share your current site, the teams that publish to it and what is changing. We will outline which research steps are worth running and what the design system should cover.