The touch enabled digital billboards we developed for Clear Channel had to withstand extreme weather conditions, vandalism and general wear and tear.
6 things you should consider when designing physical user interfaces
6 things you should consider when designing physical user interfaces
In one of our previous articles we discussed the implications of Industry 4.0 and the new business models evolving because of it. Here, we look in detail at UIs from a hardware and a software perspective and focus on key considerations when designing physical user interfaces.
Screens are everywhere. We have them in our pockets, on our desks, in our cars, and on multiple appliances in our homes. Look beyond our personal spheres and we find them in many industrial applications, an airplane dashboard, a medical device, a sheet metal pressing machine, you name it. Screens are often the direct point of contact in which a user interacts with a machine, therefore the user has to be at the centre of design. And although many of today’s screens can be mirrored and viewed from computers or devices, the design of physical interfaces creates considerable challenges.
Drawing on 20+ years of experience – including time as a lecturer on Tangible UIs at Umeå University – Daresay’s resident UI expert, Anne Kathrine Windel Nissen, has put together six key considerations when designing a physical user interface:
#1: Identify hardware and software requirements
Firstly, you have to get the basics right. In an age of seamless experiences, it’s essential that the response of a UI is frictionless. Why? Because there’s nothing more frustrating than dealing with a poorly designed user interface on a daily basis. You also need to plan for the future, which creates a few initial challenges for the system behind the hardware:
- It may need to handle different languages, but remember that designing everything in one language and translating later can be problematic. German, for instance, uses about 30% more characters than English. The product may also be rolled out in new markets at a later date, so you should be prepared for this eventuality.
- Make sure there is enough memory – besides the everyday operations, security and warning systems use considerable memory space in a UI.
The user interface is where ‘the rubber hits the road’. It’s where the input (buttons, rotaries, touch areas, etc.) meet the output (high- or low-resolution screens, indicators, sounds, haptic feedback, etc.). How successful this meeting is, lies in how well your micro interactions are designed. Basically, the micro interactions are the small sequences of trigger-feedback that ‘oil’ the mental cogwheels of the user and make the difference between a tolerable and a great user experience. Typical questions you need to answer include:
- What level of animations and transitions are requred? Is fading in/out enough or are more advanced transitions necessary? Also, how quick should the scrolling functin work?
- How many buttons and other interactive elements are required on each screen? How many elements can the processor(s) handle?
- Should there be carousels and sliders? Is there even enough memory for either of them?
- How many fonts and font sizes are supported e.g., can the system handle a change from a light font to a bold font?
- How many colours can the software support? If you have anti-aliasing a visually simple interface with white and grey text can easily use as many as 64 colours. If you then only have a 256bit colour screen, you have to think carefully about your colour choices.
These design elements and micro-interactions need to be made clear to software developers at a very early stage, so they know what to plan for and why. Creating quick wireframes to ‘stress test’ the capabilities and explore a UI design is highly recommended. You can work out the actual design at a later stage but at least you’ll know the limits to work in. This is especially important in an agile environment, where the stories completed in the beginning of the project will influence the stories at a much later stage.
#2: Use a design system
Given the multitude of information in many UIs – as opposed to the single use case of a dedicated app – the number of screens can easily run into the hundreds or thousands. Using a design system will ensure that the design is user-centric, that it adheres to the corporate brand and that users are led through logical steps with no dead-ends. If we take pop-up notifications as an example. Using a design system will ensure all the alerts, warnings, onboarding support and help files are planned and developed to work seamlessly in the system, although you have to carefully consider the steps a user goes through and understand what they expect to do next. This will also ensure the menus and notifications are uniform and logical – if they’re not the “mental cogwheels” of the user will become stuck.
#3: Hardware – the who, what, whys and wherefores
The content in a connected UI can be updated on a regular basis, but the same can’t be said for the hardware. It’s important you get your choice of hardware right, first time, especially if you can’t replace it without taking a machine or product apart. Therefore, you need consider some important questions from a user’s persepctive before you design the hardware:
- What type of environment will it be used in? Will the machines be used in hot or cold, dusty or clean, wet or dry environments? The typical usage will have a big impact on the UI hardware, it may even be that you need multiple casings depending on customer requirements.
- How sturdy does it have to be? It might be subject to a lot of shocks which will complicate the design, especially in hardware with dedicated secure circuits.
- What does the user experience while interacting with the UI? Are they operating heavy machinery or sat in a moving vehicle? Operating a touch screen in a heavy goods vehicle could easily become a hazard, in such a case you could consider using voice, audio, visual or haptic feedback.
- Do you need to cater for special needs? It could be that the screen will often have direct sunlight on it, or that typical users have rheumatism, poor eyesight or are hard of hearing. These factors will only be known if you do a thorough user journey – make sure you do it at an early stage, rather than wait for user testing.
As Bill Buxton puts it:
“Without an equally solid understanding of both the strengths and weaknesses of the technology - when, where, why, how, for what, and for whom it is and isn’t suitable – one is gambling rather than practicing design (much less acting in the best interests of users, shareholders, or employees).”
#4: Don’t forget to compensate for any connectivity challenges
In most connected mobile devices, the casing is plastic and the placement for an eventual WiFi antenna is optimal. But if a physical interface is placed within a metal casing, which is in operation in a building with sturdy walls, and/or far from a router and repeater, getting a reliable WiFi signal can be a challenge. It’s only by exploring typical user environments that you will get a good understanding of how to best support your customers. Furthermore, you may have encountered hardware size constraints (lack of available space for the components, cost constraints, code errors, etc.) which in turn reduces system speed and touch responsiveness. This is an area that is generally outside the designer’s role, but potential problems with signal strength are crucial to the user experience and the working of the connected UI – a designer has to take an active role in supporting the user. In the age of connectivity, these challenges must be overcome in order to provide a seamless service.
Our Carplay UI uses the phone’s data roaming capabilty to avoid any wifi issues when is it in use at different exhibtions and trade fairs.
Carplay in use at a Swift & fika event in Stockholm
#5: Live test as soon and as often as possible
Testing a physical interface with users adds an extra dimension to user testing. Instead of just having a paper or screen-based prototype that you walk through with a test script, carry out a scenario-based test where you build up the environment (and the prototypes) in order to be as close to the use case as possible. Remember to:
- test early
- continuously align your test goals with the team
- make the prototypes cheap and fast
- test, improve /remake, test again and again and again
In short: make failures productive, and do it lean, cheap and fast.
#6: Work as a team, always
A physical user interface is a means to achieve an end. You’re not creating a game on a screen but enabling somebody to carry out a job or a daily routine. To ensure this is achieved, all feedback in the project must be clear, to the point, and shared with the right people. Groups must be able to collaborate and work through any problems – after all, you are all working towards the same goal. We like to work with the teamwork kit to facilitate a smooth and effective collaborative process – in which team members receive the praise and support they need to succeed. Whatever way you choose to work, make sure it’s collaboratively and that you “Keep It Simple Stupid Superhero!”