Content as strategy for the PRS Database
The Private Rented Sector (PRS) Database is a new national register. When I joined the project, the policy behind it was still being written, and the team didn’t have a clear view of what the service actually needed to do for landlords, tenants or councils.
I was brought in as Lead Content Designer to help bring shape to something that didn’t quite exist yet – and to turn policy thinking into something we could design, test, and build.
The challenge
The policy changes, unclear definitions and conflicting interpretations meant:
no shared understanding of the service
no agreed user journey
design and development blocked
high risk of building the wrong thing
We needed to define the service in plain English, from a user’s point of view, before any UI or development work would make sense.
As the Lead Content Designer, I was responsible for:
shaping the end-to-end user journey
turning policy into workable steps and decisions
drafting content-first screens to expose gaps
creating a prototype for early testing
establishing a process for managing ongoing policy change
This was content used as early product design: defining logic, flow and structure.
What I did
I worked directly with policy and legal colleagues, writing the service content together. This forced concrete decisions and quickly exposed anything unclear, missing or contradictory.
By starting with what users actually needed to do (rather than the legal text alone), I created a stable content blueprint that helped the team agree the MVP and avoid scope creep.
I introduced a simple, repeatable process for managing policy updates so the service could evolve without constantly disrupting design or development.
I persuaded senior stakeholders to let us test our riskiest assumptions with real users, giving policy clearer evidence to shape how the service should work.
The impact
The team gained a clear, user-led view of how the service should work, replacing weeks of uncertainty.
We had a defined journey, structured screen logic and a prototype we could test early.
Policy teams had clearer evidence to make decisions, rather than relying on assumptions.
Design and development were finally able to move forward with confidence, instead of reworking unclear requirements.
The content change workflow meant future policy updates could be absorbed without derailing progress.
