Every organisation planning for 2027 arrives with ideas about what needs to change about their platform and website – a new design, better integration capabilities, or the adoption of new technologies and innovations. The instinct behind each of these is sound – digital infrastructure should keep pace with the organisation behind it.
So how do you tell which of these are genuinely needed, and which just sound like they are, before any of them go into a brief?
What really belongs on the digital wishlist
A new website design is a want until it's attached to something specific – a brand that's moved on from what the current site still says about the organisation, or a user journey that loses people before they reach what they came for.
Better integration capabilities are a want until they’re tied to an actual cost – hours spent re-entering the same information across systems that should already talk to each other, or decisions made slower because the data to answer them sits in three different places.
Adopting new technologies and innovations is a want until it's clear what it's actually for – a capability that changes what a team can do day to day, or a major efficiency though streamlined, automated processes.
For organisations that already have defined targets attached to a project, the more useful question is whether what's on the brief is the lever for that number, or simply assumed to be. A new feature bolted onto the existing site might fix the immediate complaint. It might also be another workaround sitting on top of a platform that's creating the problem in the first place. Knowing which is which before the brief is written is what turns a wishlist into a plan.
Pressure-test the wishlist before it becomes a brief
Every wishlist is written from inside the organisation. It reflects the lessons of the last project and the priorities of the people closest to it, which is exactly why it benefits from being tested by people a step further away.
The most useful challenge often comes from two groups.
The first is the people who'll live with the result day to day, such as the teams publishing content or handling enquiries. The second is the people who'll approve the investment. Day-to-day users know where the current platform slows them down. Those approving it see the bigger picture: where the organisation is heading, and what the platform will need to support as it grows over the next few years. Bringing both perspectives in early sharpens the list quickly.
An outside view adds another layer.
Specialists who've seen similar requests play out in other organisations can spot patterns that are hard to see from within, particularly around what a platform will need to support further down the line.
Timing matters too.
Challenging a wishlist while it's still a working document costs a conversation. Once it's out to tender, every change costs time and momentum. By the time a project is under way, a change of direction prompted by an untested assumption costs budget as well. The strongest briefs tend to come from organisations that invited that challenge early, while every option was still open.
Design for the organisation you're becoming
Every brief describes an organisation at a single moment: the services it offers, the audiences it serves and the systems it runs today. The platform built from that brief will need to serve the organisation for years afterwards, through changes that can be hard to predict when the brief is written. The space between those two points is where some of the most valuable planning happens.
Ask how it will need to grow
Alongside what the platform needs to do at launch, it's worth asking what it will need to take on later: the services already on the horizon, and the audiences the organisation wants to reach in two or three years' time. Then there’s the development that follows launch, from the innovation projects the organisation will want to explore to the new tools it will want to test once the foundations are in place. A platform designed with those in mind can extend to meet each one as it arrives, and each addition builds on what's already there.
In this section do we need something about new development and innovation projects it will need to support in future?
Expect the requirements to move
Requirements change from the outside too. The accessibility standard many UK organisations are measured against has been updated within the last couple of years, and further changes like it are a normal part of a platform's life. The same goes for how people find information, as AI-driven search changes the way content is discovered. A well-structured platform can absorb those changes as they come.
The most useful addition to a 2027 brief might be a short description of how the organisation expects to have changed by 2029, and what the platform will need to support when it does.
From wishlist to plan
On a wishlist, every item carries roughly equal weight. A plan puts them in order, showing which will make the biggest difference and which depend on others being in place first. A new design, an integration project and an AI pilot might sit side by side on a wishlist. In a plan, the integration work might come first, because the AI pilot depends on the data it brings together. Some items may move into a later phase, which keeps the first phase focused and gives later work a stronger platform to build on.
To start sorting your own list, work through the questions below for each item, ideally with both the day-to-day users and the people approving the investment in the room.
The wishlist test
- How will it be measured?
Name the metric, its current baseline and where the data will come from. If there's no reliable baseline yet, setting one up becomes the first item in the plan.
- What is it worth?
Put a rough value on the outcome, whether that's income it could generate or cost it could remove. Even an estimate makes items easier to compare and prioritise.
- Who owns the result?
Give each item a named owner who is accountable for its outcome after launch as well as during delivery.
- What has to be in place for it to work?
List the data, systems and content it relies on. This shows where the item sits in the order, and what needs to come first.
- What does success look like a year after launch?
Describe it in concrete terms. If the picture includes things the platform will need to grow into, those become part of the brief from day one.
Working through these gives you a clearer view of what to prioritise, and a sound basis for shaping a robust roadmap for the year ahead.
How we can support you
If you're shaping plans for the year ahead, find out more about how we can support you below.
