By Peter Pelles, Product Designer at PKB
Peter is a major research geek, who believes that everyone in the company should understand how the ‘product’ is being used. 

In this blog, Peter shares our goals and plans for redesigning the Patients Know Best (PKB) application. You will learn about:

• the challenges we face
• how we have assessed the current system
• how we plan to learn more about the ‘pain-points’ for users
• how we plan to create a new information architecture
• how we want to validate our designs.

The product and the problem

PKB is a good application with a great mission. We have made a huge effort to make clinical data available to patients in a secure, convenient and useful way. The application is packed with lots of powerful tools such as booking appointments, the ability to easily see changes in your test results over time and so on. However, patients are sometimes struggling to find even the basic things they are looking for – or are often presented with options that have no relevance to them or may never be relevant to their health condition. 

The application contains many great features each of which is useful to a patient at a few points in their life but nevertheless, still fundamentally important to them. For this reason, the application typically covers every point in a person’s life however, at any particular point, the person uses few and different features.

Usage is increasing greatly. Between September and November this year, we’ve had three times the number of patients returning to see their record. With that, it’s time for a redesign to further improve the experience for more patients.

When approaching the redesign, we have to keep in mind that people rely on and place a lot of trust in PKB – and that requires treading very carefully when introducing any new changes. 

One of the biggest challenges is that we will not be able to apply the design changes to the entirety of the application all at once. This will create an interim period where the new and old versions will live side-by-side, potentially for as long as a year. 

The other thing we need to be mindful of during the redesign is that change is always difficult to get used to, particularly without the time that may be needed to familiarise yourself with new features. The majority of PKB users are only visiting the application on an occasional basis but, when they do, it’s important for them to get what they need and at the same time to have as seamless an experience as possible. 

The goal

PKB wants to build an application that satisfies the needs of a variety of patients, regardless of whether they are regular visitors who are highly dependant on the information received from their doctor or they are only occasional visitors. 

The process

We started with a heuristic evaluation to identify major usability issues and set up an initial hypothesis. We also looked at the usage analytics and the database to see how the product is being used, how much content an average user deals with and what the variables are in usage between patients. 

Based on the business objectives and our initial observations, we identified the key parts of the application we wanted to focus on during our 3-month redesign process. These were to redesign the navigation, messaging and notification functions. 

Although the initial changes will only affect a small proportion of the application, the design will be done from the ground up, concerning all the user interface components and patterns; not exclusive to the ones that will be used for the key screens and features that are in focus.

To validate the designs we will run weekly usability tests, such as the ‘5-second test’ – a method of user research that helps measure what information users take away and what impression they get within the first 5 seconds of viewing a design or ‘first-click tests’ where we assess the effectiveness of the links and content hierarchy. 

Once we are at the prototype stage, we will look at task completion rates, which involves giving test participants a task to establish what path they take whilst also asking them to verbalise their thinking process as they click through the prototype. Tests like these can influence not only the information architecture but also things like labelling, which is quite often the reason why users don’t feel confident clicking on certain menus or buttons. 

Aside from the weekly testing, we will build on our existing knowledge base, such as things we learned from talking to patients who contacted us through helpdesk or other means. We will also use various qualitative methods such as interviews and focus groups towards the end of the design process. These face-to-face, in-depth interactions will help us to learn more about the routines of patients, their experience with the healthcare system and their relationship with their healthcare data. In parallel, our methodology will help us to identify any problems or requirements on the architecture and feature level. 

Although qualitative interviews are typically conducted before designs are created, there’s a reason we decided to move this towards the end of the 3-month process. We recognise there are some legacy issues with parts of the current code base and user interface which we want (and in certain cases need) to address quickly. We predict there will be some important revelations and changes to come once we start interviewing and surveying patients, however these findings will typically have less effect on the components (e.g. buttons and list items) and patterns that make up an application rather than the hierarchy of the components. 

That is why the focus of the redesign is on the key building blocks and the look and feel, rather than the various features and screens. This means that for some time, the application will “live in two places” with only messaging and notifications being revamped and the rest of the application still using the legacy navigation and style. This is what we call an ‘interim version’ which will require us to think about onboarding users to the new user interface, informing them about the changes at certain steps and helping them navigate between the new version and the legacy version.

Navigation 

We found the system did not support users to easily navigate from one page to the other or help them find the information they are looking for. The solution is to introduce a navigation that is always visible to the user and presents fewer options.  To come up with the new layout, we used inspiration from many of the most-used applications such as Gmail and other networking sites. We followed the same logic and organised the main menus to the left-hand side of the user interface and moved secondary preferences like ‘options’, under a top-right user menu indicated by the avatar of the patient who is logged in. We also introduced other well-known patterns such as the ‘notification badge’. The goal was to make the user experience as familiar as possible, where patients who visit PKB rely on recognition rather than recall, which is particularly important when a user logs in infrequently. 

Messages and notifications

Most patients receive test results, questionnaires or a message from their doctor only occasionally. One of the major changes to the application user interface is going to be combining these one-way or two-way interactions into a single screen called the “Inbox”. These were previously spread across 3 screens: the Home page with the latest notifications; the Notification page itself and finally Messages & Events. We analysed user behaviour from visits to our site and realised these 3 screens are not only by far the most visited pages of the application, but they also serve as the primary way that patients navigate to their health record. Combining them into a single screen will drastically reduce the number of clicks and steps a patient has to go through to find what they want. 

The ‘inbox’ will also become the new home page for a patient in PKB. The welcome message (from the organisation which signed up the patient) will be the very first thing the patient sees when logging in for the first time, however it will be just like any other message the user receives. Instead of taking up valuable space on the top of the application, it will move further down the list of messages as new ones take its place. 

The inbox will basically serve as the central hub for all information in PKB to help satisfy a variety of patient experiences. If you barely see the doctor, you won’t ever have to navigate elsewhere in the application but even if you receive messages on a daily basis, it will be a convenient starting point. We designed it to be very familiar (in terms of both functionality and “look and feel”) for anyone who has ever used an email service or a messaging app, whether on a desktop or a mobile. 

Takeaways

Product redesigns can be incredibly tricky. It’s tough to convince stakeholders, it’s tough to figure out what to change and what to not touch and getting them built out correctly requires a lot of patience and blind faith. Even if all that happens and all design decisions are heavily backed up by research, it’s a gamble how users in reality will react. That’s why we want to move fast, iterate fast to learn fast. 

To begin with, you will notice only small changes with the new user interface and information architecture but it will serve as a testing ground for all other features and redesigns to come. It will make it much easier for us to test and analyse user behaviour and to survey users about their experience once we have a clean and simple user interface that utilises best practice, rather than if we had to make sense of patient goals and needs in a complex system where some bad design decisions already created odd user behaviours. 

We’re looking forward to rolling out the redesign next year. In the meantime, we’ll continue to share our progress and the steps we’re taking to enhance patient experience in a series of blogs to come.