Scattered research: the evidence exists, finding it is the hard part
If your organisation holds knowledge other people need, the problem is rarely a shortage of material. In this centre's field the research is extensive, but it sits in departmental reports, evaluations, literature reviews and journal articles, spread across dozens of places.
A practitioner deciding what to try next rarely has an afternoon to go looking, and an employer trying to do the right thing for the first time often does not know the research exists at all.
Then there are the people the sector exists to serve, and their families, working out what good support should look like.
The centre set out to serve all 3 groups from one place: practical guidance on one side, the evidence underneath it on the other.
Our part in the work: technical leadership and Drupal delivery
A partner agency engaged us as their engineering partner on the build, while the relationship with the centre and the shape of the programme sat with them.
We provided technical leadership, architecture, platform engineering and ongoing maintenance. We also set the delivery process the build ran on:
- automated code quality checks
- automated tests over the journeys that matter
- a release cadence the team could plan around
An evidence base that stays where it is curated: a feed, not a rebuild
The most consequential decision on this project was about where the evidence lives.
The straightforward way to build a research library is to build one: a content type, an editorial workflow, and someone keeping thousands of bibliographic records tidy forever. We took the other route.
The centre's evidence base is curated in an established open-access research archive, by a team that has specialised in exactly that for 2 decades, and the hub consumes it. Records keep their attribution and their permanent links, so the collection stays whole and useful outside the hub as well as inside it.
That meant being a good neighbour to another organisation's system. A nightly sync that asks a partner to serialise its whole catalogue and then discards almost all of it becomes someone else's problem.
We built the feed the other way around, so the hub says what it already holds and asks only for what has changed. The library stays current, and the cost to the source stays flat as the collection grows. For a client, that is the difference between an integration that stays cheap to run and one that becomes a standing cost.
What the audiences got: a filterable evidence base
On the practice side, the hub carries best-practice guides, tools and professional development material, organised around how practitioners approach the work rather than how the material was produced.
On the evidence side, every record is a complete bibliographic entry:
- authorship and publisher
- publication details
- journal and peer-review status
- licence and subject
That depth is what makes the library filterable rather than merely searchable, and faceted search is the part practitioners lean on most.
One property matters more than the rest. Records carry their accessible-format status as a first-class, filterable field rather than as a tag, because a real share of this audience depends on those formats to read at all. Someone can ask the library for material they can actually read.
Built on an open-source design system, accessibility checked on every build
The hub runs on an open-source, accessible, component-based design system whose engineering we had led before this project began. Custom component work went only where this product genuinely differs from any other site: the filters that drive the resource library. Everything else came from the design system as it ships, which is the whole economic argument for using one.
Accessibility is checked continuously rather than at the end. On every build, an automated test reads the site's own sitemap, visits each landing page and records what it finds.
Because it discovers pages instead of working from a fixed list, a new section is covered the day it goes live, not the day someone remembers to add it to a test.
Both dates held: the first release on its promised day, the full hub early
The first release, for practitioners, went live on the date promised at the start. The full hub, serving every audience, arrived ahead of its date at the end of 2025.
2 delivery dates named at the start. Both held, and the second landed early.
Saying it plainly is the point: described, then built, then shipped, on the days that were named. For a client, a date that holds is the difference between planning a launch and hoping for one.
It has been live and in use ever since, and we are still the team on it:
- a steady release cadence
- design system upgrades
- search improvements
- accessibility fixes as they surface
For organisations whose evidence has to reach the people who use it
Everything on this page is 4 of our services running on one live knowledge platform: architecture that decided where the evidence should live, a migration that keeps it current without burdening the archive that curates it, accessibility checked automatically on every build, and ongoing support and maintenance since launch.
If you run a research centre, a peak body or a not-for-profit whose knowledge has to reach practitioners, this is the shape the engagement takes: one architectural decision about where the collection lives, a feed that keeps it current, and delivery dates named before the work starts and then met. The same engineering is available with AI-assisted delivery where it suits the work, at the same tested standard.
If your evidence base is scattered across reports, journals and someone else's archive, and you are weighing whether to rebuild it or feed from it, tell us where it sits today.