How To Apply User Experience Principles To Embedded Systems: Learnings From The Field — Smashing Magazine

How To Apply User Experience Principles To Embedded Systems: Learnings From The Field

About The Author

Eva Rio is a creative technologist with ten years of experience in the software industry, focused on user and market research. Currently, Eva works as a Product …
More about
Eva ↬

Quick summary ↬
Embedded systems make our lives easier. We unawarely interact with embedded systems all the time, and they go largely unnoticed — until things do not work as expected. In this article, Eva gives an overview of what embedded systems are and how they impact our lives. She presents three main learnings gained across her quest for creating better-embedded systems to enable the world as we know it.

Embedded systems mean different things to different people; they can be standalone and independent, working by themselves, or be a part of a larger system. They are purpose-built for a particular application, designed to perform a specific function or set of tasks. Complexities of embedded systems range from very simple to highly sophisticated implementations, depending on the functions and features that need to be performed and its interactions and connections with other systems. Some examples are autonomous driving, artificial intelligence, and the internet of things.

To provide some context, embedded systems have been around for a long-time. Two examples are the difference engine devised by Charles Babbage in the 1830s and the Apollo Guidance Computer built in the 1960s and considered to be the first modern embedded system. A key component of an embedded system is its software. Embedded software brings a system to life, performing tasks on your behalf. Software is where most of the design effort and complexity of embedded systems lie.

In this article, I share three key learnings I have gained from applying UX and human-centered approaches when working with embedded software. These three takeaways include the complexity and advantage of addressing the needs of multiple stakeholders, how to benefit from understanding the dependencies between different components (by definition, embedded means integrated onto something), and how to overcome the challenge of communicating the value of technology that’s often invisible.

More after jump! Continue reading below ↓Smashing Online Workshops on front-end & UX, with practical takeaways, live sessions, video recordings and a friendly Q&A. On design systems, UX, web performance and CSS/JS. With Brad Frost, Stephanie Troeth and so many others.

Jump to online workshops ↬

Meet Smashing Online Workshops on front-end & UX, with practical takeaways, live sessions, video recordings and a friendly Q&A. On design systems, UX, web performance and CSS/JS. With Brad Frost, Stephanie Troeth and so many others.

Learning #1: Embrace Complexity In Your Projects And Designs

Let’s take a typical car as an example and imagine you develop software for its advanced driver-assistance (ADAS) system. There are three stakeholders in this example:

Even then, this is a bit of a simplification. In real-life projects, there are even more dependencies and stakeholders involved.

Thus, who should you take into account when building and designing your solution? More than who to design software for, it is about thinking of what’s important for each stakeholder. In this example, the end-user cares about the experience and that everything works as expected or even better; the user is after a complete feature set and possibilities; the customer tends to care about cost-efficiency. In the end, you need to meet end-user expectations (who don’t even know they are interacting with embedded software) while making your product easy to integrate for the user and ensuring the customer that they are getting the best solution for an optimal price.

Additionally, embedded systems are, in many cases, resource-constrained in power processing or memory, yet the expectation is that the whole system works seamlessly and in a sophisticated way. Therefore, you need to find a balance between performance and reliability without hurting the experience. Optimizing this interaction requires a great level of expertise and specialized knowledge, which comes at a price.

When designing embedded software, it’s critical to spend time researching and understanding the problem space, the goals, and jobs to be done by the different stakeholders in real life. The better you understand each stakeholder’s expectation, the less risk of spending time building features that would have no use in a real environment or falling short of features for the future. Performing software upgrades to support new use cases in embedded systems can be very challenging because sometimes these devices are located in places that are hard to reach or have no connectivity.

Problem space exploration is closely related to user research. As such, there is plenty of literature, case studies, materials, frameworks and tools that you can use to collect data and gain insights into users’ needs and challenges. These activities usually include surveys, interviews, questionnaires, or market research.

Here are some examples:

