In today’s turbulent landscape of design, Penpot stands out with its commitment to open-source, free unlimited access, and its unique, robust features. An example could be its new components system that takes another leap forward in aligning design with code. Let's dive into how it empowers both designers and developers to create more maintainable and scalable design systems.

Years ago, NASA�s Hubble Space Telescope launched with an error in the telescope�s mirror, which blurred its images for its first years in orbit. For NASA�s upcoming James Webb Space Telescope that is traveling much farther out in space, there can�t be a mistake. Abbott scientists created a technology to calibrate the mirrors on NASA�s new James Webb Space Telescope, which is now the same technology used in the iDesign System that allows ophthalmologists to map the human eye with great precision for a highly personalized LASIK treatment.

Do you remember when having a great website was enough? Now, people are getting answers from Siri, Google search snippets, and mobile apps, not just our websites. Forward-thinking organizations have adopted an omnichannel content strategy, whose mission is to reach audiences across multiple digital channels and platforms.

But how do you set up a content management system (CMS) to reach your audience now and in the future? I learned the hard way that creating a content model—a definition of content types, attributes, and relationships that let people and systems understand content—with my more familiar design-system thinking would capsize my customer’s omnichannel content strategy. You can avoid that outcome by creating content models that are semantic and that also connect related content. 

I recently had the opportunity to lead the CMS implementation for a Fortune 500 company. The client was excited by the benefits of an omnichannel content strategy, including content reuse, multichannel marketing, and robot delivery—designing content to be intelligible to bots, Google knowledge panels, snippets, and voice user interfaces. 

A content model is a critical foundation for an omnichannel content strategy, and for our content to be understood by multiple systems, the model needed semantic types—types named according to their meaning instead of their presentation. Our goal was to let authors create content and reuse it wherever it was relevant. But as the project proceeded, I realized that supporting content reuse at the scale that my customer needed required the whole team to recognize a new pattern.

Despite our best intentions, we kept drawing from what we were more familiar with: design systems. Unlike web-focused content strategies, an omnichannel content strategy can’t rely on WYSIWYG tools for design and layout. Our tendency to approach the content model with our familiar design-system thinking constantly led us to veer away from one of the primary purposes of a content model: delivering content to audiences on multiple marketing channels.

Two essential principles for an effective content model

We needed to help our designers, developers, and stakeholders understand that we were doing something very different from their prior web projects, where it was natural for everyone to think about content as visual building blocks fitting into layouts. The previous approach was not only more familiar but also more intuitive—at least at first—because it made the designs feel more tangible. We discovered two principles that helped the team understand how a content model differs from the design systems that we were used to:

1. Content models must define semantics instead of layout.
2. And content models should connect content that belongs together.

Semantic content models

A semantic content model uses type and attribute names that reflect the meaning of the content, not how it will be displayed. For example, in a nonsemantic model, teams might create types like teasers, media blocks, and cards. Although these types might make it easy to lay out content, they don’t help delivery channels understand the content’s meaning, which in turn would have opened the door to the content being presented in each marketing channel. In contrast, a semantic content model uses type names like product, service, and testimonial so that each delivery channel can understand the content and use it as it sees fit. 

When you’re creating a semantic content model, a great place to start is to look over the types and properties defined by Schema.org, a community-driven resource for type definitions that are intelligible to platforms like Google search.

A semantic content model has several benefits:

• Even if your team doesn’t care about omnichannel content, a semantic content model decouples content from its presentation so that teams can evolve the website’s design without needing to refactor its content. In this way, content can withstand disruptive website redesigns. 
• A semantic content model also provides a competitive edge. By adding structured data based on Schema.org’s types and properties, a website can provide hints to help Google understand the content, display it in search snippets or knowledge panels, and use it to answer voice-interface user questions. Potential visitors could discover your content without ever setting foot in your website.
• Beyond those practical benefits, you’ll also need a semantic content model if you want to deliver omnichannel content. To use the same content in multiple marketing channels, delivery channels need to be able to understand it. For example, if your content model were to provide a list of questions and answers, it could easily be rendered on a frequently asked questions (FAQ) page, but it could also be used in a voice interface or by a bot that answers common questions.

For example, using a semantic content model for articles, events, people, and locations lets A List Apart provide cleanly structured data for search engines so that users can read the content on the website, in Google knowledge panels, and even with hypothetical voice interfaces in the future.

Content models that connect

After struggling to describe what makes a good content model, I’ve come to realize that the best models are those that are semantic and that also connect related content components (such as a FAQ item’s question and answer pair), instead of slicing up related content across disparate content components. A good content model connects content that should remain together so that multiple delivery channels can use it without needing to first put those pieces back together.

Think about writing an article or essay. An article’s meaning and usefulness depends upon its parts being kept together. Would one of the headings or paragraphs be meaningful on their own without the context of the full article? On our project, our familiar design-system thinking often led us to want to create content models that would slice content into disparate chunks to fit the web-centric layout. This had a similar impact to an article that were to have been separated from its headline. Because we were slicing content into standalone pieces based on layout, content that belonged together became difficult to manage and nearly impossible for multiple delivery channels to understand.

To illustrate, let’s look at how connecting related content applies in a real-world scenario. The design team for our customer presented a complex layout for a software product page that included multiple tabs and sections. Our instincts were to follow suit with the content model. Shouldn’t we make it as easy and as flexible as possible to add any number of tabs in the future?

Because our design-system instincts were so familiar, it felt like we had needed a content type called “tab section” so that multiple tab sections could be added to a page. Each tab section would display various types of content. One tab might provide the software’s overview or its specifications. Another tab might provide a list of resources. 

Our inclination to break down the content model into “tab section” pieces would have led to an unnecessarily complex model and a cumbersome editing experience, and it would have also created content that couldn’t have been understood by additional delivery channels. For example, how would another system have been able to tell which “tab section” referred to a product’s specifications or its resource list—would that other system have to have resorted to counting tab sections and content blocks? This would have prevented the tabs from ever being reordered, and it would have required adding logic in every other delivery channel to interpret the design system’s layout. Furthermore, if the customer were to have no longer wanted to display this content in a tab layout, it would have been tedious to migrate to a new content model to reflect the new page redesign.

