My design process
Hello :)
This article will be me discussing my design process with real life examples from my past projects.
Empathise: Understanding User Context
To understand the reality of my designs, I spent time observing pharmacists and technicians during peak operating hours at hospital pharmacies. I conducted contextual research, informally speaking with staff while shadowing their daily routines. My goal was to understand their existing workflows, not just the tools they used, but the real constraints, workarounds, and communication breakdowns occurring often.
What stood out immediately was how fragmented and manual many of their processes were. Staff were juggling paper records, supplier systems, and internal messaging tools while trying to manage high volumes of prescriptions, often with little time for training or system switching. Inventory tracking relied heavily on memory and handwritten notes, leading to errors and delays. Communication between staff was often verbal and undocumented, creating gaps during shift handovers.
What I learned:
Designing for this environment meant assuming limited time, minimal training, and low tolerance for unnecessary complexity. The solution needed to be fast, intuitive, and flexible enough to support real-world workflows, not force them to change how they worked. This research became the foundation for every design decision that followed.
Define: Mapping the system
Mapping the broader system helped me understand the relationships between different user groups, data flows, and internal teams.
While working on the Monitor Your Attendance service for the Department for Education, I used Miro to create a detailed system map showing how school staff, local authority officers, DfE analysts, and support teams interacted with the platform. The map included key user goals, touchpoints, dependencies (such as Power BI dashboards and onboarding forms), and pain points across the journey.
This revealed major issues in the onboarding process, for example, schools were being asked for data before they understood the value of the tool, and analysts had limited visibility into user behaviour due to data silos. It also highlighted the need for differentiated flows: what a local authority needed from the tool was different from what an individual school needed.
What I learned:
Mapping the ecosystem clarified conflicting user goals and surfaced misaligned touchpoints across the onboarding and reporting journey. It influenced how I structured the onboarding flow, leading to simpler, more segmented entry points tailored to each user type.
Ideate: Sketching early solutions
Once I had mapped out the ecosystem and gathered research insights, I began exploring possible solutions to the key problems users were facing, primarily friction in onboarding, lack of clarity in reporting, and role-based confusion.
I sketched out low-fidelity wireframes in Figma and on paper to explore different approaches for onboarding journeys, dashboard layouts, and navigation patterns. Some of these included split user flows for local authorities vs schools, redesigned data table layouts to make attendance insights more digestible, and more prominent CTAs for key tasks like uploading pupil data.
I facilitated short idea validation sessions with stakeholders, including policy leads and analysts, where I walked through early concepts using FigJam to annotate user flows and decision points. Their feedback helped me narrow down which flows were most viable for MVP and which features could be deprioritised.
What I learned:
By co-creating with stakeholders early, I was able to align business goals with real user needs. This helped me avoid overbuilding and focus on the flows that mattered most to onboarding and daily usage.
Prototype: Rapid Iternation in Figma
After mapping out key pharmacy workflows and identifying user pain points, I created low- and high-fidelity prototypes in Figma to visualise a streamlined digital portal. These prototypes focused on simplifying three main user tasks: managing prescription orders, tracking stock levels, and flagging inventory issues.
Given that many pharmacy staff had limited experience with digital systems, I focused on designing a clean, step-by-step interface with large touch targets, labels, and accessible colour contrast. I prototyped key journeys such as placing a new order, checking stock levels, and messaging internal staff through the portal.
I conducted moderated testing sessions with pharmacists and pharmacy technicians using these prototypes. Feedback revealed issues such as unclear button hierarchy, missing feedback on task completion, and unnecessary steps in the ordering flow. I iterated based on this input, reducing clicks, clarifying actions, and refining the dashboard layout to better support real-world pharmacy routines.
What I learned:
Prototyping early and often helped uncover usability issues that weren’t obvious on paper. Testing with real users meant I could iterate rapidly and design a portal that felt intuitive even to non-technical staff working under pressure.
Test: Validate & Refine
Once the interactive prototype was ready, I ran moderated usability testing sessions with pharmacists and pharmacy technicians in live or simulated pharmacy settings. These sessions focused on core workflows like creating a new prescription order, checking stock availability, and navigating between modules in the portal.
Participants were asked to complete realistic tasks while thinking aloud, so I could observe friction points and capture qualitative feedback. I also tracked time-on-task and completion success for core journeys. For example, multiple users struggled with locating the “submit order” action due to poor button placement and unclear feedback states. I addressed this by adjusting layout spacing and adding clearer confirmation patterns.
Across several iterations, I reduced the number of clicks required to place an order by 40% and clarified interface labels based on user language. Testing insights also led to changes in colour usage for status indicators to support accessibility needs such as colour blindness.
What I learned:
Testing directly with pharmacy staff revealed design issues I would not have seen otherwise. Their feedback helped ensure the final product matched real-world expectations, not just from a usability standpoint, but also in terms of pace and clarity.
Reflection
My past projects taught me the value of designing for users who often get overlooked in digital transformation, people who are under constant time pressure, working in high-stakes environments, and who don’t necessarily consider themselves “tech-savvy.”
Working closely with pharmacists and technicians reminded me that good design isn’t about making things look modern, it’s about making things feel effortless and trustworthy for the people who depend on them every day. From simplifying orders to clarifying feedback, every small decision added up to something meaningful.
It also reinforced how powerful quick, collaborative iteration can be, especially when paired with real-world testing and feedback. It made me have a deeper appreciation for accessibility, clarity, and the need to meet users where they are, not where we assume they’ll be.