Über Ihr Red Hat Konto können Sie auf Ihr Benutzerprofil, Ihre Einstellungen und die folgenden Services abhängig von Ihrem Kundenstatus zugreifen:
Noch nicht registriert? Folgende Gründe sprechen dafür, dass Sie es sein sollten:
- Greifen Sie auf Artikel in unserer Knowledgebase zu, verwalten Sie Ihre Supportfälle und Subskriptionen, laden Sie Updates herunter, und nutzen Sie viele weitere Funktionen über eine zentrale Schnittstelle.
- Lassen Sie sich die Benutzer aus Ihrem Unternehmen anzeigen, und bearbeiten Sie deren Kontoinformationen, Einstellungen und Berechtigungen.
- Verwalten Sie Ihre Red Hat Zertifizierungen, sehen Sie Ihre Prüfungsübersicht ein, und laden Sie Logos und Dokumente zum Thema Zertifizierung herunter.
Über Ihr Red Hat Konto können Sie auf Ihr Benutzerprofil, Ihre Einstellungen und andere Services abhängig von Ihrem Kundenstatus zugreifen.
Vergessen Sie zu Ihrer Sicherheit nicht, sich wieder abzumelden, wenn Sie die Red Hat Services auf einem öffentlichen Computer verwendet haben.Abmelden
In this post:
Why the Red Hat User Experience team set out to create a design system
Identifying a unified voice and defining standards for our website system and apps - learn about these and other goals we hoped to accomplish
How did we build out the design system website in just three short months and how are we continuing to use it today?
In 2019, the Red Hat User Experience (UX) team set out to create our Red Hat digital design system. It has evolved from a few research decks and Adobe XD files to a comprehensive shared design kit library and documentation website that many internal and external teams use every day.
Our mandate was to design flexible building blocks and use new web technologies to create consistent user experiences that instill trust among visitors or customers who use our system of websites and apps. In this post, we’ll share some of our challenges, actions and outcomes.
Why design systems are important
The necessity to create a design system was more than our desire to appear on design system listicles with the likes of Adobe, Google, IBM, Shopify, and more.
Rather, it was an effort to combat the sprawl of inconsistent user experiences, page layouts, design components, and other artifacts. Inconsistent or jarring experiences might lead to distrust, lessening the satisfaction of a user which would reduce their likelihood of becoming or continuing as a customer.
About 10 years ago, the Red Hat User Experience Design (UXD) team created PatternFly, an open source design system that is used to define the design language of Red Hat enterprise applications and websites.
The necessity to create the design system was the result of that team having to frequently redesign and rebuild similar styles and components over and over again. These situations are common reasons why teams and companies unify their design language by investing in design systems.
Challenges and goals
Prior to creating a design system, our teams ran into these challenges:
Sprawl - Too many design tools, outdated templates, and documentation spread out across files, cloud documents, and old websites.
No voice - No unified voice existed when communicating why we do what we do.
No source of truth - No dedicated place for team members or vendors to reference usage standards regarding how to use components (some people made snowflake or custom components or wrote their own rules).
Tech and time debt - Duplicate components were created in new repos as a quick fix which created tech debt. The effort to purge multiple repos of old components wasted time.
To address these challenges, we set a list of goals for our project:
Unified voice - Create tools that give our team a shared voice while enabling us to communicate how we design and code.
Bonds and parity - Learn more from the PatternFly team about how to scale our design system and foster an environment where we can share ideas.
Brand integrations - Collaborate with the Red Hat Brand team to integrate foundational elements like color and typography into our design system.
Defining standards - Write documentation that outlines design system components and patterns while defining the fundamental standards of how to use them.
One source of truth - Create a solution that plugs the leak of inconsistent designs and conflicting documentation while educating people about the correct paths to take.
What we did
In the early stages of the design kit and before the design system website, there was a lot of research and experimentation. We read Medium articles, looked at other design systems, consulted with design system teams at other companies, and more.
Since PatternFly already had an established open source design system, we looked to that team for guidance as we built our design system. The PatternFly design kit is easy to use, the website has a lot of documentation, and the team is focused on accessibility. We felt that we could learn from their processes and work over the years, so it made sense for us to partner with them.
Thought slow, moved fast
When creating the design system website, we had lots of ideas, but we pivoted and iterated fast knowing that our team had set very aggressive deadlines for ourselves. Some features had to be backlogged in order for us to release something lean and fast.
We launched a minimum viable product (MVP) website and surveyed our team members after letting our team use it for a while. We were surprised by the kinds of responses that we received (see the "Eating our own pet food" section).
When creating the design kit, our UX team needed to be unified around one design tool. After auditing design tools and meeting with our team to learn what their needs were, we decided on Adobe XD as our primary user interface and prototyping design tool.
Leveraged brand into foundations
We worked with the Red Hat Brand team to integrate the Red Hat color palette and new fonts into our design system. Color and typography are important foundational elements and crucial to any design system. We credit the Red Hat Brand team for the work it did on those assets.
Before adding components to the design kit, we audited our own work and the PatternFly website. We noticed there were components that we were using several times on multiple pages, like Card, Accordion, and Tabs (see examples below).
PatternFly also had these components as part of its design system, so we decided that they should be the first components in our design kit, but with a different theme. PatternFly components are themed (visually styled) for enterprise products and websites whereas the components the UX team uses are themed for Red Hat's system of websites.
Nowadays, we still audit the PatternFly website before designing and adding new components to our design kit. This prevents us from duplicating work if there is already a PatternFly component that may fit our needs. Most of PatternFly’s components are suited for product or app environments, but if we see something that our marketing team could use, we discuss and prioritize.
Used fundamentals as standards
When writing website documentation for our components, we only wanted to write standards that are fundamental to each component. No fluff, no gray areas, just clear language about how things should be used. We also wanted to include multiple sections so that a user gets the complete picture of a component or pattern—so when they leave the website to start working, all of their questions will have been answered.
Created a single source of truth
The design kit and website can both function as sources of truth. The design kit is the source of truth for the latest components and patterns whereas the website is the source of truth for documentation.
Small team, big launch
A scrappy team of designers, developers, and architects set out to build the design system website in three months. Although the website was just an MVP, it included more than 20 component pages and hundreds of images.
Better internal collaboration
Even before the website launched, we were sharing the design kit with other internal teams and external vendors who also use Adobe XD. Now that the website is live, multiple teams across the organization continue to use the design kit and reference the website for their projects. These resources, in combination with a shared voice, allow us to have more productive conversations and richer working sessions with other design and development teams.
Shared library and hub for documentation
We are unified in our goal of creating harmonious user experiences and developing web components together as a collaborative team. We have shared the design kit across Red Hat teams and even with external vendors like agencies.
Eating our own pet food
Our team has been using the design kit and website for a multitude of projects now as a way of eating our own pet food or as a form of quality control. In the first of our series of quarterly design system surveys, we have received the following testimonials.
"I've been extremely impressed with how much the design kit has grown over the past year, from the range of screen views to the detailed themes. It’s such a helpful and necessary resource."
"The limited amount I’ve used the website, I’ve loved it! I think it’s especially a great resource when working with vendors."
"Overall, I love the website! It's so clean and there’s so much well-thought-out information."
"Love how it's organized, super easy to find what I'm looking for."
New ways of collaborating
Collaboration with the PatternFly team has evolved beyond checking their website every now and then. We attend their design meetings, have discussions with them in Slack, and sometimes contribute to their design system.
Collaboration with our developers has improved as well. For some projects, designers and developers will pair up and work closely on building things together instead of designers handing off specs to developers and then working on other projects. This process of collaboration and communication has transformed the way we work and improved the quality of work that we create.
Surveys and spreadsheets
We rely on our team members to express their opinions about the design kit and website, positive or negative. Their feedback not only helps us understand how to make improvements, but it also gives us ideas about what features to put on the roadmap. Our philosophy is to build what our users want based on their feedback, not dictate what they should or should not use based on our assumptions.
We are also looking into creating a forced ranking spreadsheet in order to prioritize features. This will help us a) audit what features we need to build, b) leverage data to learn how important those features are, c) have more streamlined discussions with developers, and d) provide visibility or reporting to stakeholders about the future of the project.
To contact the design system team or if you want to contribute, start on the UX website.
It has been quite the journey and our work is far from over. We want to build the best product that serves Red Hat employees, customers, and vendors. If you would like to share ideas with us or participate, let us know.
About the author
Corey Vickery is a Senior UX Designer within the Marketing team at Red Hat and is also Lead Designer of the Red Hat design system. He's a cat lover, hiking enthusiast, pretend chef, and wine nerd.