Design systems are not just for designers
At RingCentral, the UX team has a fairly large design system housed in Sketch and shared out via Abstract. Designers and developers reference it, and we actively maintain and evolve it as much as possible.
As thorough as it is, we recently ran into an issue.
Many new Project Managers and Product Owners have asked to view our design system to help understand the brand as it applies to our products. We would send an Abstract link along, but would quickly get feedback that the format was too difficult to navigate and overwhelming with content. It’s perfect for designers and developers who need to understand the nitty-gritty of every color and component, but too much for a viewer who just wants a high-level understanding.
We received enough of these comments from non-designers and non-developers to identify that it was time to explore a version of our design system tailored to a different audience.
There are many different design system audiences and stakeholders depending on your company and the type of products or services you offer. To ensure consistency, brand ownership and high-quality design throughout your product ecosystem, it’s important to identify who may need to reference your design system and in what context.
Listed below are a few common and not-so-common design system personas that you may need to consider besides the actual UX/UI design team:
The developer
Goals
- This one’s a given — developers view a design system to access detailed UI element specs for development purposes. State changes, sizing, color, type, functionality…they need all of the details.
Frustrations
- Needing to reference too many different sources when working on a component or feature.
This is a general best practice and a frustration I’ve especially heard from developers. Who likes having a million windows open to complete one task? It can be confusing and will result in one or two of those sources falling off the radar. Try to consolidate relevant information as much as possible. - Out of date info. It’s critical that what a developer is referencing is up to date. Fixing mistakes later can be costly.
Developers are the most common second audience type for a design system. If you’re building software or websites, you 100% need to consider the needs of developers.
This includes ensuring design elements are easy to access and well thought out. You will want to make it clear what the different states and variations of a design element are and how they work together with other elements in the system.
I’ve also found that sharing the design system through a non-native source, like Abstract or InVision with built in “inspection” tools, makes reference of the design system much easier for developers. Designs will update synchronously, and you wont have to worry about your Sketch or Adobe files mysteriously changing due to others poking through them.
The project manager or product owner
Goals
- Project managers and products owners want to see what the design team has or has not considered in the product UI, from a high-level.
- They also want to see how the UI works together as a whole. What pieces fit where and in what context.
- Last but not least, they will need to reference related information like product strategy info, roadmaps and backlogs. This will aid in comparing product design initiatives to business objectives and understanding company product design from a holistic perspective.
Frustrations
- Needing to access an unfamiliar tool to view the design system. The goal is for this persona is to get info they need quickly. They don’t want to learn a new tool to do so.
- Information overload. PMs and POs are not re-creating the UI like developers are. They want to understand the big picture more than they need to see the min-width of a primary button.
This was the persona I spoke about previously that the RingCentral team is currently understanding a bit better.
A Project Manager and Product Owner will want to have access to the very detailed design system so that they may inform their development teams what to reference and where — but most importantly, their goal is to understand the high-level principles of the design system. When do we use certain elements and why? Do these UI solutions best fit the needs of our product and business?
The marketing designer
Goals
- A marketing designer will want to understand and compare the UI implementation of the brand to the marketing design implementation.
Transparency between product and marketing design teams will ensure a strong overall brand look and feel. - They may also need to pull high-level specs and guidelines for components or design styles to translate to marketing designs for the web (like email templates).
Frustrations
- The same frustrations as the previous persona apply. A marketing designer does not necessarily want to see all of the states and details of every component and it will make scanning the design system very difficult if they have to sift through all of that.
They are also probably utilizing different tools than the product design team and will not want to spend the time learning a new tool to get what they need.
A marketing designer is most likely already following a brand style guide. There may be discrepancies in implementation between, say, the company’s website and the company’s product, and that’s okay.
The goal is for a brand’s marketing design and product design to be complimentary, not the same.
The entire company and the general public
Design systems shared with the entire company and/or the general public are often shared for two reasons:
- To instill transparency and build excitement for product design within the company
- A show of thought leadership
When a company re-skins or builds a new product with shiny new UI, people get excited about it! Designers aren’t the only ones who care about design, and sometimes the product design team will also decide to share the inner-workings of their design system to satisfy interest.
It’s one thing to see the final product, but it’s another to see how much damn work went into designing it and how many moving parts are involved. Sharing a (well thought out and maintained) design system within your company can increase visibility and respect for the incredible amount of work design teams contribute to the product ecosystem.
Extremely large companies (and a few mid-size) go as far as sharing out their design systems to the world. There are well known open source systems such as Google’s Material, Salesforce’s Lightning, or Shopify’s Polaris. These modern and successful design systems serve as great inspiration to other product and development teams to learn and evolve from.
Goals and frustrations for this massive user type vary — you’re basically sharing this design system with everyone. Although your primary audience will be more design and tech-savvy, it’s most important to ensure a couple of things no matter what:
Ease of access
If your design system is not responsive to a range of devices and easy to access via a web link, wait to share it with the entire company (and especially the world) until you can facilitate that level of access.
Up-to-date material
If you’ve identified the need for an open source design system, you had better keep it maintained and up to date — no broken links! This may mean you need to have a dedicated designer (or team of designers and developers) looking after it.
In conclusion, consistent and high-quality product design relies on knowing who your design system users are and understanding their needs, goals and frustrations.
The number of personas your design system caters to will vary per team and company type. The way we found out that we needed to cater to someone other than designers and developers was by receiving a good amount of feedback internally.
If you are running into this as well, it’s important to really understand the intentions of your new user(s) and gather information through further research.
To better understand our new design system user, we conducted a small card sorting exercise to help us identify what design related topics are valuable to them, and then followed up with a casual Q&A session to gather more context and refine the card sort.
Sometimes multiple personas have similar needs although they have very different roles within the company. The “Marketing Designer” and “Project Manager / Product Owner” personas can probably reference the same high-level version of the design system because their needs, goals and frustrations are very similar.
