An application to facilitate the exchange of information on request (EOIR) that takes place when the tax authority of a requesting jurisdiction asks for particular information from the competent authority of a partner jurisdiction.

Once I had the background research I broke the scenario into a simple set of stages.

To better understand the complete landscape with regard to how we might design a digital experience for users we mapped the 'As Is' and the 'How Might We'. This involved me working with the UX researcher and the Product Owner to consider all possibilities.

Mapping the landscape helped us to understand not only how each piece of the application fits together, but also how each function would relate to all the other functions within the application structure. This allowed for setting out the objectives of each screen and the role the screen would play for the user. For me the process mapping and streamlining the work processes helps plan projects and allow the team to visually communicate the important details rather than writing extensive directions.

The next stage involved planning the project. Having established the functions that were key to the application module. We could create the requirements and define the desired outcomes.

User journeys, identifying personas, identifying the goals of the user, all here helped the team understand user behaviour and anticipate how users will interact with a new application. By understanding this we were opening up the opportunities to design a service that anticipates the users needs and provides them with an effective tool.

I want to have and conduct research and data gathering. I want to generate something quick show stakeholders and review with domain experts/users (or proxy users) for feedback. Then build in Figma, review and then handoff for development...and refine post release based on feedback/success.

Once we had a project plan and had established what the key functions and important features were that we had to design, I worked in low-fidelity creating the main user flows and interactions.

I organised a workshop presentation of our proposed EOIR solution and stepped through the wireframes with clients. I had five clients agree to get involved in a Beta review. The reviews allowed us to iterate and refine the proposed flows before we pushed forward.

The initial low fidelity screens, the wireframes, I created using a combination of 'scafolding' from Loveable and manual refinement using Basalmiq..

It also allowed me to test with users and understand how users would interact with the proposed application. The context for them, the pain points that they have.

In this phase I concentrated on building screens and interactions, building from the company component library. The page structure, the master layout, components; controls, buttons, a complete design language.

The components I had created in Figma as part of our component library and combined with our custom design system.
‍

Based on the reviews and feedback from stakeholders, our own domain experts and users, the designs evolved into an application environment consistent with user expectation.

The development team were heavily involved at this stage as I customised the design system, in tandem we began to build out an Angular component library.

Given the extent of the application functionality before pushing to full production I created a prototype to engage clients and validate the user flows and proposed solution.
‍

The MVP version of the product was launched in January 2026. As of summer 2026 there are nine tax authorities using the application with over four hundred licences. We will continue to refine the product and develop additional features based on feedback.

In July of 2026 I began work on a new refined design system for the entire Regnology suite of products to incorporate this application as a single module within the Regnology suite of regulatory products.
‍

From a design feedback perspective I work backward from decisions. I agree what ‘working’ means before I instrument our analytics...definitions are important...targets are important, what are we trying to achieve, what does ‘success’ mean, what is our target for success.
‍

I capture the data from the analytics on a Confluence page as "What we're listening for" per feature under “Feedback” and keep analytics tied to design intent. Every screen or flow gets a success metric defined at design time (task completion rate, time-to-completion, error rate, drop-off point, support ticket volume rtc.).
‍

After working through the design phases, post release based on feedback I loop back in again. Where in the process depends on the issue/the severity of what has been identified/the priority/budget/etc.
‍