| 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 45, deep dive hosted on February 13, 2025 with Ben Callahan and Doug Neiner. There are 73 answers. The question this week was: ----- Hello curious design system nerds! We’re back this week with one of the most important topics a DS practitioner or leader can consider—how do you stay connected to the actual work? Let me explain. Design systems are especially susceptible to the “Ivory Tower Architecture” problem. That means it’s really easy for us to sit in our ivory towers designing and building all the things we think our consumers will need. After all, we have a really good view from up there. 🫣 As you likely have experienced, this can lead to a design system that is full of things people don’t use. Nobody wants that. There are a lot of ways to combat this problem. As I was chatting with Doug, he shared how his team’s approach to this is to maintain their own example application. This is essentially a little product that exists solely for the design system team to use as a playground that closely mimics how their consumers will use the design system. With an approach like this, you can often catch all kinds of integration issues, you can really understand the impact of changes to your system, and you can start to consider the consumer experience (what it’s like to use your design system). This week on The Question, we’re going to talk about how you stay close to the work. Let’s do it! How often have you and/or your design system team found yourselves in the ivory tower? How often do you and/or your design system team design/build something with your own design system? How do you stay close to the work? | |||||||||||||||||||||||||
2 | Question 1: How often have you and/or your design system team found yourselves in the ivory tower? | Question 2: How often do you and/or your design system team design/build something with your own design system? | Question 3: How do you stay close to the work? | |||||||||||||||||||||||
3 | A lot of the time | Never | Using the customer facing product is one obvious method of staying closer to design system. Additionally, your design system team could implement a variety of strategies, like a rotational embed program, working within a product team for a set period, developing empathy with product teams, using the design system on a daily basis. A team can also, choose random questions from the design system's support channel and conduct a set number of qualitative conversations to learn more about the challenges and friction that teams are facing with the design system. | |||||||||||||||||||||||
4 | Some of the time | Some of the time | I build Figma plugins that solve real-world requests. Also, documentation sites and demo apps using the code. | |||||||||||||||||||||||
5 | Some of the time | A lot of the time | Many synch and asych communicating methods. Building page-level designs with product teams and 'from scratch' | |||||||||||||||||||||||
6 | A lot of the time | Never | Testing is often a skipped step in system or other work, but it is also one of the most valuable. Testing doesn't have to be big and slow, being creative like this example is vital to success and process adoptability. | |||||||||||||||||||||||
7 | A lot of the time | Some of the time | Working hands on with both the design system team and the consumers | |||||||||||||||||||||||
8 | Some of the time | Some of the time | Partnering with product teams for migrations, implementation, and exploration. We try not to do anything in the system unless we can confirm it's needed by multiple teams or will be used in multiple places. | |||||||||||||||||||||||
9 | Some of the time | Some of the time | Our core team has two lead designers, one is responsible for planning and documentation and the other one collaborates closely with the designers in charge of projets. We complement each other. | |||||||||||||||||||||||
10 | A lot of the time | Some of the time | We try to keep an eye on opportunities to dog food the system. i.e Hackathons and during product discovery of high visibility initiatives. We also have playgrounds on each platform to test components ourselves. Sadly, doing user research tends to fall in priority when there's a lot of pressure to deliver results :/ | |||||||||||||||||||||||
11 | A lot of the time | Never | ride-along programs with line of business design teams | |||||||||||||||||||||||
12 | Some of the time | Never | Our team knows we need this, but getting the time and capacity set aside for creating and managing it has been the challenge stopping us. | |||||||||||||||||||||||
13 | Some of the time | Some of the time | We meet with designers and engineers weekly and also run a DS channel on Slack for ongoing questions/conversation. | |||||||||||||||||||||||
14 | Some of the time | Some of the time | Our team has an example application that we refer to as our "QA app" because we run visual diff testing against it before releasing a new version of the design system's code packages. To some extent it's a "kitchen sink" app that makes use of every component, but we also include pages that mimic pages from digital applications across the organization. I, as Design System Manager, also attends a sampling of product squad working sessions each week and attend all UX team demos. I also encourage designers and product team leads to share work in progress at our Design System office hours each week if no one has questions or feature requests. | |||||||||||||||||||||||
15 | Some of the time | Some of the time | We talk to users regularly whether that be for support questions, regular meetings with product teams or sometimes through random run ins with our users. As a product manager, I meet with users regularly for interviews to learn more about their products and the problems they are trying to solve. This also provides me insight into how they are using our DS which I can relay back to my team. For large initiatives, we have regular connection points with the product teams to ensure they are getting what they need of the DS and help them best use the DS. | |||||||||||||||||||||||
16 | Some of the time | A lot of the time | We are an agency with ownership of multiple design systems, we also use almost of the design systems we create - this naturally helps us stay very close to the work. | |||||||||||||||||||||||
17 | Some of the time | A lot of the time | We encourage all new dev and updates to existing experiences to fully align with our new design system and web components, having the web components really helped with dev engagement. | |||||||||||||||||||||||
18 | We build as we see fit and continue evolving and adapting the design system so far. | A lot of the time | Try to keep it consistent and not include new design elements that doesn’t fit the brand or style | |||||||||||||||||||||||
19 | A lot of the time | Some of the time | Attend other team meetings and see how the system is being used in real life and what is and isn't working | |||||||||||||||||||||||
20 | My organization is too small to have this problem, but I want to hear the discussion. | All the time | In my role as an application designer and a front-end developer, I constantly use the design system both in my designs and to improve the design system. | |||||||||||||||||||||||
21 | Some of the time | All the time | My company does not have a design system team. All the designers have product team roles, and we work on the design system on the side. This leads to other problems, but it does keep us very close to the work. | |||||||||||||||||||||||
22 | Some of the time | A lot of the time | Critiques, office hours. I will say its a little easier for us to stay connected right now because we are at the early days of our system, so we're actibly checking in and building the bridges. Definitely thinking about sustained engagement to ensure the right level of support. | |||||||||||||||||||||||
23 | Some of the time | Never | I'm integrated into the product design team (which is already quite small). I participate in the same crits and reviews as product design so both parties are privy to each others' work. | |||||||||||||||||||||||
24 | Some of the time | Some of the time | We learned very fast we have to stay connected to our consumers. On the design side it's easier, since we can construct example pages in Figma and that gives us a very clear indication when something is off (assuming it will be used as intended by designers). On the code side it's way more difficult, since we're dealing with a massive engineering org and dozens of different tech stacks. If something works in a certain flavour of Angular, there's no guarantee it will work in another team's slightly different flavour, not to mention React or any of the other frameworks used. We do have code regression to catch code issues, but it never guarantees the component will work for everyone. None of this, though, fixes the problem of the "ivory tower" and having to stay closely connected to our consumer and their needs, so we know if we're even building the right things. | |||||||||||||||||||||||
25 | Some of the time | All the time | We are building our reference site using our own design system. | |||||||||||||||||||||||
26 | Some of the time | All the time | By staying close to the users and use cases. | |||||||||||||||||||||||
27 | Some of the time | A lot of the time | We have a “dogfood” phase in our process, where before we ship, we make sure to QA in a live build of the product to catch any of those integration issues, dependencies, etc. we also have live previews apps for native that we use internally that help us catch potential issues up front, although their main purpose is to allow our DS designers to QA in a live environment. The only thing I’ve found to keep us out of the ivory tower mindset is to: - attend design reviews to see what’s coming up/stay on top of internal emerging patterns - have our engineers review feature team PRs when they can - office hours (more reactive) - make the full DS team available for bookable pair sessions All of this together works to positions us as partners, rather than a team who sits up in the ivory tower, or a team feels more like a group of external contractors. | |||||||||||||||||||||||
28 | Some of the time | All the time | We constantly ask for feedback from both design and engineers, UX research interviews, and post often in our design review to get higher management involved as well. Basically, over communicating to make sure we have a pulse on what to work on, if we're on the right track and if we need to pivot. | |||||||||||||||||||||||
29 | A lot of the time | Some of the time | For me, it's just the new trends and updates which keeps in touch with the work. As a Design System Engineer, I like to wear multiple hats and talk to both Designers and Developers. | |||||||||||||||||||||||
30 | Some of the time | Some of the time | I first look for any opportunities for my team to operate in a product design role - we sometimes have resourcing gaps that i volunteer my team to fill so they can feel what its like to use what they built. I truly believe that rotating occasionally to support other types of work can give a team great exposure overall so Id like to formalize this even more in the future as well. I also advocate for the team to be in tune with assumptions they make. If were on a call saying "a designer might do x or y" thats a cue to park the comment and just go ask or observe how the work is actually occurring. As DS practitioners we have the luxury of having our users so close to us - we should take more advantage of that! As an IC, i prioritize active listening and observation. If someone is having a problem they reach out about, i ask for their file so i can troubleshoot....but then i creep around at everything else and take note at how the system is being used. Not everyone is going to know theyre even having an issue or will feel comfortable raising it so being proactive has always been helpful here. I also just ask a lot of questions - they might come with one problem but as im listening im able to question other choices and decisions. Through one of these types of convos in our recent office hours we learned that a designer found one of our hidden components that wasnt meant to be used - we learned how persistent our team is and digging for answers alone when they need to. We now plan on shifting our strategy of hidden elements and adding support for the use case that designer was looking for out of the box. This has been on our side of desk backlog but we also sometimes play with using our DS to recreate popular apps - sort of like a lookbook. We want to show how flexible the DS is and how it could be used in other ways so doing this type of exercise gives us exposure to using our own work while also illustrating how the system can flex for our consumers. | |||||||||||||||||||||||
31 | A lot of the time | Some of the time | Due to some big pushes we are going to start doing support rotations. I'm very excited about this because it means we are going to partner with our different teams in their design files and their code to help them do some major upgrades. I love this approach and am hoping we learn a lot about any issues we've built into our system when facing our consumer's real project restraints. | |||||||||||||||||||||||
32 | All the time | Right now the DS team is gathering requirements from across the portfolios to get closer to the work. This should help them prioritize. We are also meeting with them every other week to ask questions and gain input to DS utilization across the teams | ||||||||||||||||||||||||
33 | Some of the time | A lot of the time | We have a weekly meeting every week to discuss what everyone was working on to assist and help everyone else with problems that another designer might have experienced with other product teams. | |||||||||||||||||||||||
34 | Some of the time | A lot of the time | Our team tries to work closely with consumers of our DS but it can be challenging. Our approach includes office hours and workshops we hold on a monthly cadence to get valuable feedback. We also maintain a few demo applications that others can reference while using the design system. We are looking to expand this area as we think it's the best way to help teams get started. Lastly, we occasionally get embedded into feature teams and work with them to build out an application. This is a great approach to uplevel the team and give us valuable info on how team are using the DS and any pain points they are experiencing along the way. | |||||||||||||||||||||||
35 | A lot of the time | Never | In our component roadmap, each has designer stakeholders tagged, and these get involved early on from RFC specs (providing use-cases and requirements) to feedback on design and code demos. We have recently started to look for "component sponsors" as well, meaning a team that would be willing to pilot our new component and prove it's working, before we finalise and mark it as stable. | |||||||||||||||||||||||
36 | Never | Some of the time | It's just me, so... I also do a bit of product work, and review PRs :) | |||||||||||||||||||||||
37 | Some of the time | Some of the time | Or documentation site was built with the design system, so maintaining and adding to that was very helpful in gaining the users perspective. Definitely would be good to work with more data driven components that don't have use cases within the documentation site. We also would act as reviewers on some product implementations of the system to gain insight. | |||||||||||||||||||||||
38 | Some of the time | Some of the time | Through design and tech office hours, fielding questions on our Slack channels and a lot of outreach. Per your last topic, we also utilize our localized systems to stay close to given use cases. | |||||||||||||||||||||||
39 | I don't officially work on the design system team, but as the Director of Product Design at Planview, I work very closely with Doug and the team to help them stay down from that pretty tower. | This will be Doug's time to shine with you, but I would love to observe and maybe I can be in the crowd to verify that what he is saying is 100% real and verified. | Design system designers meet with all of the product designers at least once per month and meet weekly with the product design leaders. Sometimes product designers have done prototype testing to validate patterns and interactions that feed design system requirements. Engineers work closely with product engineers to support them in the use of the product and we adapt as we try new components within the product. We also have plans for a customer conference later this year to do unmoderated studies to test some new components within a test application experience or we will fall back on Figma prototypes if necessary. | |||||||||||||||||||||||
40 | Some of the time | Never | Continuous conversation with designers, combined with DS working group with devs, gives a good temperature check. Having said that, we are at a point where we are working through a tech / design dept and building DS retrospectively, so might be we are just not that mature and have not built our tower yet :D | |||||||||||||||||||||||
41 | A lot of the time | Some of the time | I'm in a constant internal battle between supporting teams by building footguns and not wanting to build said footguns. Some days I can't bear to see the work happening, other days I have the energy to provide guidance. | |||||||||||||||||||||||
42 | Some of the time | Some of the time | Attend every design review you can! We were fortunate to have weekly design leadership experience reviews that I would sit in on. That is where we learned about the latest, most highly prioritized work. My company had a LOT of products, so could not possibly stay up to date on everything. Additionally, make sure you/the DS team are seen as collaborative and helpful, not prescriptive. That way designers share their work in progress with you willingly (during office hours), and you stay in the know. Nothing beats talking to people!! | |||||||||||||||||||||||
43 | Never | All the time | Current project is a weird one... so I'll discuss a previous project instead: I led the UI component library build, as part of a wider project to re-platform a large e-commerce multi-branded website. One of the key aspects of this was to ensure that digital merchandising teams had access to the component lib + docs, early in the project, at the prototyping phase. This enabled them to see in a browser how the UI functioned for all their CMS-integrated "widgets", and they could read any supporting documentation about usage. For example, hero banners, product carousels, product cards, etc. They could "play" with configuration options, which mirrored configurability in the real back-end. They could also test the UI for different brands. This allowed us to (a) rapidly prototype new functionality, and (b) highlight missing functionality prior to integrating with the back-end. ------------------- I've always tried to adopt this approach of early prototyping (e.g. in Storybook) and publishing the component lib, so dev teams, designers, CMS users, product owners, etc, have early visibility. | |||||||||||||||||||||||
44 | Some of the time | Some of the time | - Collaborating with other folks to see how they’re using components & patterns in their feature/product work via attending design reviews, usability testing sessions & just making friends with our partners (possible in a small company where it’s easier to make time to get to know each other and connect at a more personal level) I think it’s a good sign when folks feel comfortable asking for stuff that works for them! - Sprint retros - Putting together prototypes to test DS components or collaborating with product designers to assist when they’re building prototypes for feature work - keeping an “open door” policy | |||||||||||||||||||||||
45 | A lot of the time | A lot of the time | I think we need to get design system team members closer to the customers. While building something with your own design system is great, using that built component for the same purposes as the target customer is another thing entirely. | |||||||||||||||||||||||
46 | Some of the time | A lot of the time | Besides building things regularly we have support ticket intake and a chat channel where people can ask for help. This exposure to what people are trying to achieve, or are struggling with, gives us good examples as to what kinds of things might need attention. If we see patterns of need emerge we'll make a plan to address it. Sometimes this is through development, but sometimes it prompts education efforts. | |||||||||||||||||||||||
47 | Some of the time | Some of the time | Honestly, farther away than I would like. The current team was brought in specifically to work on the design system (me included) so our familiarity with product work isn't the greatest. We've taken steps to reduce that divide by closely partnering with product teams and maintaining several open communication channels and transparency on our current work. | |||||||||||||||||||||||
48 | Consumer, attending for learning! | Consumer, attending for learning! | Consumer, attending for learning! | |||||||||||||||||||||||
49 | Talking with designers and design teams | |||||||||||||||||||||||||
50 | Some of the time | All the time | I'm one of the few product designs within our organization so by nature of my daily responsibilities I'm embedded in the outcome of the library and system I have also established and continue to maintain. | |||||||||||||||||||||||
51 | n/a just didn't get the invite the first time I filled this out so ??? | |||||||||||||||||||||||||
52 | Never | All the time | Small team. The design system is built by the same designers that work on the products. We don't have a separate 'design system team'. | |||||||||||||||||||||||
53 | Some of the time | Some of the time | Area experience reviews | |||||||||||||||||||||||
54 | Some of the time | Some of the time | Collaborative conversations with primary consuming teams. Design groups with design system team members and representatives from consuming teams. | |||||||||||||||||||||||
55 | A lot of the time | Some of the time | Constant communications with product designers. | |||||||||||||||||||||||
56 | Some of the time | A lot of the time | Documentation and presentation of progress made on the design system gives immediate visibility to designers. However, designers need to be reminded of all that exists within the files for them to incorporate into their work. | |||||||||||||||||||||||
57 | Some of the time | Never | Lots of sessions woth our 100+ designers talking about their worj and the system | |||||||||||||||||||||||
58 | Some of the time | A lot of the time | We have an internal docs site that is built with our own components (though we've got some custom "guide site" components powering it also). We often catch bugs this way. We also try to build some complex code examples that combine our components (like, an expandable card with a badge in it and some content that resembles real content) to make sure we can compose the things our users want. Finally, a portion of our team attends UX design reviews to know what is being built and how they're using (or not using) the design system | |||||||||||||||||||||||
59 | Some of the time | A lot of the time | Historically this has been a huge challenge, but I think we are moving towards a melding of designing and building for the front end. In my recent work I have been designing the UI in code and shipping the end components. | |||||||||||||||||||||||
60 | Some of the time | All the time | The system was built for a specific project and has since expanded. Since the initial project is still its core consumer, we're able to see and work with the engineers and design teams directly on a daily basis. Additionally, with any external expansion project now using the system, we ensure feedback cycles to research how they are using the system as well as consult when new large projects are going into major phases. | |||||||||||||||||||||||
61 | Some of the time | All the time | Currently I’m a designer overseeing the design system and „business as usual” design work, which helps me stay close to it. I frequently reach out to the team I provide DS for to get their feedback on the library and processes around the DS, as well as to be able to relate to the hands on work done. | |||||||||||||||||||||||
62 | A lot of the time | All the time | We semi-regularly send out our design system team members to embed within our customer teams to actually consume the things we build. This has been a useful technique; we've learned so much by trying to implement design systems components in a real product. | |||||||||||||||||||||||
63 | Some of the time | A lot of the time | Usage examples on our documentation site closely mimic the actual usage scenarios and constraints. | |||||||||||||||||||||||
64 | Some of the time | A lot of the time | We do several things. We sometimes take a comp from another team and turn it into running code using our components. We often add example screens with real world like concepts to validate new components. We also will do live support with developers (or pull down their branches to assist), all of which can inform how our components are working. | |||||||||||||||||||||||
65 | Some of the time | Some of the time | As a manager i volunteer my team to fill resourcing gaps in product design when we have needs to fill so that they can stay close to our products and get a sense of what its like to be on the other side of the DS. I also make sure we have great relationships and an open feedback environment so people feel good about coming to office hours and showing us how things are going. As an IC,I take an approach of asking lots of questions and active listening. Many times someone will come to the table with a simple quesiton but i dive into their file and go the extra mile to review so that i can get closer to the work and observe how its being used. Many times someone doesnt know theyre using elements from DS in a unique way so they dont raise it so this approach is important to be detail oriented when it comes to support. Our team hasnt done this fully yet but we started to play with the idea of a DS lookbook where we use our DS to create designs for other popular apps outside our industry. This helps to not only show how the DS can be used in innovative ways but also forces us to see what can really be done with our work if we think about applications that are more outside of the box. We also use our styles and tokens on presentations and get involved in product vision work that uses all DS elements (even if theyre not live in app yet) which helps to see how fast teh DS allows us to ideate and support new product ideas | |||||||||||||||||||||||
66 | Some of the time | A lot of the time | Give myself a product design challenge 2-3 time a year | |||||||||||||||||||||||
67 | Some of the time | A lot of the time | It depends. I've had more strict focus on components, and I've taken different roles supporting product designers. One is EXTREMELY SILOED, and the other is pretty in the weeds with a couple of product teams. Very mediocre communication has made that entire experience worse. | |||||||||||||||||||||||
68 | Some of the time | A lot of the time | We have co-working sessions during DS onboarding where we build a few pages of products hand in hand with the product designers and devs. Post that we have regular feedback loops where we ask the product to share what they are building with our DS (and what they can't). It often ends up in either contributions to the DS or us suggesting better ways/components/patterns to the product teams. | |||||||||||||||||||||||
69 | Some of the time | Some of the time | have a focus group of designers on a group chat to ask questions and bounce ideas off of most of the new work/components are initiated by consumers | |||||||||||||||||||||||
70 | A lot of the time | A lot of the time | Listening tours, csat surveys, attending cross design crits, design reviews | |||||||||||||||||||||||
71 | Some of the time | Some of the time | Pick actual examples from designers' work. Are the documentation might have some ivory tower situations, but if you pick actual screenshots or examples to highlight it's more realistic. It also makes for a good newsletter blurb. | |||||||||||||||||||||||
72 | Some of the time | Some of the time | We have a ‘kitchen sink’ to test all our components and configs, starting to build out some demo pages to showcase larger components and layouts more contextually. | |||||||||||||||||||||||
73 | Some of the time | Some of the time | Designers on the team work on other product teams. | |||||||||||||||||||||||
74 | Some of the time | Never | We have a few ways we address this: - We attend dept-wide "Show and Share" sessions - We have Office Hours where folks bring in-flight work for discussion - We attend Guilds around the org as representatives of the DS team - We have plans (once we get through the pilot) to host a design-specific and an engineering-specific jam session each sprint to allow for that collaboration - We also maintain a "reference screens" file in Figma of common/high value experiences across the org so that we have files to play with during Discovery work | |||||||||||||||||||||||
75 | A lot of the time | Some of the time | Lots of engagement with teams in office hours and research when designing components. Using our components for our own doc site. Working on adding useful examples as a huge initiative this year. | |||||||||||||||||||||||
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 | ||||||||||||||||||||||||||