Interview recordings captured and organised in Dovetail as part of the 14-participant discovery phase. These sessions represented carers, managers and support staff across a range of care settings.

 

My Role

Senior Product Designer (Discovery Lead )Log my Care
Timeline: July - October 2025: approx. 3 months

 

First of all, what is 'eMAR'?

eMAR - Electronic Medication Administration Record - is the digital system care workers use to record, administer and audit medication for vulnerable adults in residential and homecare settings across the UK. It is regulated by the Care Quality Commission (CQC) and used daily by thousands of carers. Getting it wrong has direct consequences for the people in their care.

I led the end to end discovery and strategic definition of Log my Care's Electronic Medication Administration Record - a safety critical system used by thousands of carers across the UK to administer, record and audit medication.

Designing for this space required clarity, humility and close collaboration with real carers and care managers. Medication errors in this environment carry direct safeguarding and audit consequences.

 

The Challenge

As the product had scaled, medication workflows had grown more complex and interdependent than their original design could support. No shared model of the medication lifecycle existed across the organisation. Feature prioritisation was driven by stakeholder opinion rather than the people actually using the system every day.

Every day, carers were managing high risk medications in a system that couldn't be consistently trusted. The cost wasn't just operational. It was human.

The work focused on uncovering the root causes behind:

  • Medication errors and missed doses

  • Stock discrepancies and audit gaps

  • Incomplete or unreliable MAR charts required for CQC compliance

  • Workflow stress in high pressure care environments

 

“When we’re dealing with time critical stuff… that can be the difference to hospital admissions, life, death.

— Care Manager, User Interview 6

 

What I Did

I mapped the system from the ground up - putting carer voices at the centre of every structural decision made, not internal assumptions or feature requests.

  • Worked closely with Developers, PMs, Sales, Customer Success

  • I designed a semi structured interview guides covering four focus areas - medication scheduling, PRNs and safety information, stock management and GP/pharmacy integrations - with tailored question sets for both internal stakeholders and external care providers.

  • Conducted and synthesised 14 user interviews across carers, managers and support staff. Interview recordings captured and organised in Dovetail.

  • Ran 9 internal stakeholder interviews (Across Product, Engineering, Sales, Customer Success, CTO and CEO) to identify patterns, themes, gather constraints and align understanding

  • Gathered 69 survey responses from existing and churned users

  • Proactively reached out to both churned and existing users, building rapport and trust to encourage participation.

  • Mapped the full end to end medication lifecycle (Adding, Administering, Updating/Pausing, Stock, Exceptions)

  • Benchmarked leading eMAR competitors to assess structural gaps and differentiation opportunities

  • Facilitated alignment with PM, CTO and Engineering

  • Presented findings and design solutioning plan to the full company in an in office sessions

  • Defined problem statements, JTBD and success criteria adopted across Product and Engineering.

 
 

What I Found

What emerged wasn't a list of UI complaints. It was a system with compounding failure modes across six interdependent workflows - where a failure in one stage made the next stage worse. Critically, many of these risks were previously invisible - stock logic gaps, inconsistent audit trails and missing escalation paths had been contributing to errors and support load without being formally recognised or connected.

 

6 interdependent workflows mapped end to end for the first time:

  1. Onboarding

  2. Adding Medication

  3. Administering Medication

  4. Updating & Pausing (Editing) Medication

  5. Stock Management

  6. Auditing & Reporting

Initial deep risk analysis focused on Adding, Administering and Stock Management due to highest frequency and safety exposure.

 

Full walkthrough available on request during interviews.

 

Five cross workflow safety failure patterns from 200+ synthesised insights:

  • Unsafe Medication Editing

    Inability to safely edit or update medications

  • MAR Accuracy Gaps

    Missing or inaccurate MAR charts

  • Stock Count Inconsistency

    Stock inconsistencies and audit gaps

  • Escalation Visibility Gaps

    No clear way to flag issues

  • Alert Clarity Failures

    Overwhelming, unclear, or missing alerts

 
 


The critical insight: unsafe editing in Adding directly created MAR gaps in Administering. Stock inconsistencies created escalation blind spots in Auditing. These weren't parallel problems. They were connected.

These failures appeared consistently across 14 interviews and were reflected in support tickets and usage trends.

 

How I prioritised the findings

23 pain points emerged from the research. The challenge wasn't finding problems - it was deciding which ones to solve first in a safety critical, CQC-regulated environment where the wrong call has real consequences.

A simple impact and effort matrix wasn't good enough here. Impact in a care setting isn't about user satisfaction or engagement. It's about clinical risk, compliance exposure and what happens to a vulnerable person if the problem goes unresolved.

So I built a multi criteria scoring framework with defined rubrics across four dimensions. Every score traces back to something a real user said or experienced - not internal opinion or stakeholder preference.

 

