Background
LloydsDirect, an online pharmacy and NHS service provider based in London, dispenses over 1 million prescription items per month, delivering medicine to patients at home and helping them in managing their healthcare needs. The Patient Care team are responsible for managing customer contacts, resolving issues, and ensuring that patients receive their medications without delay.
Over time, their tooling had become outdated, cumbersome, and ineffective, leaving staff frustrated and overwhelmed. Despite the critical role that Patient Care played in the business, their primary tool, Support, had been neglected, forcing advisors to use a series of workarounds to complete basic tasks, impacting patient experience and response times.
Company
LloydsDirect
Duration
1 year (part-time)
Project team
Front-End Engineer, Product Designer. Later addition of Product Manager, User Researcher and Back-End Engineer.
Problem to solve
Although the business believed Support to be technically functional, a hack day exploration into smaller fixes revealed deeper issues with the tool. Alongside various UX pain points, we discovered that previously promised features were never implemented, requiring staff to use workarounds and legacy tooling to complete tasks, leading to rising patient response time. It was clear to us that this critical internal tool needed a complete overhaul.
Project outcomes
The overhaul of the Support tool delivered significant improvements across response times, cost savings, backlog reduction, and increased patient satisfaction. Advisors were now empowered to resolve challenges directly within the tool, reducing reliance on legacy tools and expensive database queries, making the tool more efficient and cost-effective to run and maintain.
This discovery and subsequent improvements not only enhanced patient care workflows but also laid the groundwork for broader strategic transformation within the Patient Care team, influencing other customer support initiatives.
By addressing the unique needs of pharmacy and actively involving advisors and stakeholders throughout the design process, the new Head of Patient Care recognised the impact, calling it “the best piece of customer support software he had ever used.”
Challenges
Lack of awareness: Tech and product leadership were initially resistant to investing time into Support, as it was perceived to be technically functional. Gaining buy-in required building a strong business case that highlighted the tool’s critical role in the Patient Care team’s workflow and its direct impact on customer experience.
Balancing priorities: Although leadership gave us the go ahead to begin work on Support, the project was not updated into a formal ‘Objectives & Key Results’ (OKR) initiative. This meant we could only work on it in our downtime and required us to balance this effort with our primary responsibilities.
No dedicated project team: For the first 6 months, the project team consisted of myself (Senior Product Designer) and Andrew (Senior Front-End Engineer). With limited resource, we had to be highly strategic and resourceful about prioritisation while also bridging gaps in our combined skillsets.
Lack of documentation: Support was originally built by engineers who had since left the business, leaving behind underdeveloped or incomplete features, and a stark lack of documentation. To fully understand the tool, we needed to dig into code, where we frequently uncovered broken or unfinished functionality.
Research outcomes
We relied on basic user research methods to gain a deeper understanding of the problem to be solved. I interviewed the Patient Care team about their experiences with the tool and shadowed advisors as they interacted with patients. This insight revealed several significant pain points:
Confusing navigation
The tool’s navigation was unintuitive, relying on a long list of undocumented keyboard shortcuts that advisors had memorised over time. Additionally, initiating a workflow opened a full-screen modal, blocking critical patient information and disrupting the user’s ability to reference key data while completing tasks.
Convoluted menus
Workflows and features had been added over time without any consideration for user experience, resulting in long and confusing menus that required advisors to expend significant cognitive effort to find what they needed.
Poor order information display
The original design attempted to simplify the order detail view by omitting certain details, but this often forced advisors to switch to old legacy tools to find missing information.
Missing workflows
The tool lacked a lot of required workflows that would allow advisors to handle the majority of patient and account issues, again forcing them to rely on external or outdated tooling that was not fit for purpose.
Overhauling an established layout
I set out to rethink how order information was displayed. The previous design had attempted to simplify orders by consolidating or completely hiding key information, often leaving advisors without the information they needed to resolve queries efficiently. Through multiple iterations, I worked to develop a solution that aligned with advisors’ mental models of the system and understanding the actual flow of how orders moved through the fulfilment process.
A key insight from my research led to the introduction of a three-part horizontal layout for the tool. This design kept the navigation menu, an ‘action panel’ for completing workflows, while the account detail section remained visible on the screen at all times.
With these core concepts in place, I moved into rapid prototyping, creating low-fidelity designs to test and refine with users.
User feedback and iteration
Patient care advisors played a crucial role in shaping the design through continuous feedback. Sentiment around the new navigation and revised workflows was positive from the start. However, opinions on how we displayed orders were mixed. This challenged me to step back, rethink my approach, and embrace the critical input. This led to the order view that felt counter intuitive to me, technically, but it far better aligned to the needs of the actual users.
Additionally, many advisors expressed frustration over having to switch between Support and our internal ticketing tool—used to track patient issues—just to check if a patient already had an open case. This seemingly small but frequent disruption created unnecessary friction.
Recognising an opportunity for a low-effort, high-impact improvement, we integrated the two tools, enabling advisors to check for existing issues without context switching. Later, we expanded this functionality, allowing them to create new issues directly within Support, further reducing cognitive load and task times.
Key factors for success
Most of our collaboration on this project occurred asynchronously, meaning we relied heavily on Linear to track progress and ensure alignment. Regular check-ins were crucial for discussing the technical feasibility of my ideas and refining our approach. Once designs were finalised, Andrew implemented them in a preview environment, allowing us to test, iterate, and continuously improve the tool.
Understanding user needs
A key challenge of the redesign was presenting vast amounts of data to non-technical users without overwhelming them. Early testing revealed persistent confusion around complex systems and data structures, leading us to an approach of progressive disclosure, designing the UI to show key information first and revealing details gradually as advisors moved through workflows.
As the project gained traction, other teams expressed interest in using Support and began contributing their own requirements. While their use cases varied, I identified significant overlap in the information they needed. To serve these needs without overcomplicating the tool, we introduced team-specific views, rearranging the same data and workflows to address different team needs effectively.
Building momentum
As our work progressed and the business started to prioritise the needs of the Patient Care team, we gained valuable support and resource from Product Management and some part-time User Research. This added structure and tightened the feedback loop between design, development, and testing. Later, added back-end engineering resource enabled a transition to GraphQL, allowing faster updates to the tool based on continued user feedback and significantly lowering the long term cost of maintaining the tool.
The result was a brand new version of Support that featured a more intuitive navigation, improved visualisation of orders and integrations with our other tools.
I designed new features such as History and Notes, which help advisors to quickly catch up on and track a patient’s previous contacts. All of the refreshed and new components were added to our design system, which helped to reduce the time needed for adding new features or refining existing ones.
In time, other teams were able to migrate to the new tool after we added specific prescription based views and workflows. This cleared the way for us to start deprecating older tools and focus our efforts on maintaining and improving Support which was more accessible, stable, and made full use of our design system.
Key learnings
Fighting for work you believe in: It was so rewarding to see this project transform from a hackday exploration into a full scale product transformation. Convincing senior leadership about this opportunity and and pushing this forward in my spare time was both challenging and exciting.
Getting out of my comfort zone: The fast-paced, hands-on approach of this project pushed me beyond my usual discipline. By working across product management, design and implementation, we delivered a product that exceeded expectations while creating a valuable personal growth opportunity.
Building my technical confidence: This project deepened my understanding of software engineering. I even started an online course in web development and React, giving me a stronger grasp of the technology I design for and enabling more meaningful and active contributions to technical discussions.
What would I do differently?
Avoid unnecessary workarounds: Back-end limitations led to temporary fixes that later required rebuilding. Addressing these constraints earlier would have saved time and allowed us to deliver more impactful features.
Pushed for more analytics: Without quantitative data from the old version of Support, we had to rely on user feedback and broad performance indicators like reduced response times. Implementing better analytics earlier would have provided clearer insights into our impact.
Closing thoughts
The Support project was a resounding success, not only in the improvements made to the tool but in its broader impact on the business. It highlighted the importance of maintaining internal tooling, addressing technical debt, and prioritising user-centered design. It also showcased the power of small, agile teams in driving high-impact solutions. Most importantly, it proved that when teams are empowered to take ownership of business-critical challenges, they can deliver transformative results.
