Building a UX Culture at OutSystems — A Talk With UX/UI Team Lead, Andreia Mesquita
OutSystems released a new version of our integrated development environment (IDE), Service Studio, at the end of July 2021. Before the release, we’ve shared a month of content on how our User Experience (UX)/ User Interface (UI) Team tackled this project while building and implementing their very own Product Design System to create a delightful experience for all users.
As part of this series, we showed you how we grew our UX practice, explained how we used data to elevate our product’s look and feel, and spoke to our UX/UI Team about design systems in general and the one they helped create at OutSystems.
Here, we talk to the UX/UI Team Lead, Andreia Mesquita, about how OutSystems built its UX culture.
A designer by heart, Andreia Mesquita believes that the most important feature of a UXer is empathy. Torn between science and art — she grew up in a creative home where tech and paintings were always around — she chose both. After a stint in architecture, she completed a degree in Design Communication and then a master’s in Human-Computer Interaction (where she was distinguished as a top student) because she wanted to be “closer to people.”
Unsurprisingly, she is a firm believer that teamwork can go a long way. Also unsurprising — at least for a sports and design aficionado who enjoys running and watching F1 races — is her dream of owning a Lamborghini Miura. And while Andreia is a metal music fan, due to recent life events, the next concert she will attend is most likely the Panda Festival.
As a UXer, her ability to put herself in the user’s shoes has earned her several design awards and a fulfilling career: from generative art, managing UX teams, and working with IoT to designing the interface for the dispatch center of one of the largest renewable energy companies in Europe and the US, she’s done a bit of everything before coming to OutSystems.
Since joining the organization, she has been working with the UX group to unleash its full potential. In this interview, she talks about building a UX culture, achieving UX maturity, and what’s still left to do once you get there.
What defines a good user experience?
UX design — and this is a sort of mantra — is a way of solving problems in an interdisciplinary, holistic, and targeted manner. It aims to achieve a deep understanding of human beings by diving into their behaviors, cognitive processes, and wishes.
To tap into this, we look at UX work according to three vectors. Think of it as a pyramid: at the bottom, there’s usefulness: we want to understand if that piece of software or tool will solve the user’s problems and pains.
In the middle, you have usability. Is this easy to use? Can I use it? Often, engineering is obsessed with delivering features, but when these features reach users, they can’t make sense of them or even use them. It’s like trying to kill a fly with a cannonball. You need a middle ground, you need to make it usable.
Finally, at the top, we have delight. How can we make people use or return to the OutSystems platform and tools while building engagement and a product they love? Delight is about people missing a product when it’s not available — and that is where we want to be, to achieve that quality. I strongly recommend to everyone interested in learning more about their consumer or user needs books like Emotional Design, by Don Norman, or for a deep dive, António Damásio’s The Stranger Order of Things.
“Traditionally, a product designer at OutSystems has a background in Computer Science or programming experience and has worked with OutSystems or other programming languages”
How did we evolve into having separate UX/UI and UX Research Teams?
When I joined OutSystems a little more than two years ago, Gonçalo Veiga [Head of UX] and I decided to launch those two teams. We realized that to jump from the middle of the UX pyramid to the top, we had to “clean up” our features’ user experience and assess what users really needed. So, we did some fieldwork. We launched several initiatives to get a bigger picture of what we had at that moment, the value we were providing to users, and what we still needed to do. And for that, we had to build a UX Research Team.
Then, to achieve a delightful product, we aim at one of Paulo Rosado’s [the OutSystems CEO] mottos, which is lowering the complexity level of our platform so that everybody can use it. We need to simplify our features and only build those that are necessary. On top of that, there’s the interaction layer, which must be pleasant, delightful. And that’s only possible thanks to the UX/UI Team, which brings the foundations of good UX practices to the table. How? We have to study the best UX practices out there and add top-notch interactions to the product by doing research, user tests, those kinds of tasks, and everything related to accessibility.
For example, we’d never done visual impairment tests before to assess if the colors we use in our icons and fonts are suited to those with visual problems. We are now set on improving their experience.
Did you have to change the ways teams work due to the Product Design System, or was it the other way around?
When we decided to revamp the product’s look and feel leading up to the release of our new IDE, we realized we lacked a framework to help us collaborate as a team and connect all the team’s elements. That’s when we decided to launch our Product Design System. This system provides guidelines on how to build the interface — there are modules, snippets of code, and widgets available that have been validated from a usability and accessibility standpoint. So, as a designer or developer, I can use the Product Design System to quickly build a more uniform product.
It’s a way of accelerating the production process while also making it cheaper because developers don’t need to worry about building a codebase, and designers don’t have to solve problems they figured out before.
However, that delight layer is like a chef’s work: everybody can follow a recipe, but your cooking experience and creative flair will dictate the result. The system only accelerates the process: everybody can take the Product Design System elements, assemble them, build a structure, but then we have to add a layer of delight and engagement.
Following your chef analogy, too many cooks spoil the broth. How do you organize teams to define who does what?
When talking to Veiga the other day, he shared that we’re probably one of the largest UX groups working in the Iberian Peninsula. To work seamlessly, we had to adopt a methodology revolving around the Product Design System.
At the moment, we have several UX teams working together to achieve a better user experience. Product designers have a different role at OutSystems, so this is slightly difficult to explain to the outside world [laughs]. Traditionally, a product designer at OutSystems has a background in Computer Science or programming experience and has worked with OutSystems or other programming languages. They can understand developer needs and translate that understanding into the user experience, so we spread them among different Product teams.
Then we have more traditional UX roles, such as research, in which teams assess the user needs and conflate them with our own business goals. Basically, they build a bridge between what we already have and what we think the future will be.
The UX/UI Team will also help validate the information coming from the Research Team by testing, covering the UX basis, and adding the final delight layer to build a visually consistent product.
Finally, the Product Content Team creates suitable messages and descriptions according to the voice and tone of the product, in a way that supports the experience of our users. These teams work together, using the Product Design System as a foundation while sharing other tools and work areas. For example, the UX writing guidelines: we all use them. It does not mean that everybody excels at UX writing, but everybody has guidelines that they can follow to write a simple message without compromising the user experience.
“That is exactly what we want: we allow and encourage people to switch teams depending on their wishes and the company’s needs”
How do you maintain the OutSystems motto of having autonomous teams?
First, we accommodate people according to their background and skills — essentially, what they feel most comfortable doing. They can switch teams as they grow within the company. A good example is Natalia [Alves, a Product Designer].
She worked in the UX/UI Team and moved to product design because she wanted to focus more on the technical side and learn the meanders of Service Studio.
Still, what’s interesting is that precisely because she has a UX/UI background, she provides us with feedback while building and interacting with Service Studio. She says, “Maybe we should review this flow to make it more usable” or “Maybe this command should be easier to use for developers.”
You can’t keep the UX voice in your head quiet. Even when you do move to a more technical area, you take that voice with you. And that is exactly what we want: we allow and encourage people to switch teams depending on their wishes and the company’s needs.
It’s almost like you’re working undercover. People move to strategic product areas but take their UX knowledge with them.
That’s exactly what we want [laughs]. It’s not our primary goal, but it does happen, and that’s great. We’re evangelizing developers, product owners, and product managers by spending time with them daily.
Our UXers are spread among all our teams in the core areas of our product. These UXers can leverage the quality and consistency of our product by applying UX methods to improve the overall user experience. All UXers — UX researchers, UX/UI designers, UX writers, and product designers — are allocated to projects in a different way. They can be immersed in a team full-time or join teams for a particular activity. Still, all of us are aware of the development lifecycle, and we apply it to our UX process.
“What’s most rewarding is that the team is so proud of their work that they act as UX evangelists outside the company”
And then you have particular cases in which they enter the “UX warzone”: they go in, do what they need to do, and leave. We avoid these in-and-out interventions at all costs because there is not enough context. The team who’s receiving the UX information won’t have enough time to digest it, and the UXer won’t bring us much feedback because they’ll learn little about that team and their work.
So, we try to keep UXers allocated to different teams 100% of their time or working on particular projects. As they evolve, they will eventually become specialists in those areas or groups. This is why we empower these people to work autonomously and provide them with as much training as possible and encourage them to attend conferences, webinars, and other events so that they really raise their UX level and gain technical skills.
What’s most rewarding is that they are so proud of their work that they act as UX evangelists outside the company. They are pleased to talk about their work and show off our swag. And our goal is to have individual contributors become leaders. We don’t work in a fenced structure: if they become specialists in a given area and that area gains relevance within the product org, we believe they should become team leads in that particular field, as well as managing, training, and guiding others to do the same.
You mentioned research as a bridge between UX and the business side. How does that work?
UX design is not about aesthetics or prettifying your product. We decided to prove this by building a solid practice and bringing metrics to the equation. For instance, we can tell how many times OutSystemers used our Product Design System elements because that translates into money saved and fewer developer hours.
Through research and metrics, we can anticipate and measure the consequences of our actions. The addition of a dark mode in our new IDE is one of those cases. We listened to our community of users and they asked — actually, demanded — a dark mode. We worked with our stakeholders and the business side to evaluate if and when we could achieve it.
We spoke to numerous users, interpreted the facts from the field, and decided to add a dark theme. It’s always a mix of user needs, business goals, and excellent UX practices.
You often use storytelling to get user needs across to the rest of the org. Why?
Storytelling is one of the most effective ways of communicating. We’ve been doing it as humans ever since we slept around a campfire. At OutSystems, when product managers or product owners can’t attend a usability test, we need to tell them our users’ stories. That is something we’re working on as a team and wish to improve further.
Storytelling helps “sell” the users’ pains by bringing stakeholders to the field in some way. While they’re not there, they can understand user needs by reading user quotes or watching a quick video illustrating their issues. They realize user struggles and relate to them. They become more sensitive to user problems.
We need to understand our audience when telling these stories: if we’re dealing with a more emotional person, we can show them the user pains. If we’re dealing with more feature-oriented people, we need to bring more data to the table to show that that specific feature is inefficient.
But one thing is sure: we always need to do user research before, have a compelling, structured story to get those pains points across, reach our target audience using well-known company terms (we can’t use UX jargon), and actually do our work, which is to put ourselves in the users’ shoes.
“Anybody with empathy in their hearts can work in the UX field”
As a team, how would you describe your modus operandi?
Very often, UX teams in other companies embrace a waterfall working process. We established an iterative process: all areas have a seat at the table, with the same level of importance, and are involved in the projects from day one.
We are trying to include writers in the initial stages of product development, which makes perfect sense to us. So, we have research, prototyping with Figma, and by then, we add someone from the Product Content Team to the process.
This person will immediately influence the design by saying, “We need to adjust the layout; there’s no space here for the message we need to write.” That means we can spot potential issues early on. And the same goes for the UX/UI Team; we instantly realize that there’s a missing component, turn to our Product Design System to insert a previously designed solution, and customize it accordingly to that product or feature. By doing this, we save time and increase efficiency.
Can anybody be a UXer? Do you need to have a specific background?
Anybody with empathy in their hearts can work in the UX field. This is actually true because our main goal is to think about what users want and need and what’s best for them. Our UX group has the following mission: “Create a product users will love.” If you do have this emotional ability to read people, then all you need is hard skills — and you can learn those. Then, it’s a matter of applying those hard skills to a specific UX area, whether it’s code, UX research, UX/UI, or writing.
But you definitely don’t have to come from a design background to work on UX. There is always a way of adapting your core training and the insights you can bring to a team. I once worked with a UXer who had trained to be a nurse!
“We need to look at accessibility as a means for inclusion and embrace developers or designers with disabilities”
How do you onboard people from such different backgrounds?
Our onboarding process is critical. Mainly because we are a big team, and working at OutSystems can be challenging at first due to the complexity of our product.
We are constantly evolving the onboarding process, but we’re now setting aside at least one week in which people move around teams and learn more about other areas. If you work for the UX/UI Team, your onboarding will not be limited to your team. It’s not so much about people’s background and experience because we are sure they know the best UX practices. It’s more about giving them the right tools to start working.
We also set one day aside to present what they’ve been up to on each UX practice. It’s a lesson on where you can find stuff on Confluence, how our design system works, how the organization of Figma files works. And then we have go-to people in charge for each area. This way, people know who does what and can reach out if they have questions.
We invest a lot in onboarding so that everybody, regardless of their work, understands that we don’t work in isolation and will always rely on other UX practices. And also to realize that there’s no hierarchy — there is no higher practice, they all have a seat at the table. Otherwise, projects would be incomplete.
In your opinion, now that the team has reached UX maturity, what are the next steps? How can the group evolve further?
We’re already integrated into other teams in terms of UX maturity, and our practice is seen as fundamental, impacting product development. But there’s more to do. If you talk to people within the UX group, everybody will say that accessibility is crucial, but very few master it. I’d like to see effective mastery over small accessibility details, which aren’t small in any way.
We have more and more people with visual impairments or motor disorders and older people using technology. We need to look at accessibility as a means for inclusion and embrace developers or designers with disabilities.
How can we include people with special needs in programming? Will we start programming using our voice and gestures? What will the future bring for this field? Will programmers still use their mouse and keyboard? I don’t think so. Will they use their hands, augmented reality or virtual reality? We need to start looking at this and figure out how we can be ahead of the curve. We need to think about programming with sounds and building a design system for these new ways of programming.
Originally published at https://www.outsystems.com.