The four scoring criteria were:

Frequency of Occurrence - how often the pain point appears in a carer's daily workflow, from initial setup tasks through to actions taken multiple times a week like administering medication and managing stock.

Frustration Level - how disruptive the issue is from the user's perspective, from barely noticeable through to completely blocked with no workaround available.

Severity of Impact - the clinical, safety or compliance consequence if the issue goes unresolved. This was the most heavily weighted dimension. A pain point that occurred rarely but carried a risk to care, safety or CQC compliance ranked above something that happened constantly but caused minor friction.

Frequency of Mentions - how many times the pain point appeared across the consolidated research, from fewer than 3 mentions to 10 or more.

 

Each pain point received a composite score. The top cluster - one pain point scoring 16 and five scoring 15 - emerged as the highest priority group. These formed the evidence base for the first roadmap cycle. These covered difficulty editing medication records, lack of structured administration input, missing alerts and warnings, lack of access to critical information at the point of care, inflexibility in signing workflows, and stock alerts not visible when needed.

The framework was reviewed in a session with the product owner and engineering lead. My job in that session was to hold the clinical risk and user perspective and make sure those didn't get traded away for delivery convenience. Every prioritisation decision was traceable back to the research - which made alignment significantly faster than opinion led roadmap discussions.

 

Prioritisation Model

 

What I Decided

I introduced a risk based prioritisation model combining frequency, safety exposure and operational impact - replacing opinion led roadmap debate with evidence led sequencing.

Not every decision was popular. I recommended descoping two high visibility features from Phase 1 because neither addressed any of the 5 structural failure patterns. Fixing the surface without fixing the system underneath would have created false confidence in a still broken record.

I also established a safety led operating model with explicit decision gates between discovery and build. When engineering pushed to ship ahead of validation I held the sequencing. In a CQC regulated product, shipping first and validating later isn't a velocity decision. It's a safety risk.

 

My safety led operating model

 

What Changed

At the close of discovery I presented findings to the full company - not as a research readout, but as a deliberate attempt to create shared understanding across teams who had never spoken directly to carers or care managers.

The conversation shifted visibly:

Before:

"Which features should we prioritise?"

After:

"What do we need to understand before we redesign this?"

That shift created the organisational conditions for the right redesign to happen. This work didn't just shape the eMAR redesign - it reshaped how the organisation approaches problem solving and clinical safety.

 

What I established:

  1. A shared understanding of who carers actually are and what they face every day - bringing the human reality of medication management into a business that had never spoken directly to the people using the system. For many in the room, hearing carers describe the pressure of a medication round for the first time visibly changed how they thought about what we were building and why.

  2. A unified system model across 6 interdependent workflows - aligning PMs, sales, customer service, developers and leadership around shared failures and user needs for the first time. This didn't exist before I joined.

  3. Defined problem statements, opportunity areas, Jobs to be done and success criteria adopted across Product and Engineering - creating a shared language for what carers needed to accomplish, not just what they were complaining about.

  4. An 11 step design solutioning framework adopted across design, product, engineering, sales and customer success - preserving safety critical insights through to build and giving every team a clear shared structure for the redesign phase.

  5. Explicit safety decision gates between discovery and delivery - reducing ambiguity and ensuring engineering couldn't ship ahead of validation in a CQC regulated product.

  6. A concise cross team report and documentation replacing scattered knowledge with a stable shared reference for roadmap planning across product, engineering, sales and customer success.

  7. Presented findings and the design solutioning plan to the full company at in-office sessions - creating cross team visibility and buy in at a moment when the organisation needed a shared direction, not just a research readout.

 
 

Solution foundations for the redesign

I left the organisation before the full UI redesign phase. The work below represents the conceptual foundations the team used to begin solutioning.

  1. A clearer, safer Administering Medications structure

    step based clarity, stronger dose checking, reduced cognitive load during rounds, safe error handling and missed dose patterns

  2. A modernised Stock Management model

    ideal relationship between stock, MAR entries and exceptions, simple guided top up flows

  3. A scalable interaction model across medication tasks

    modular patterns that future features could plug into

  4. Solution principles to guide future UI

    Safety first. Clear timely visibility of critical alerts. Reduce cognitive load. Clarity over density. Predictable consistent patterns across all tasks.

 

What I learned

The biggest tension in regulated discovery is pace. Leadership wanted solutions before the system model was stable. Safety critical framing only lands when you give leadership a risk cost for moving too fast - not just a design rationale. I'd quantify the regulatory exposure earlier next time to accelerate alignment.

Safety must be architected before it is designed. That principle shaped every decision I made on this project.

 

Good discovery doesn't just find problems. It makes the people in the building feel the weight of solving them.