This article is the first in a series on our journey to creating OutSystems UI—our most recent UI framework.
We’ve all heard the quote:
“Life is about the journey, not the destination.”
Whether you agree or not, when it comes to designing a user interface, your journey and destination are both of vital importance.
Imagine your destination is your company application portfolio that delivers a consistent brand style and user experience that can be evolved as your product landscape scales. The choices you make along your journey determine whether you achieve it.
When designing an experience, you have many choices to make. For instance, you have screen dimensions, color palettes, copy, content, navigation, and so on. Once you’ve defined all your choices, how do you ensure consistency, and not a confusing design patchwork?
How do you manage design at scale? Well, you could verify every decision, ensuring consistency, from checkboxes to screen dimensions. It’s a solution, but a nightmarish one. Another solution is to create a design system that everyone can follow and contribute to.
What’s a Design System?
A design system is a centralized source of design guidance on processes, components, tools, and guidelines on how to use them, that are used as the building blocks to equip teams to design and develop a product experience that is visually and functionally consistent. Think of design systems as a common shared language that brings together everything required to ensure a consistent experience.
- Standardized Tools - defines and standardizes the tools used at every stage of the project.
- Standardized Design Practices - file structures, naming conventions, etc.
- Live Style Guides - defines the standards and rules for interfaces and includes all the visual styles and components you’ll need to build your application. It’s a central repository for designers and developers. Have a look at ours!
- Content Style Guides - organized set of rules for copywriting, voice and tone, terminology, etc.)
Our First UI Framework
Challenge: Accelerate Application Development
At the time of writing, OutSystems UI was reaching its first anniversary. OutSystems UI is the natural evolution of Silk UI, our first official UI framework.
Silk UI emerged in 2014, the challenge at the time was to help teams accelerate web and mobile application development—they could drag and drop pre-built UI patterns (web blocks inside Developer Environment), turning the experience of developing interfaces into a breeze. Silk UI (read the story of Silk UI) helped a lot of our customers build all kinds of applications, from simple to complex in a wide range of industries, such as banking, insurance, healthcare.
Despite Silk UI’s success and significant adoption, continuous technological progress, and emerging best-practices in dealing with medium-to-large projects, propelled us forward in continuing to find ways to support the evolving needs of our users.
To better understand their evolving needs, we talked to our customers and our partners, collecting their feedback and assessing their circumstances. We also worked closely with our in-house specialized customer services colleagues, who work closely with our customers on-site and bring back valuable insights on what their needs and pain points are.
We identified several areas of improvement that would enable the teams working with Silk UI to do so with increased agility, and we also identified ways to improve project scalability. There was a lot of potential for improvement.
Evolving Our UI Framework
Challenge: Manage Application Scalability/Revamped Look And Feel
We were now faced with a different challenge - to help design and development teams manage the scalability of their apps—meaning they could add functionality, and fix issues, at full speed, while creating and maintaining a modern and consistent look and feel. OutSystems UI is not only the most complete framework we have ever built, but it also lays the groundwork for the teams to face their design challenges.
With years in the making, it had been a long journey working around systems that provide design solutions (that ultimately led to our frameworks) and with design and development teams that build apps with OutSystems.
With the launch of OutSystems UI, we’d successfully:
- Created a new design language for web and mobile apps.
- Modernized the way we assemble elements, patterns, and components.
- Established a foundation to create a consistent, cohesive experience among products (like design systems).
And the best part is we get to share it with you.
Here are some of the core solutions, summarized:
1. Atomic Design: Modular UI Patterns
One of the most significant changes was how we addressed the construction of our UI patterns. We based our approach on atomic design principles, a modular approach to building UI components.
In atomic design, UI elements are broken down to their most basic elements, and then isolated to form independent, reusable pieces—these elements are called atoms (e.g., color, spacing, typography, shadow.)
Assembled groups of atoms are called molecules, an example would be a search field comprised of field, label, and button (i.e., a molecule comprised of three atoms.) Molecules can be assembled with other molecules, deriving even larger components, and you can keep assembling till you’ve got a complete user interface.
A common analogy to illustrate this approach is Lego® bricks. UI patterns constructed from reusable elements represent a significant benefit, especially for customers with large factories. Building apps at scale usually means different layouts and customizations, and with a design system, customers can quickly use ready-made patterns (like you’d reuse a Lego® brick) to build interfaces, customizing them to their needs and according to their brand identity.
2. A Modernized Style - That You Can Make Your Own
Far are the days when ugly and boring software was the norm. Like everything else, visual design naturally evolves to accommodate user needs, tastes, and requirements. So you can count on a redesigned look, that will please even your most sophisticated users. Changing the styles is a breeze, so go ahead and make them your own—customize them to your brand identity, to reflect the mission and values that bring your customers joy.
3. A Revamped Naming Convention
I consider myself to be pretty creative, but there’s a time and a place for everything. An absence of rules to call and declare things can lead your developers to struggle daily. We created a simple naming convention that everyone can easily follow, it’s a quick-win, that dramatically impacts developer autonomy.
"Every single line of code should look like it was written by a single person, no matter how many people wrote it." - José Rosário, Software Engineer at OutSystems
The Discovery Phase
A Designer’s Perspective, a Developer’s Perspective
Discovery is the first chapter in our journey to evolving the UI framework. In this first chapter, we gather information, digging deep into the details, to find what’s important/what our customers need. The end goal of discovery is to predict whether the proposed solution is going to fulfill their needs.
We needed to include different perspectives for the framework to be successful—Design and Development. At OutSystems, we know from experience that we’ll get better results if we address research as a team rather than a one-person’s job. So I teamed up with José Rosário (quoted above). We worked side-by-side, discussing, and searching for the same topics, our different technical backgrounds led to different conclusions. It was a successful match—we were both equally invested in the discovery process, dedicating all our time and attention to finding the best strategy.
Given the areas of our UI framework in need of modernization, we started our discovery phase on two fronts. First, we wanted to understand what kind of applications were being built by our customers and by our in-house specialized customer services, then we identified areas where the framework should provide more support. After looking inside our ecosystem, it was time to explore. We looked at what other successful companies were doing with their frameworks and design systems, hoping to learn more and avoid common pitfalls.
Laying a Solid Foundation
The Essential Elements of the Visual Design Language
In the discovery phase, we had researched a full spectrum of topics, and it was now time to converge. We knew that to create products that can consistently scale and evolve, it’s important that we start by establishing a solid foundation that can be shared across all UI patterns of the framework.
As I mentioned before, we decided on a modular design, based on atomic design principles—simple and essential elements that are the building blocks for every component/pattern. For OutSystems UI, we decided on the following essential elements:
- Shadow and Shape
I encourage you to deconstruct any OutSystems UI pattern, and you’ll find that they are all composed of these simple elements.
Color is one of the most critical elements of design. The right palette is engaging and accessible, it’s an essential element of your user interface—every part of your app has color. The palette establishes an overall look (aesthetics), and feel (the emotions it evokes).
In OutSystems UI, our primary goal at the time was to set a color system, defined by their usage (for example, the color used to express hierarchy, states) in the interface. Based on our identified top use-cases, we set four color palettes:
1. Brand Palette
Every company has one or two colors that identify them, distinguishing them from their competition. In this palette, brand colors are the primary colors of an interface and should reflect the brand guide. It includes a primary brand color, and for special cases, a secondary brand color.
2. Extended Palette
In the extended palette, you’ll find a wide variety of colors for use in your content areas, and to serve data visualization (like a pie chart). We included a vast choice of colors in this palette, making it extremely versatile, so the framework can cater to a wide range of needs since our customers have unique requirements concerning color usage.
Tint and Shade Palette
Color grading is a color scale from a base color’s lightest variation (tint) to its darkest variation (shade). And this is how color grading is achieved:
Tints are a base color + white
Shades are a base color + black
This palette provides six variations for each base color—three tints and three shades. It gives you more choices to work with but keeps the consistency of your chosen color scheme.
3. Neutral Palette
The neutral palette holds a color scale of grey tones intended for text elements, subtle elements, borders, backgrounds, and so on. We wanted to provide a good range of greys, and we intentionally picked bluish-grey tones of grey, adding a little blue makes for richer and brighter tones of grey.
4. Semantic Palette
Typography is another element of visual design, and it’s an element of the interface and an element of content; applications rely on words to a great extent. Which is why we need a strong typography base.
Picking a font family for a framework isn’t an easy task. It's like picking a pair of shoes in the morning to wear to an important meeting, knowing that later on, you’ll be wearing them to run a marathon—a difficult choice between stylish and safe.
It’s always a compromise when our customers may be building anything from an internal dashboard to overview dozens of satellites orbiting Earth to a multichannel application that connects to IoT applications to coordinate all stages of production for one of the largest wine producers in Portugal.
Every design choice must serve a purpose. In this case, we chose to use System Fonts. The framework provides the scaffolding for good typography, applied to the native font family of the user’s operating systems. Our choice was in favor of great legibility/functionality and an aesthetically neutral look.
With this agnostic approach, there’s no doubt that whatever the device or platform users have, the text on OutSystems apps will be extremely legible, fast to load and render. And this doesn’t stop our customers from including their own font family to customize their interfaces. Regardless of the choice of font - the framework organizes the text elements.
Size and Scale
Typographic hierarchy organizes text elements in order of importance, and this helps the user understand and navigate through the content of a page. To determine the size and scale of our typography, we used the modular scale, which is a method to establish a clear and harmonious hierarchy.
Notice in this very article—you have the eye-catching title (level 1), the sub-titles (level 2), and the bodies of text (level 3).
We chose a type base (base font size, the baseline) of 16px with a ratio of 1.125. The numbers this scale provides have worked well for us in the past, and curiously are somewhat identical to other web UI frameworks. We took this as a good sign yet we still looked for further confirmation by simulating this typographic scale in demo applications. With this baseline, we defined our scale, distributing the sizes into two categories: headings and bodies.
The way we perceive an interface, and how it’s structured, is highly influenced by the layout of elements, and how they relate to each other. We learned that design systems commonly use spacing as a foundation (thanks Nathan Curtis). Applying space consistently across your interfaces creates a harmonious rhythm and natural visual balance, that would be difficult to achieve without a system in place to define these spacing relationships.
Our research tells us that a good way to deal with spacing is to establish a spacing scale. The 8-point grid system is the most common, and it uses increments of eight points to size and space out elements in an interface. What this means is that all margins or paddings will place elements spaced in 8 point increments of each other, and every element’s height and width will also be an increment of 8 points.
One of the proven benefits with using this system is that once we have a scale with semantic sizes (e.g., small, medium, large) designers and developers can speak the same language, and can work alone whenever needed. A common scale removes doubts and creates a better and shared understanding of how to apply space with intent.
Shadow and Border
Shadows aren’t as prominent on an interface as color, typography, and space, yet, for consistency and cohesiveness, these elements should also be considered. We established a shadow scale for interface elements that need to be differentiated from others, to draw the user’s attention to them. We chose five elevation levels, that should be thoughtfully applied, elements with larger shadows have an increased prominence, less prominent elements, at lower elevations have smaller shadows.
About border, there are a lot of elements that use some edge roundness, the most common ones are buttons, inputs, cards, and so on. So it was also essential to establish and isolate these classes so they would be consistently applied. The default border value in OutSystems UI is soft (4 px), easily customized by picking another option.
The Road Ahead
Because UI Frameworks are ever-evolving, their lifecycle is theoretically infinite. As technical requirements change and aesthetics evolve, so will OutSystems UI. As a team that values beautiful and enjoyable interfaces and always keeping the user in mind, it’s rewarding to be able to share the foundations for you to apply to your next design system.
We all want to put our best face forward, and when it comes to applications, the interface is the first thing users will notice. This framework is where design meets frontend development. Live style guides is where the guidelines are compiled, and the CSS code snippets your development team needs to get the design just right. For example, when you choose a color, you will get the code for that color to use in your project. You’ll get the color name - like ‘red,’ the color Hex value - like ‘#ff0000 ’, the background color CSS class, the text color CSS class, and also the color’s CSS variable, no guesswork required.
You can find all of this inside the ready-made UI Pattern blocks, inside your Developer Environment. Developers can drag and drop and voilá, like magic, you’ve got a working pattern that can be customized. Now, I’m not the best choice for telling you all about how we started with these foundations and ended up with fully-functional UI Patterns, so I’ll pass the ball over to José Rosário, stay tuned for the second part of this series.
Undoubtedly, great apps are great experiences, and with that in mind, we offer a UI kit for designers to improve productivity and collaboration. Each style, pattern, widget, or layout in the framework is included in the kit. Our goal is to empower every designer to create quickly and consistently based on OutSystems UI. Why don’t you give it a try?