UK Government department, Microsoft Power Apps, 2026

Developing a UK Gov service front door

The service had grown complex, with lots of internal stakeholders all vying for changes. Requests arrived as Teams messages and emails, requesters spent time working out what had happened to them, and feature sizing meetings took three hours with little progress. My role was to do more than map the service and co-design it. I also built a working front-end application by vibe coding with AI, to help deeply embed the process and change needed.

Client: UK Government department, an internal data service
My role: Service Designer, Power-app developer
Built with: Microsoft Forms, Power Automate, Power Apps, SharePoint, Azure DevOps
Status: In use by the whole product team on a government service
Duration: 3 days to prototype, 2 weeks to build, 4 weeks to alpha and beta test
Outputs: Discovery phases, request workflow, stakeholder form, operating guide, clickable prototype, working app

All requests: a seven-step tracker from To triage to To evaluate, filters by status, and a list of requests each with its type and current status — Seven steps across the top, and every request in one of them.Data shown is illustrative.

Results

The results

What the work produced.

A custom-built application Built on the Microsoft enterprise software the department already had.
The whole team uses it Business analysts add their project initiation details, and the team comments on and tracks every request.
Easier for everyone, and one team aligned People spend less time hunting for documents, and the product owner says it has helped her massively.
Sizing has its own monthly session Before, sizing meetings ran for three hours and made little progress.
One way in for stakeholders I worked with the stakeholder community to use the form rather than going straight to the team.
Every no comes with a reason Sign-off records why, and the reason goes back to the requester.

From a spreadsheet to an agreed process

Requests lived in one huge spreadsheet, and sizing meetings took three hours with little progress.

I interviewed the people who asked for changes and the team who made them, prototyped a workflow as a clickable app, shared it round and iterated. Nobody pushed back: the work was getting the group to agree, and to build new habits. The result became an operating guide: stages, roles and governance in one place.

The operating guide on the team's SharePoint site, titled New Request Process, with buttons for the request form, the app and a technical guide, and contents starting with purpose, current challenges and objectives — The guide, with the form, the app and the technical guide one click away.Data shown is illustrative.

One front door, seven stages

I mapped the whole service before building any of it, from the conversations where requests start to checking that what shipped did its job.

Small tactical fixes take a fast lane. Everything else is triaged, sized by the team, prioritised and signed off. The aim: better prioritise the right features to create the most impact, and give more accurate timelines.

Service diagram of the end-to-end process in seven stages: capturing new work requests, define and triage, size, prioritise, awaiting sign off, in development, and release and evaluate, with the status a request holds at each stage and a fast lane for small tactical changes — Seven stages, the status at each, and a fast lane for small fixes.

One way in, built around the user need

Requests came from anyone: the team itself, other teams across government who needed the service to do something, policy colleagues and the product owner. They sent a Teams message or an email, then spent a long time working out what had happened to it.

I designed one form and worked with the stakeholders to use it. It asks what problem users have, who it affects and what task the change supports, before asking how to solve it.

The new work request form: what is the challenge, defect or opportunity, who will be impacted, and what tasks will this change support the users to do — The problem and the task come before the proposed fix.Data shown is illustrative.

A quick value call before anything is sized

Every request sits in exactly one of the seven stages, visible to everyone.

Triage comes first: must size, maybe, or hold, with the right teams assigned. Requests worth sizing go to a monthly session where we review the priorities together and each team sizes its own share. That session is what made the new habits stick.

The In triage step: a seven-step tracker across the top, and requests sorted into Must size, Maybe and Hold columns — A quick value call, before anyone sizes anything.Data shown is illustrative.

A no that comes with its reason

Several groups compete for the same capacity, and the choice used to live in one inbox.

Sized requests are ranked on a Now, Next and Later roadmap. At sign-off each is approved, deferred or rejected with a reason, and the reason goes back to the requester.

The Sign off step: a request awaiting a decision, with the case for doing it on the left and cost and commitment on the right — Demand against capacity, on the page where the decision is made.Data shown is illustrative.

Released is not finished

Once a feature shipped, nobody went back to check whether it had done what it was meant to. Delivery was where the work stopped.

I built the review into the process itself. Each request now agrees a success measure before it is built, and after release someone records whether it worked and what surprised them. Anything new becomes a new request, so the team keeps learning from what it ships.

The To evaluate step: a released request with its agreed success measure, asking did it achieve the intended outcome, with options from too early to tell to not achieved, and evaluation notes — Did it achieve the intended outcome? Asked of every release.Data shown is illustrative.

Reflection

What I did not expect

I expected building it to be the hard part. It was the quickest part: about two weeks for a Power App that had been estimated at six months. So the real work moved to the people: agreeing the service with the teams who would run it, and changing it as they used it.

Once it was live, people wanted one for their own area, and the question I was asked everywhere was not what it does but how I built it with AI inside the Microsoft tools the department already had.

Happy to walk through the build, the decisions or what I would do differently in more detail. Or see how I help teams with AI transformation.

Book a 30-min chat