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:
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:
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:
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:
Recommended by LinkedIn
“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:
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:
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:
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:
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.
Nice article
Glad you liked the article Roberta Varela 😀
Well written! 👏🏻 IMO, keeping a solution centric approach over a feature/ product centric approach is what separates GREAT stuff from GOOD stuff.