Here is the second part of our blog series on building a successful healthcare application for web or mobile. This post focuses on utilizing ‘user-centered design’ methodologies to enhance the usability and usefulness of your app. But firstly, what is ‘user-centered design’?
User-centered design (UCD) or user-driven development (UDD) is a rigorous, user-focused methodology which seeks to investigate problems, rapidly design solutions and validate assumptions with users in an almost simultaneous flow, enabling users to drive the development of the product or service in real-time. User characteristics, environment, tasks and workflow of the product, service or process are given extensive attention at each stage of the design process and tested with users as soon as possible, almost always in a prototype or ‘beta’ form before any design decisions are committed to.
Put more simply, it’s a design methodology which asserts that the end-user (who is not always the same as the ‘customer’) is the best qualified person to say how the app should function, and which features are most important and desirable. Seems obvious, no? Well, you’d be surprised how many people out there are designing apps with almost little or no input from the individuals or groups who will be using the app; and focusing instead on the desires of some other stakeholder in the process.
Depending upon the audience and user-base of your app, this may mean that you will have establish a group of clinicians, patients, administrative staff, or just random members of the public who are willing to answer your questions and test your early prototypes. Best practice in regard to establishing these groups is to try and test with at least 8 users, and make sure that all possible end-users are represented in the group.
So, say your app is aimed at supporting more efficient workflow for Doctors working in under-resourced Primary Healthcare Centres in low income areas. Great idea, but have you actually tested the idea, and better yet have you tested any early prototypes with this actual user group?
The three key things to consider when designing an app that will be used specifically in a Healthcare setting are typically: usefulness, usability, security. In this post we will be focusing on the first two factors, but for more information on how to make sure that your app is secure, see part 1 of this blog series. I believe that these two factors, Efficiency and Usability can be mapped to the ‘Design Thinking’ process in the following way: ‘Usefulness’ is a measure based on ‘who’ and ‘why’, whereas ‘Usability’ takes account of the ‘what’, and ‘how’ aspects.
So let’s delve a little deeper into ‘Usefulness’, and what this term actually means for your app design and architecture.
When we get the idea or desire to build something, it is almost always in order to solve a problem, or meet a need. There is no point in having a beautiful, easy-to-use application if it doesn’t actually solve the problem that it was designed to address.
This statement seems obvious, but, as we start to get excited about the look, brand and features of the app we are hoping to design, it can be surprisingly easy to forget that it also needs to be a more efficient solution to our core problem than what is currently out there - if there is anything currently being done about your ‘problem’.
If there is no current solution, you need to be extra careful about answering the following question, since you’ll be the first person or company operating in this space: How well have you defined the issue that you are trying to solve? Are you really knowledgeable and well- informed about the problem or need as it stands?
If you don’t understand the problem, you can’t build the right solution. Here are some questions that might help you determine your current level of understanding and define the need you are trying to meet with your application:
- How did you discover this issue or need?
- Why is it important?
- Who has the direct need or problem?
- How are they solving it now?
- What is your solution, and how is it better than what’s currently available?
You should take time to make sure that you really understand the problem and that you are not making assumptions about what the issue is and how it can be solved. While desk-based research can be helpful in the early stages of planning, there is no substitute for actually talking to and observing people who have the issue, and understanding what they see to be the barriers to solving it. This stage of the Design Process is often referred to ‘Discovery’ or ‘Empathy Building’ with your target user group(s).
There are lots of great websites and blogs that can help you get into the detail of planning your design process and provide helpful tips on how to conduct your initial research. The Interaction Design Foundation provides great articles and insights covering every imaginable area of UX/UI design, but I found this article on the ‘Empathy’ stage of the Design Thinking process, and this one on ‘Defining the Problem’ particularly valuable. If you are completely new to user research you might also be interested in this post by Stefan Jost and Hyper Island which provides an overview of both qualitative and quantitative research methods.
Once you have started the process of asking these questions and engaging the users around their ‘problem’ and how it affects their lives and / or work you should start prototyping solutions and testing with users. Which bring us to…
The design factor that we refer to these days as ‘Usability’ is actually a collection of design choices which are intended to make the experience of using and navigating an app as easy as possible. You can also think of this dimension as ‘user-friendliness’ - how easy is it to start using your app? How easy is it to learn new functions and features? Is there much of a learning curve for your users? Are the interactive elements easy to recognize? Is the information arranged in an intuitive way?
Along with general Usability you might also need to consider ‘Accessibility’ for people with cognitive or mobility restrictions. This is particularly important in designing a healthcare app. For example, if your app is designed to be used by a patient or person receiving medical treatment, what additional factors might you need to consider? What is the patient’s physical and mental condition? Are they able to manually manipulate the buttons, or should there be strong support for voice commands within the app?
The key to nailing this important factor is actually asking your users to use the application (or some aspect / feature of it) and recording the results, then iterating and improving based on their actual feedback. If you’re designing an app for use by healthcare professionals, are you assuming any level of technical or ICT skills on their end? Are they required to install additional diagnostic software, or troubleshoot anything within the app? Let them use it - the earlier the better - and tell you whether using it is simple enough to be incorporated into their busy schedule.
Usability testing - if it is to be most effective - generally employs the use of prototypes or low and high fidelity mock-ups so that you can observe and record the users interacting with your app before you go and invest time and money in building and coding the actual architecture.
A super-simple and inexpensive technique which is helpful in both software architecture and UX/UI design is ‘Card Sorting’ - where uses are asked to arrange or sort topics or functions (written down on cards or sticky notes) into groups for you, giving an insight into what they see as the most obvious and logical arrangement of elements or steps in a sequence. You can learn more about Card Sorting and other user-testing techniques here on the excellent Usability.gov website which provides free advice and tools for testing, and through the helpful posts on Usability Geek.
*One thing however to be really careful about is the capturing and use of healthcare and patient data, always make sure that you are HIPAA compliant in respect of any data that you gather about your users and either the ’empathy’ or ‘prototyping’ stage. For more information on HIPAA and what compliance measures you may need to put in place, see our slide deck here.
If you have any comments or questions on any of the above, let us know! [email protected]
Joel Garcia has been building AllCode since 2015. He’s an innovative, hands-on executive with a proven record of designing, developing, and operating Software-as-a-Service (SaaS), mobile, and desktop solutions. Joel has expertise in HealthTech, VoIP, and cloud-based solutions. Joel has experience scaling multiple start-ups for successful exits to IMS Health and Golden Gate Capital, as well as working at mature, industry-leading software companies. He’s held executive engineering positions in San Francisco at TidalWave, LittleCast, Self Health Network, LiveVox acquired by Golden Gate Capital, and Med-Vantage acquired by IMS Health.