Website concepts

These high fidelity exploratory concepts show how the Doctorlink website could better represent value for prospective clients. Along with a cosmetic refresh and a cleaner UI, this work aims to visualise a clear value proposition which was creating using a combination of internal stakeholder insight and user research.

Case study: Repeat prescription management

In order to reduce the amount of time-consuming administrative tasks GP practices have to work through, we wanted to allow patients to manage their own repeat prescriptions. Products which let you do this already exist, so I needed to decide how this functionality could seamlessly slot into the existing Doctorlink application. I began by researching competitors operating in the same space and mapping out some concepts.


Once I felt I had a fairly strong understanding of the limitation and constraints, I started to draw up a proposed journey. This is a simple success flow, which shows a registered patient logging into Doctorlink and re-ordering medication for an existing repeat prescription.


In order to validate or disprove any outstanding assumptions I worked with our UX researcher to test the concepts with real people. We conducted qualitative testing with seven individuals who’d previously had experience of managing their prescriptions using a digital service.

There were some clear key learnings from the prototype testing:

  • Patients want an indication of when a repeat prescription is ‘ready to collect’ from their nominated pharmacy.
  • We need to be clearer about how the user is contacted by the practice or pharmacy regarding their prescription request.
  • Patients want to be reminded before they need to renew their prescriptions.
  • The word “remove” sounds a bit final and users are unsure if medication can be added again.
  • Some patients may need reassurance that changing their nominated pharmacy isn’t a permanent change.

The solution

It's not enough to just have a validated prototype. I had to work closely with our project manager and developers to ensure that every aspect of this feature had designs. There was a lot to consider - some of the major considerations were;

  • What happens if a patient's record didn't contain all of their current repeat prescriptions?
  • How should a patient request additional medication?
  • How does a patient review their previous orders?
  • How should we show the status of an order?
  • How should we differentiate existing medication orders and new medication requests?
  • What do prescription notifications look like?

I mapped out various journeys in Sketch and prepared these for a second, more rigorous round of user testing.


Updating design documentation

New components which have been approved for use in the new journey need to be added to our design documentation. This process ensures that the work is available for other designers but also helps to add context and detail for developers building the components.

The results

Our MVP only allows patients submit a request to their practice so they can re-order an existing repeat prescription. Our feature needs to connect directly with the patient record at their practice.

We already know that GP practices prefer solutions which create time and cost savings - this means reducing unnecessary touch-points with patients - but this MVP is currently creating administrative tasks for practice staff. They're required to review and escalate the requests which have been submitted to the practice inbox via email.

The uptake of the feature hasn't been as high as I'd hoped, so we're now looking to have the feature fully connected and surfaced via a practice portal managed directly by clinicians.