| 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 The Question, Episode 054, deep dive hosted on May 29, 2025 with Ben Callahan and Guy Segal. There are 45 answers. The question this week was: ----- Happy Monday, System Thinkers! This week, Guy and I were chatting about how—without tremendous intention and repetition—what your consuming teams believe about your design system is largely left to chance. He and I have both heard some…interesting…assumptions those users make about design systems. So this week, we want to hear what misconceptions your consuming teams have (or have had) about your design system. Of course, we also want to hear what you’re doing to combat those false assumptions and create more alignment inside your organization. Here we go! Has your design system adoption been impacted by your consumers’ assumptions or misconceptions? What misconceptions have your consumers had about your design system? What have you done to correct any misconceptions about your design system? | |||||||||||||||||||||||||
2 | Question 1: Has your design system adoption been impacted by your consumers’ assumptions or misconceptions? | Question 2: What misconceptions have your consumers had about your design system? | Question 3: What have you done to correct any misconceptions about your design system? | |||||||||||||||||||||||
3 | Yes | One of the biggest misconceptions is that everything designers need in terms of components needs to be in the design system. Another misconception was that the design system team can move at the same speed as product teams and build components on time for this one team to deliver one product. Overall maybe the biggest misconception I saw which actually embeds both of the previously mentioned ones is that a design system is the same as a component library which leads people to think that every components needed is included in the library and that each new idea can just be added to the library | We ran internal workshops and started pitching the idea of having specific libraries separated from the core design system in order to have different pace layers and also criteria on what is included in the core library and what is included in the specific libraries. | |||||||||||||||||||||||
4 | Yes | It doesn't have enough components (or - it doesn't fill ALL our needs). It is built for web applications. It is built for static web. It doesn't meet accessibility standards. | Accessibility statement and accessibility testing page. Launched a Forum every 2 months for users to learn more about the system, tech choices and see implementations and delivery from users. Storytelling through blogs. | |||||||||||||||||||||||
5 | Yes | - That it serves any and all of both internal and external websites and apps. Although that was our team's long-term vision, we had to focus and maintaining 32 different consumer-facing digital products. Also, this was heavily highlighted in documentation and marketing materials. - Some see it too prescriptive, others too flexible /shrug | - Redirect lost users to the proper departments - Quaterly surveys to identify and address issues, hold regular education sessions, and | |||||||||||||||||||||||
6 | Yes | Misuse of tokens. Where a color token meant for backgrounds was used for foregrounds because the user preferred that tone better. | Fix. Educate | |||||||||||||||||||||||
7 | Yes | That adopting this “version” of the system (the very first system) would just mean that there’s another design system they’ll need to adopt the next year or so. | So much over communication and forwarding prior messages that clearly state what will be able to be adjusted “for free” in subsequent releases. | |||||||||||||||||||||||
8 | Yes | That our design system is self-sustaining and doesn’t need dedicated resources to maintain. That we can add a new component to Storybook and that that is enough to get everyone to add it to their pages. | Well, we’ve tried a lot to explain why we need dedicated resources. Mixed results so far. | |||||||||||||||||||||||
9 | Yes | Probably some DS users didn’t expect that they would be in fact hands on contributing (building components) to design system to full extent (this is what our DS requires at this point). | Thorough onboarding, 1:1 sessions with designers, dedicating time to answering questions and guiding users. I also built documentation to be a knowledge source to reference at any time (it’s still in building to accommodate any rising ambiguities. | |||||||||||||||||||||||
10 | Yes | Some of our consumers were under the impression that all (and I mean all) front-end components would be provided by us. When really our intention is to cover the the highly reused ones rather than the one-offs. | In our case it's just been constant education by reminding the developers that that component is not within our realm. I think this misconception comes from our consumers not fully understanding the purpose of a design system, in which case there's probably some fundamental onboarding and education that should be provided earlier on. | |||||||||||||||||||||||
11 | Yes | n/a | n/a | |||||||||||||||||||||||
12 | Yes | That it's not accessible, that the DS provides EVERYTHING they need, and that they can't change anything that's already in there. | Remind teams/products that the components/patterns themselves ARE accessible, but that they still need to do the due diligence to make sure that the ways they use them throughout their products are accessible. Remind teams/products that the DS is a guidebook, and not a rulebook. If they really have the change something, and for legitimate reasons, that's ok. That the DS cannot provide everything for everyone—if they need something super specific that other products don't need, then that's on them to build and maintain for themselves at this time. | |||||||||||||||||||||||
13 | Yes | We've had folks who assume that the role of the design system was to extensively document a wide variety of very specific business cases, which we can not support as a small team. It takes time for them to appreciate the simplicity of the design system and where to go to get access to more specific use cases, which live outside the core framework in patterns files. | It took us a lot of time to reset things drastically and build the design system team back up to include engineering and product partners as core members of the team, so it wasn't just a "design thing." Once it was a more proper workstream with quarterly goals, a backlog, and a product manager, we we able to see the design system as a fundamental layer of the product infrastructure. But that took a long time. | |||||||||||||||||||||||
14 | Not sure | That the design system should cater for ALL components (some developers) and handle ALL the branding of the product (some execs). | Added an introduction page (which no one seems to read) about what the design system is and what it isn't. | |||||||||||||||||||||||
15 | Yes | So many! Engineers believing that a design system is something being imposed on them for the benefit of design, not engineering. Engineers expecting the system to rapidly replace the UI library of organisms they were previously using, without an understanding of the atomic approach. From Product, Design and Engineering, a belief that number of components is the most important metric for design system maturity. Overall, a misconception that design systems are all about tooling and not about a way of working. | Lots of comms, lots of conversations, sometimes targetting Leads and Managers, sometimes targetting 'do-ers'. Conversations with individuals who are particularly vocal in spreading misconceptions. Attempting to bring those people closer to the system with a 'champion' type role. Using data in our arguments where we can, both our own and from other design systems / the wider industry. | |||||||||||||||||||||||
16 | Yes | we have 1 big product that often thinks we should be making their specific things, immediately, for one-off designs. misconceptions about Lit Web Components and whether they can be used in angular apps, etc. many misconceptions on what it means to contribute to a system. thinking it will speed things up. | We have a lot of methods of communication to try and help clear up misconceptions, make space for folks to ask, and just introduce ourselves regularly in order to open lines of communication: - Forum to our users every other month - quarterly newsletters - Slack announcements - office hours across the frameworks and design/tech - we do a lot of education/trainings. mostly design-focused as our partners can't prioritize it, but we're trying to train folks on the system and open up lines of communication --even had a presentation across the Design org on the Myths of the design system (addressing things like: "detaching's no big deal," "system can't support multiple use cases," "i can't innovate quickly b/c a system slows me down," "systems are static and can't support new functionality or business needs.") | |||||||||||||||||||||||
17 | Yes | - design systems and innovation are incompatible | • Recreate innovative designs using foundational system components and patterns • Highlight proven capabilities with supporting metrics • Educate teams on our offerings, how to use them, and their value • Build relationships—most challenges stem from a lack of connection and collaboration | |||||||||||||||||||||||
18 | Yes | That if a component is not in the system and we can't get to it right away, we are a blocker. | Establish the criteria we use for including components (e.g. min 3 teams will use the component) and we are working on creating SLAs to boost with expectation setting and planning so partners have a better sense of when a component or something our teams offers is going to release so they can plan their own launches around it when needed. | |||||||||||||||||||||||
19 | Yes | 1) It's only for "that" business unit/org (our example was consumer vs business products) it's not designed for us. 2) It's only for "that" tech stack, our product uses something else (css, react, native, etc) 3) It won't work for our use case (everyone is a snowflake) 4) They (DS team) won't add our components 5) The DS backlog is too long, we need to move quickly | Roadshows and onboarding to explain our process, how we collaborate with teams, to establish a clear understanding of how the DS works with for/with them. DS slack channels with attentive responses also helps. | |||||||||||||||||||||||
20 | Yes | Well... where do we start? "creating a component for platform is easy" would be from designers. "UX feature designers know how to use components, so there is no need to ask" would be from developers. This results in variations of components in the code, overirdes etc | communication, communication, communication To designers we keep exposing the process which design system working group is going through, when creating components. With developers we try to stress that questioning designs is important In addition we work closely with designers, trying to catch any potential diviations from components and paterns at earlier stages. | |||||||||||||||||||||||
21 | Yes | That it wouldn't work for them, that they had differing tech stacks, how it related to the additional systems floating around, who was "allowed" to use it, etc. Our org is rife with miscommunication issues. | We built one pagers to concisely address specific topics, executive summaries to talk about availability/compatibility for the "higher ups"/decision makers, office hours to discuss things, deep dives/collab session with the Accessibility Team to show functionality, etc. | |||||||||||||||||||||||
22 | Yes | - There is no need to use design tokens - It is up to the designer manages the design system to keep with all new variants and nuances even if it isn't shared. - The design system doesn't allow for creativity. - It is just my design system and my work instead of seeing it as a group effort. | Create education content around design tokens, shared really cool YouTube videos around design tokens, helped the team realize creativity is definitely allowed, and repeatedly asked for feedback and help growing the system. | |||||||||||||||||||||||
23 | Yes | The top two misconceptions were that the design system needed to deliver features for product teams ahead of the product team's deadlines, and all proposals and contributions would be accepted into the design system. | We offered tokens and tried to educate consumers (via co-creation sessions, documentation, contribution guidelines, etc.) about how to create and test components/features to contribute back to the design system after they've been validated. Our contribution guidelines detailed the types of contributions we accepted, what to include in proposals, how we reviewed proposals, and the overall process (i.e., intake meeting goals, discovery, design, implementation, documentation). In parallel, we tried to set expectations about the design system's purpose and scope with senior leadership and product. | |||||||||||||||||||||||
24 | No, but maybe too early for us to have any clear signal on this | Understandably that the design system is essentially just a new component library. At this early stage, the Figma + React components ARE the most valuable thing we offer though. | We have been very explicit since the beginning that the Design System does not GUARANTEE accessibility because we assumed this would be a misconception. I have no data to confirm if that has been an effective strategy though. | |||||||||||||||||||||||
25 | Yes | That dev teams should update their design system packages upon every release and always stay up-to-date. | Quarterly communications with product teams stating clearly that the design system team works very hard to not introduce breaking changes so there is no need to update to the latest version unless a feature from a later version is needed for the product. | |||||||||||||||||||||||
26 | Yes | That it’s optional to use. | Design system clinics, design language crits and through discipline communities of practice | |||||||||||||||||||||||
27 | Yes | That they could do it better. That it was about control not enablement. | ||||||||||||||||||||||||
28 | Yes | That in a successful system they can ask for a component or a variation, I introduce it, and they use it. | I just started at this company so am strategizing how to shift this dynamic without disappointing the team. | |||||||||||||||||||||||
29 | Not impacted, it’s more of an understanding of the purpose of a design system | That every component idea should be added to the system, regardless of whether it’s a snowflake. Let’s not mention the complex snowflake implementation patterns that sneak into a system and become a maintenance nightmare! | Ask how many current use cases each component idea will have. “Well, we may have other use cases in the future” is not a valid answer. | |||||||||||||||||||||||
30 | Yes | Mui is a magic wand that will fix everything out of the box with minimal designer or dev input. Including UX and UI issues, accessibility, fix applying to multiple tech stacks (we'll just use dynamic UI) AND give us a strong corporate presence just by adding orange to the color palette. | Unfortunately, I don't know that I was able to correct any misconceptions after many, many presentations and walk-throughs. Designers and devs just kept doing shadow work to get it to work, then thrown under the bus for why it was taking so long, why it looked like that, and why we didn't instantly have a way for resellers to apply their own custom themes and deploy them in less than two days, and wouldn't just adding an orange stripe to "paper" give us what we want? | |||||||||||||||||||||||
31 | In the early days of the design system, there was the mythical near 100% adoption rate. Over time, the adoption rate has slipped, not because the design system/component library didn't solve the use case but rather because designers newer to the org, began inserting subjective design ideas (i.e. slight visual tweaks) into their design, causing engineers to create bespoke versions of existing core components. These bespoke tweaks would either be CSS hacks, or whole bespoke component creations. | One large misconception I've seen is the assumption that accessibility is solved because we have a design system. There was historically a disconnect between the notion of creating accessible atomic components and creating accessible experiences with those atomic components. | Course correcting on the accessible component vs. accessible experiences gap was a slow process. One of the most effective corrections happened a few years back when the VP of Design pinged me about an issue a screen reader user was having using one particular part of the platform, asking how the design system would solve these issues. I dug into the app, and quickly realized the issues were largely related to the decisions the feature team had made vs. something the design system could alleviate. I did a wholesale breakdown of both the UX and Engineering issues, as well as paths to resolve the issues, and shared the breakdown to the VP. My original intention was to help our VP understand the divide between design system and product accessibility. However, the document was shared widely amongst leadership, resulting in some significant improvements to the app in question. Fantastic. As a design system practitioner I began noticed a shift in message from our VP. The talk track became less "accessibility is solved via the design system," and more "you still need to sweat accessibility at the product team level." | |||||||||||||||||||||||
32 | Yes | Product owners that think they know better than Design Org or customer research and that want something 'flashy' or differnt | user feedback, design research, analytics and A/B testing, | |||||||||||||||||||||||
33 | Yes | One misconception or gray area that I've had to work through in the past is the notion that design systems reduce designer responsibility for quality outcomes. Many organizations and designers believe that implementing a design system automatically elevates design quality and reduces the individual designer's responsibility for thoughtful decision-making. There's an assumption that following the system's components and patterns guarantees good design outcomes. In application, design systems provide a foundation of documented decisions and design intent, but they can't replace the critical thinking, research, and collaborative skills that designers must bring to each project. | Through documentation, workshops and presentations make sure it's clear that the design system is an enabler of better design thinking, not a replacement for it. It handles the foundational decisions so designers can focus their cognitive energy on higher-level problems like user flows, information architecture, contextual interactions, and product innovation. | |||||||||||||||||||||||
34 | Yes | One misconception or gray area that I've had to work through in the past is the notion that design systems reduce designer responsibility for quality outcomes. Many organizations and designers believe that implementing a design system automatically elevates design quality and reduces the individual designer's responsibility for thoughtful decision-making. There's an assumption that following the system's components and patterns guarantees good design outcomes. In application, design systems provide a foundation of documented decisions and design intent, but they can't replace the critical thinking, research, and collaborative skills that designers must bring to each project. | Through documentation, workshops and presentations make sure it's clear that the design system is an enabler of better design thinking, not a replacement for it. It handles the foundational decisions so designers can focus their cognitive energy on higher-level problems like user flows, information architecture, contextual interactions, and product innovation. | |||||||||||||||||||||||
35 | Yes | It only applies to React teams | Lots of in-person meetings and discovering who is behind the misconception and why they are holding onto it | |||||||||||||||||||||||
36 | Yes | It’s slow. Creates tension and compromise or it’s not complete or robust enough. | Demo through the org | |||||||||||||||||||||||
37 | Yes | Typical misconceptions relate to what our components can or can't do. | If our documentation clarifies misconceptions, we share that with our users. If our documentation does not help, we acknowledge the misconceptions and update our guidance. We try to be as empathetic and transparent as possible, and our users appreciate that. | |||||||||||||||||||||||
38 | Yes | Lots of challenges around understanding the design system is the source of truth for design rather than the quick mockup by a product manager. | Tried to get better buy in from both product team, and development team to default to what is in the design system and not end around it if a mockup doesn't match. | |||||||||||||||||||||||
39 | Yes | Non-system leadership saying things like "Why does it matter what technology we use for our design system? Its going to change in 6 months anyway!" and the classic "So is the design system something that like, once you're done, its done?" | Help provide analogies. My two favorites: 1. The car factory. Design systems are like auto makers, designing and engineering the current model, but once released, having to both support the version people are currently driving, while simultaneously designing and building the new model. 2. Infrastructure. Design systems are like your local transit system, with a primary goal of getting people from one place to another (serving users), but also also requiring all these things: payment systems, mobile apps, maintenance, roadmaps, communication, system visualization, how to start docs, how to pay docs, and more... | |||||||||||||||||||||||
40 | Yes | The misconceptions do evolve and change as our design system is growing but one that's been common is the idea that we're doing everything and we will solve all the problems of our org. In some pockets this exists when we talk about accessibility because there are people who don't understand that accessibility is not a box you check by components and color contrast only. In some pockets this exists because teams think that we will build every component that makes up a UI instead of only building the right things that are repeatable and make sense to scale. In some pockets, this exists because they think the design system will magically deliver product autonomy instead of simply providing a vehicle for products to have that autonomy. They think that we'll be able to solve differences in navigation and experiences simply through theming. So there's a misconception of visual differentiation versus product differentiation and how that plays out with our platform. Early on though there was definitely a misconception that the design system was a fairy tale pipe dream that we would never deliver on. There was also misconceptions that it was only a design thing and had nothing to do with engineering or platforms. The worst one though was the misconception that we could just create a design system for organizations that never had one before and not disrupt ways of working or need change at scale outside of the thing that we were building. | Most of these get solved through more communication. With greater clarity. We have stood up town halls to communicate to large groups more frequently, we've set up strategic communication decks to clarify upwards to stakeholders that this work is far more complex than they may be hearing about, and I personally work hard to create more education for my leadership team so that they understand the world of Design systems a bit better and get out of the thinking that it's anything less than organizational change at scale for how we ship products. My team created a central set of slides that also allow us to communicate at scale with autonomy in a consistent way. Most of the content we need to clarify is the same, but maybe it's just different slides depending on the audiences. This actually worked really well when my Dev team gave a town hall presentation for the CEO who they report into that's different who I report into. I wasn't there. I didn't know about the town hall and I didn't get to see it but they used all the slides that we had in our Central repository so I know the communication was consistent to what we would have said if we were there. Some of the other misconceptions come by just making sure the work is done and is visible. The people who didn't think the design system would ever come to light. We're never going to be proven wrong by communication. We had to show them. The people who thought that design systems were only a ux thing and had nothing to do with engineering or operational changes were shown differentlybonce we could clarify the challenges we were facing and point to specific examples of why we needed alignment across teams. I still think I can be doing more though. I want to start creating more education snacks to clarify very specific topics in smaller bits. We are working on an FAQ page to just capture as we go along the common questions we see across all of our different pockets of communication and align on single answers. | |||||||||||||||||||||||
41 | Yes | That you cannot customize it or do something if its not documented and explicitly said you can. Also that the design system is the decider if something is ok to do as far as keeping the UX consistent and on brand. The system relies on a core team outside of the system to focus on the decision making there. | Lots of training, support and comms to show what you can do and what teams have done. Theres a need for doing more to make the responsibilities of the core team and the design system team clear or change the org structure so they are the same thing and make it clear how they govern the decisions. | |||||||||||||||||||||||
42 | Yes | Misconception that you cannot customize/innovate when using the system. If its not documented its not possible. And that the system is the same as the people who decide what is allowed to maintain a consistent, on brand, digital experience. | Training, support and comms. | |||||||||||||||||||||||
43 | Yes | They can only use existing design system solutions, and nothing else. | Meet with teams to explain that the design system is a tool that should be used when possible and when applicable, but teams also have autonomy to 'fill in the gaps' and design unique solutions to meet their product's needs. Also documenting this in the design system. | |||||||||||||||||||||||
44 | Yes | - We have had many misconceptions that our DS only supports one side of the business, rather than all of it. For example, we support hundreds of apps, but our e-commerce site is built using a different tech stack and DS. - Many thought that the inconsistencies between components and patterns were the primary source of pain for product teams. But, components and patterns were only a symptom. A lot of the pain focused on a central theme of: This is not just a design system issue. The problems focused on a need to enable product design and engineering squads to communicate and organize common work for their product more efficiently. The component- and pattern-specific painpoints are byproducts of and symptoms of the Ways of Working painpoints. - Design system team is responsible for EVERYTHING (all components, all patterns, etc.) and that everything should live in the DS. | - I've had to meet 1:1 with dozens of designer, engineering, and PM executives to educate them on what a DS is responsible for and the value they bring. Problem: Within H-E-B, organizations need a way to maintain agency and autonomy over their domain while adhering to leveraging standards and processes available within the core design system. This extra capability would allow teams to tailor how the design system applies within their domain and specific use cases. The Mortar design system doesn’t have to own, include, or oversee every bit of UI across H-E-B’s product landscape. Mortar can provide the core set of ingredients—and support/encourage teams to build product-specific solutions with those ingredients. The previous process within CX to create, maintain, and use reusable components wasn’t sustainable or scalable for the future. Due to the lack of standardization and a single source of truth has led to myopic decision-making across teams, inconsistent end-user experience, and UI rework. Although design systems provide reusable components and patterns, they are organizational-wide tools with multiple layers of ownership and communication between core design system maintainers and organizations. These unspoken pain points bled into the work Mortar team and created friction between CX, Mortar, and individual designer & developer relationships. Solution: Create a “system of systems” where a middle layer between the design system and individual product teams is needed to support and drive consistency of product-specific solutions that should not live in the design system layer. What I did I organized, planned, and facilitated a series of workshops to understand the current designer and dev experience around using components and understand the gaps. Created a process framework for CX to work within the system of systems. Wove together the narrative to bring alignment between CX leadership, Mortar, and partners to understand the root cause of designer. | |||||||||||||||||||||||
45 | Yes | - Outdated, and at times, detrimental opinions/beliefs of the system and the component libraries (web, iOS & android) that implement it - That it will restrict their ability to innovate - Expectations of a level of support that is on par with holding their hand and tucking them into bed - When a consumer raises a support issue/question that the core maintainers MUST drop everything and see to it immediately or be damned if they dont... - Beliefs of contributors to the DS that their contribution proposal is the best since sliced bread and the core maintainers should marvel at their brilliance... | - Increase community engagement with focused sessions and group sessions - Aim for as exhaustive and cohesive documentation of the DS and the component libraries - Operate with openness and consistent tone of voice - Pray! | |||||||||||||||||||||||
46 | Unknown | I think one misconception is that because we built for maximum accessibility compliance its too rigid to fit what folks need. That somehow their content will be hampered by these mysterious guardrails. | We communicate how our efforts improve our score on reporting. We also try to show how reach extends with the expansion of accessible audiences. | |||||||||||||||||||||||
47 | Yes | 1. it should be all of the UI (mostly leadership) 2. "it doesn't have the components we need" meaning "I don't know how to use atomic building blocks" or "it doesn't have pre-built large patterns for my custom UI" (see #1) - literally heard this today! 3. design-code parity just... happens??? | add stories/docs for all the building blocks and not just custom components; pairing with engineers to build custom things | |||||||||||||||||||||||
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 | ||||||||||||||||||||||||||