Introducing aragonDS, the new Aragon design system

Intro

We are so excited to announce the release of the new Aragon design system, a living project that will continue to evolve and further consolidate over the upcoming months.

This journey began a little more than four months ago, during a design sprint week, when we made the decision to take a step back in order to move forward and faster. Building a design system from the ground up can be quite a challenge, but nothing is more rewarding than being able to witness its impact on the Aragon ecosystem, driven by an earnest passion, commitment, and team effort.

At this point the advantages of having a design system are very well documented. We can safely say that by adopting a systematic approach towards composing our UIs, we have completely changed the way we design and build products. From small startups to large organizations, single products to entire ecosystems, design systems help ensure products have a unified look and feel as they scale and mature.

If we had to reduce them to their essence, their core benefit: design systems allow teams to build better products, faster. This is what aragonDS is about.

What is a design system?

This systematic approach is nothing new. From the NASA manual published in 1975 to the award-winning GOV.UK’s and of course Material Design - the design tool with the greatest impact for the entire industry. Simply put, design systems are collections of components and patterns that can be combined, reused and extended to build products.

A design system ensures consistency and establishes a shared vocabulary. It reduces design debt, elevates quality while accelerating output, and builds a culture of inclusiveness and smoother collaboration between teams working together, to bring cohesive products to life.

Our approach & key objectives

We followed the Atomic Design methodology, which we have adapted to fit our design process, product offering, and team's context. Our approach to specifying the components and naming them is based on evolving a shared design language collaboratively and empowering all designers and engineers to contribute to the system.

Before we began our journey, we defined the objectives of our design system and outlined the guiding principles that we’ll follow throughout the process:

• To unify our brand and product design around a common, coherent, shared visual language.
• To ensure quality standards and consistency in how we use patterns and UI elements, as multiple teams need to work autonomously on various projects.
• To deliver products faster and more efficiently, reusing code and reducing custom instances to a minimum.
• To provide guidance and documentation to developers and designers wishing to build an Aragon app, so we support the scaling of the ecosystem.

We all agreed from the start that our approach had to be extremely flexible: after all, we already have a product and an ecosystem of apps relying on our UI toolkit. This is where these objectives became really useful: while aragonDS was taking shape, the new color system and the foundational elements were integrated in aragonUI, rebuilding one component after another, and used in apps as they became available. This list helped us to keep going in the right direction, while we were all busy shaping all these different pieces at the same time.

An additional challenge that we face when designing a system for a platform or app ecosystem is that, not only do we need to create components that fulfill our current requirements, but we also need to cater to future, unforeseen use cases, enabling app developers the expression of their own brand and purpose, while maintaining consistency and integrity.

aragonDS overview / sneak peak 👀

Principles

1. Consistent

Being consistent when designing an interface will give users a sense of predictability when browsing. We have drawn up a set of rules to ensure the construction of a sound, coherent, scalable base.

1. Hierarchical

The visual hierarchy is an essential element in any interface. The appearance of each item within the hierarchy is an indicator of its relative importance and its relationship with other elements, setting a well-defined order based on the user's visual axis.

1. Simple

Our interface is based on a straightforward, minimalist design with a lot of importance being given to the white space among the elements. This is to avoid 'cognitive overload' and thus make it easier for the user to explore and make decisions. The 'magic of design' includes making complex elements simpler.

1. Human

Design involves forging strong links with people, making things understandable and user-friendly, and giving help when it is needed. Resources such as illustrations, colors, and messages strengthen communication with the user.

Foundational elements

1. Color

We have created a color range that not only provides a more colorful interface but also guides users through a logical, coherent, consistent color scheme.

1. Grid

aragonDS bases its central content on a structure of 16 columns at maximum resolution and reduction to 4 columns at minimum resolution, with a separation between them of 16 px and a maximum resolution of 1104 px in keeping with the minimum unit size (8 px).

1. Font

We defined a main font within our choice of typefaces (Overpass) and the secondary font (Roboto Mono). Both fonts are open source and are easily readable. They also have a great variety of typographic weights. The main font (Overpass) will be used for all texts while the secondary font (Roboto Mono) will be used for numbers given its high readability for this application.

1. Illustrations

