| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 004. You can check out the Episode 004 FigJam file, watch Episode 004 on YouTube, or read the Episode 004 Wrap-up Post! Major thanks to zeroheight and Sparkbox for their sponsorship of The Question this week. ----- It’s become well understood that design system work is people and culture work. Because of this, one of the most important pieces of a holistic design system program is a communication strategy. For the sake of today’s question, I’m defining a design system communication strategy as: "A program intended to spread information throughout an organization about the past, present, and future of that organization’s design system(s)." This would include information about the evolution of the system (issues, features, releases, deprecations, etc), as well as more educational (“how to onboard to the DS”) or engaging (“what would be most valuable for you?”) communications. With this context, I have two questions for you: What groups are a regular part of your current design system communication strategy? What are the core elements of your current design system communication strategy, and how would you change it if you had no constraints? | |||||||||||||||||||||||||
2 | ||||||||||||||||||||||||||
3 | Question 1: What groups are a regular part of your current design system communication strategy? | Question 2: What are the core elements of your current design system communication strategy and how would you change it if you had no constraints? | ||||||||||||||||||||||||
4 | Content,Design,Development,Product | Our current communication strategy is not really based on anything and we sporadically remind ourselves to keep communicating with the teams we support with our product. We are in contact with our respective disciplines (design & development), but that's often focused on small parts of the system such as Figma or the code library. We rarely give a holistic view on the system to these disciplines, which I think would help with their understanding of the bigger picture. We really want a more mature design system where the organisation is aware of the system and aknowledges its value. I think we would need to demonstrate this by measuring the systems' value with some key metrics and spreading communication over the entire organisation instead of just product / design / development / content. I'm not quite sure how to get there yet. Especially because we need to research where the system can add value in all those different spaces that we're not reaching at the moment. We can't talk about our component library with marketing, but we can help facilitate their dialogues with product when it comes to setting up a landing page for a new feature or product. For all these segments to truly acknowledge the system as a product, we've got a long way to go. And I'd love to learn more about the possibilities and key points to look out for in developing a communication strategy. | ||||||||||||||||||||||||
5 | Brand,Design,Development,Executive Leadership,Information Technology (IT),Product,Quality Assurance (QA),Research,User Experience (UX) | Community meetings and office hours sessions with our main user groups- product design and development Process and prioritisation workshops. Educational workshops. A monthly newsletter detailing releases, roadmap, adoption and usage stats plus other general information that changes each month depending on what initiative is being run that month i.e. an education workshop, user satisfaction survey results etc. Regular slack posts I would love to add a podcast interviewing a team using the Design System to help promote adoption but due to the general constraints of those teams, it would be hard to find participants (it can already be difficult to get everyone to attend workshops as everyone is just so busy) | ||||||||||||||||||||||||
6 | Brand,Content,Design,Development,Information Technology (IT),Product,User Experience (UX) | Id say a core element to our design system communication is purpose/audience/message, ensuring we are delivering communication that is wanted. What the Design System did, Why it did, what it's currently doing and what it plans to do next. | ||||||||||||||||||||||||
7 | Brand,Content,Design,Development,Executive Leadership,Product,Research,User Experience (UX) | Quarterly events to showcase highlights from previous quarter, section in monthly business report, Teams channels, email announcements of big updates, sprint reviews and release notes, DS roadshows, adoption case study articles. | ||||||||||||||||||||||||
8 | Brand,Content,Design,Development,Executive Leadership,Information Technology (IT),Marketing,Product,Quality Assurance (QA),User Experience (UX) | Bi-weekly showcases Teams channels for support / discussion: General, Design, Engineering, Brand, Content Quarterly updates to leadership Quarterly planning with Product, Design, and Tech leaders | ||||||||||||||||||||||||
9 | Brand,Content,Design,Development,Executive Leadership,Marketing,Product,Quality Assurance (QA),User Experience (UX) | The core: what was recently released, what will be released soon, major milestones, links to resources including the main Slack channel and how to sign up for more information. This appears in an email to subscribers. Without constraints, it would be largely the same, but just more synchronized: email mailing list, an internal design system website, Slack, and committee meetings. | ||||||||||||||||||||||||
10 | Content,User Experience (UX) | Currently, our design system is being promoted by its creator. This includes road show talks with stakeholders and teams outside of UX, as well as office hours with UX. As the sole content designer creating our content design system, I'd make sure that I was included in all of the above. The value of content guidance within a design system is not 100% understood, so it needs to be part of the overall package when "selling" the system. | ||||||||||||||||||||||||
11 | Content,Design,Development,Executive Leadership,Product,Quality Assurance (QA),Research,User Experience (UX) | All-hands meetings, lunch and learns, monthly & quarterly email updates, slack champions channel (sponsor customers), general slack design systems channel (all customers), ad-hoc slack updates, in-person comms. | ||||||||||||||||||||||||
12 | Design,Product | Core elements would be producing a roadmap that is hosted in a public place where everyone can access it. If I had no constraints I would want to have a monthly check-in with stakeholders from all departments where we make sure everyone's aligned on what we're doing, why and how it will benefit them. | ||||||||||||||||||||||||
13 | Design,Development,Product | Monthly update, breaking changes, quarterly survey, participation in design reviews. If I had no constraints, a design system bot would be awesome, who could answer any questions related to design system assets. | ||||||||||||||||||||||||
14 | Brand,Content,Customer Experience (CX),Design,Development,Executive Leadership,Marketing,Product,Research,Sales,User Experience (UX),Tap into the Customer Service Team!!!! | Feedback Loops is the core to my communication strategy. It is the most important key to learning for the product team. "The feedback we want to find to address the right problem isn’t always clear, since the environment where the many factors are interacting—for example, to cause climate change—is a system of entangled, “moving” parts that touch, and are touched by, many other factors elsewhere." -Interaction-design I establish several feedback loops. Everything and everyone is a system circling back on itself. It's important to workshop with all the cross-functional teams to understand past, current, and future pain points and opportunities. Then, as you release new features or fixes, establish feedback loops with each team. Make sure to check in on them frequently not just with the group. I had one on ones with department heads every other week for 45 min. This kept my meetings focused on getting feedback. We then started building a system to tag feedback and document it so that it would be easy to reference and find again. Documenting feedback in detail is essential to continuous learning and avoiding repeat mistakes. It also creates collaborative learning not just for the product team but for everyone in the company. | ||||||||||||||||||||||||
15 | Content,Design,Development,Product,User Experience (UX) | Mainly, we have a Slack channel and post in there. We know this is insufficient, and intend to split this out into a) one channel dedicated solely to help and support, b) a second channel aimed at more conversation, discussion and collaboration around design systems in general, c) a one-way channel, when we post all updates and announcement about new releases. We also host a bi-weekly office hours style design system review session, on MS Teams. For new starters, we host, 60min remote, group onboarding sessions, which includes a set presentation, with a live demo and Q&A opportunity. We are also intending to introduce: - A monthly email roundup - A microblog/social media feed with bitesize animated content on hints and tips. - Interactive guides to demo the use of more complex components (like Figma presentations which demonstrate how to use their features) - Longer form video content to serve audiences who don't like reading lots of text based documentation. | ||||||||||||||||||||||||
16 | Agency Partners,Customer Experience (CX),Design,Development,Marketing,Quality Assurance (QA) | We utilize a few different resources to uphold our communication strategy and collaboration throughout the different stakeholder groups utilizing our system. For the design and development teams, they work directly within Figma and Confluence adding comments and feedback while updating requirements. This ensures design isn't creating anything that isn't technologically feasible, and ensures tech understands the design specs. Here is also where our accessibility team weighs in. To communicate with external teams, we utilize ZeroHeight and a Storybook instance which has spaces for us to note updates to components and our utility files. These are not as built out, but they will end up becoming a larger part of our strategy as we build things out further. For feedback, we have internal retrospectives (for our internal teams) and quarterly discussion sessions (for our external teams) to gather information on needs and requests. ----- Right now, I feel the most beneficial change we could make would be to have more dedicated time and/or resources that can be put toward making those connections, improving upon communication processes, and gathering the feedback required. | ||||||||||||||||||||||||
17 | Design,Development,Product,User Experience (UX),In-House Accessibility Consultant *Product = Variety of Project/Product teams | We hold two weekly office hours and have a channel where people can post. While the schedule and methods are successful (high attendance and participation), the spaces are more focused around support than honest feedback of the system. Support is very important, but I think folks are resistant to bring critiques to our team. Frustrations often come in the form of a "support question." This is likely due to intimidation and/or feeling like they've given feedback in the past and not had a satisfactory experience. Overall, I would remove that barrier so we could improve faster. | ||||||||||||||||||||||||
18 | Design,Development,User Experience (UX) | Our communication strategy is based on mainly automatic releases notifications (wikipage + email) as well as Teams channel. This covers the present state of affairs. For future development we don't have much other than a Jira backlog. If I had no constraints I'd like to develop an onboarding program aimed to tell about the past and history of the DS as well as the why it was built in the first place. For present and future I could imagine roadshows twice a year with the past 6 months of work and a sneak peak in what comes next. Also I would like to involve upper management with those updates but I don't know in which form. | ||||||||||||||||||||||||
19 | Content,Design,Development,Product,User Experience (UX) | We currently have a forum, teams channel, webinars, office hours, readouts and of course, website documentation. | ||||||||||||||||||||||||
20 | Brand,Content,Design,Development,Research,User Experience (UX) | We don't have one. I'd like to have one. | ||||||||||||||||||||||||
21 | Design,Development,Inclusive Design | Other than a weekly office hours, we don’t really have any core elements because leadership doesn’t currently value communication the same way it values components. If I were to change things without any constraints, I would host a regular conference like Apple’s WWDC to the organization to roll out all updates together with a concise and high quality message. Providing a week of workshops to help teams update and onboard to the design system. | ||||||||||||||||||||||||
22 | Content,Customer Experience (CX),Design,Development,Product,Research,User Experience (UX) | Monthly updates on confluence, broadcast across relevant slack channels. Targeted comms to teams we know it will benefit directly. No constraints? More time on group sessions to share changes and take questions and feedback. Format seems to work well, would love time to explore what would work better. | ||||||||||||||||||||||||
23 | Brand,Design,Development,Marketing,Research,User Experience (UX) | Internal blog posts. I would add one section into company’s internal news letters along with quarterly to biannual readout/shareout depending on the request to share progress and planning for the next quarter/half year. | ||||||||||||||||||||||||
24 | Brand,Design,Development,Executive Leadership,Product | At this point, our current strategy is primarily a concept. However, we have begun to apply it in practice in order to iterate based on feedback and adapt accordingly | ||||||||||||||||||||||||
25 | Design,Development,Executive Leadership | We had a newsletter for a bit but it stalled because it was mandated by engineering to a design team without bandwidth to maintain. In other words, internal design system team communication failure resulted in external communication failure. | ||||||||||||||||||||||||
26 | Design,Development,Research | Release notes and component demos are the core of the strategy. Demos can include hands-on workshops to understand the architecture of the component. Every once in awhile we present our released components (or in progress components) to the larger group which includes executive leadership and QA. If I had no constraints, I'd look at my subscriber groups and really try to understand what artifacts or outputs they would need in order to really be attuned to the design system. | ||||||||||||||||||||||||
27 | Design,Development,User Experience (UX) | Right now we are still building our design system so our primary communication channel is a weekly meeting with design/UX and development. As it grows, I want to include more stakeholders, maybe with a once monthly meeting and/or release notes. | ||||||||||||||||||||||||
28 | Design,Development,Product,User Experience (UX) | I don't know that we've called anything a "communication strategy," rather we've just addressed needs in different contexts. In our DS site we have a "Get started" section with some guides, and a page for UI kit release notes. In Slack we have bots that post when our SVG or Storybook has been updated. And the individual repos have readme files that are a bit more static. There are so many touch points, so with no constraints I'd like to see these things live closer together, or have a centralized place for reporting/subscribing to updates. Our different audiences look in different places, so it could still be a challenge. | ||||||||||||||||||||||||
29 | Design,Development,Research,User Experience (UX) | Communication has been somewhat difficult for my team thus far in our design system implementation. We currently have a very hands-on approach to communication, directly reaching out and working with the teams that consume the design system. We plan to step away from this model soon and rely more heavily on our documentation site, email updates, and office hours. | ||||||||||||||||||||||||
30 | Design,Development,User Experience (UX) | We cover the core bases - what are we doing, what was done, what do we plan to do. To improve this, we are looking to automate chunks of it to reduce overhead for those that compile the communications. | ||||||||||||||||||||||||
31 | Brand,Design,Development,Executive Leadership,Product,User Experience (UX) | Slack announcements, executive status reports, email newsletter. If I had a magic wand, I would communicate through beautifully animated and funny/clever video reels. "If I had more time, I would have written a shorter letter" :) | ||||||||||||||||||||||||
32 | Design,Development,Product,User Experience (UX) | We have little to nothing right now - its HORRIBLE. The most we are doing is running a series of design system episides where we share with a broad audience of product and tech the updates we are making as we move to a world without a true design system to a world with one. Without constraints I would make a very clear RACI chart for all DS work and decisions and use that RACI chart to inform the comms strategy within the working group and for those immediately affected. I would also get rid of teams in favor of slack to help with comms across time zones, companies, and countries for the broader audience | ||||||||||||||||||||||||
33 | Design,Development,Quality Assurance (QA),User Experience (UX) | A teams channel and an intro page for devs and designers? We dont have a good cadence or process built for communication. Eeek! "I couldn't find anything in Okra for animations" –developer A quote from yesterday where one of our devs was trying to replace old jquery interactions on our site. We haven't built out animations in our design system. | ||||||||||||||||||||||||
34 | Design,Development,Executive Leadership,Information Technology (IT),Product,Research | Major releases Changelog Glossaries Metrics w/ no constraints - translate releases into how it affects the company's ROI | ||||||||||||||||||||||||
35 | Brand,Design,Development,Marketing | My design system communication is pretty easy. I do Design/Development/UX/Marketing/Brand. | ||||||||||||||||||||||||
36 | Customer Experience (CX),Design,Development,Product,Quality Assurance (QA),Research,User Experience (UX) | The User Experience team of a designer and 2 front-end developers has its own Jira sprints. We record demos at the end of sprints of new features and components in the library. These are shared with the engineering team leaders. I would like to have a cadence of lunch box learning sessions with engineers and management to listen to how they use the system and suggests on better ways to provide the system for their efficencies. | ||||||||||||||||||||||||
37 | Content,Design,Development,Executive Leadership,User Experience (UX) | Our communication strategy is to align on 1:1s, drop in clinics, updates shared on slack, Onboarding docs. Improved strategy would be (w/o some constraints ) 1. Better onboarding - more doing less reading 2 More team engagement - In DS enhancement workshops or even half a sprint! 3. Better comp guidance- by show and tell is brand new compes. Short snappy and clear guidance. Tools to automate comp updates 4. round table with domain leads on redundancies and aspirations 5. Aligned terminology | ||||||||||||||||||||||||
38 | Design,Research | Currently, our design system is limited to design and interface guidance. Very little input from engineering because there are so many different platforms and codebases to contend with, and not enough engineering resources on the design team. I've interviewed engineering teams and even conducted a survey, but have struggled to come up great action items for next steps in terms of communication. I've thought an annual survey would be helpful, as both a baseline measurement and a way to keep continuous conversation going. | ||||||||||||||||||||||||
39 | Content,Design,Development | New additions and updates to the Design System, current roadmap focus, announcing wins, surveying users to learn about their satisfaction levels on Design System, surveying to learn about the needs for Design System to be able to expand our roadmap | ||||||||||||||||||||||||
40 | Brand,Content,Design,Development,Product,User Experience (UX) | It was a team of product designers in strong collaboration with developers. Product designers did all the research about the brand, ui/ux and were aware of future plans. Developers brought knowledge of the limitations from a technical point of view. This worked very well for us, nothing to change. This may not work as well for larger companies where responsibilities are spread much more widely. | ||||||||||||||||||||||||
41 | Brand,Design,Development,Marketing,User Experience (UX),Channel engagement | We have yet to establish consistent communication outside of the core team. | ||||||||||||||||||||||||
42 | Content,Development,User Experience (UX) | We use zero height for documentation where I (UX) occasionally work with content. Devs fill when they have time to work on it. I also send out end of sprint newsletters for things that happened that sprint. Wish there was a way to populate it quicker. I spend quite a bit of time working on the newsletter every sprint. | ||||||||||||||||||||||||
43 | Brand,Design,Executive Leadership,Product | We have our own coms rituals based on the audience and tailored to the level of information they need. Designers and developers get weekly and bi weekly guilds/office hours. Executive leadership has monthly program report meetings to share metrics and align on priorities. We have a monthly advisory council with representatives from brand, design, dev and ops in order to align on strategy and scope. We also are provided with a quarterly platform for kick off meetings and town halls to share updates on our backlog, releases and adoption for the broader org. Communication is handled wildly different between design and development. They have different rituals and cadences for communication. Aligning the two orgs to have more similar rituals would reduce redundancy and allow us to provide information with equal parity. | ||||||||||||||||||||||||
44 | Design,Development | We (Design) implement changes (e.g. updates and/or new components), and communicate out to Development via Slack. | ||||||||||||||||||||||||
45 | Design,Development,Research,User Experience (UX) | The core elements of our current design system communication strategy are documentation of component libraries and constant updates to the team. | ||||||||||||||||||||||||
46 | Agency Partners,Brand,Content,Design,Development,Executive Leadership,Marketing,Product,Research,User Experience (UX) | Listen less to executives and more to the product teams using the system. | ||||||||||||||||||||||||
47 | ||||||||||||||||||||||||||
48 | ||||||||||||||||||||||||||
49 | ||||||||||||||||||||||||||
50 | ||||||||||||||||||||||||||
51 | ||||||||||||||||||||||||||
52 | ||||||||||||||||||||||||||
53 | ||||||||||||||||||||||||||
54 | ||||||||||||||||||||||||||
55 | ||||||||||||||||||||||||||
56 | ||||||||||||||||||||||||||
57 | ||||||||||||||||||||||||||
58 | ||||||||||||||||||||||||||
59 | ||||||||||||||||||||||||||
60 | ||||||||||||||||||||||||||
61 | ||||||||||||||||||||||||||
62 | ||||||||||||||||||||||||||
63 | ||||||||||||||||||||||||||
64 | ||||||||||||||||||||||||||
65 | ||||||||||||||||||||||||||
66 | ||||||||||||||||||||||||||
67 | ||||||||||||||||||||||||||
68 | ||||||||||||||||||||||||||
69 | ||||||||||||||||||||||||||
70 | ||||||||||||||||||||||||||
71 | ||||||||||||||||||||||||||
72 | ||||||||||||||||||||||||||
73 | ||||||||||||||||||||||||||
74 | ||||||||||||||||||||||||||
75 | ||||||||||||||||||||||||||
76 | ||||||||||||||||||||||||||
77 | ||||||||||||||||||||||||||
78 | ||||||||||||||||||||||||||
79 | ||||||||||||||||||||||||||
80 | ||||||||||||||||||||||||||
81 | ||||||||||||||||||||||||||
82 | ||||||||||||||||||||||||||
83 | ||||||||||||||||||||||||||
84 | ||||||||||||||||||||||||||
85 | ||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||
100 | ||||||||||||||||||||||||||