Controlled Drugs Register

In my spare time, I've been working with a friend on a controlled drugs registry for veterinary practices. I'm leading the design of the platform, helping to not rely on paper-based record keeping with a more secure and efficient digital solution.

This project is actively in development, my process/update will be added here.

The Controlled Drugs Register (CDR) is a large-scale, security-critical platform, so my starting point was to analyse and understand the user stories in detail. This allowed me to establish the foundations of the system, map key workflows, and identify opportunities for improvement or areas where further clarification was needed before design work began.

View full size ↗

As the project was being delivered using an agile approach, I worked closely alongside the client throughout. My aim was to stay ahead of the build where possible, enabling me to answer implementation questions, and adapt designs when technical constraints emerged.

One of the first tasks was redesigning the exported PDF reports. Although a relatively small piece of the wider system, the functionality had already been developed, making it an ideal starting point. Using the existing .NET PDF library as a technical reference, I redesigned the layout to improve readability and ensure important information could be reviewed quickly and efficiently by veterinary staff/inspectors.

View full size ↗

Before designing individual screens, I created a complete sitemap of the platform. This helped visualise the structure of the system, identify every screen that required design, and uncover potential user errors, edge cases, and decision points. Collaborating closely with the client at this stage was key in validating the system architecture and ensuring we had a solid foundation before progressing into the UI.

View full size ↗

With the sitemap agreed, I moved on to designing the user journeys and screens.

Login

The login experience was the first area explored. Whilst initially appearing straightforward due to the absence of a sign-up journey, it quickly surfaced several important security considerations. As the system would contain sensitive and personally identifiable information, ensuring a secure authentication process was critical.

Mapping this journey raised a number of questions that needed resolving before moving forward:

• Should users be able to reset their password themselves?
• Should there be a limit on failed login attempts?
• What should happen when that limit is reached?
• How can we communicate restrictions clearly without creating unnecessary friction?

View full size ↗

Once these scenarios had been defined, I translated the wireframes into interactive prototypes. This included designing all key states within the login journey, such as initial entry, enabled and disabled login button states, escalating error messages as users approached their final login attempt, and the ‘locked screen’ experience.

View full size ↗ View full size ↗

Landing Page (Drugs List Page)

Following authentication, users are taken to the Drugs List - the central hub of the system. From here, they can view every controlled drug in the register and carry out key actions such as supplying, receiving, disposing of, editing, or removing records. Given that most user journeys originate from this screen, it was important to establish a clear and scalable foundation before designing the surrounding workflows.

I started with wireframes on paper, using the user stories to map the core structure and identify how the different actions would fit together. At this stage I intentionally focused on the primary experience rather than every edge case. My priority was to establish a strong information architecture before refining the details.

View full size ↗

As this evolved, I worked closely with the client/developer to validate ideas early and ensure they were technically feasible.

These conversations proved invaluable, particularly when I learned that the front end would be built using the LumexUI framework. Understanding this allowed me to work within an established design system while still having the flexibility to introduce bespoke solutions where they added value.

This also influenced several design decisions. I revisited my early concepts, refining them to better align with the framework, while continuing to look for opportunities to simplify the interface. One example came from Miro itself, where I noticed the use of a vertical ellipsis to group secondary actions - as shown in figure 6. This pattern allowed me to consolidate multiple row actions into a compact overflow menu, reducing visual clutter within an already information-heavy table.

View full size ↗ View full size ↗

Updated: 02/07/26