A key aspect of understanding the problem space is to be able to map the different journeys for each of your stakeholders and their touchpoints and where in those journeys you could implement those research tools and feedback mechanisms to help you with your planning of user research and problem discovery.

The template below from Columbia Road is a great starting point. I have simply added a new dimension — Feedback tools — to be able to link feedback activities to the journey stages. There are also other activities that you don’t necessarily think of as feedback or research tools. Yet, there are incredibly rich practices for gathering information, and I will cover some of those in the next point.

Learning #2: Find Ways To Learn Fast And Don’t Go Solo

As mentioned, embedded systems have many dependencies. Something as trivial as a fridge can have dozens of interrelated embedded systems.

The software runs on the hardware. Multiple systems need to interact in consonance with one another to deliver the expected functionality to the end-user. In practice, this dependency means that no matter how good of an idea you have, you will have to collaborate with someone to make it happen. Collaborations and joint efforts can take different shapes and forms, and here are a couple of tools and practices that I’ve found helpful:

An initiative, theme-based roadmap with broad timelines (now/next/later) helps you drive a discussion where to align your current focus, explore together ideas for the future, and discuss expectations. In other words, it helps to validate that you and the customer have the same understanding of the current landscape, a willingness to collaborate in the future and that your efforts are going into addressing the right problems. The cadence will vary depending on your business and your product release planning.

Talent is highly specialized, and hiring prices in the industry can be relatively costly. Collaboration is a cost-effective way to work on proof of concepts for addressing emerging demands, finding new revenue streams, or reaching new markets. Joint prototyping can help you identify potential challenges and gather early feedback, as well as speed up the development process, spread out risks, and support your time-to-market strategy.

In embedded, the saying “the whole is more/something else than the sum of its parts” is accurate. Being able to show how systems “talk” to each other and what is the jointly created value is very useful, especially when it comes to complex systems that can have a lifecycle of 5 to +10 years. In these cases, it is essential to get things right or rather spot design mistakes early on and validate your concepts whenever possible.

The embedded systems industry is highly competitive, with multiple players developing products in the same category. However, paradoxically, there’s still a reluctance to publicly engage in dialogues that may challenge the status quo and provoke new ways of thinking.

I have found that the companies that end up being trusted (and building trust is one of the central goals of user experience and goes beyond the bare visuals of a product ) and respected are those who show up and spark discussion, and share their points of view and ideas without fear of others taking credit. To quote a sentence from the TV series Billions, “A lot of people watch Bruce Lee movies. It doesn’t mean they can do karate.”

Learning #3: Communicate The Value Of Embedded Software

You cannot differentiate your product with graphical interfaces, visual design elements, or aesthetics for software that performs tasks in the background and controls systems behind the scenes. Therefore, you need to find different ways to convey its value and relevance. Even if you are not able to directly interact with it, this type of software plays a key role in the end-user experience, impacting, for example, the performance of a device, its battery life, power consumption, and its overall behavior. Let’s see some examples:

Thinking of the scenarios and systems holistically and then being able to explain how you help in the field and the impact you can make for the final user is an effective way to communicate the value of software and the impact it has in providing seamless experiences and meeting expectations. Find a story that resonates with your audience first, and from there, you can always go into more details for those interested in the hows and why their devices operate.

Conclusion

We interact with embedded systems all the time by unawarely experiencing how they make our lives easier and enjoying all the features and benefits they bring. Quietly in the background, performing the tasks they were meant to, embedded systems are ubiquitous and have different levels of complexity, such as smartphones, traffic lights, manufacturing appliances, satellites, vehicles, medical equipment, and countless other devices. They are present in nearly every aspect of our lives.

Understanding the multiple dependencies to other components, the different needs of all the stakeholders you need to consider, and being able to validate your concepts and communicate your ideas early is crucial. It will help you design your embedded product in a way that lets you differentiate yourself through a better overall user experience and, silently behind the scenes, improve people’s lives.

Smashing Editorial
(yk, il)

This content was originally published here.