Developing user interfaces for embedded systems can have some difficult obstacles. We’ve come up with these 5 important steps to help:

 

Bluefruit Processes

 

1. Work out what you want to achieve

The most important goal for any user interface should be to fit in smoothly with the product and company branding. Embedded software is a significant touch point for any brand, so it’s imperative that it is consistent with the rest of the product, and the company’s image.

When developing a user interface, we discuss the client’s vision of how they want the interface to look and feel, and how the experience should relate to their branding.

 

 2. Understand the users

The user interface should firstly be fit for purpose. By this we mean, ‘does it do what the user will want/need it to do?’.

This doesn’t necessarily mean it should be easy or intuitive. There are plenty of successful software kits, such as Photoshop or AutoCAD, that are definitely not easy or intuitive for first-time users. However, they are packed full of necessary functions and features for professional power-users that, once they are trained and well-practiced, become exactly what they want and need.

Therefore, it’s incredibly important that we fully understand who the typical users are, and how their knowledge, experience and needs affect the way they use the product. Are the users old or young? Are they used to using technology on a day-to-day basis? Are they looking for a quick solution or an in-depth system? Do they mind having to read lengthy instructions?

These are the questions that should be asked about the typical user base, to ensure that the interface is appropriate for them.

 

3. Create prototypes and undertake A/B testing

Providing prototypes for our clients means that they are able to see and test out a tangible element of the project and provide us with feedback for future development. However, it would require a lot of time to provide an initial prototype for the software as a whole, so we use vertical slicing to provide samples of certain features instead.

Software development is commonly designed in layers, with drivers being the bottom level, and user interface being the top. In traditional software development, the bottom layer of code for the whole project is written at the start, followed by the second layer and so on. However, this means that you are only able to see whole elements of the project at the end of development, providing the customer with little to feed back on.

Vertical slicing means that instead of working on the horizontal layers of the software one at a time, we choose a specific feature and work through all the layers of code for just that feature. This method means it takes less time to create something that is demonstrable to the client, therefore giving us the opportunity to get feedback much sooner.

 

4. Provide iterations to gain feedback

Working with embedded software user interfaces is very different to computer or application UIs, because we don’t usually have the option of continuous delivery and regular software updates once the product is in the hands of the users. For this reason, we use a variety of testing methods and release software iterations at the end of each sprint (2 to 3 weeks) to the client.

While we usually recommend a firmware update system, these updates should be implemented early on in the project, which is why we try to get as much feedback as possible each time. We encourage regular feedback loops with each of our team members, our clients’ team members, the end users, and the customer service/tech support operatives, so that we can understand a variety of different user journeys and issues that could arise. As well as this, we always want to get feedback from our clients’ Marketing department, to ensure that the interface integrates smoothly with the company’s brand.

 

5. Take the product the market

Using Lean-Agile methodologies, our goal is to adapt rather than predict, which is difficult with embedded systems running on circuit boards and digital displays, as by nature they aren’t very flexible. Therefore we want to avoid Complaint Driven Development, which can be caused by taking the product to market too soon, so we aim to get as much feedback as we can during development. It is only when the iterations receive purely positive feedback do we suggest taking it to market.