A Talk About Design Systems — Why We Need Them, Why We Built One
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 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 grew our UX practice and explained how we used data to elevate our product’s look and feel.
In this interview, UX/UI Lead Andreia Mesquita; Design System Team Lead João Guerra; Interaction Design (IxD) Team Lead Margarida Mendes; and Runtime Experience Team Lead Miguel Nicolau talk about design systems in general and go into detail about the one they helped create, run, and evolve at OutSystems.
So, before we get into your work at OutSystems, can you explain what a product design system in general is?
João Guerra (JG): A design system aims to solve the problem of having multiple applications within an organization by creating a design framework that will feed and make all your products more uniform. It’s often described as a starting point, as the foundations of a building, in the sense that it’s a base upon which you can build. If we go into more detail, a design system is a series of atoms [a reference to Brad Frost’s book Atomic Design, in which interfaces are compared to matter; just as matter can be broken down into atoms, interfaces are made of fundamental components], principles, and rules that allow this to happen.
Andreia Mesquita (AM): In the end, a design system is a product in itself. It’s a product that feeds the product we’re building, and it impacts it by accelerating the teams’ speed of production, improving the customer and user experience, and the product’s efficiency. This is the general definition of a design system, which we adopted from Nathan Curtis. Then, the atoms and these other components Guerra was talking about come from Brad Frost. There are several isolated elements — or atoms — that can be mixed. For example, you have text and image, which combined can build a form, but a form is also a page, so you’re growing from an atom to a molecule.
What are the main advantages of a design system? You already mentioned some, like speed.
AM: Speed, efficiency, consistency, quality.
Margarida Mendes (MM): It’s not just faster and more efficient for designers, but also development teams because they don’t have to reinvent the wheel every day. They’re not building specific code every single time. When we change a part of the design system, that change will impact all the products and tools that contain those elements.
AM: There’s a ripple effect.
MM: Exactly, and that means that your capacity to do updates and become faster at keeping things fresh and working at their best increases exponentially.
Why is it so hard to create a design system?
AM: Basically, it has to do with managing the number of assets. To exist, a design system must be used by teams, which means you have to evangelize them about the framework you created. And also continuously validate if those assets still make sense or need to evolve to answer the team’s present needs.
JG: Yes, you have to create, govern, and evolve it. You need to promote it, as Andreia said.
MM: I would add that it’s strenuous to explain a design system’s impact to teams who are quietly working in their corner and building products that were initially created without one and which, therefore, lack the structure in place to receive it. It’s much easier to have a design system in place and scale it. In a product such as ours, which was built over the years, evangelization is key because we had to go back to things that were made years ago and modify them to comply with a design system. It’s time-consuming having to return to the past in a product that’s constantly looking at the future.
Who are the main users of this ecosystem of design systems at OutSystems?
JG: Development teams, designers, and also some product managers.
AM: It depends. In our case, we named it Product Design System (PDS) because product teams use it, but the rules we’ve been mentioning apply to all design systems and may be used by marketing teams, sales teams. Basically, any group of people who need a framework to ensure they’re all speaking the same language and are not duplicating solutions or reinventing the wheel.
MM: Yes, we can say we have three design systems in place. The PDS, which the OutSystems teams use to build our product, alongside the developers who work with OutSystems. This is the design system that dictates the look of Service Studio, for example. Then, we have the OutSystems User Interface (UI), which our end-users see when they create apps with OutSystems. And finally, we have a partnership with the Marketing Team, which we call Hybrid. All these design systems aim to create an accessible and delightful experience.
JG: Hybrid was a turning point in terms of offering the same experience to all our users. At first, we were more concerned with building a design system for the products and tools we had, but now we are looking at the user journey from end to end — starting at the website and our community pages and then moving to our existing tools.
AM: That’s exactly what we’re doing — taking on a more holistic approach. We have our core PDS, but other universes touch it and have to be integrated. When users go to our website, they don’t think: “Okay, so now I’m in the Marketing realm, and now I’m moving on to Product….” No, they enter our world and we need to provide them a seamless experience. We need to ensure they have a bump-free ride and that we are getting our message across thoughtfully and with excellent quality.
“Lack of cohesion influences the confidence in the product and also hinders the user’s learning curve”
— Margarida Mendes, IxD Team Lead
That leads me to the following question: why did you feel the need to create a product design system?
MM: Because when a machine is up and running without a design system, the user experience will consist of a bunch of copy-paste styles with no cohesion whatsoever. Lack of cohesion influences the confidence in the product and also hinders the user’s learning curve. You can look at a design system as a house: the house still has doors and windows if you don’t have a design system in place, but every room will have different doors and windows. It’s not like you don’t know how to open them, but your experience will be ruined — one opens to the left, the other to the right. There’s friction. Obviously, the way our PDS is built is different from Hybrid, for example. One was designed for a user working with our product for hours, which does not happen when you’re browsing our website. But there’s unity now: we don’t have seven dropdown menus, different buttons, stuff that was built differently over the years. Creating a PDS was mandatory for us to be the sophisticated product we said we wanted to be.
JG: Margarida mentioned the user experience, but there’s also the question of scalability — we now expect many more people at OutSystems to use it because people are directed at it and help evolve it. It recently happened with an app. We were at a system demo, an internal event to present the progress made by our teams to the entire department, and suddenly, a product owner showed us an app that uses the PDS, and which we didn’t even know about. It was perfect because it’s proof that the goal of the Design System (making teams autonomous when delivering new experiences) worked very well for that team. After that demo, we talked to some of the folks on that team to understand what improvements we could make and the ingredients of this success story so we can reproduce the “recipe” with other teams.
How did you evangelize teams at OutSystems to use this Product Design System?
MM: Through onboarding!
JG: By cracking a whip!
Miguel Nicolau (MN): With difficulty…?
[Laughs.]
JG: Okay, seriously now. We had a group of people who joined forces to create the PDS, evangelize teams, and spread the word and our guidelines. One of the ways was through the onboarding process in which people are introduced to our PDS. Then, we have syncs with the teams who work on our tools and products, and we make sure to attend these meetings and listen to their problems so we can correct them. This proximity is essential so they don’t forget us. Also, we strategically collaborate with teams in certain moments of the product building process not only to teach and evangelize but also to know firsthand where the system can improve. It is extremely important for our success that some of our team members gravitate around teams and products where we get the most of our value.
AM: Also, not everything they request is included in the PDS. We search for pattern needs among our users and check if they can be extended to the whole company or are niche necessities.
JG: One of the criteria is the number of tools that include that component. Another criterion is the component’s potential. “Will this be used in another tool or product in the future?”
How do you triage those needs?
MN: That is one of the main challenges of any design system. You have to maintain it while also evolving it as it is used in the real world. As you absorb that feedback and improve it, users gain a better understanding of why it is valuable to have a design system, and they help you keep this ecosystem alive and growing.
JG: Yes, this is part of our governance model, but we also have the onboarding and evangelization. You need to have feedback channels in place. It’s not just about being close to the teams to get their feedback, but also creating Confluence pages with documentation…
MM: And training…
JG: [Nods in approval] And training…
MM: Dude, do I have to be the one to remind you of all the cool things you do?
[Laughs.]
AM: It’s hard when you have to list everything; you forget things!
MM: And now you may be wondering about those who work with our design systems outside the company…
That’s a great question, Margarida. How do they give you feedback?
MM: That’s Nicolau’s area, who’s also our accessibility expert.
MN: Well, let me see if I can wrap this up in one answer. When it comes to this other design system — the OutSystems UI — which is external-facing, there’s a bigger challenge because we don’t have such an active voice yet amidst the designer community. I think this is something we need to work on. We collaborate with our partners and other people with whom we have a great relationship to get feedback and bake a sort of “iteration cake.” This is easier to achieve with our PDS because we’re all going in the same direction, building our product. When it comes to a design system like the OutSystems UI, which can be applied to banking, insurance companies, or a shoemaker — it’s a completely different game. We need a larger amount of feedback which is absolutely precious, and this is clearly something we must develop further.
“It was important to us at OutSystems to have that ethical value and representativity. This is incredibly significant and a differentiating factor from other companies”
— Miguel Nicolau, Runtime Experience Team Lead
In the meantime, while debating this, we realized that accessibility is fundamental and could be a blocker. It was a necessity at a business level, but it was important to us at OutSystems to have that ethical value and representativity. This is incredibly significant and a differentiating factor from other companies. When I spoke at the Global Accessibility Awareness Day [the event was promoted by Athos and the name of the panel was “Making It Easier to Create Accessibility Apps With Low-Code”] last year, one of the reactions we got from the experts in the accessibility panel was this perception that low-code could be bad for the industry. They felt low-code didn’t care about accessibility the way high-code tools do. Well, if low-code isn’t addressing these issues, this means that there is a huge volume of applications being launched in the market without any accessibility concerns. So, a person who doesn’t see very well and needs a bigger font size or a screen reader adaptation, and all other sorts of things — this could be a silo for many problems. This became even more evident with the lockdown during the pandemic. From the moment you’re stuck at home on lockdown, having that digital help is essential. People were having to leave their homes when they shouldn’t because they couldn’t do what they needed to do on their computers due to accessibility issues. For us, that was an extra push: it’s not just about being ethical, but it’s a market requirement, especially in the US and UK, and slowly, in other places of the world.
So, our OutSystems UI design system began opening up: it has to do with the colors we use, with the way people use their keyboards, screen readers, etc. These concerns are integrated into our PDS — for now, we’re really focusing on colors and ensuring contrast when it comes to the text and its background so that it’s easy to read in both light and dark modes. In sum, we’re trying to make these tools as widely available to everybody as possible, and help those people’s lives, so we’re not creating barriers. It’s not perfect yet, but we’re on the right track.
AM: I found that test we did with our teammates on visual impairments very interesting. Some of our colleagues are parachromatic, and they helped us with testing. It’s an essential concern, and it’s cool to have people within the company collaborating and who now feel closer to the product.
MN: As our user base continues to grow, we wish to adapt to everybody using our platforms.
MM: Exactly, and while internal testing is cool, it’s only an initial step. We’re now working to find out the most common impairments to prioritize those that affect a larger portion of users.
“A design system is never truly completed, it’s always evolving depending on your needs. There are other questions to be taken into account, such as delight. The pinnacle of user experience is delight”
— Andreia Mesquita, UX/UI Lead
Your design system is made of several elements. Where can people find them?
JG: If we think of a design system as a series of assets that are designed and built to feed products, we can think of them as design stacks or code stacks. We keep them as a series of Figma libraries that are available to be used and paired when we’re creating experiences. There are three main pillars: the foundations (this includes all the core values and principles, writing guidelines, research, and governance), and then two other pillars which are atoms, such as typography, color, iconography, illustrations, spacing, elevation; and finally, components and patterns. All of this is stored in Figma libraries for our designers to use and is translated into code (which we make available on GitHub/Storybook) with its respective guidelines so users know where they can use the components. Our documentation is also ongoing, and I think we have to keep everything evolving; it’s not something you can say, “There, it’s done.”
AM: A design system is never truly completed, it’s always evolving depending on your needs. There are other questions to be taken into account, such as delight. The pinnacle of user experience is delight — that’s what makes people come back to use your product. And we want our applications to be as delightful as the tools we build them with. This is why one of the areas we’re evolving in our PDS is interaction design — anything related to micro-interactions, motion design, how do you make those illustrations come to life. That is the spark Miguel is working on externally, while Margarida is developing the product’s micro-interactions.
How do you articulate this work as part of the same team?
MN: We’re kind of glued at the hip as we all share the same technical foundation. If we change something under the hood, it will affect both. We work together on the fundamental basis of these components and then work separately on more specific needs on each side.
AM: It’s all about building a cohesive experience and feeling you’re part of the same product, whether you’re a user in a banking app or the developer who built the app. The same principles apply. Of course, the banking app has a layer of branding, the image of the brand that bought it, but the usability, consistency, and rigor are there. If an end-user is used to a certain type of swipe in most apps, we must use that same swipe — there has to be a consistency between what we offer and what people are expecting. We have our central PDS, we have our Hybrid, and the external-facing OutSystems UI, which is closer to end-users, but all of this is wrapped up in accessibility, usability, seamless interaction, cohesive icons. They all gravitate, like moons, around the same planet.
“Some people perpetuate the myth that design systems work almost like a straitjacket. In reality, they’re a set of rules that promote consistency, but they’re more than that.”
— João Guerra, Design System Team Lead
MN: There’s B to B (business to business) and B to C (business to client), but this is a B to all, which is very popular at the moment. We don’t just compare applications from the same segment anymore, we need to look at what Facebook or Instagram are doing — there is more uniformization, and users have expectations. They expect it to work a certain way, and the same goes for Service Studio. This is why all our work revolving around the delightful concept is not only expert work — it’s also research on what delightful means to different people across different geographies.
AM: Just a final note. We have our spinal cord — the PDS — because we wanted to elevate our current IDE (and launch a dedicated Mac IDE) based on visual, accessibility, and usability studies on the best user experience practices and the needs of the OutSystems community. From there, we began fine-tuning the rest, and this is how the UX/UI Team specialized because we were very much focused on the practice alone. We subdivided into three areas: the Design System Team, which is focused on managing and evolving the PDS and the Hybrid System; the Runtime Experience Team, which is responsible for growing the external design system (the OutSystems UI); and the Interaction Design Team that develops and adds interactions and micro-interactions to multiple products within our Product area.
Fact or myth: do product design systems mitigate innovation and creativity?
JG: Some people perpetuate the myth that design systems work almost like a straitjacket. In reality, they’re a set of rules that promote consistency, but they’re more than that. They should be seen as atomic elements or ingredients in a recipe that can be mixed together to create new things. It’s like when you go to the supermarket to buy ingredients for an Italian dish: you grab pasta, cheese, tomato, and you make a great dish. The design system is structured, it’s only with the recipe and the ingredients that you can create a great dish, but then you have your creative flair.
AM: It also depends on the cook — you can end up with a different dish using the same ingredients. A design system in itself does not guarantee a delightful experience; you can buy the same ingredients and have a different result. What we ensure is that the ingredients are there, the foundation is there, but then you have to add seasonings to make it stand out. Otherwise, you’ll end with a cohesive page that works great and follows usability principles, but for that special extra spark, you need to add delight and creativity.
Do you work with a centralized or federated governance model?
JG: Governance is almost like having an orchestra and the maestro who conducts it, or the European Union and its member states. In fact, we are between a centralized and a federated model. While we have a core team that works in our PDS, everybody chips in on certain initiatives and brings the needs of their teams into our PDS. This is vital because the design system feeds people’s work, but it’s people who feed the design system, too. So we work as a solid core with many satellites around us that bring information — not just the product designers within those teams, but also other contributors who help us understand what their needs are.
Can you give us an example of how it works?
JG: Yes, for instance, I already mentioned syncs. Within each project, there are sync meetings between teams. In our Marketplace, there’s also a UX/UI Team member that is helping design the product while feeding the PDS and bringing their needs to our team.
MM: We have product designers within development teams, and they work as part of the product design system team — they are aware of the use cases and will try to solve them using our PDS or might even reach the conclusion that they found some unattended needs. Where we don’t have people on the ground, there’s a centralized team to help — the product designers or UX/UI Team members can raise red flags and signal new needs. The PDS team will then do their research: is there a pattern? Can this be applied to more tools? Either way, it will be integrated into our PDS, whether as a general component or a specificity within a certain tool.
JG: As you were talking, I remembered that IDE use case. We have two really active team members on IDE, who are designing the product. At one point, they realized that there were components that they could use, but the experience wouldn’t be as delightful as possible. And they reached out to us: “Hey, PDS Team, what do you think?” And that is beautiful. We’re not there, but they recognize our existence and importance, they make suggestions, and our intervention is almost surgical. Our work is like…Have you seen Toy Story? I’m sure you’ve seen it — you know when Buzz Lightyear is with Woody and makes that gesture: “Look at all this.” That’s why we’re for, to show what’s already been done and where we can fit everything that is suggested by our team.
Originally published at https://www.outsystems.com.
