Almost all electronics systems need user interaction, but If users find it painful, you’ll soon have no users
Human Machine Interfaces (HMI) can probably be described as the core of many electronics systems, their scope is to connect the user’s will to the system that can accomplish a certain function.
I like to summarize the importance of HMIs in this one sentence:
If users find it painful to use your product, you will soon lose them.
This sentence depends on a few important things, mainly if your product does have substitutes or not, but this is not the core of the article. What I would like to stress is that it is necessary to involve the user early on in the development of a product to be sure not to be wasting time as, if the product is very difficult to use, or does not satisfy the user needs, it will have no users to use it.
In this case, we’re going to take a brief look at the way the user interface for the Open Source Ventilator – Open Lung collaboration* was developed, and at the process one can follow to develop a user interface centered around the user.
*The collaboration is currently (April 2020) working on the design of an Open Source respirator to be deployed in developing countries during the Covid-19 pandemic.
1: Identify the user
The first thing that needs to be done when developing a product is, of course, to identify the user and try to design around his or her needs.
The identification can be done in various ways and can lead to the creation of user persona models to be used as references, where developers imagine their target users and start describing them. A good user persona profile includes a demographic profile, work-life balance details and whatever touches the reality of the system we’re designing.
Once a user persona profile is written, it is time to do some homework. We need to sketch down our user interface (UI) and user experience (UX) to start getting some feedback.
2: Do some research on already existing systems
Once we have a scope and a user, it’s time to do some research. The biggest probability is that your system is not completely new and does already have some similar counterparts. Therefore try to research what others are doing and identify who is doing it better than others, then, try to sketch over it with your intuition and creativity.
The core of this point is not to nail the UI or to copy what others are doing, but to create something good enough to fake the interface functionality of the product to get feedback from the user on their needs, even before committing to any kind of design choice.
In our case the final product is not a completely new device, therefore, to have a starting point, we’ve headed towards manufacturers already building ventilators.
After a fast google research, we end up reaching out a few websites and user manuals to study the user experience of existing ventilators and their user needs (i.e. what does a doctor needs to set, to see, monitor and change). Then, time to sketch.
3. Sketch the UI
A fast mockup can be created with anything, let it be Paint, HTML or some web apps. The core point is to create something to start discussing with the user about their controls and feedbacks (i.e. buttons, layout, displays, light, sounds).
4. Sketch the User Experience flow
Together with the mockup, which shows a static image of the situation, it is also very important to sketch the dynamic view. This can be done either with a wireframe or by using a flow chart of what the user will have to do to use the system. In our case, this was enough as the users (Medical doctors) were actively collaborating with us. Otherwise, a dynamic wireframe would have been better.
5. Ask the user and be ready to redo everything
Once these two components are ready, a conversation with the user can start. It is very important to note that this route biases the user with our approach and that there are many other ways. Unbiased feedback can be received by asking what the ideal user interface would look like, but be prepared to consider a good amount of user-centered bias depending on their daily experiences.
Depending on the feedback one can then iterate again the design or starting to produce the first prototype to field test it.
6. Prototype the User Interface
Once a discussion with the user ends up in good feedback, the result can be converted to a real-life product. This way we will be able to watch the user actively using the system and understand if hidden pains are hidden between their expressions.
The result of our first round can be seen in the following picture, a graphical display with 12 buttons of different colors (only the PCBA is shown, no covers are included in the model shown).
7. Iterate again until the results are optimal
Once prototyped and tested, the HMI can proceed through final manufacturing and production. Before this happens, be sure to have tested the usability of the system in unbiased environmental conditions, meaning that Users should be asked to use the product without a designer telling them how to do it, and feedback should be gathered by checking if the interaction is seamless or, unfortunately, painful.
Conclusion
Involve the users as soon as you can and build your user interface around their needs. What the engineer or Designer thinks of their design shall not be considered to validate or not a system.
All that matters is how the user is going to use the product, and remember:
If users find it painful to use your product, you will soon lose them.
Nadim Conti 