OutSystems will soon release a new version of our integrated development environment (IDE), Service Studio. In the meantime, we'll share a month of content on how our UX / 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 built our UX practice. Now, we explain how our data-driven mission to improve the look and feel of our products culminated with the creation of our Product Design System.


The aesthetics of a product influences not only if people are drawn to it but also how pleasurable and easy it feels to use. So, although good looks can’t save a lousy product, given humans are primarily visual beings, it’s no surprise that aesthetically pleasing design and usability walk hand in hand.

Nevertheless, the visuals of a product are often its most prickly side, and software is no exception. One of the reasons is that you are dealing with people’s subjective taste and perception of what is eye-pleasing.

At OutSystems, we have long focused on usability and function. But when it was time to address the look and feel of our product, we came across some challenges. How do we measure how beautiful an interface is? How do people perceive how the product looks, form their expectations, and draw assumptions from it? Could we obtain answers that would apply to our particular users? And could we do it before implementing a whole redesign?

In sum...

How Can You Know What You Don’t Know?

First, you need to collect facts to make informed decisions. But in this case, the facts got to us first. Field complaints about the old-fashioned look of our product were increasingly louder in tone. To get to the root of it, we interviewed our sales architects, who confirmed such perceptions, especially in the US and UK.

In the US, it's hard to get developers and new hires because people perceive our product as outdated

So, we set out to define the product’s future look and feel and inspire the organization on this evolution. The Product Visual Sophistication initiative was born! Its goal: to remove the customers’ resistance to buying and adopting OutSystems due to its visual impact (or lack thereof).

By now, it should be evident that OutSystems is a data-driven company. No project starts, and no developers are assigned unless we have data proving their time will be well invested. But how can you quantify data points, such as:

We have to work hard to get our foot in the door. It's like dating: you won't even approach someone who doesn't look attractive or nobody will tell you your baby is ugly

It’s tough to get data that shows that the visual aspect of the product is negatively impacting sales, but we also can’t say it helps us sell. This applies not only to the first sale but also to prolonging subscriptions. The insight behind this is pretty straightforward: people think that the same UI equals the same features. By not changing the UI, we were leading people to believe that our product wasn’t evolving.

In the US, it's hard to get developers and new hires because people perceive our product as outdated

It’s also incredibly challenging to gather feedback regarding the visual aspect of the product because:

  • Prospects don’t share such feedback openly, often due to cultural reasons (politeness).
  • We seek visceral reactions (first impressions that last a short time) to avoid rationalized feedback biased by the other experience aspects, including ease of use, navigation, organization of the information, language concepts, ease of learning, available features, etc.

In short, users can’t tell the difference between the look and feel and the usability. For them, these are hard to evaluate separately.

Thus, the Product Visual Sophistication initiative would focus on revamping the entire product’s look and feel, turning it into something globally perceived as modern, sophisticated, and powerful, thus supporting our sales process and laying the user experience (UX) foundations for our product evolution.

Our main goals were:

  • To ensure the usability of our product beyond look and feel.
  • To develop a new standard for the UI (user interface) of our product’s tools.
  • To respond to our users’ requests — having a light and dark mode.
  • To define a future direction for our product user experience.

Quantifying Beauty and Powerfulness

To achieve these goals, we needed to learn how users perceived our current tools. A renowned company in the user experience field, the Nielsen Norman Group, recommends assessing aesthetics as part of usability testing or using a structured word choice test for evaluating desirability (as established by Microsoft).

However, the first method would be very time-consuming, and we wouldn’t get “statistically significant” numbers (as usability tests aren’t done en masse). The second method would also give us a list of words, and words are not numbers.

So, to start, we asked 20 users to look at a screenshot of a software tool and rate it on a ten-point scale from “ugly and old-fashioned” to “beautiful and modern.”

It was not enough to test our product only, we needed a benchmark — a comparison with other tools. We decided to get ratings on other programs people use every day, for work and more.

Three members of the UX Team working in the OutSystems office 

We used usertesting.com to recruit people with our user profile and then sent them to Qualtrics to do the rating survey. It was a perfect combination because we got numbers and qualitative feedback from the think-aloud technique (we asked them to be brief, but still, each test was about ten minutes, and we had 20 to watch and analyze!).