We had a breakthrough when we discovered that our customer had a specific purpose in mind for each tab: it would reveal specific information such as the software product’s overview, specifications, related resources, and pricing. Once implementation began, our inclination to focus on what’s visual and familiar had obscured the intent of the designs. With a little digging, it didn’t take long to realize that the concept of tabs wasn’t relevant to the content model. The meaning of the content that they were planning to display in the tabs was what mattered.

In fact, the customer could have decided to display this content in a different way—without tabs—somewhere else. This realization prompted us to define content types for the software product based on the meaningful attributes that the customer had wanted to render on the web. There were obvious semantic attributes like name and description as well as rich attributes like screenshots, software requirements, and feature lists. The software’s product information stayed together because it wasn’t sliced across separate components like “tab sections” that were derived from the content’s presentation. Any delivery channel—including future ones—could understand and present this content.

Conclusion

In this omnichannel marketing project, we discovered that the best way to keep our content model on track was to ensure that it was semantic (with type and attribute names that reflected the meaning of the content) and that it kept content together that belonged together (instead of fragmenting it). These two concepts curtailed our temptation to shape the content model based on the design. So if you’re working on a content model to support an omnichannel content strategy—or even if you just want to make sure that Google and other interfaces understand your content—remember:

• A design system isn’t a content model. Team members may be tempted to conflate them and to make your content model mirror your design system, so you should protect the semantic value and contextual structure of the content strategy during the entire implementation process. This will let every delivery channel consume the content without needing a magic decoder ring.
• If your team is struggling to make this transition, you can still reap some of the benefits by using Schema.org–based structured data in your website. Even if additional delivery channels aren’t on the immediate horizon, the benefit to search engine optimization is a compelling reason on its own.
• Additionally, remind the team that decoupling the content model from the design will let them update the designs more easily because they won’t be held back by the cost of content migrations. They’ll be able to create new designs without the obstacle of compatibility between the design and the content, and ​they’ll be ready for the next big thing. 

By rigorously advocating for these principles, you’ll help your team treat content the way that it deserves—as the most critical asset in your user experience and the best way to connect with your audience.

We have a design system, we call it “Beam” ☄️

Beam is our core product design system. We also have a web design system and email design system under the Beam umbrella ☂️

This is how we do design systems…

Read on Twitter or Read on Medium

Brad Frost has got design systems on his mind—at a global scale. What is a global design system? Are two design systems ever the same? How would this slot inside atomic design? What has been the response from the web community to global design system as an idea? And what's Frostapalooza?

Jina Anne silences the night to talk about how we talk about Design Systems. Can the language we use impact the effectiveness of the solution? Fear not, if mighty dread has seized your troubled mind. Design systems of great joy we bring to you and all mankind.

---

Ooh, clickbaity title. Why on earth would I, a self-proclaimed “design systems advocate”, say there is no design system? Yes, I’m being a little tongue-in-cheek. Maybe I just wanted an excuse to use the “there is no spoon” gif. But I do have an actual point, so bear with me.

Design systems as a “thing” vs design systems as a methodology

Recently I tweeted my thoughts on why I have been tending to use design systems in plural form (rather than using an article like “a” or “the” in front of it). During my time at Salesforce when our team was called “Design Systems” and my role was “Lead Designer, Design Systems”, I would get asked “Why is it plural? We only have one.”.

My thoughts:

I liked my title at Salesforce as “Lead Designer, Design Systems”.

People asked, but it’s just one. Why plural?

“A design system” or “The design system” makes people think of a deliverable artifact/library.

But it’s ongoing design systems work. Process improvement & workflows.

— design systems jina (@jina) December 12, 2019

Lately, I’ve been thinking a lot about the way we talk about design systems, including the confusion and negativity that can come along with it. Amélie Lamont gave a talk in 2018 called “The Language of Design”, and in it, she talked about the way we talk about design systems and design itself from a “jargony point of view”. She argues that design is technically problem-solving.

I definitely agree. People get caught up in “design” as the actual role or action of designing and have even taken issue with the term “design systems” for this very reason (and have suggested it be more focused on code). I don’t think it really does us a good service to just swap out one role for the other. And… is it even about the role?

For other folks, which I include myself, we see design as a larger effort that involves the end-user experience (which includes usability, accessibility, performance, etc) as well as having a huge impact on the business. This includes code.

But really, it should all be focused on people. I like Mina Markham’s definition of what makes for good art direction in design systems:

Art direction is progressive. Localized. Cross-functional. Inclusive. Systematic.

Mina Markham

You’ll notice that the emphasis of what she speaks about is on people.

So in the design systems work we do, you often think of a style guide. Or a component library. Or a Sketch UI Kit. And there are arguments on whether either of those things can be called a design system if it doesn’t include this other thing or that other thing. We even talk about whether design systems are products or are more of a service. My take? The word “design” and “system” used in combination together literally just means to systemize your design (and in my world view that is more about the overall experience). And so if for you that means a Sketch UI Library, then you do you! My point is I think there is too much focus on the deliverables in the first place.

I touched on this briefly very recently:

Something I’ve been thinking a lot about is how much time we spend on making beautiful design system websites. I love looking at them. They’re great. But as our design and engineering tools get closer and closer together, will we come to a point where we don’t need the website? Can our tools surface suggestions for better accessibility, localization, performance, and usability, because our design system is baked into the tools? Just a thought.

Quote from post in Smarter Design Systems Tools

Invisible Design Systems?

So this is something I am striving for in 2020 — in what ways can we improve our collaboration, remove any proverbial gaps between design and engineering (not just bridge them), and have more meaningful conversations around the work we do? I don’t have any wrong or right answers here, but I am looking forward to seeing this progress in our field.

Design tools are bringing in smarter, automated ways to check for color contrast and other accessibility issues that can be detected early on. Sketch just announced their Assistant feature planned for 2020, which will check for your visual design discrepancies. And some design tools are using real code to be used in your product.

