Table of contents
You’ve just released your latest work on the design system. All the foundations are updated and the new libraries are full of neatly aligned components.
Everyone from the design and development teams is informed about it. You’ve made sure they know which banner to use, and how the components, cards, infoboxes, and everything else, are made and work.
Life is good.
Two weeks later, you open your product’s mobile app and see a marketing promo banner that has nothing to do with the design system. It's an outdated card with the wrong icons.
What. Is. Going. On.
Why has the marketing team completely ignored your hard work? Why do they use their materials and not your awesome design system?
Touchpoints · noun, plural
Digital products today are complex with many touchpoints. Branding, marketing and the product itself often melt together, and boundaries are not at all explicit.
Like in my previous relationships. But I digress.
When team ownership overlaps, it’s not clear where one team’s work ends, and another starts. It gets more and more complicated to keep the interfaces and brand expression consistent. We see this most often with the marketing team, but it can be a problem with any team that contributes to interfaces, such as customer support or sales.
The product team expects the marketing team, or sales team, or even the brand team to be aligned with the design system and work as if they were the design and development team.
But they are not.
They may not have even been involved with the design system before. Are the other teams aware that it exists? Should they use it and provide feedback? Can they access Figma? And most importantly - does the design system support their needs?
Marketing needs are different to product needs: marketing prioritizes expressivity and communication, while the product prioritizes interaction and usability.
Product design standards are different from marketing standards too. The marketing team probably has their own standards and documentation stored somewhere. As they have some influence over the digital product (for example, they create banners and promos for it), their documentation will partially overlap with the design system.
You might think it’s an easy solution - just merge the documentation and then every team will be on the same page. But that’s not the root of the issue here. The real problem is interface ownership.
Who owns the product interfaces?
You might have built the design system as a tool for design and development teams only, because you think the interface is the domain of designers and developers.
Huge misconception.
The product interface is the domain of many teams who all have an interest in, and can influence, the construction of the product.
Teams like marketing, sales and customer support have dedicated roles to play in the digital product: there is the customer support bot, the marketing banner with a new promo, and the onboarding demo. Perhaps there is a call to action for a sales call and a webinar communication on the homepage.
The whole team must be aware of this.
Once everyone understands that each team has an interest in the interface, there should be a discussion about how these different interests fit together in the product. Or, in other words, who has ownership of the interface?
For product companies that have marketing, design and development teams, and someone in charge of the product (e.g. product manager), it makes sense to discuss and agree on a way of working that’s clear for everyone.
When you sit down for this discussion, you’ll find that each team owns the content they contribute to the product, but there are discrepancies in their expectations of how it is shown and who decides how it is shown.
Looking back at the outdated banner on my homepage, marketing probably thought that they were right to use their own design. Meanwhile the designers expected to be the team to choose the design system banner. So, it’s not a problem of documentation, it’s a matter of expectations and ownership.
Does the marketing team know that the design team has a different standard in the product interface?
This calls for a clarification. Design systems could be the solution: many teams use them as a source of truth that collects standards for the product and for marketing as well. But the design system is a tool. And tools can only come after resolving issues with people and alignment.
How to break the status quo
If you’re not talking to other teams about how to work together on the same product, here’s my best advice to break the status quo.
Face the conflict
Gather everyone involved in a case where the teams overlap with design and development. Start by talking about what was good and what went wrong. This highlights the “interface ownership” problem for everyone in the room, so you can really start discussing it.
Map their needs
Make an effort to note down the teams’ needs, by interviewing them and collecting the way they work on the product interface. It’s useful to learn what type of component each team needs and which product areas they care the most about.
Define a standard for the next project
Who has the last word? A designer? A product manager? Should marketing align their material to the brand or the design system?
You have to start somewhere, so define a standard for working on interfaces. Try it on the following project and see how it goes. Have another retrospective afterwards to gather feedback.
Monitor improvements
Have regular meetings, no less than monthly, to discuss how things are going. This will take time to implement (note to self: be patient) so make sure everyone knows that you will have a retrospective on the new structure. It’s their chance for feedback on the new organization asset to be heard.
Agree on the ownership
Talking, shouting, arguing and eventually agreeing on interface ownership won’t make the marketing team do exactly what you say, luckily. It’s more important to have an organization that can speak up about problems and discuss them than to have a shiny, unused design system: this will help you collaborate on product interfaces that look good.
∗ ∗ ∗
Want more insights from our independent research?
- Why is nobody using your incredible design system documentation?
- How do you know if your design system is giving you a return on investment?
- How being too much of a control freak can harm your design system
Want a safe pair of hands to help with your own design system?
Check Design System Audit, our service to make sure your design system brings you results.
