Lessons Learned from Working With UX/UI in Engineering
https://www.altair.com/resource/improving-perceived-quality-at-cevt-new-body-evaluation-method-enables-squeak-rattle-prevention

Lessons Learned from Working With UX/UI in Engineering

After reading a very insightful article about User Experience, reposted by my colleague Dario Dorella this week, I am sharing some of my lessons learned from it after working with various customers to develop custom Engineering applications for them.

Lesson 1: UX ≠ UI

While User Interface refers to the area where interactions between the customer and the product happens, User Experience is a psychological impression while interacting with that product.

Imagine a simple light switch: the user interface is that piece of plastic that is supposed to move up and down to turn the light on/off connected to an electrical circuit, whereas the user experience will help you address the following questions:

  • Does the design of my light switch really work under all conditions? What if I am lazy in my bed and want to turn the light off with my toe?
  • Is my light switch comfortable to use or is its surface too rough?
  • Is my light switch easy to use or does it need a lot of force to turn the light on and off? What if the house where it will be installed has elderly people unable to press it that hard?

No alt text provided for this image

Lesson 2: the UI is not designed for you

Like my grandfather used to say:

“We have 2 ears, but only 1 mouth”

Which means that we should listen more than we talk. Usually in discovery calls to collect requirements from the customer, I have seen that the Application Engineer has prepared a tedious 50-slide deck to be presented, and sometimes s/he reaches the end of the meeting with the customer saying that this is not what s/he is looking for, causing:

  • A waste of time of the Application Engineer
  • A waste of time of the customer
  • A potential bad (first) impression

No alt text provided for this image

From the customer’s perspective, their goal is to assess if we can understand the details of their use case, so before going through a boring slide deck, let the customer speak about the requirements that will ultimately help the User Experience that you want to provide:

  • Their current process – what is the objective, what drives the decision-making?
  • Their needs – what is missing, what could be better?
  • Their pain points – what is slowing down the productivity, what is error-prone?

Lesson 3: exceed the expectations

After taking into account the previous lesson for the most basic requirements that have been agreed with the customer, now it is time to think like Steve Jobs:

“Some people say, "Give the customers what they want." But that's not my approach. Our job is to figure out what they're going to want before they do. I think Henry Ford once said, "If I'd asked customers what they wanted, they would have told me, 'A faster horse!'" People don't know what they want until you show it to them.”

In other words, customers sometimes do not know how to articulate what they need. Using the light switch example for a house of elderly people: instead of simply listening that they want “a light switch to turn the light on/off”, spend a few hours with them to understand their habits and limitations to come up with clever ideas for the User Experience based on your observations.

Anticipating mistakes is also a very important component that will foster a feeling of confidence that you designed something robust and reliable. From my experience working with customers like Stellantis, Northrop Grumman and CEVT, it was always helpful to think beyond and consider corner cases such as:

  • What if the file input is not well-behaved and delimited as expected?
  • What if the user gives a word in a certain field that expects numerical data?
  • What if the user tries to write an output in a read-only folder?

Lesson 4: less is more

With an ever-decreasingly focus, it is needless to say that the number of mouse clicks should be reduced, as well as the amount of visual information that is present in the UI.

Play with the size and the position of widgets to seamlessly guide the User Experience and create an intuitive flow, taking into account basic factors such as:

  • Text in most languages is read from left to right, hence headers should come before the user inputs
  • Buttons should be big enough to easily see and click
  • Buttons with most important actions should be more prominent than others

Lesson 5: be ready to expand your UI

While creating a UI, it is important to keep in mind that the extent of the workflow desired by the customer may grow – at least based on my own experience, this has always been a good sign that the customer is actively using what has been developed and is willing to wrap more tasks around that UI. Here, the keyword to be considered while designing your UI is modularity, in order to facilitate:

  • Maintainability
  • Extensibility
  • Reduction of duplication of functionalities

This immensely helps not only the developer's life, who will focus practically only on the new features without worrying about how it affects the rest of the code, but also the user's life, with a reduced chance of finding bugs and diminishing the trust in the solution.

Lesson 6: sell yourself first

Speaking of trust... When the customer builds trust in you as a technical liaison and a partner that is seeking for a win-win relation, s/he will not only provide you honest feedback on what has been developed, but this feeling will also serve as a stepping stone to sell the company and then finally sell the product or solution:

No alt text provided for this image

Thanks for reading and please get in touch if you have more insights into this subject!

That's a good article. I think one of the hardest things newer programmers need to tackle is developing good habits in their coding style: 1) Modular Programming (The ability to swap-out a newer version of a function) 2) Document the Source Code 3) Have a plan I used to scoff at the "top-down" approach taught in school, but as applications get bigger, the need for it gets ever more important. In school, one can count on fingers the number of functions/subroutines needed for a class project, but in industry, a real application will have dozens to thousands of functions and subroutines. I was surprised at how much was needed for a simple Viscosity Fitting tool. Programming for UI/UX is quite complicated if you don't have a plan. It reminds me of an old saying... 千里の道も一歩から。 百里の道も地図から。 A thousand mile journey is traveled in single steps. A one-hundred mile journey is traveled by the map.

Well written! 👏🏻 IMO, keeping a solution centric approach over a feature/ product centric approach is what separates GREAT stuff from GOOD stuff.

To view or add a comment, sign in

More articles by Roberta Varela

Others also viewed

Explore content categories