In this post I would like to tell you how we ran the user experience (UX) process for a healthcare project. For me as a software engineer and consultant on IoT projects, UX is a very important topic. I think it is becoming more and more essential as a unique selling point. In my view it’s important to get users excited about using your product, both before they start to use it and once they are already using it. You want to get to a point where users of your product talk to their friends and colleagues filled with enthusiasm about the product they’re using. That’s what I try to achieve for all of the applications I’m working on.
If you take into account the Internet of Things (IoT) and all the possibilities it holds for new products and new user groups, you can understand why it is important to deliver the best UX for your products out there in the IoT. If you do not make it to the point where you fascinate the potential users about your IoT product your product will never take off. At least that is what I think.
Now I would like to introduce to you how we ran the UX process for a health care project.
Introduction to the project
Let’s start with the overall goal of the project. This is to support patients who are recovering back at home after a stay in hospital with chronic diseases, by keeping an eye on their state of health and monitoring them professionally. To achieve this we have several systems and parties involved in the solution as it was finally rolled out. On one side there is the patient located at home, and on the other there is the health care professional (HCP) located in a hospital. Patients have a device (Health Buddy) that enables them to report their state of health to their HCP. It is these HCPs who are actually in charge of monitoring the patients’ condition and who must react as soon as required. But how do these HCPs get hold of the information about their patients’ condition? I’m going to describe this using the following illustration.
Patients receive a survey with several questions concerning their state of health on the health buddy device, which can connect to the internet daily if necessary. Patients must answer this survey within a defined period of time and, if needed, enter vital sign parameters or connect their health buddy to an external device that is able to read their vital signs. The answers to the survey are then directly uploaded to the internet. From there the HCP accesses the data and can reliably monitor the patients’ condition without intruding into their lives.
Who is our user?
Our part in this project is to provide HCPs with a system that allows them to keep an eye on patients’ condition. We created several fictional users and generated descriptions of them, known as personas.
The important thing about personas is that the description of such a fictional person must be based on hard evidence gained from thorough research. In our case, this research was delivered by our customer. Our challenge was to gather all this information from the customer and consolidate it in order to identify and describe in detail the personas we needed for our project. One of them is called Nora Roberts (see below).
Once you’re finished with your persona description, you should be able to think, feel, and behave like this person. If you achieve this, you are well on the way to building a product with a good user experience.
Now I’ll go into detail on how we designed a great product for our user. Below, I’m going to list the steps we took and the hurdles we had to overcome.
UX evolution or UX revolution
We had to take into consideration the fact that our customer already has a product on the market, while from our persona we know that the user is not very tech savvy. That’s why we decided not to start a UX revolution and kick off a whole new design thinking process, but instead to optimize the UX of the current product by building a new user interface (UI) with an improved UX.
The context of use
During the user experience design process you need to specify the context of use. This includes the following steps (Source: DIN EN ISO 9241 Part 210):
- Identify the user and stakeholder groups
- Identify the characteristics of the user
- Identify the goals and tasks of the user
- Identify differences between user groups regarding their goals, tasks, and requirements
- Describe the environment of the system
Steps 1 and 2 are included in our persona. Step 3 is also partially included. We additionally created two further personas to describe different system users and groups. Doing this allowed us to discover differences between the user groups, which covered step 4. Concerning step 5, we took the description of the old system and documented any differences between the old and the new one. Another factor we had to consider was that the medical world is moving really slowly to adopt new IT technologies, which narrows your solution space a lot.
The next step in the process is to understand the requirements for the product. In our case we used the requirements for the old system as a starting point. In two workshops with the customer we matched these requirements with our identified context of use and adapted them as necessary. We also discussed upcoming features, so we could prepare the new designed product for them.
After matching the requirements and the context of use, the conclusion was that the UX will be realized primarily in a web-based UI used by the HCP.
For design realization we took a number of different approaches. For general concepts and things like information architecture we used the whiteboard and made scribbles. I personally find this approach better than working on the computer because it’s easier not to get tangled up in details. But when you’re working on actual UI screens it’s important to know your target screen resolution. That’s why we created the wireframes directly on the computer.
As the next – and in my view very important – step we implemented a clickable demo application. Using this application we presented our results to all the stakeholders to get everybody on board for the new UX and the new UI based on it.
This brings me to the last step in our process: testing the new UX and the behavior of the new product.
For this we also used the clickable demo. Together with experts in the clinical environment and users of the old system, we evaluated the new UX and UI design. From these evaluations we collected the feedback and made changes to the demo application to improve the UX iteratively.
That’s my overview of our UX process for this IoT health care project. It would be nice to hear how you run the UX process for your products: what is different, and which experiences would you like to add and share with the community?