Building confidence into HMRC's first Security Console.

As HMRC digital services evolved, customers were being given access to increasingly sensitive information through their Government Gateway accounts.

Cybercrime presented a significant threat. Customers needed a clearer way to understand who had accessed or changed their account, recognise suspicious activity and report potential fraud through the correct support route.

The Security Console was intended to become a central hub for this activity, improving transparency for customers while helping HMRC respond more quickly and effectively.

When I joined, however, the service was already moving towards delivery without a complete view of the end-to-end journey. Design work was not being shared consistently, several patterns had been created outside established guidance and confidence across the team was uneven.

The challenge was not only to improve the service.

It was to create the conditions for the team to deliver it with confidence.

I initially joined to take over from the outgoing interaction designer and complete several outstanding pieces of work.

After reviewing the service, it became clear that the programme needed more than design production. It needed stronger design leadership, clearer communication and a shared understanding of what was being built.

I began meeting with people across the core team, creating space for them to question the work and understand the reasoning behind design decisions.

I also encouraged designers to present their work more regularly, both within the delivery team and to the wider design community. This created a healthier feedback loop and helped design become a shared team activity rather than something happening in isolation.

The work included:

• Reviewing the complete service from entry point to confirmation.
• Supporting designers to take greater ownership of their work.
• Creating regular opportunities for critique and feedback.
• Building stronger relationships between design, delivery and engineering.
• Giving stakeholders greater visibility of the programme's direction.

A full review of the journey exposed inconsistencies, gaps between screens and several invented interaction patterns that could create accessibility and behavioural problems.

I facilitated a prototype and design critique with the wider team, giving developers space to raise concerns about implementation and allowing us to examine the journey together rather than screen by screen.

Where bespoke patterns had been introduced, I demonstrated how established GOV.UK and HMRC design-system patterns could solve the same problems with less risk.

This was not about enforcing consistency for its own sake. Using tried and tested patterns reduced uncertainty for users, lowered implementation effort and gave the team greater confidence that the service would behave accessibly.

The work included:

• Reviewing accessibility and interaction patterns across the service.
• Replacing untested bespoke components with established patterns.
• Resolving inconsistencies across the end-to-end journey.
• Using prototypes to test feasibility with developers.
• Clarifying the distinction between the MVP and future service ideas.

As the programme approached launch, one of the biggest risks was that different people held different views of what the MVP included.

I created a separate, clearly defined prototype showing the version intended for launch. This gave stakeholders, designers and developers a single reference point and removed ambiguity from sign-off conversations.

I also introduced a delivery plan showing what needed to happen next, how future design work would be prioritised and where engineering needed to be involved.

By making the work visible and structuring the decisions around it, the programme moved from fragmented conversations towards a shared plan.