You already have the tools, you're just not using them

On a recent government project, I saw this play out in several ways at once. One spreadsheet was being used to capture and triage user feedback. Another tracked multiple projects, teams, features and comms releases, effectively a huge Gantt chart with 200 rows. Another kept track of user research participants.

None of those spreadsheets was doing its job very well. What I want to share is how I helped solve each of those problems, not by making a better spreadsheet, but by doing two things. First, designing the process itself, using standard service design methods: mapping how the work actually flows, and getting consensus and buy in from the people involved. Then going beyond what a service designer would normally do, and building a custom application to support the process that had been broken.

The clearest example was feature estimation. The team needed to capture new feature requests, evaluate them, and gather everyone’s view so they could estimate how long each one would take. They used a spreadsheet, of course. That’s what anyone would do. Rows for features, a reference column, and then column after column for each person’s input. Everyone was meant to fill it in before the meeting. Often they didn’t, or they did it in different ways. The meeting then became a three hour session of working through colour coded responses, trying to work out what people meant.

What struck me was that the spreadsheet was straining to be something else. What the team actually needed was an application: screens designed for each step, guidance explaining what to do and why, and a process built into the tool rather than held together by goodwill and calendar reminders.

The difference now is that building that application is no longer a 12 month project.

I started where a service designer normally would, with the process. I ran workshops and spoke to lots of different stakeholders, mapped how they worked today, and then designed a better future process and journey map for how requests could move through the front door. At that point I wasn’t thinking about an app at all.

To support that process, I set up an MS List with custom views representing each phase, so the team could see requests as they moved from one stage to the next. It helped, but it was still a glorified table. Then I realised I could vibe code Power Apps. Each stage in the list could become a stage in an application, and all the thinking in the journey map and the database could be carried straight across.

So I gave the structure of that list to an Office 365 agent I’d configured to produce HTML prototypes, and very quickly I had a clickable prototype of what a proper front door app could look like. I showed it to the team. They liked it, but could I change this, and move that? I changed it, there and then. We went round that loop several times until it was right.

Once the prototype was good enough, I handed the HTML file to another AI agent and asked it to help me build the same thing as a Canvas app, with whatever Power Automate flows it needed to support it.

In about two weeks, the team had a fully working front door application. Multiple screens, different views, and a proper triage process for capturing and assessing requirements. The whole team can log in and use it. It runs on the same MS List they already had, using tools that are already part of their Microsoft licence.

I’d never built anything in Canvas before. When I showed it to people who build Power Apps for a living in government, the reaction was something close to disbelief. Their estimate for building it the traditional way was around 12 months.

Traditionally, the outputs of service design have been consensus, shared understanding and a common language. Post it notes, journey maps, service blueprints. Valuable, but someone else always had to turn them into something people could use.

Now I can see a way to go further, from the map to a working application, without the handover in between.

I should be clear that everything I’m describing here is internal tooling, used by staff, not public facing services. That’s a deliberate line, and a sensible one for now. But I don’t think it will be long before the same approach can be applied to bigger services, in the public sector and in private organisations too.

The front door app replaced a spreadsheet. But the same approach works for tools organisations would normally buy.

Voice of the Customer. There’s an entire industry of vendors selling voice of the customer platforms. I built one that sits inside the department. It pulls in user feedback from lots of different sources and presents it back as thematic analysis. Instead of sifting through hundreds of scattered comments, teams can review feedback in a consistent, standardised format and see what actually matters.

A portfolio tracker. Think monday.com, but built for one programme. Different teams log their features and submit a monthly update covering progress, challenges, milestones and dependencies. All of it feeds a Gantt chart, so teams working in separate silos can finally see how their workstreams depend on each other. The monthly reporting process lives inside the tool, not in a reminder email and a shared spreadsheet.

ReOps. A research operations tool for managing a participant panel shared by multiple teams across the department. It brings together MS Lists, Bookings, Forms and Teams, runs on 11 Power Automate flows, and has a Canvas front end styled on the GOV.UK Design System. Researchers can recruit participants, send invitations from their own accounts and keep track of consent, which matters a great deal when you’re handling personal data.

A commercial equivalent of any of these tools would come with a per seat licence for everyone who uses it. It probably wouldn’t fit the team’s process either, so the team would end up bending to the tool.

There’s a bigger problem too. Government is rightly cautious about third party SaaS products. Data ends up on servers somewhere else, under someone else’s terms, and every new supplier means procurement, security assessments and a data protection review.

When you build inside the organisation’s own Microsoft environment, most of that goes away. The data stays where it already lives. The licences are already paid for. There’s nothing to procure. You’re not bringing in capability from outside. You’re unlocking capability that was sitting there all along, and using AI to make it reachable.

I don’t think this means anyone can or should start building apps tomorrow.

Part of the reason this worked was that I’ve spent years designing services and working alongside developers. I could look at what the AI produced and say no, not like that, like this. I knew what the user journey needed to be, where people would get stuck, and what would make the process feel obvious rather than confusing.

AI is very good at producing something. It’s much less good at judging whether that something is the right experience for the people who will use it. It doesn’t know that a particular screen will confuse a busy colleague, or that a step could be removed altogether.

That’s the gap. If everyone starts building their own apps with no design thinking behind them, we’ll swap messy spreadsheets for messy apps. I think one of the most valuable profiles in this next phase is someone with user centred design experience and enough technical understanding to steer AI towards something genuinely useful.

Right now, building like this takes some know how. I used more than one agent, moved between an HTML prototype and a Canvas app, and had to understand enough about Power Automate to spot when something was wrong.

That won’t last. Microsoft is already putting Copilot into Power Automate and its other tools, and it’s not hard to see where that leads. Before long, you’ll describe the app you want and a single built in agent will make it for you.

When that happens, custom applications will be normal. The question will shift from whether you can build it to whether you should, and what good looks like. That’s where design judgement becomes more important, not less.

Most of the conversation about AI at work is about productivity: doing the same things faster. That’s real, but it misses the bigger point.

None of these tools are about doing the old work more quickly. They let teams do things they couldn’t do before. A programme can see its dependencies across silos for the first time. A department can analyse user feedback without buying a platform. A team can replace a three hour meeting with a process that actually works.

That’s new organisational capability. And most organisations already have the tools to build it. They just aren’t using them yet.