UX engineers add great value to the design process
Takeaways on my experience working with UX engineers and their valuable role in the design process.
For a long time, I found myself wondering what exactly a user experience (UX) engineer does. The term came up a few times during my education, but I’d never met or worked with one. Their role in the design process or when to include them wasn’t clear to me. Luckily, I had the opportunity to work with UX engineers firsthand and learned about their valuable role in the design process and when to include them.
As a user researcher for Watson Knowledge Catalog, my design lead brought to my attention an unusual problem. The condition builder design she’d been working on was also being worked on by another team. Condition builders allow you to create condition statements for actions like creating filters, administering access controls, and making rules. To further complicate things, both teams had different approaches, so they couldn’t easily consolidate their designs. The major difference between the designs was the logic in how conditions were being created: One used prefix notation, and the other infix notation. The key difference being that infix has the operator between operands in the expression whereas prefix has the operator before the operands. Since the teams created two designs with no clear direction on which was best, we decided to get feedback to see how the designs performed through A/B testing. Condition builders are quite intricate, so it was important to test how users interacted with the designs without being confined to the limitations of a Figma prototype. This design would not only be used for data privacy, but would also become a IBM Software component for various products, bringing even more significance to identifying the best design approach.
Before diving in, let me provide some context to how IBM is structured. At IBM, designers are distributed into various product teams. IBM uses a design system, which includes the base components, patterns, and guidelines, as the unified platform for product design and development. The design system provides guidance for the entire company, but sometimes things may be too generic. In this case, the special design task force may work on these assignments for more specific usage, enhancements, or updates. The task force has senior designers that have been appointed to spend 10% of their time working on more specialized components not covered in the Design System. These designers have a deep understanding of IBM’s design patterns, making them well suited to identify what might be missing and propose design solutions.
Our challenge with the two designs presented an opportunity to reach out to UX engineers and create a working prototype. I was excited to have the chance to learn something new and collaborate with UX engineers. It was surprisingly easy to reach out to the team and incorporate UX engineers to assist us on this project.
As Stephane Rodet, a UX engineering manager explained, “As soon as you approach more advanced things like visualizations, micro interactions, [and] responsiveness, you touch very quickly a point where it’s good to do a prototype. It’s a lack of history and habits from the designer, which makes them not think about this.” The designer and I communicated the designs and requirements for the sessions that I had planned to the UX engineers. From there, we checked in regularly to ensure the prototype was made according to our requirements and was working correctly.
During the sessions, each participant received the same scenario to create conditions using the condition builder and interacted with both designs. To balance things, participants were split between using either A or B first. We captured qualitative data throughout the sessions in two ways: First, participants spoke through their thoughts aloud during the session, and afterward, we asked questions and gathered ratings to understand their perspective and preference between the two designs.
The results were unexpected and valuable. We found both the prefix and infix designs weren’t performing, as participants had trouble successfully creating the conditions based on the scenarios. The root issue for both designs was that the relationship between the conditions was not clearly communicated visually. While participants understood the scenario, they weren’t sure how to build the conditions with the correct logic in both designs. Without the fully functional prototype, it wouldn’t have been possible to gather the rich feedback we did or see how users would interact with the designs.
“The biggest takeaway was to have people test the concept and understand if at the end, they achieved, successfully, defining what it is that they were asked to do,” Tomer Maimoni, one of the task force designers, reflected. “The answer was, ‘No,’ and that led us to understand how biased we are towards the design that we’ve been looking at for several months.”
The task force designers were able to use this feedback to iterate on their condition builder design and create one that better visually communicated the relationship between conditions.
Our collaboration across research, design, and UX engineering led to a stronger outcome. I encourage designers and researchers to look for opportunities to work with UX engineers, especially if they haven’t before, to better understand the value firsthand.
UX engineers can help with:
- Domain knowledge and be a technical advisor to the team
- Evaluating the feasibility of something in terms of elements and timeline
- Coding designs to create prototypes
- Designing things like how an attribute moves and reacts in a real environment
- Bridging the gap between designers and developers
I had such a great experience partnering with UX engineers and look forward to my next opportunity to work with them in the future.
Have you or your team worked a UX engineering team in the past? How did it help improve your project outcome? I’d love to hear your experience in the comments!
Linda Martinez is a design researcher at IBM based in San Jose, California. The above article is personal and does not necessarily represent IBM’s positions, strategies, or opinions.
