Betas are hard! They’re complex, messy and unpredictable. Multiple stakeholders, shifting priorities, unclear roles, tricky dependencies and big expectations – often all at once. We’re in the middle of one right now. We haven’t hit our beta assessment yet, but we’re deep into the build. We’re working hard to unpick problems, untangle complexity and keep the service moving forward.
This post won’t dive into the policy or the domain itself. Instead, it’s a reflection on how we’ve kept going when things got bumpy. It’s about working in uncertainty, under pressure, with shifting policy, heavy content and stretched teams. It’s about what we’ve learned and what we’re still learning as we try to move a complex service forward.
5 beta challenges we’ve been facing
We’ve been through discovery and alpha. Now we’re in beta, working toward a pilot in the summer and a private beta release later in the year. There’s still a long way to go, but this felt like a good time to pause, reflect and share 5 challenges we’ve faced and how we’ve tried to solve them.
1. When roles get too wide, bring in support
Large beta teams bring scale, but also complexity. On this project, our user-centred design (UCD) team (interaction, service and content designers, user researcher and business analyst) were being pulled in too many directions.
They weren’t just designing. They were refining tickets, managing backlogs, engaging with policy and devs and trying to hold the whole thing together. It was unsustainable.
Our solution to help this strain was by supporting the introduction of a client-side product manager. This was someone that could own the backlog, shape sprint goals and bring clearer focus to planning and delivery.
This one shift has already helped ease the load and rebalance the team.
2. Find your rhythm by creating space for work that matters
Naturally over time, what started as a few useful meetings turned into a packed calendar – ceremonies, stand ups, working groups and huddles.
Nothing was done ‘wrong’, this kind of thing happens as projects evolve. As the service took shape and the team grew, our ways of working expanded to keep pace. But without noticing, the balance shifted. There were so many sessions that people struggled to find the time for the deep, focused work needed to make real progress.
We stepped back and took stock. A retro helped us understand which meetings added value, and which didn’t. From there we started streamlining. Fewer meetings, more targeted attendee lists, clearer purpose and more room to think.
3. Policy and legislation keep changing, so learn to work with it
On this project the policy is still progressing through Parliament and all of the secondary legislation is yet to be finalised. That means we’ve had to deal with changing requirements, new priorities and some rework.
Rather than let this derail the team, we mapped the service and clearly marked areas where policy is still undefined. To help manage change, we introduced content and design logs to track what’s changed and why. We talked openly about ambiguity and worked to build team resilience around it.
In a beta like this, some uncertainty is the norm, not the exception. We encouraged the team to focus on what’s known and move forward with confidence, while flagging assumptions, documenting decisions, and staying ready to pivot. That mindset has helped us keep moving while also contributing to shaping policy in a user-centred way, even when things are in flux.
4. Heavy content lifting: our approach to a demanding workload
This is a content-heavy service with complex, multi-page guidance that needs to be shown clearly and simply in the user journey. As policy and legislation evolve, content often needs reworking. Some become outdated and new features introduce fresh guidance needs.
Managing that volume with a single content designer has been tough, especially with shifting priorities and ongoing context switching. To help ease the pressure, we mapped what content is left to do, what was blocked and where the biggest risks were.
This helped create clarity around the remaining work, making it easier to plan, prioritise and move forward in a more achievable way. It also gave us better visibility of where we might need to adapt or bring in additional content support to meet the demands of the beta.
5. Early UCD work matters and we’re making it visible
As soon as features start being built, it’s easy for the earlier UCD work (research, mapping and prototyping) to fade into the background. But that groundwork is critical to building the right thing, not just building anything.
We’ve made a conscious effort to recognise and celebrate that work – including in blogs like this one. It’s not just about morale, it’s about making sure every part of the team sees the value of what’s come before and how it connects to what’s happening now.
Good delivery is always a team effort, and it starts long before the first line of code. Keeping that work visible helps everyone stay aligned on the purpose behind what we’re building.
The beta benefits – we’re always learning
Betas are hard, and we’re still building, learning and adjusting.
We haven’t figured everything out, but we’re moving forward, because we’re open about what’s not working, supportive when people are under pressure and pragmatic about what we can fix now versus what needs to come next.
Every beta is different. This is just what we’ve learned from ours so far. Hopefully, it helps others facing similar challenges.
Looking to read more on what our user-centred design team are up to? Take a look at their latest blog posts, covering everything from career journeys to design insights.
The post Beta blockers: 5 challenges and how we navigated them appeared first on Made Tech.
