Case Study: A New 'Arrange View'

Studio's Arrange View, which allows users organise dynamic audio visually on a timeline, had several major problems;

• A cluttered user interface which was complicated for new users
• Built in a way which made iterating on it difficult and time-consuming
• Numerous bugs which impacted user confidence

Design Workshop

I organised a design workshop with our Product Manager and the team of engineers who would be working on the project. I always like to extend the invitation to others who might be able to help, like people who were involved with building the original version. That usually helps to identify potential pit-falls early on. The main aim of the workshop was to map out our assumptions about what the Arrange View should allow users to do, and how we might be able to improve the experience for them.


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.