“Design system” is a misleading term. Design systems go way beyond the needs of design teams; they’re built to unite product teams in their entirety around a central source of truth.
While many design systems are managed by product designers as part of their design role, some larger organizations have chosen to establish design system teams. These teams are usually made up of designers, developers, product managers, and occasionally, content strategists.
Jess Sattell, Senior Content Strategist for Adobe’s design system, Spectrum, shared her thoughts on her role in a design system, how she tests her work, and her biggest contribution to a design system to date.
Knapsack: What’s your role on the Spectrum team?
Jess Sattell: Between the need to have documentation and the need to name things within a design system in a logical and strategic way, a design system team already naturally thinks a lot about language in everything that they’re doing. I work on a gamut of things that reflect this. A large part of my time is focused on creating design documentation and guidelines for the Spectrum website—both the strategy and style for the documentation itself, and also developing standards for UX writing at Adobe. I’m part of Spectrum’s design team, meaning that I ensure that content design and information design are being incorporated into all of our component designs.
Not surprisingly, I also do a lot of naming of things and making sure that we’re doing that naming in a way that’s as straightforward and clear as possible, and in a way that can work across both design and code. I also work on taxonomy and IA—how we identify unique concepts and classify them—and terminology management.
Finally, I work on communication strategies for getting people to use and build with Spectrum. I think this kind of skill is especially valuable for a design system team to have (and that they don’t realize that they need) given that a large amount of what they need to do to be successful is about driving adoption at an organization.
Knapsack: How do you maintain consistency in such a large, complex design system?
JS: A large part of this comes down to creating and nurturing relationships with the users of the design system, and with that, instilling a sense of ownership in those people. If users feel like there’s the opportunity for open communication and that they can contribute to the system, that’s naturally going to make people feel empowered to use it and to advocate for it—which helps maintain consistency.
Knapsack: Do you consider design systems a type of product? If so, why?
JS: Yes and no. I consider a design system to be a meta-product in that it supports another product or number of products, so it’s simultaneously all products and no products!
Knapsack: What’s your greatest contribution to a design system?
JS: People half-jokingly call me a “design therapist” because I’m very good at creating opportunities to have conversations about difficult (and often extremely subjective) human-computer interaction concepts in a way that makes people feel productive, respected, and heard. Related to that, I view my biggest contribution to our design system as being like a cognitive scientist, rather than a writer per se. A lot of my time is spent writing and editing for our website, but all of my work involves thinking through very abstract things with my teammates and helping them to use language and communication to describe the very meta things that are involved in creating the parts of a design system.
For my entire career—even before I got into product design—I’ve been working at the intersection of the visual and the linguistic, and I think my skill with that is very valuable. Several people on the Spectrum team (myself included) went to art school, and that sets us up well to be working in that in-between space. We have a lot of training in how to be comfortable with thinking about things conceptually and with a high degree of ambiguity, and then figuring out how to take that and make it into something tangible.
I really believe that language is an absolutely crucial, and often extremely overlooked, part of the success of a design system. This is because code, design, and words are all languages that have their own logic and syntax, and design systems also use logic and syntax to make sense of abstract and complex things. So it really benefits a team to have someone who is very good at communicating abstract things in a straightforward way, which is a skill that comes naturally to people working in content strategy/content design/UX writing.
Knapsack: What does success look like for you? What are your metrics?
JS: My own idea of success isn’t so much about how many components I’ve shipped or how many new standards I’ve created, although those are obviously important metrics. Success, to me, is when people show me that they’re working with a design system and using guidelines in a way that feels natural and generative, rather than daunting or restrictive. I feel successful when people tell me that, thanks to the resources that I make and to my mentorship, something that was previously complicated is now clear to them.
Knapsack: Do you test your work with the design system’s users? If so, how?
JS: I do test my work, although I would like to be doing more of it. I use pretty straightforward methods: user interviews and usability testing. I do user interviews mainly to try to understand how our users think about design concepts and to see what language they naturally use on their own to talk about those concepts. And we do usability testing on our website to understand how our users look for things and the kind of guidance they come to us for. I also keep an eye on our feedback channels and have my own system of keeping track of questions that designers and engineers ask me as data points that inform how we manage any updates to our guidelines.
Knapsack: What distinguishes your work on a design system from content strategy for a product?
JS: A lot of the same skills apply to both things, but the distinguishing factors come down to the concepts of scale and diplomacy. My work on a design system is about creating something that works on a huge scale and has to take into account several complex systems at once—and then showing people why it works.
The thing I really love about working on a design system is that I’m reconciling two complex systems—design and code—both of which use their own languages and have speakers or practitioners of those languages who use different words for the same concepts. And on top of that, the things that make up a design system (like components, styles, and behaviors) are thought of very differently, depending on who you ask. This gets even more complicated on the scale that Adobe has to work with, which is over a hundred products, each built on a different framework or combination of frameworks, and designing for all kinds of web, mobile, and tablet implementations. This all builds up into layers of very subtle abstractions that create a huge issue about the need for a consistent “source of truth” for design and code choices, and having to coordinate thousands of people across dozens of product launches and across multiple timezones. Strategic communication and naming helps solve that.
With all that in mind, there’s also the need to communicate design and code choices in a way that doesn’t come across as noncommittal (“this is just our opinion”) nor as strict (“you must do this”). It’s about finding a balance between teaching and showing. This is where content strategy skills become very important: we have to show our users, through our guidelines, that we’ve made these decisions based on lots of research, iteration, and testing, and that we’re ensuring that we’re meeting accessibility requirements—and then teach them how these decisions make things in the design system work.
Knapsack: How can a design system be beneficial to a content designer’s work?
JS: Having a design system readily established at a company is very beneficial if you’re looking to start researching, writing, and publishing content standards since a large part of a design system is already about documentation and information management. Also, a design system provides a centralized viewpoint on design at a given organization, which should inform a content designer’s practice.
Knapsack: What does documentation look like for writers/writing?
JS: I see writing as another form of design, so I tend to write documentation in a way that focuses on structure and logic. For example, breaking down a dialog into its component parts and then explaining how all of those parts work together as far as the messaging, tone, and such. I also tend to approach documentation for writers in a way that creates flexible patterns or templates, rather than a methodology of where you’re trying to cover every possible thing and scenario just for the sake of having it documented.
Writers also naturally tend to look to a style guide (something that covers how you format writing, or anything that could be automated into a spell checker or linter) as something solid and foundational that they don’t need to think too hard about or question that often. Having one frees them up to be more creative; they tend to want more flexibility in how they take that foundation of a style guide and then do the actual writing. Again, that’s why I try to design documentation for writing in a way that presents “content” just as you would in the parts of a design system: so that people can use it in a way that makes sense for their product or user needs, rather than being overly prescriptive.
Knapsack: What has your biggest “win” been as a content designer working on a design system?
JS: I actually have two. The first is that I’m really proud of launching Spectrum to the public in fall 2019, and being part of that huge milestone with my team.
The other is that I was the first content designer for the Facebook Design System, and the content design lead for the recent visual redesigns of the Facebook website and mobile app. It felt really great to see how my work on their design system in making sure that content design was part of visual and interaction design decisions was translated into this huge update. It was exciting to be redesigning one of the most iconic websites in the world, and I was really proud of how I was able to partner with researchers to make sure that we were introducing the new visual and functional changes with clear communication.
Knapsack: How do you incorporate accessibility and inclusion into your content design?
JS: Adobe Design’s Content Strategy team takes this very seriously—what we say in products is just as important as how things look. We have an entire guide on the Spectrum website about designing content for accessibility and inclusion, with sections on writing about people, writing for readability, and writing with visuals. This resource is definitely going to evolve and change over time, since language evolves and changes.
Organizationally, the Content Strategy team and the Inclusive Design team (as well as Spectrum) report to the same director at Adobe Design, so we’re set up well to readily collaborate together.
