OutSystems released a new version of our integrated development environment (IDE), Service Studio, at the end of July 2021. Before the release, we 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.

We will kick off this series with an article by our Head of UX, Gonçalo Veiga, on how OutSystems established its UX practice in the Product area.

OutSystems has always had a strong focus on user experience. On my first day at the company, 15 years ago, Tiago Simões spent the whole time sitting behind me, watching me use the product. In fact, he was the first UXer I came across in my career.

However, our UX focus relied for too long on hero efforts and failed to create a UX structure for scale. With the accelerated growth of our Engineering group, we really needed to step up our game. This was when, about five years ago, I was challenged to drive the UX area to become a powerful force in the Product organization. 

Growing a UX practice hasn’t been a linear process, but there is some science to it as well as many lessons learned. This is the story of how we grew the UX Team at OutSystems Product from five to more than 50 people in five years.

Join us for the ride!

Year 1 — Getting Started

Our starting point was far from ideal: a small team with much to prove and a huge product to cover. An important factor that did not help was the complexity of the OutSystems domain (our product is targeted at developers and other similar profiles), so designers without development skills struggled to develop the trust from the teams, and we suffered from turnover.

So we tried a new approach to address our challenging domain: a multi-disciplinary team of UXers with a background in development and design that would work closely to create pragmatic and impactful solutions.

This was just one of our experiments that worked well. I’ll present these lessons learned in some “battle cards” so that you can replicate and adapt when building a UX practice within your own organization.

We also learned that some places are not the place to start.

Where Not to Start

  • Don’t start by creating product personas. This is a standard procedure in the UX world, but it didn’t align with our team’s immediate needs. Personas require significant research and socialization to fulfill their purpose adequately and, in our case, came to play a larger role as we matured.
  • Don’t do extensive research. When you’re starting, it’s very easy to do research that doesn’t matter or has little impact. Because we don’t have the focus time and don’t understand the whole problem, the “good stuff” often falls between the cracks.
  • Don’t create “ivory tower” designs. Translation: working alone to produce intricate designs that aren’t feasible or relevant. You’ll only lose credibility.

When you’re working with a mature product, as we do at OutSystems, there’s a vast scope, which is precisely why you have to start with the now — the product under development. The most effective thing to do is focus on these current goals and forget about the past — too much to handle — and don’t look too much into the future because you won’t influence it just yet.

What to Do

Focus on doing less but with a more significant impact. By centering our small team, working actively with the teams and stakeholders, and pushing for pragmatic solutions, we were able to get recognition. People clearly noticed the difference in outcomes between the projects where we were involved and where we were not.

  • Focus on fewer projects. By focusing on only some initiatives, you can have the most impact and achieve an in-depth understanding to reach good solutions.
  • Keep pragmatism high. Focus on actions that will create the best insights and results. Don’t overdo it.
  • Collaborate at large. Stay with your team and collaborate actively to improve the designs.

Perhaps the main lesson as you’re growing a small team is just saying “no.” I know this is really hard, and I still tend to be overly helpful, but refusing some tasks will create the exact amount of necessary pain in the areas that require UX intervention. And, trust me, that can be a good thing.

As that pain escalates and becomes an issue, it creates a better understanding within the org about the need for more UX, better processes, a clearer vision of why the design of the products matters. The fact that we’re saying “no” helps the development of the UX practice — it may not seem like a good idea in the short term, but it will help you immensely in the long run.

It’s also a powerful tool. Whenever you say “no,” you bring more focus to your team, allowing them to develop projects fully. You go up in the value chain and really understand the problem you’re trying to solve. By having the time to continuously question what the user needs are and your starting point, you will find a better solution.

Year 2 — Growing Your UX Practice

Kicking off year two, our top challenges were:

  1. A growing number of requests for a small team.
  2. Onboarding the new hires to answer that demand.
  3. Covering everything the OutSystems team was building.

As we struggled to answer requests and needed instant capacity, we looked for UX enthusiasts within the development teams themselves. This is how the Experience Owner (XO) program was born. We turned developers, identified as enthusiasts, into UX champions by involving them in our activities and providing specific training. With this, we brought further enthusiasm and understanding about the area, which proved fruitful.

 

In the meantime, we perfected our very own version of the design process. The process of figuring out what works for us was absolutely fantastic because it revolved around culture — it gave us some soul. We encouraged the team to write articles on thought-leadership (in which we talked about Defining the Experience System: Going Beyond Design Systems; dove in the OutSystems UI; and reinforced that It Takes a Product Design Team to Build a Product Users Will Love), and we created stickers and t-shirts — this is all part of becoming an exciting team within the company, with an identity of its own.

Some of those XOs eventually became product designers. And good ones. The fact that they were not designers in the first place didn’t mean they couldn’t become UXers. In fact, while some may not have been the most visual people, they mastered other critical skills to build a great user experience in our space, like research, facilitation, or conceptual design.

When you’re bringing on new people, don’t underestimate the value of adequate training — you need to help them develop proficiency, supported by a relevant, pragmatic knowledge base. Having your processes and techniques documented and building a continuous improvement culture pays off.

 

On this front, size also matters: start building the culture before the team expands. Don’t wait until you have an enormous group of people to define the culture. As UXers, we tend to be visual and creative, so let’s share the good work and celebrate these special skills.

What to Do

Summing it up, when you’re facing the same growing pains as we did, these are the battle cards you can use:

 
  • Convert non-designers into UXers. You don’t have to be a designer to be a UXer, and we built a program that succeeded in proving just that. They won’t be completely autonomous, but it is key to tackle complex domains.
  • Invest in the documentation.As we’re luring more people to the wonders of UX, having up-to-date documentation comprising processes and techniques is a time-saver, among other benefits.
  • Develop the culture. Create enthusiasm and foster interest by sharing and teaching people right from the start.

