The panel discussion included speakers Amy Hupe and Andy Welfle, plus Amy Thibodeau and our host Rachel McConnell.
How do you include content patterns in Figma components?
Our attendee Mette wanted to know how designers can easily add content patterns and edit them in their designs to design in a more content-first way. Amy T responds that while she hasn't seen a great approach to doing this in Figma, it's really important to integrate content guidance and patterns in component documentation. Often documentation for design systems has a section on content, but no one visits it except for content designers. Consider how you might put language patterns and guardrails where designers and developers are working and learning about components. In Polaris, the Shopify design system Amy T worked on, the documentation for each relevant component includes guidance about how to think about designing the content — this is every bit as important to understand as how the colour system works!
Andy recommended providing a good example of a pattern within the component in Figma, but it doesn't leave a lot of room for freestanding text. Amy H agreed - use realistic text in component examples and supplement it with guidance that lives with the component, integrated with the technical and design documentation. If you separate it out, you're leaving a strong chance it won't get looked at by the people who need it!
How do you navigate a more long-established design system?
This is all well and good when creating a new system. Our attendee Rachael was after advice when you want to improve a well-established design system from a content design/documentation perspective. Amy H recommends asking all the questions. Be relentlessly curious about the system, its users, and the team that supports it.
- What's going well?
- What do they wish they could change?
- What would they do differently next time?
Design system teams (like any product team) can become bogged down by decisions that were made a long time ago, and this is where fresh perspective can really add value. Is it time to revisit something that didn't work in beta, if that was two years ago? Plus, starting with questions will help to build trust and show that you care about the system and respect its history (and those who worked on it). This is an important foundation for when you want to start introducing changes.
Amy T also advises to be opinionated. Make your list of questions and things you wish you could change and start making the case for them with anyone who will listen to you. Ask why decisions have been made and what the current structure is optimizing for. You've got the benefit of fresh eyes on a system that others on your team have probably been working on for a long time — this is your superpower. Be brave and use it! Andy warns that it matters how you share those opinions - make sure you can clearly articulate why and how words fit into the process, and how you can be just as systematic with words as they are with designs and code. Depending on how content-savvy your content design team is, they may not even realise that! That's a great way to show your value quickly.
Which skills are most important for a content person who manages the design system?
Amy H has three key skills that any content person involved in a design system should have for our attendee Chris:
The ability to get seriously meta and be able to move between the different layers of content design in a system. Some days you'll need to be thinking about the content standards you want the system to embody and distribute. On others, you'll want to be thinking about the content that explains the system - its landing pages, guidance for system users, contribution guidelines etc. You'll need to get comfortable switching between these different aspects of a system.
The desire to work as closely as you can with the system's designers and developers, and the people who use it. Content cuts across everything, so developing a strong understanding of what other disciplines need from the content and how to deliver it to them in a way that makes sense to them is critical. To avoid divorcing content, development and design within the system, it has to be built by a collaborative, multi-disciplinary team.
Finally - the capacity to relentlessly challenge the need to use design system industry vernacular. Design systems are an area of specialism and those of us who work in that area have developed a whole language around it which works great as a shorthand for those in the know but can (and does) alienate those who aren't design system experts - but still very much need to use them. It's your job to simplify, simplify, simplify. Open it up. Do the hard work to make it simple.
How do you approach content localisation in a design system?
Our attendee Teresa wanted to know about our panel's experience and thoughts around content localisation best practices in design systems. Andy mentions as always 'it depends' - on your company, if you have a localisation team, and whether the design system folks have a working relationship with them. He think it's important to establish that as early as possible, so if you don't work with them, set up a meeting and introduce yourselves. Talk about what you do, how you do it, and see how you can help them. Chances are, your scalability can improve their consistency efforts and make sure designs are loc-ready from the start.
Amy T adds even if you're pre-internationalisation and your product isn't being translated, one of the ways you can future proof your language is to have a plan for how you'll deal with colloquialisms and eccentric branded turns of phrases. Having a robust terminology usage list that drives consistent use of terminology is also a good way of future-proofing your content for translation. Amy H warns that components are nearly always built away from specific contexts they're going to be used in, and so they need to be built flexibly - and that includes making sure they can support text strings, language conventions and content formats for all of the localities they'll be used in. A final tip from Andy is to listen to any non-native language speakers in your team. They're likely thinking about localisation and culturalisation from the start -- from something as simple as identifying that "this string will truncate when it's translated into Norweigan" to as complicated as "This icon and colour don't mean what we intend it to mean in this locale."
Is an outdated design system better than none?
Our attendee Kristiina shared that one thing that's discouraging about design systems is how resource-demanding they can be to maintain. Challenging our panellists - is an outdated system better than none? All our panellists agree with Amy T who says no system is better than an outdated one. With an outdated system, it can be really hard for people to trust it as a source of truth.
Design systems don't have to be expansive. Think about what your team needs most and invest in that — it doesn't have to be all things to all people. Her second tip would be to federate ownership. It can be very hard to maintain a system with a small centralized team. Instead, put a couple of people in place to create some tools and workflows that make design system maintenance a company-wide sport shared across people. Many hands make light work.
Amy H recommends a plan to maintain and support a design system beyond its initial development should be part of an MVP. There is a graveyard of abandoned design systems leaving teams unsupported, creating confusion and doing more harm than good. In terms of what to keep in mind, consider the maintenance burden as you go. Anytime you add to the system, make sure you know how you'll continue to support whatever you've just added. If you can't - leave it out. She's also a fan of staggered rollouts. Start small with something rough and scrappy, and test it continuously as you grow the system and invite more teams to use it.
What's the easiest way to let people suggest improvements to the design system's components?
A great question from Matt, Amy T recommends creating rituals that help them understand how to do it and invite them in. Often when people don't contribute it's because it's unclear whether contribution is even welcomed.
For starters Andy can recommend what the design system team at Adobe does - regular share-outs about what's new (with a robust Q&A), open and transparent workshops, bookable office hours, regularly syncs with representatives and partners from each product suite plus a bevvy of Slack channels where anyone can discuss or bring up ideas or critique.
Meeting the team where they are and making sure you're accessible and open in a myriad of channels is a good start! It can often depend on how mature your design system/team is. Amy H adds that in a new design system team, create open forums and touchpoints where people can come along and share their feedback. Keep the process light and focus on open discussion and collaboration. Over time, move towards something more contributor-led, with a documented process to follow and a place to get support if they need it.
All Content by Design ticket holders can re-watch the panel in the On Demand area of the hub until the end of September.