The data that emerged from the survey confirmed our hypothesis: participants rated our product in the middle of the scale. We wanted to be at the top! We learned which tools were considered beautiful and modern and heard the reasons why. These tools became our benchmark.

Users Speak, You Listen

By listening to users, we realized that people tend to separate how beautiful and powerful an application looks (some may look beautiful but not powerful or vice versa). They consider dark themes more powerful and apt for complex tasks. Light themes help establish the perception of simplicity and being easy to learn and tend to be considered less capable of performing complex tasks.

We also identified a list of main characteristics that make applications look more beautiful and/or powerful and listened to our Community Ideas — they suggested having a dark theme.

These insights guided us when we got down to designing the next version of our product’s UI.

Various quotes from the OutSystems users demanding a dark theme for Service Studio

Design, Test, Learn, Iterate. Rinse and Repeat

Next steps? We designed multiple concepts with light and dark themes. We revamped not only the visual layer but also considered changing the structure of the layout. For example, the tests showed that most developer-facing and prototyping tools have tree navigation on the left.

Due to Jacob’s Law — users spend most of their time on other sites, which means they prefer your site to work the same way as all the other sites they already know — we designed such a version. (Eventually, we did not implement this layout change because it would be too disruptive and technically very costly.)

We did rating tests on every design version, learned from it, iterated, and relaunched it. Once the ratings started to increase, and positive verbal reactions appeared, we knew we started heading in a promising direction. Overall, we made five iterations and tested it with over 300 users.

A graph displaying the work done, with around 300 user tests completed

A graph displaying the improvements in Service Studio. Users said it looked more modern and beautiful, and also more powerful, both in the light and dark themes

Laying the Groundwork

Our data looked good, we had a reasonable indication that the new UI would resonate with the users and achieve its goal, and these starting concepts gave us a clear direction. It was time to dig in, evolve, and lay down the roots of what would become the experience of the OutSystems products. It was time to take a chance and start building a design system.

First things first, we followed the best practices suggested by the experts in the field (Nathan Curtis, Brad Frost, Dan Mall, and others) and began with the meticulous and surprising work of auditing our current main tools.

We identified the system’s core elements, like color, typography, spacing, iconography, and elevation. Our goal was to unify these core elements across our tools and design them to easily and quickly assemble to create any UI/layout/screen.

The new look of some of our elements.

Opportunities Come Before You’re 100% Ready

While we were focused on how we could take the product to the next level of sophistication, new complementary tools started to emerge. OutSystems introduced new ways to assist and accelerate the development process with a few new tools dedicated to solving certain use cases. (Architecture Dashboard, Experience Builder, and Workflow Builder, just to name a few).

Margarida Mendes and Natalia Alves during a presentation in the office

This was a great chance to expand and test all that we’ve been doing. Suddenly, we were not only modernizing the main tool of OutSystems but also preparing the groundwork for an ecosystem of tools.

Even though our Product Design System (that’s how we named it) was at an initial stage and far from stabilized, what we had was the best guide our product teams could have at the time. Instead of dealing with mundane decisions like what button should be used or what color would best suit a particular icon — there, it was already done. Product teams could instead invest time and focus into defining business goals, getting into the users’ heads, or developing new business logic.

A design system serves essentially two purposes: on the one hand, providing a high-quality, consistent and cohesive experience to your customers; on the other hand, clearing the way for those designing the product so that they can come up with new experiences.

Example of OutSystems tools
Same of our tools.

 However, the small task force of three people with sporadic help from a front-end developer was not enough, and the groundwork we set was only the tip of the iceberg. We knew we had to partner with product designers working inside product teams. This was key not only to evangelize and advocate the correct use of the design system and listen to their feedback in the long run but also to facilitate their contribution to the whole.

The team working in the office, sitting at a desk and writing in a whiteboard

Looking back, it was a very rewarding journey. It all started as a mission to evolve the look and feel of our product and then scaled into a Product Design System that is currently used across tools and encouraging collaboration between designers and developers. All the while providing a great experience to our customers.

The new look is presented at the NextStep event

As if this great feeling wasn’t enough, we all got to see our tools presented at NextStep looking like a consistent product and receiving great feedback.

And, just like a product, a design system is permanently evolving. Ours is no different, and we will dig in on more of its elements in the following articles of this series.


The Authors

Pictures, names, and roles of the blog authors