Actions
Planning workshop
Wireframes
User interface design
Figma prototyping
Usability testing
[MY ROLE]
UX/UI Designer in a 2-person design team. We worked in close collaboration across the full process: desk research, stakeholder workshops, persona development, information architecture, wireframing, UI design, Figma prototyping, user interview preparation, conducting interviews, and analysis.
[OVERVIEW]
Client asked us for designing a web tool that helps pharmacies keep track of medical paperwork and spot any changes automatically.
The system needed to work well with the tools pharmacies already use and handle different types of medical documents, helping our client build a strong case for getting project funding
Their task
Time-poor, drowning in information noise, focused on detecting risks and changes in drug markets before competitors do.
Making assessments on unproven data, paying for expensive reports, needing a consumable way to track competitor product changes and understand the motivations behind them.
[RESEARCH]
Understanding the documentation maze
We kicked off with a strategic workshop that brought together pharmacy managers and documentation specialists. Through their stories and experiences, we uncovered not just the technical needs, but the real daily struggles of managing medical documentation – insights that shaped our vision for a solution that would truly make their work easier.
Personas
Product Vision Board
The core challenge wasn't UX — it was the domain. The most complex part of this project was understanding the legal and regulatory framework around drug documentation, and mapping how it connects to the technical possibilities of automatically pulling and analyzing leaflet data. Designing a clear way to present document changes required deep domain immersion before any wireframe could be drawn.
[DESIGN]
Bringing ideas to life
Building on hand-drawn sketches from our design studio exercise, we refined ideas into low-fidelity mockups for client feedback, paving the way for polished high-fidelity designs
Hand-drawn sketches
Lo-fi mockups
Hi-fi mockups
Designing for comparison, not just display. The key design decision was how to present document changes. Simply showing two versions side by side wasn't enough — users needed highlighted differences within specific data sets, intuitive change indicators, and the ability to select which documents to compare. We iterated through sketches and lo-fi mockups to find a format that made regulatory changes scannable rather than overwhelming.
[USER TESTING]
Validating potential and refining features
To assess the product’s potential, we conducted prototype testing through eight user interviews across two key user groups. Using Figma prototypes, we gathered valuable feedback, confirming strong interest and identifying essential features for success.
The evaluation of the tool’s potential played a crucial role in our findings, shaping recommendations for future development. The final report, presented to the client, was well received—positioning the product as a strong candidate for future funding.
The headline finding: Testing revealed an unexpected opportunity — users saw strong potential for team collaboration features (sharing tracked changes, custom group lists, tagging for colleagues). This wasn't in the original scope, but the client noted it as a key opportunity for future product development.
[CONCLUSION]
So what did we achieve?
Validated product with real user demand
Through 8 user interviews across two groups, we confirmed the product's relevance — and discovered it could support not just document tracking, but pharmacovigilance and market intelligence workflows more broadly.
An unexpected growth path
Users' enthusiasm for collaboration features (not in the original scope) gave the client a concrete roadmap for future development beyond MVP.
Funding-ready deliverable
The prototype and research documentation were received positively by management, with implementation budgeted for the following year.
Lessons learnt
Domain complexity is a design problem, not just a research problem
Understanding drug documentation regulations, data-pulling limitations, and legal constraints wasn't a prerequisite to design — it was the design challenge itself. The information architecture couldn't exist without that understanding. In domain-heavy projects, I'd now budget explicit time for domain immersion as a design activity, not just a research phase
4 weeks is enough to validate — if you scope ruthlessly
With a tight timeline, every decision had to earn its place. We couldn't test everything, so we focused validation on the core value proposition: does the change-tracking view actually save time? That focus kept us on track