By the end of year two, we had some serious “money in the bank” that allowed us to further evolve our practice foundations.

Year 3 — Increasing Impact

At the start of year three, while we had established our reputation, processes, and culture, we still faced three main challenges:

  1. We were still very much reactive instead of proactive. We were not as impactful as we could be.
  2. Our UX foundations were still weak. We had defined a few techniques and processes but didn’t know what the product should actually be and feel like.
  3. Our designers still relied too much on a central structure and their own ingenuity to address challenges.

Again we picked up momentum from the company, as it pushed to provide more autonomy to teams as we scaled. We leveraged this movement to embed our product designers in the teams. But this time, with a strong practice behind it, which ensured our designers were not relegated to lesser roles.

Not less importantly, we took a stand to ensure we’d remain a strong practice. We ensured the group spent 10% of their time focusing on our practice and shared product. This means we were coming together, sharing work and practices, insights, and achievements. This was key.

Although we’re spread apart, we must continue working closely. Time spent together helps the team share their values and enthusiasm — this is the main source of a good user experience, as it brings the group closer and “glues” the experience as a cohesive whole for our users.

To further empower UXers, we also greatly evolved our skillset and UX foundations. We established our design and UX writing system, defined design principles and personas. Pushed for further UX research to further support and accelerate our design.

We also adopted a set of operating models — a core practice at OutSystems. We use these models to help the team figure out what kind of product you should design in a mostly autonomous way. As the British statistician George E. P. Box once said: “All models are wrong, but some are useful.” Indeed.

What to Do

These were our battle cards for this very prolific — yet challenging — year. Feel free to play them:


  1. You need to leverage the momentum within your company. Sometimes, you push as hard as you can, and you don’t get anywhere. Then, things start to happen within the organization, and it’s time to go all in. Pick your timings wisely.
  2. Be part of the team. Embed product designers in product teams for maximum influence and impact.
  3. Keep a strong core practice. Again, none of this will work if we lose ourselves in the process, and UXers are scattered among teams. You need to grow and develop as a practice with the help of carefully planned time together.

Year 4 — Owning the Whole Product

With the current developing product covered, we started looking into the next playing field — our heavy past.

This is, in fact, the moment when you can start looking into the past — in our case, we had to face 20 years of legacy and, yes, own it. For us, it all started as the organization picked up on an industry term: friction. We had to provide frictionless experiences to our customers, and again, this was a perfect opportunity provided by our org, as talking about friction is the ideal excuse to communicate user experience.

We gave friction a clear meaning that everybody could understand by building pragmatic methods to measure it and communicate it to our stakeholders. While usability expert Jared Spool says there’s not really a grand unified metric for UX, we found ours.

Whenever a user is aiming at a particular outcome while using your product and finds a bump in the road during their journey, that’s called friction. We also implemented a way to quantify the severity and impact of those bumps, and suddenly we had something to communicate experience issues quantifiably. This worked wonders, as it was a lot more specific than indirect subjective measures.

What to Do

In sum, this was our second winning hand of battle cards by the end of year four that summarize our lessons learned:

  • Don’t tell stakeholders how the experience is — show them. We did that by presenting the friction in our user journeys.
  • Carry on leveraging momentum for your team. Find opportunities within your org and ride those waves.
  • Adapt to your organization. People do not care about UX lingo; you need to speak the language of the company.

Year 5 — Pushing Future Visions

We’ve made it, year five! What a journey so far, right? With the house in order, it was time to look ahead and start leading more.

Coming into this year, these were our main challenges:

  1. We were still at a “good enough” level.
  2. We weren’t inspiring the organization to build a better product.
  3. Where was the radical innovation? We didn’t find it, and we needed to push forward.

We had to start envisioning what the OutSystems product should become and creating inspiring UX visions to go with it.

As we’re looking forward, one important lesson is to innovate at the edges. The innovation labs and ivory tower designs don’t really work, in our experience. What works is when you get influential people who understand problems and can come up with interesting solutions. These are researchers, thinkers, and makers — if you give them time, they invent amazing things.

That is what we’ve done to push the product. We got people to focus on a specific product problem for a couple of months, collaborate, and then find a solution. This is how we’ve been influencing the OutSystems roadmap.

What to Do

These were our battle cards for year five. To push your org further, this is what you can do:

  • Generative research. Stay ahead of what you need to know and identify the questions you need to answer in strong alignment with the company.
  • Design UX visions. Develop the ability to create these inspiring visions. Leverage deep user, product, and business understanding and business sense to create compelling visions for the future by leveraging our unique design skills.
  • Innovate at the edges. Relieve a team member from their daily tasks, and focus that person or people on a particular task or product. Some excellent solutions can come from this and will inspire the company to follow suit.

After five years, what did we gain from these efforts? We’re now at a great place in our product org. We’re co-leading the product, along with project management and development.

This is how UX became a force to be reckoned with at OutSystems. For a few more insider stories on this topic, check out the Winter Talk I gave earlier this year at Lisbon’s Interaction Design Foundation. We hope this can help you along with your own UX development.

But, hey, we still need more hands, hearts, and minds to keep pushing towards our vision. If you think you’re up to the task, join us.

OutSystems Engineering has a lot of interesting things to say! Be part of our conversation on Twitter or Facebook, or check out our job opportunities here.

Want OutSystems Engineering blogs delivered to your inbox? Click the Subscribe box below.