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

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


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 >>

As a development framework, Qt can be used to create amazingly intuitive, cool and fluent UX. However, it’s important to note that it is equally easy to create a horrible UX. When it comes to designing for human interaction, companies often rely on three to four engineers to figure it out. However, these engineers often base usability on business requirements that are defined within a vertical format. The outcome often results horribly. If the UX design is left to developers, they are great for developing the UX but not for designing human interfaces. Human design is also not something you solve through tools alone. As mentioned before, tools enable both the good and the bad, helping you get there more quickly and efficiently.

Area 4: Other issues

Mistake #11: Underestimating the effort for a BSP, OS, toolchain and all related bells and whistles.

If you don’t know what you’re doing, ask for help. When creating an OS, developers often underestimate the amount of time they must spend on hardware drivers, operating systems, tools/toolchain and integration with working processes. If you do any of those things manually on your own, it’s very easy to underestimate the time you put into that. If you ask the community or those who are in the know, they may say it’s a three-day job. However, in reality even skilled developers underestimate time spent to get things working. The project start time is then delayed. Maintenance becomes a problem, etc.

Qt, for example, offers premade reference environments with all the bells and whistles included. When you buy a solution with all the hardships covered, you will not see the underlying problems.

Mistake #12: Treating embedded systems the same as PC systems.

An embedded system is alien to PC, and PC looks alien to embedded system. When developing on PC, developers must always consider if they’re still able to deploy to embedded. Making two systems alien to each other work together – that’s the hard part. Then multiply that by number of developers, software code lines, release and version management, etc.

Cross-compilation environment and ready-made embedded tooling is the magic bullet here. With over 20 years of experience in making these two disparate systems work together, Qt has seen its fair share of challenges in cross-compilation, along with the various solutions to make it work.


While it may seem like there is a minefield of mistakes to avoid when creating cross-platform UIs, it is still very possible to create immersive, intuitive user experiences for your end users. Approach your software engineering projects with clear, high-level strategy and planning. Understand the full scope of work that cross-platform UI creation entails. Ensure your final UI product resonates with your end-user. Ensure you have the right tools and competencies at your disposal. Following those four key steps will set you up for success in not only creating stellar user experiences but also driving business revenue and goals.

Santtu Ahonen  works in The Qt Company as product manager of the Qt for Device Creation. Santtu has over 20 years of experience in product management on various high technology products including Nokia Maemo as Head of Developer Offering Product Management where Qt was essential part of the plan. Santtu joined back in to Qt technology and The Qt Company in spring 2017.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.