Corporate presence
Demiurgic
A corporate site carrying a wide service catalogue that still had to read as one business.
- Type
- Corporate presence
- Scope
- Design system and site build
- Constraint
- A catalogue expected to keep growing
- Engagement
- Fixed scope
The brief
Several service lines needed to sit on one site, each legible alone, without the company reading as an unsorted list of capabilities.
Our approach
A component library first — type scale, spacing, card and section patterns — so each new service reuses existing structure instead of inventing a layout, with its own route into contact.
Decisions
The choices that shaped the result
A case study is only useful if it says why. Each of these was a live argument at the time, with a reasonable alternative on the other side.
Build the component library before the pages
With a catalogue that was going to keep growing, designing pages individually would have guaranteed drift — the eighth service page would resemble the first only loosely. Establishing the type scale, spacing and section patterns first meant every subsequent page was assembled from existing parts, which is also what keeps the site looking like one company.
Give every service its own route into contact
A single generic contact form for a wide catalogue produces enquiries that have to be triaged before they can be answered. Each service line got its own path through to contact, carrying the context of what the reader was looking at, so the first reply can be useful rather than exploratory.
Make copy editable without a developer
On a site whose whole premise is a growing catalogue, requiring a deploy for a wording change would have made the structure a liability. Content was separated from layout so the team can revise service descriptions themselves, which is the difference between a site that stays current and one that is accurate on launch day.
Resist a bespoke layout per service
There was a reasonable-sounding request for distinct treatments per service line. We argued against it: visual distinctiveness per service reads as several small companies rather than one capable one, and it makes every future addition a design project. Consistency did more for how the catalogue reads than variation would have.
What they were left with
The catalogue grows without a rebuild: new services drop into existing components, and copy changes do not require a developer.
What we would do differently
We under-specified the empty and overflow states in the first pass of the component library — long service names and short descriptions both needed handling that was added later rather than designed in. It is now the first thing we check on a component set.
Visit DemiurgicAnother engagement
Have a brief of your own?
Send us the problem rather than a feature list. Both engagements above started that way.