Engineering tools are advancing every day as well. I was just attending Flutter Interact recently, which was an event held by Google about their Flutter UI toolkit. It previously enabled you to get apps built for native platforms like Android and iOS, from one code base, and now has also announced their support for desktop and web. The push at this year’s event was focused on making this approachable for creatives (with their integrations into tools like Adobe XD. It really does feel like design and engineering tools are coming closer and closer together. And that’s all really cool and exciting.

However, I have to tell you: a lot of the time that I’m working in design systems, I’m not even touching a design tool. Or coding. Rather, it’s a lot of people-focused work: Reviewing. Advising. Organizing. Coordinating. Triaging. Educating. Supporting. That’s a lot of invisible systems work right there. (I use “invisible” here to mean there is not a direct tangible object in some of this work, though it all does serve the end-user through the product outcomes).

Designed objects are the fruit of invisible systems.

Amélie Lamont

This definitely is not me saying “don’t build a style guide” or “don’t make a Sketch UI Kit”. Use whatever works best for your organization. But this essentially is a plea to always put the focus on the people using your products. And, think about design systems as more of a methodology. A shining example of this way of designing systems is the newly released Encore from Spotify. I had the opportunity to see this revealed at Design Systems London, and they just published a post on it recently.

What’s different about Encore is that it isn’t a single monolithic thing. It’s a framework that brings Spotify’s existing design systems under one brand—a “system of systems.”

Source: Reimagining Design Systems at Spotify

This design systems work is not about one style guide website and instead focuses on the needs across several systems that are connected. Design Tokens help this to be a reality. Needless to say, I’m a big fan.

Love for your community

Design system principle #4: Favor community over control.

— Nathan Curtis (@nathanacurtis) March 23, 2017

When you’re doing design systems work in your organization, you are actually building a community. This can involve shared language and nomenclature, an aligned purpose, and better, closer collaboration. It doesn’t have to be a “style police” situation (I actually very much dislike the term “governance”). This can be a joint effort – working together to share the ownership of design systems together.

I was a big fan of the pairing model that we had at Salesforce when I was there. The work we did in design systems informed the work our product designers did. But then the work that the product designers did, in turn, informed the work we did in design systems. It was a very cyclical model and combined Nathan Curtis’s observed models of the Centralized Team and the Federated Contributors.

From my experience, I have found that great design systems teams have hybrid skillsets. Whether that is having actual hybrid designer/engineers on the team, or just ensuring that those skillsets are represented across the team, it’s important to have the perspectives of design, engineering, product, content, accessibility, and more.

I think that part of a designer’s role – and not even a designer. Anybody who uses the design system by nature of what a design system is – it’s the conglomeration of all the disciplines. Some code, some design, some product knowledge, some writing. And what that means is I think everybody on the team has to approach it with some humility.

Dan Mall

Kim Williams spoke recently in her talk, Start with your Brand Purpose, on Design Systems Love:

Love is patient. With design systems, …it’s a marathon and not a sprint. …this is a long game and it is a labor of love. And love is kind. We support everyone through change. Internally change is so hard. How do you help engineers work in a different way, how do you help PMs think strategically and embrace a new definition of analytical, how do you make in-roads with marketing so that they’re comfortable with you talking about brand and that you’re comfortable with marketing talking about user experience? How do you really, really build those relationships up through empathy. …the onus is on us to educate, to facilitate, to help others understand, to speak the language, to be that bridge, to be that connector, to be that catalyst for our companies. It always trusts, always hopes, always perseveres. Never fails. I love this because there’s a resiliency that we need to have, a resilience when we go through this.

Kim Williams

I love, love, love that.

And so while I still think it’s fun to explore new tools and get really excited about certain processes, at the end of the day, (in my most humble opinion), the best design systems teams are not just hybrid teams — they are also teams that work and supports each other really well, thus producing amazing user-centered work.

So, my suggestion for the coming year is to perhaps move away from thinking of design systems as an actual thing (especially when it comes to the negative perception of spending time on them) and more as a way of working better, more efficiently, and more creatively so that we can build great experiences for our users. I like to repeat in my work, Design Systems are for people, because it is a call to cherish, support, and empower the people you serve (both internally and externally).

Happy holidays!

---

About the author

Jina is a design systems advocate and coach. At Amazon, Jina was Senior Design Systems Lead. At Salesforce, she was Lead Designer on the Lightning Design System. She led the CSS architecture and style guide for the Apple Online Store. She’s also worked at GitHub, Engine Yard, Crush + Lovely, and Memphis Brooks Museum of Art, and more. She developed projects with W3C, Mass.gov, FedEx, etc.

Jina coauthored Design Systems Handbook, Fancy Form Design, and The Art & Science of CSS. She’s published several articles. She’s spoken at conferences including Adobe MAX. Print Magazine featured Jina as a leading San Francisco creative.

More articles by Jina

Amy Hupe prepares a four bird roast of tasty treats so we can learn how the needs of many different types of users can be served through careful implementation of components within a design system.

---

Design systems help us to make our products consistent, and to make sure we’re creating them in the most efficient way possible. They also help us to ensure our products are designed and built to a high quality; that they’re not only consistent in appearance, and efficiently-built, but that they are good. And good design means accessible design.

1 in 5 people in the UK have a long term illness, impairment or disability – and many more have a temporary disability. Designing accessible services is incredibly important from an ethical, reputational and commercial standpoint. For EU government websites and apps, accessibility is also a legal requirement.

With that in mind, I’ll explain the four main ways I think we can use design systems to promote accessible design within an organisation, and what design systems can’t do.

1. Bake it in

Design systems typically provide guidance and examples to aid the design process, showing what best practice looks like. Many design systems also encompass code that teams can use to take these elements into production. This gives us an opportunity to build good design into the foundations of our products, not just in terms of how they look, but also how they work. For everyone.

Let me give an example.

The GOV.UK Design System contains a component called the Summary list. It’s used in a few different contexts on GOV.UK, to summarise information. It’s often used at the end of a long or complex form, to let users check their answers before they send them, like this:

Users can review the information and, if they’ve entered something incorrectly, they can go back and edit their answer by clicking the “Change” link on the right-hand side. This works well if you can see the change link, because you can see which information it corresponds to.

In the top row, for example, I can see that the link is giving me the option to change the name I’ve entered because I can see the name label, and the name I put in is next to it.

However, if you’re using a screen reader, this link – and all the others – will just say “change”, and it becomes harder to tell what you’re selecting. So to help with this, the GOV.UK Design System team added some visually-hidden text to the code in the example, to make the link more descriptive.

Sighted users won’t see this text, but when a screen reader reads out the link, it’ll say “change name”. This makes the component more accessible, and helps it to satisfy a Web Content Accessibility Guidelines (WCAG 2.1) success criterion for links which says we must “provide link text that identifies the purpose of the link without needing additional context”.

By building our components with inclusion in mind, we can make it easier to make products accessible, before anyone’s even had to think about it. And that’s a great starting point. But that doesn’t mean we don’t have to think about it – we definitely do. And a design system can help with that too.

2. Explain it

Having worked as the GOV.UK Design System’s content designer for the best part of 3 years, I’m somewhat biased about this, but I think that the most valuable aspect of a design system is its documentation.

(Here’s a shameless plug for my patterns Day talk on design system documentation earlier this year, if you want to know more about that.)

When it comes to accessibility, written documentation lets us guide good practice in a way that code and examples alone can’t.

By carefully documenting implementation rules for each component, we have an opportunity to distribute accessible design principles throughout a design system. This means design system users encounter them not just once, but repeatedly and frequently, in various contexts, which helps to build awareness over time.

For instance, WCAG 2.1 warns against using colour as “the only visual means of conveying information, calling an action, prompting a response or distinguishing a visual element”. This is a general principle to follow, but design system documentation lets us explain how this relates to specific components.

Take the GOV.UK Design System’s warning buttons. These are used for actions with serious, often destructive consequences that can’t easily be undone – like permanently deleting an account.

The example doesn’t tell you this, but the guidance explains that you shouldn’t rely on the red colour of warning buttons to communicate that the button performs a serious action, since not all users will be able to see the colour or understand what it signifies.

Instead, it says, “make sure the context and button text makes clear what will happen if the user selects it”. In this way, the colour is used as an enhancement for people who can interpret it, but it’s not necessary in order to understand it.

Making the code in our examples and component packages as accessible as possible by default is really important, but written documentation like this lets us be much more explicit about how to design accessible services.

3. Lead by example

In our design systems’ documentation, we’re telling people what good design looks like, so it’s really important that we practice what we preach.

Design systems are usually for members of staff, rather than members of the public. But if we want to build an inclusive workplace, we need to hold them to the same standards and ensure they’re accessible to everyone who might need to use them – today and in the future.

One of the ways we did this in my team, was by making sure the GOV.UK Design System supports users who need to customise the colours they use to browse the web. There are a range of different user needs for changing colours on the web. People who are sensitive to light, for instance, might find a white background too bright. And some users with dyslexia find certain colours easier to read than others.

My colleague, Nick Colley, wrote about the work we did to ensure GOV.UK Design System’s components will work when users change colours on GOV.UK. To ensure we weren’t introducing barriers to our colleagues, we also made it possible to customise colours in the GOV.UK Design System website itself.

Building this flexibility into our design system helps to support our colleagues who need it, but it also shows others that we’re committed to inclusion and removing barriers.

4. Teach it

The examples I’ve drawn on here have mostly focused on design system documentation and tooling, but design systems are much bigger than that. In the fortuitously-timed “There is No Design System”, Jina reminds us that tooling is just one of the ways we systematise design:

…it’s a lot of people-focused work: Reviewing. Advising. Organizing. Coordinating. Triaging. Educating. Supporting.”

To make a design system successful, we can’t just build a set of components and hope they work. We have to actively help people find it, use it and contribute to it. That means we have to go out and talk about it. We have to support people in learning to use it and help new teams adopt it. These engagement activities and collaborative processes that sit around it can help to promote awareness of the why, not just the what.

At GDS, we ran workshops on accessibility in the design system, getting people to browse various web pages using visual impairment simulation glasses to understand how visually impaired users might experience our content. By working closely with our systems’ users and contributors like this, we have an opportunity to bring them along on the journey of making something accessible.

We can help them to test out their code and content and understand how they’ll work on different platforms, and how they might need to be adjusted to make sure they’re accessible. We can teach them what accessibility means in practice.

These kinds of activities are invaluable in helping to promote accessible design thinking. And these kinds of lessons – when taught well – are disseminated as colleagues share knowledge with their teams, departments and the wider industry.

What design systems can’t do

Our industry’s excitement about design systems shows no signs of abating, and I’m excited about the opportunities it affords us to make accessible design the default, not an edge case. But I want to finish on a word about their limitations.

While a design system can help to promote awareness of the need to be accessible, and how to design products and services that are, a design system can’t make an organisation fundamentally care about accessibility.

Even with the help of a thoughtfully created design system, it’s still possible to make really inaccessible products if you’re not actively working to remove barriers. I feel lucky to have worked somewhere that prioritises accessibility. Thanks to the work of some really brilliant people, it’s just part of the fabric at GDS. (For more on that work and those brilliant people, I can’t think of a better place to start than my colleague Ollie Byford’s talk on inclusive forms.)

I’m far from being an accessibility expert, but I can write about this because I’ve worked in an organisation where it’s always a central consideration. This shouldn’t be something to feel lucky about. It should be the default, but sadly we’re not there yet. Not even close.

Earlier this year, Domino’s pizza was successfully sued by a blind customer after he was unable to order food on their website or mobile app, despite using screen-reading software. And in a recent study carried out by disability equality charity, Scope, 50% of respondents said that they had given up on buying a product because the website, app or in-store machine had accessibility issues.

Legally, reputationally and most importantly, morally, we all have a duty to do better. To make sure our products and services are accessible to everyone. We can use design systems to help us on that journey, but they’re just one part of our toolkit.

In the end, it’s about committing to the cause – doing the work to make things accessible. Because accessible design is good design.

---

About the author

Amy is a content specialist and design systems advocate who’s spent the last 3 years working as a Senior Content Designer at the Government Digital Service.

In that time, she’s led the content strategy for the GOV.UK Design System, including a straightforward and inclusive approach to documentation.

In January, Amy will continue her work in this space, in her new role as Product Manager for Babylon Health’s design system, DNA.

More articles by Amy

Years ago, NASA’s Hubble Space Telescope launched with an error in the telescope’s mirror, which blurred its images for its first years in orbit. For NASA’s upcoming James Webb Space Telescope that is traveling much farther out in space, there can’t be a mistake. Abbott scientists created a technology to calibrate the mirrors on NASA’s new James Webb Space Telescope, which is now the same technology used in the iDesign System that allows ophthalmologists to map the human eye with great precision for a highly personalized LASIK treatment.

Yesenia Perez-Cruz started her career as a designer at Happy Cog Philadelphia. From the first day, her design gifts were unmistakable. As her career progressed, she moved from one challenging role to another. At companies like Vox Media and Shopify, and at conferences around the world, she has been a design team leader, a popular […]

The post Expressive Design Systems appeared first on Zeldman on Web & Interaction Design.

Our mission is to make cloud computing accessible to everyone. We build products for developers and designers. And those who aspire to become one.

In his Putting the 'Design' in Design Systems presentation at An Event Apart in Seattle, Dan Mall talked about the benefits of design systems for designers and how ensure they can be realized. Here's my notes from his talk:

• Most content in design systems are not for designers but for developers. This helps to scale design efforts when there's a lot more developers than designers (typical in many companies).
• But where does design and designers fit within a design system? Are they no longer required?
• Design can be part of strategy and big picture thinking but most designers are good at making designs and iterating them, not working across the company on "big D" design.
• When it comes time to make a design system, most people start with "let's make some components!". This is problematic because its missing "for ____". What's the purpose of our design system? Who is it for?
• Design systems need a focus. One company's design system should not work for another company. A good "onlyness" statement can only apply to one company, it would not work for other companies.
• Design system principles can guide your work. Some are universal like: accessible, simple. Others should be very specific so you can focus on what matters for you.
• An audit of common components in design systems shows the coverage varies between companies; the components can focus on their core value.
• Instead of starting with making design components, think about what components you actually need. Then make some pilot screens as proofs of concept for a design system. Will you be able to make the right kinds of things?
• Don't start at the abstract level, start at the extract level. Take elements from within pilot designs and look for common components to pull out for reuse. Don't try to make it cover all use cases yet. As you work through a few pilots, expand components to cover additional use cases you uncover.
• The most exciting design systems are boring. About 80% of the components you're making can be covered by your design system. They allow you to remake product experiences quickly. The remaining 20% is what designers still need to do: custom design work.
• A good design system takes care of the stuff you shouldn't reinvent and allows you to spend time on where it matters.
• Creative people are driven by autonomy, mastery, and purpose. A good design system will enable all of these.
• The most common benefits of design systems are greater efficiency and consistency. But another important one is relief from having to do mundane design work. (editor's note: like maintaining & updating a design system!)
• The real value of a design system is to help us get back to our real work.

Jina Anne silences the night to talk about how we talk about Design Systems. Can the language we use impact the effectiveness of the solution? Fear not, if mighty dread has seized your troubled mind. Design systems of great joy we bring to you and all mankind.

---

Ooh, clickbaity title. Why on earth would I, a self-proclaimed “design systems advocate”, say there is no design system? Yes, I’m being a little tongue-in-cheek. Maybe I just wanted an excuse to use the “there is no spoon” gif. But I do have an actual point, so bear with me.

Design systems as a “thing” vs design systems as a methodology

Recently I tweeted my thoughts on why I have been tending to use design systems in plural form (rather than using an article like “a” or “the” in front of it). During my time at Salesforce when our team was called “Design Systems” and my role was “Lead Designer, Design Systems”, I would get asked “Why is it plural? We only have one.”.

My thoughts:

I liked my title at Salesforce as “Lead Designer, Design Systems”.

People asked, but it’s just one. Why plural?

“A design system” or “The design system” makes people think of a deliverable artifact/library.

But it’s ongoing design systems work. Process improvement & workflows.

— design systems jina (@jina) December 12, 2019

Lately, I’ve been thinking a lot about the way we talk about design systems, including the confusion and negativity that can come along with it. Amélie Lamont gave a talk in 2018 called “The Language of Design”, and in it, she talked about the way we talk about design systems and design itself from a “jargony point of view”. She argues that design is technically problem-solving.

I definitely agree. People get caught up in “design” as the actual role or action of designing and have even taken issue with the term “design systems” for this very reason (and have suggested it be more focused on code). I don’t think it really does us a good service to just swap out one role for the other. And… is it even about the role?

For other folks, which I include myself, we see design as a larger effort that involves the end-user experience (which includes usability, accessibility, performance, etc) as well as having a huge impact on the business. This includes code.

But really, it should all be focused on people. I like Mina Markham’s definition of what makes for good art direction in design systems:

Art direction is progressive. Localized. Cross-functional. Inclusive. Systematic.

Mina Markham

You’ll notice that the emphasis of what she speaks about is on people.

So in the design systems work we do, you often think of a style guide. Or a component library. Or a Sketch UI Kit. And there are arguments on whether either of those things can be called a design system if it doesn’t include this other thing or that other thing. We even talk about whether design systems are products or are more of a service. My take? The word “design” and “system” used in combination together literally just means to systemize your design (and in my world view that is more about the overall experience). And so if for you that means a Sketch UI Library, then you do you! My point is I think there is too much focus on the deliverables in the first place.

I touched on this briefly very recently:

Something I’ve been thinking a lot about is how much time we spend on making beautiful design system websites. I love looking at them. They’re great. But as our design and engineering tools get closer and closer together, will we come to a point where we don’t need the website? Can our tools surface suggestions for better accessibility, localization, performance, and usability, because our design system is baked into the tools? Just a thought.

Quote from post in Smarter Design Systems Tools

Invisible Design Systems?

So this is something I am striving for in 2020 — in what ways can we improve our collaboration, remove any proverbial gaps between design and engineering (not just bridge them), and have more meaningful conversations around the work we do? I don’t have any wrong or right answers here, but I am looking forward to seeing this progress in our field.

Design tools are bringing in smarter, automated ways to check for color contrast and other accessibility issues that can be detected early on. Sketch just announced their Assistant feature planned for 2020, which will check for your visual design discrepancies. And some design tools are using real code to be used in your product.

Engineering tools are advancing every day as well. I was just attending Flutter Interact recently, which was an event held by Google about their Flutter UI toolkit. It previously enabled you to get apps built for native platforms like Android and iOS, from one code base, and now has also announced their support for desktop and web. The push at this year’s event was focused on making this approachable for creatives (with their integrations into tools like Adobe XD. It really does feel like design and engineering tools are coming closer and closer together. And that’s all really cool and exciting.

However, I have to tell you: a lot of the time that I’m working in design systems, I’m not even touching a design tool. Or coding. Rather, it’s a lot of people-focused work: Reviewing. Advising. Organizing. Coordinating. Triaging. Educating. Supporting. That’s a lot of invisible systems work right there. (I use “invisible” here to mean there is not a direct tangible object in some of this work, though it all does serve the end-user through the product outcomes).

Designed objects are the fruit of invisible systems.

Amélie Lamont

This definitely is not me saying “don’t build a style guide” or “don’t make a Sketch UI Kit”. Use whatever works best for your organization. But this essentially is a plea to always put the focus on the people using your products. And, think about design systems as more of a methodology. A shining example of this way of designing systems is the newly released Encore from Spotify. I had the opportunity to see this revealed at Design Systems London, and they just published a post on it recently.

What’s different about Encore is that it isn’t a single monolithic thing. It’s a framework that brings Spotify’s existing design systems under one brand—a “system of systems.”

Source: Reimagining Design Systems at Spotify

This design systems work is not about one style guide website and instead focuses on the needs across several systems that are connected. Design Tokens help this to be a reality. Needless to say, I’m a big fan.

Love for your community

Design system principle #4: Favor community over control.

— Nathan Curtis (@nathanacurtis) March 23, 2017

When you’re doing design systems work in your organization, you are actually building a community. This can involve shared language and nomenclature, an aligned purpose, and better, closer collaboration. It doesn’t have to be a “style police” situation (I actually very much dislike the term “governance”). This can be a joint effort – working together to share the ownership of design systems together.

I was a big fan of the pairing model that we had at Salesforce when I was there. The work we did in design systems informed the work our product designers did. But then the work that the product designers did, in turn, informed the work we did in design systems. It was a very cyclical model and combined Nathan Curtis’s observed models of the Centralized Team and the Federated Contributors.

From my experience, I have found that great design systems teams have hybrid skillsets. Whether that is having actual hybrid designer/engineers on the team, or just ensuring that those skillsets are represented across the team, it’s important to have the perspectives of design, engineering, product, content, accessibility, and more.

I think that part of a designer’s role – and not even a designer. Anybody who uses the design system by nature of what a design system is – it’s the conglomeration of all the disciplines. Some code, some design, some product knowledge, some writing. And what that means is I think everybody on the team has to approach it with some humility.

Dan Mall

Kim Williams spoke recently in her talk, Start with your Brand Purpose, on Design Systems Love:

Love is patient. With design systems, …it’s a marathon and not a sprint. …this is a long game and it is a labor of love. And love is kind. We support everyone through change. Internally change is so hard. How do you help engineers work in a different way, how do you help PMs think strategically and embrace a new definition of analytical, how do you make in-roads with marketing so that they’re comfortable with you talking about brand and that you’re comfortable with marketing talking about user experience? How do you really, really build those relationships up through empathy. …the onus is on us to educate, to facilitate, to help others understand, to speak the language, to be that bridge, to be that connector, to be that catalyst for our companies. It always trusts, always hopes, always perseveres. Never fails. I love this because there’s a resiliency that we need to have, a resilience when we go through this.

Kim Williams

I love, love, love that.

And so while I still think it’s fun to explore new tools and get really excited about certain processes, at the end of the day, (in my most humble opinion), the best design systems teams are not just hybrid teams — they are also teams that work and supports each other really well, thus producing amazing user-centered work.

So, my suggestion for the coming year is to perhaps move away from thinking of design systems as an actual thing (especially when it comes to the negative perception of spending time on them) and more as a way of working better, more efficiently, and more creatively so that we can build great experiences for our users. I like to repeat in my work, Design Systems are for people, because it is a call to cherish, support, and empower the people you serve (both internally and externally).

Happy holidays!

---

About the author

Jina is a design systems advocate and coach. At Amazon, Jina was Senior Design Systems Lead. At Salesforce, she was Lead Designer on the Lightning Design System. She led the CSS architecture and style guide for the Apple Online Store. She’s also worked at GitHub, Engine Yard, Crush + Lovely, and Memphis Brooks Museum of Art, and more. She developed projects with W3C, Mass.gov, FedEx, etc.

Jina coauthored Design Systems Handbook, Fancy Form Design, and The Art & Science of CSS. She’s published several articles. She’s spoken at conferences including Adobe MAX. Print Magazine featured Jina as a leading San Francisco creative.

More articles by Jina

Amy Hupe prepares a four bird roast of tasty treats so we can learn how the needs of many different types of users can be served through careful implementation of components within a design system.

---

Design systems help us to make our products consistent, and to make sure we’re creating them in the most efficient way possible. They also help us to ensure our products are designed and built to a high quality; that they’re not only consistent in appearance, and efficiently-built, but that they are good. And good design means accessible design.

1 in 5 people in the UK have a long term illness, impairment or disability – and many more have a temporary disability. Designing accessible services is incredibly important from an ethical, reputational and commercial standpoint. For EU government websites and apps, accessibility is also a legal requirement.

With that in mind, I’ll explain the four main ways I think we can use design systems to promote accessible design within an organisation, and what design systems can’t do.

1. Bake it in

Design systems typically provide guidance and examples to aid the design process, showing what best practice looks like. Many design systems also encompass code that teams can use to take these elements into production. This gives us an opportunity to build good design into the foundations of our products, not just in terms of how they look, but also how they work. For everyone.

Let me give an example.

The GOV.UK Design System contains a component called the Summary list. It’s used in a few different contexts on GOV.UK, to summarise information. It’s often used at the end of a long or complex form, to let users check their answers before they send them, like this:

Users can review the information and, if they’ve entered something incorrectly, they can go back and edit their answer by clicking the “Change” link on the right-hand side. This works well if you can see the change link, because you can see which information it corresponds to.

In the top row, for example, I can see that the link is giving me the option to change the name I’ve entered because I can see the name label, and the name I put in is next to it.

However, if you’re using a screen reader, this link – and all the others – will just say “change”, and it becomes harder to tell what you’re selecting. So to help with this, the GOV.UK Design System team added some visually-hidden text to the code in the example, to make the link more descriptive.

Sighted users won’t see this text, but when a screen reader reads out the link, it’ll say “change name”. This makes the component more accessible, and helps it to satisfy a Web Content Accessibility Guidelines (WCAG 2.1) success criterion for links which says we must “provide link text that identifies the purpose of the link without needing additional context”.

By building our components with inclusion in mind, we can make it easier to make products accessible, before anyone’s even had to think about it. And that’s a great starting point. But that doesn’t mean we don’t have to think about it – we definitely do. And a design system can help with that too.

2. Explain it

Having worked as the GOV.UK Design System’s content designer for the best part of 3 years, I’m somewhat biased about this, but I think that the most valuable aspect of a design system is its documentation.

(Here’s a shameless plug for my patterns Day talk on design system documentation earlier this year, if you want to know more about that.)

When it comes to accessibility, written documentation lets us guide good practice in a way that code and examples alone can’t.

By carefully documenting implementation rules for each component, we have an opportunity to distribute accessible design principles throughout a design system. This means design system users encounter them not just once, but repeatedly and frequently, in various contexts, which helps to build awareness over time.

For instance, WCAG 2.1 warns against using colour as “the only visual means of conveying information, calling an action, prompting a response or distinguishing a visual element”. This is a general principle to follow, but design system documentation lets us explain how this relates to specific components.

Take the GOV.UK Design System’s warning buttons. These are used for actions with serious, often destructive consequences that can’t easily be undone – like permanently deleting an account.

The example doesn’t tell you this, but the guidance explains that you shouldn’t rely on the red colour of warning buttons to communicate that the button performs a serious action, since not all users will be able to see the colour or understand what it signifies.

Instead, it says, “make sure the context and button text makes clear what will happen if the user selects it”. In this way, the colour is used as an enhancement for people who can interpret it, but it’s not necessary in order to understand it.

Making the code in our examples and component packages as accessible as possible by default is really important, but written documentation like this lets us be much more explicit about how to design accessible services.

3. Lead by example

In our design systems’ documentation, we’re telling people what good design looks like, so it’s really important that we practice what we preach.

Design systems are usually for members of staff, rather than members of the public. But if we want to build an inclusive workplace, we need to hold them to the same standards and ensure they’re accessible to everyone who might need to use them – today and in the future.

One of the ways we did this in my team, was by making sure the GOV.UK Design System supports users who need to customise the colours they use to browse the web. There are a range of different user needs for changing colours on the web. People who are sensitive to light, for instance, might find a white background too bright. And some users with dyslexia find certain colours easier to read than others.

My colleague, Nick Colley, wrote about the work we did to ensure GOV.UK Design System’s components will work when users change colours on GOV.UK. To ensure we weren’t introducing barriers to our colleagues, we also made it possible to customise colours in the GOV.UK Design System website itself.

Building this flexibility into our design system helps to support our colleagues who need it, but it also shows others that we’re committed to inclusion and removing barriers.

4. Teach it

The examples I’ve drawn on here have mostly focused on design system documentation and tooling, but design systems are much bigger than that. In the fortuitously-timed “There is No Design System”, Jina reminds us that tooling is just one of the ways we systematise design:

…it’s a lot of people-focused work: Reviewing. Advising. Organizing. Coordinating. Triaging. Educating. Supporting.”

To make a design system successful, we can’t just build a set of components and hope they work. We have to actively help people find it, use it and contribute to it. That means we have to go out and talk about it. We have to support people in learning to use it and help new teams adopt it. These engagement activities and collaborative processes that sit around it can help to promote awareness of the why, not just the what.

At GDS, we ran workshops on accessibility in the design system, getting people to browse various web pages using visual impairment simulation glasses to understand how visually impaired users might experience our content. By working closely with our systems’ users and contributors like this, we have an opportunity to bring them along on the journey of making something accessible.

We can help them to test out their code and content and understand how they’ll work on different platforms, and how they might need to be adjusted to make sure they’re accessible. We can teach them what accessibility means in practice.

These kinds of activities are invaluable in helping to promote accessible design thinking. And these kinds of lessons – when taught well – are disseminated as colleagues share knowledge with their teams, departments and the wider industry.

What design systems can’t do

Our industry’s excitement about design systems shows no signs of abating, and I’m excited about the opportunities it affords us to make accessible design the default, not an edge case. But I want to finish on a word about their limitations.

While a design system can help to promote awareness of the need to be accessible, and how to design products and services that are, a design system can’t make an organisation fundamentally care about accessibility.

Even with the help of a thoughtfully created design system, it’s still possible to make really inaccessible products if you’re not actively working to remove barriers. I feel lucky to have worked somewhere that prioritises accessibility. Thanks to the work of some really brilliant people, it’s just part of the fabric at GDS. (For more on that work and those brilliant people, I can’t think of a better place to start than my colleague Ollie Byford’s talk on inclusive forms.)

I’m far from being an accessibility expert, but I can write about this because I’ve worked in an organisation where it’s always a central consideration. This shouldn’t be something to feel lucky about. It should be the default, but sadly we’re not there yet. Not even close.

Earlier this year, Domino’s pizza was successfully sued by a blind customer after he was unable to order food on their website or mobile app, despite using screen-reading software. And in a recent study carried out by disability equality charity, Scope, 50% of respondents said that they had given up on buying a product because the website, app or in-store machine had accessibility issues.

Legally, reputationally and most importantly, morally, we all have a duty to do better. To make sure our products and services are accessible to everyone. We can use design systems to help us on that journey, but they’re just one part of our toolkit.

In the end, it’s about committing to the cause – doing the work to make things accessible. Because accessible design is good design.

---

About the author

Amy is a content specialist and design systems advocate who’s spent the last 3 years working as a Senior Content Designer at the Government Digital Service.

In that time, she’s led the content strategy for the GOV.UK Design System, including a straightforward and inclusive approach to documentation.

In January, Amy will continue her work in this space, in her new role as Product Manager for Babylon Health’s design system, DNA.

More articles by Amy

Sponsors

• Datadog

• Sentry use code “devchat” for 2 months free

Panel

• Aimee Knight

• Chris Ferdinandi

• Joe Eames

• AJ O’Neal

• Charles Max Wood

With Special Guests: Josh Thomas and Mike Hartington

Episode Summary

Today’s guests Josh Thomas and Mike Hartington are developers for Ionic, with Josh working on the open source part of the framework on Ionic. They talk about their new compiler for web components called Stencil. Stencil was originally created out of work they did for Ionic 4 (now available for Vue, React, and Angular) and making Ionic 4 able to compliment all the different frameworks. They talk about their decision to build their own compiler and why they decided to open source it. Now, a lot of companies are looking into using Stencil to build design systems

The panel discusses when design systems should be implemented. Since Ionic is a component library that people can pull from and use themselves, Jeff and Mike talk about how they are using Stencil since they’re not creating a design system.

The panel discusses some of the drawbacks of web components. They discuss whether or not Cordova changes the game at all. One of the big advantages of using Stencil is the code that is delivered to a browser is generated in such a way that a lot of things are handled for you, unlike in other systems.The panelists talk about their thoughts on web components and the benefits of using a component versus creating a widget the old fashioned way. One such benefit of web components is that you can change the internals of how it works without affecting the API. Josh and Mike talk about some of the abilities of Stencil and compare it to other things like Tachyons. There is a short discussion of the line between frameworks and components and the dangers of pre optimization. If you would like to learn more about Stencil, go to stenciljs.com and follow Josh and Mike @Jtoms1 and @mhartington.

Click here to cast your vote NOW for JavaScript Jabber - Best Dev Podcast Award

Links

• Building Design Systems book

• Stencil

• Cordova

• Shadow DOM

• Tachyons 

• Ionic 4

Follow DevChat on Facebook and Twitter

Picks

Aimee Knight:

• What Does Debugging a Program Look Like?

AJ O’Neal:

• Legend of Zelda: Link’s Awakening

• Neon Genesis Evangelion soundtrack

• Prettier

Chris Ferdinandi:

• Kindle Paperwhite

• Company of One

Charles Max Wood:

• Ladders with feet

• Lighthouse

• Acorns

Joe Eames:

• Moment.js

• How To Increase Your Page Size by 1500% article

• Day.js

Josh Thomas:

• Toy Story 4

Mike Hartington:

• Building Design Systems

• Youmightnotneed.com

Kaelig Deloumeau-Prigent is a self taught web developer from west France. He has worked for BBC, The Guardian, and The Financial Times in the UK. He has also worked in the US for SalesForce and currently works for Shopify on their Polaris design system. Shopify has multiple design systems, and Polaris is open source. Today the panel is talking about design systems and developer tooling around design systems. 

To begin, Kaelig explains what a design system is. A design system is all of the cultural practices around design and shipping a product. It includes things like the words, colors, spacing grid system, and typography, plus guidance on how to achieve that in code. The panelists discuss what has made design systems so popular. Design systems have been around for a while, but became popular due to the shift to components, which has been accelerated by the popularity of React. The term design system is also misused by a lot of people, for it is much more than having a Sketch file. 

Next, they talk about whether design systems fall under the jurisdiction of a frontend developer or web designers. Kaelig has found that a successful design system involves a little bit of everyone and shouldn’t be isolated to one team. They talk about what the developer workflow looks like in a design system. It begins with thinking of a few common rules, a language, and putting it into code. As you scale, design systems can become quite large and it’s impossible for one person to know everything. You either give into the chaos, or you start a devops practice where people start to think about how we build, release, and the path from designer’s brain to production.

The panelists then talk about how to introduce a design system into a company where there are cultural conflicts. Kaelig shares his experience working with SalesForce and introducing a design system there. They discuss what aspects of a design system that would make people want to use it over what the team is currently doing. Usually teams are thankful for the design system. It’s important to build a system that’s complete, flexible, and extensible so that you can adapt it to your team. A good design system incorporates ‘subatomic’ parts like the grid system, color palette, and typography, referred to as design tokens. Design systems enable people to take just the bits of the design system that are interesting to them and build the components that are missing more easily. 

The conversation turns to the installation and upgrade process of a design system. Upgrading is left up to the customer to do on their own time in most cases, unless it’s one of the big customers. They talk about the role of components in upgrading a design system. Kaelig talks about the possibility of Shopify transitioning to web components. Kaelig shares some of his favorite tools for making a design system and how to get started making one. A lot of design teams start by taking a ton of screen shots and looking at all the inconsistencies.Giving them that visibility is a good thing because it helps get everyone get on the same page. The panelists talk about the role of upper management in developing components and how to prioritize feature development. Kaelig talks about what drives the decision to take a feature out. The two main reasons a feature would be removed is because the company wants to change the way things are done and there’s a different need that has arisen. The show concludes by discussing the possibility of a design system getting bloated over time. Kaelig says that Design systems takes some of the burden off your team, help prevent things from getting bloated, allow you to ship less code.

 

Panelists

• Chris Ferdinandi

• Aimee Knight

• Steve Emmerich

With special guest: Kaelig Deloumeau-Prigent

Sponsors

• Sustain Our Software

• Sentry use the code “devchat” for 2 months free on Sentry’s small plan

• Adventures in Blockchain

Links

• Shopify Polaris

• Bootstrap

• React

• Sketch.ui

• Figma.ui 

• CSS

• StoryBook

• ESLint

• Jest

• Ensign

• Webpacker

Follow DevChatTV on Facebook and Twitter

Picks

Steve Emmerich:

• CedarWorks play beds 

• Azure’s container instances

Aimee Knight:

• Awesome Actions for Github

Chris Ferdinandi:

• Free Meek docuseries

• Simplicity: Part 2 by Bastian Allgeier

Kaelig Deloumeau-Prigent:

• Dependabot

• Ink by Vadim Demedez

• Follow Kaelig on Twitter @kaelig

A key part of my job for the past year has been contributing to design systems. To benefit from those contributions though, users need to be able to find them. That’s why it’s not only the content of a design system that’s important but also its usability. Design systems should be easy to navigate, especially […]

In The Design Systems We Swim In, Ethan Marcotte asked a thoughtful question about design systems: Does the system you work with allow you to control the process of your work, to make situational decisions? Or is it simply a set of rules you have to follow? Ethan makes the case that many design systems […]

When we embarked on creating our design system, we unearthed over 50 kinds of buttons and links and 100+ instances of style definitions for type.

At the beginning of every engagement, we spend a great deal of time learning about our client's culture, politics, products, tools, and workflows.