We have worked on the creation and adaptation of the new style of illustrations to make it even more user-friendly. Illustrations that are dynamic and full of character help users to better understand the product. We also set great store by the use of color in each case, creating contrasts and adapting these to our interface.

Design guidelines

We are working on gathering all items, rules and principles within the Design Guidelines section of hack.aragon.org where you will be able browse each one of the sections in an easy, intuitive way.

The portal will be split into 3 sections, the first one giving an overview of the project, defining the pillars on which aragonDS is built. The second block will define and list each of the components and their properties, establishing a home page or index for easy browsing. And finally, there will be a summary of the present state of the web and future steps in the form of a timeline.

In this portal, you will be come up with new ideas, define components, and ask questions.

Testimonials

Here's what people that have started using our alpha release are saying about it:

“aragonUI makes your workflow much easier since you’re reusing a lot of the components in the library. The new design system makes it trivial to make your own custom components because you have clear guidelines and rules to follow.” — Deam Hansen, Front-end engineer at Aragon Black

“Building an Aragon app with the new design system and UI framework is amazing! The feature I love the most is how you can, with just a couple of components, build a grid where everything fits together so beautifully. Now building an Aragon app is so much straight forward enabling you to really focus on building your app rather than worrying on making it look good as that already comes straight out of the box.” — Fabrizio Vigevani, Software developer at 1Hive

“The new design system is very comprehensive and provides substantial guidelines for designing apps on Aragon with clean, intuitive components. At the product level, it's becoming a cornerstone for Flock cross-team collaboration and coordination on design decisions.” — Javier Alaves, Product Designer at Autark

But my favorite quote about the design system is from one of our Aragon One team members who, when using the Figma components library for the first time, said: “I feel like I'm playing with Legos! Using aragonDS feels like having a ton of shiny and ready-to-use LEGO bricks that we can play with to visualize our product ideas.”

Lorikeet

You may have heard of the Lorikeet project, which was started as an effort across multiple teams to build a generic design system for the decentralized web. The initiative was quite broad, and not specific enough to fulfill the needs of the Aragon platform, which aims for a strong sense of consistency and adaptability.

It also happened during a complicated time for decentralized projects, and most of the different participants had to shift their priorities during this year and realign their objectives, moving them away from Lorikeet.

This is why we decided to sunset Lorikeet as a project, and redirect our efforts to aragonDS and its toolkit, aragonUI. The efforts we put into it are not lost though: they helped us to learn more about our own specific needs, and paved the way towards aragonDS. It also served as a technical base for the new aragonUI.

aragonUI

aragonUI has been reworked at the same time, translating the principles defined by aragonDS into React components. It comes with a new theming system, multiple new components, and a refreshing visual update coming right from aragonDS.

We decided to name this version 1.0. The core Aragon apps have been ported to use it, and several others from teams like Autark, Aragon Black, 1Hive, and EmpowerTheDAO are on the way or already ported. It is still in preview, but even in the current state, it is fair to say that aragonUI is already more consistent, accessible, and easy to use than ever before.

During this redesign, we honed our work to be based on these guiding principles:

• aragonUI should be optimized for Aragon apps. It means that the API choices we make will favor what we believe should be expected by an Aragon app developer. Specific needs are also handled − we still plan to use aragonUI in different situations − but we want to provide the best experience possible to Aragon app developers.
• It should be possible to build a simple app without using any custom CSS. Some components are aware of what component they are in, and adapt their styles appropriately. The spacing is also managed by components when
  possible, but also lets users override it if needed.
• But anything outside of the simplest apps will need customized styling.
  That’s why components will let you extend them easily, by passing the
  className and style props to their main element. We particularly
  recommend using styled-components with its Babel plugin.
• Component APIs should have short and straightforward names, manifest the
  least surprising behavior, and offer the developer one − and preferably
  only one − obvious way to do [something] (from the infamous PEP 20)

If you develop Aragon apps, we strongly encourage you to try this early
version, and give us any feedback you have:

npm install -S @aragon/ui@next

You can find the upgrade instructions here.

As our immediate next steps, we will continue improving upon this foundation, adding more components to the kit and defining a contributor governance model for the design system. We’d also like to provide a chance for anyone using aragonDS to ask question and give feedback, so if you are interested in getting some one-to-one time with the team, feel free to reach out to us on the Aragon Forum or #design channel on Aragon Chat!