Advertisement

Top 12 mistakes in creating cross-platform UIs, Part 2: Technology and UX design

May 27, 2018

Santtu Ahonen-May 27, 2018

As today’s devices and their respective user interfaces become more advanced, so does the creation and production of today’s user interfaces as well. Creating a UI for a modern-day device is often complicated enough as it is. However, when you want to make the UI for a specific custom embedded device, it can be a totally different beast to tame.

We often see developers fall into various problem buckets, coming across the usual suspects of mistakes. In this short series, we dive into these problem areas and reveal the most common mistakes developers make when creating cross-platform UIs. Part 1 already described 6 mistakes related to the application and solution architecture. 

Area 2: Selecting and Mixing Different Technologies

Mistake #7: Prioritizing bill of materials over cost of software engineering work.

IoT device manufacturing companies usually make money by selling the devices. To generate as much revenue as possible, the focus typically goes to the cost of manufacturing these devices. This pushes management and engineering to focus on the bill of materials (BoM). Many companies also have financial control structures, where capital expenditure and hardware purchases are calculated for the hardware business profit and loss, but the software engineering is “just an operating expense” that is controlled under different rules of engagement.

For example, it’s natural for manufacturing companies to focus too specifically on the exact unit price of a device as the primary indicator of profit or loss. However, the actual cost gets complicated when incorporating the cost of software engineering. The price of a transistor is always clear, but the “benefit” of saving $0.03 on a transistor, which may force a software engineer to redo work, is not as clear.

The outcome of all this is that the project will often optimize bill of material just a little too low with the hope that whatever pitfalls in hardware can be fixed on software engineering side. This results in bad UX, performance, and ends up being horribly expensive anyway. When you save on bill of materials, you typically create expenses in software development.

Mistake #8: Selecting technologies and architecture without high-level strategy.

Selection of architecture and technologies can be hard. Sometimes when people select technologies, it isn’t until during the project that they learn their technologies cannot be used together or the technologies mix very poorly. This forces the project team to rewrite and rearchitect assets. If you must do either, it’s going to be expensive. If you don’t know the technology available in your market, you buy that knowledge through consultants, etc., so that the things you’re working with work together.

Mistake #9: Selecting a software development team without high-level strategy.

If a company lacks UX development capability, they sometimes select subcontractors as a stopgap solution. However, if the team is suboptimally constructed, things quickly go south. Time-to-market issues arise as soon as your team has to rewrite and/or rearchitect mistakes that stem from a disjointed team.

The problem is not just your development framework, nor your software developer. There are many things to consider as well in your solution and application architecture, some of which are described above. When all these things add up, the implications of any issues usually result in time-to-market cost, total cost of ownership and engineering cost.

Area 3: Usability and User Experience (UX)

Mistake #10: Filling the need for features instead of filling the needs of the user.

I hate to say it, but the average user experience with embedded devices is poor. The user experience often looks as if developers create the UI based on (and in order of) the list of features they needed to implement (see Figure 4). The focus is too heavily on fulfilling the needed feature list, and somewhere along the process the end user is forgotten, or is not even considered. Worse yet, perhaps the end user was not even on the original list?

click for larger image

Figure 4: UIs built in order of the list of features do not translate to high-quality user experiences (Source: The Qt Company).

For those of us who have an engineering mind, the user experience may seem totally logical. However, for the end user, a grandmother for example, it may be impossible to comprehend. Developers take the approach of “what is it that I want to achieve,” which doesn’t always align with how the technology will be used.

To combat this, bring in your human designers early on to the project. If you do not have one, invest in professional services, and your investment will pay back in sales. What is the user problem you are in fact solving? Is each feature used as frequently as the others? Good tools don’t guarantee a good user experience, they just enable it. To further help in this area, Qt, for one, has invested a lot into improving and enhancing the designer and developer joint workflow on a project.

Continue reading on page two >>


 

< Previous
Page 1 of 2
Next >

Loading comments...