Adapting Embedded GUIs to Meet Increased UX Expectations

Hello Everyone and thanks for joining,
My name is Gilles Hendrikx and I’m Product manager at Logic Technology.

We help engineers create great products and to lower their development risk. We do this with a wide variety of tools and hardware.

Today we would like to share some of the challenges that our customers have faced when developing their UI product.

With me today, from Crank Software, is Garry Clarkson;
“Last couple of years we have worked together with customers in many different markets and there are some common challenges that we see very often.

The User experience is key.  Customers are so used to smartphones and the smooth look and feel these high end devices deliver that this have become the norm for all UI products. With evolving products and growing feature sets this might lead to upgrading your hardware sooner than you anticipated at the start.
A different hardware challenge is that within a product family or a product ecosystem, a wide variety of hardware is being used, which is often developed by the same R&D team.

Within these R&D teams, product development happens on different levels at the same time. Graphic designers and Marketing are working on the look of the UI, UI/UX specialist are figuring out how everything should feel and off course Hardware and software engineers are making sure everything works accordingly.”

Garry can you please tell us more about how these challenges have affected some of the projects we did?

Our customers have told us the following issues - embedded GUI is hard!:

• Lots of products in range - every device has different hardware so different design tools = No Scalability
• Point of sale installations in retail with customer specific branding and advertising - hard to manage the change = No Reusability
• Managing translations and localization - we have Storyboard tools for this too!
• Collaboration - external agency for design, another for prototyping then bring in-house for full product development

Do you remember the time when we received an entire UI design in PDF? 

Oh, yes; our customer had to:

• Hand code the UI and translate pixel by pixel
• Every change went through all the coding and testing steps again
• It took them a long time to change stuff
• tTey had to compromise the end product.

What do we have to change and what does this mean for the R&D team?

Well, Traditionally the process is very involved as every design code change is a software code change. It is inefficient and leads to compromised UX and UX features can get lost in the translation from designer to engineer. The designer needs to ensure their GUI design can be realized with the actual software and hardware resources available

How exactly do you solve this?

By decoupling of the front-end UI from the back-end logic. The designer and developer can work in parallel to build the Design first and use this information to deploy to prototypes quickly. With this you can also profile the performance for proper hardware selection. This way you can evaluate a hardware shortlist side by side and select the best cost-price to performance. By decoupling front-end from back-end, it is easier to design, test, tune, iterate and deploy very quickly.

So, the big profits of this approach are:

• Designers use high productivity design tools to create exactly the design that they want
• No fixed and limited sets of standard widgets to limit your creativity
  • differentiate the UX with animations and total design freedom
  • not barriers to creativity
• Designers drive the UX by design and prototype on the desktop using the Storyboard simulation to refine - not software engineers

[Gilles] Can you show us how this works in practice?