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 35, deep dive hosted on October 25, 2024 with Ben Callahan and Elyse Holladay. There are 69 answers. The question this week was: ----- Hello curious people! Elyse and I have been discussing the fact that a lot of design system teams seem to be stuck in the never-ending cycle of “build more components!” When I chat with design system practitioners one-on-one they seem to know there’s much more to the work than this. So why is it that our backlogs are full of more and more components? This week, we’re going to try to uncover what is driving the prioritization of work. Hopefully, we can start to break out of the mindset that there is one right way to build a design system and free ourselves to figure out what would most benefit the organizations and cultures in which we work. In order to join the deep dive, all you have to do is answer The Question: Overall, do you feel your design system team is doing the right work? What should the number one top priority for your design system be right now (and, are you working on it)? What is your design system team currently working on that you believe is not valuable (and, why are you working on it)? | |||||||||||||||||||||||||
2 | Question 1: Overall, do you feel your design system team is doing the right work? | Question 2: What should the number one top priority for your design system be right now (and, are you working on it)? | Question 3: What is your design system team currently working on that you believe is not valuable (and, why are you working on it)? | |||||||||||||||||||||||
3 | No | We should work on a proper governance model and on tier 2 libraries as well as more education via templates and guidelines | We are working on new components and wishes from product teams instead of focusing on what’s really delivers value for the whole organization | |||||||||||||||||||||||
4 | Yes | 1. Set processes up in a way that if the DS team were to evaporate the DS subscribers would be able to pick up and survive for a short period | We're solving more UX problems on the product front for the designer. Although rare but sensing a bit of complacency. | |||||||||||||||||||||||
5 | I'm not sure. Whenever we discuss our goals and next steps and stuff we need to prioritize higher we get caught up in small discussions and lose focus. It is not only creating new components but more like renaming properties. | Finalizing the big picture, optimizing our way of working and not on the daily base. | Optimization of properties. | |||||||||||||||||||||||
6 | Yes | Releasing our rewrite of components which ultimately will be our v1. We are currently working on it, it is in RC stage and hoping to release by November. | Nothing, our team is so small that we can only focus on certain amount of things at a time. | |||||||||||||||||||||||
7 | Yes | get more web components out for folks to use (we've got way more native components out), so we can get closer to parity (as appropriate). and work on self-service tooling. we have a good baseline set of components for native, now we can improve the experience of onboarding, etc. | low-impact components...components not used widely. we are working on it because leadership wants to 100% replace an old system and has missed the fact that it is indeed old and perhaps some of the old components shouldn't be replaced "as-is" or at all. there WILL need to be some migration and some changes to modernize. | |||||||||||||||||||||||
8 | Yes | We have a massive opportunity to improve mobile design system support within our DS. We were making great progress on this challenge, but internal restructuring has removed this problem from the scope of the central design system team, so we're no longer working on it directly. The new owner does not have the knowledge, leadership or support needed to move this problem forward and we're left sitting on the outside to observe the system we build slowly fall apart. | There is a focus on adding more components to the system, particularly within the mobile space; this is driven by an oversimplified view of the value DS brings from our leadership team. Our current component coverage covers most of our use cases; adding new components now has diminishing returns. We should have a greater focus on adoption. | |||||||||||||||||||||||
9 | Yes | Creating some case studies of design system success...I'm kind of working on it but finding it hard to get started | I dont think we're working on anything that's not valuable :) | |||||||||||||||||||||||
10 | No | Governance. We don't have it. Mandate is that all things must be built as a sharable component and included in the npm package(s). We are not working on it. | Building highly bespoke components that have little chance of being picked up by another brand. We work on that because of VP level mandate. | |||||||||||||||||||||||
11 | I'll be joining a flat-org scaleup soon so looking to make an impact with their existing Component Library (Design System). | The priority should be to build and maintain the components that are needed (based upon sourcing requirements from the consumers), while resisting the temptation to go overboard. | From the interviews, it sounds like components are being built with functionality that was not requested but engineers thought it would be nice to have. The result has been bloat. | |||||||||||||||||||||||
12 | Yes | Customer Facing Experiences | N/A | |||||||||||||||||||||||
13 | Yes | Content templates and guidelines on putting together components in common patterns | Overly locked down components. The design team and business value global control more than flexibility and good culture. | |||||||||||||||||||||||
14 | Yes | The number one topic within the company right now is accessibility compliance. We're tightly connected to this initiative and identify areas where we can help accelerate and scale solutions (for a wide range of legacy web applications). We've identified and prioritized work that is both needed by products and will have the biggest impact in advancing accessibility compliance forward (e.g. responsive layouts, components we can supply that will free product teams to focus on fixing other bugs). | Call me biased, but I don't think we're doing work that isn't valuable :) I mean, why would it otherwise be on our roadmap? If anything, we might be doing work that isn't _perceived_ to be as valuable as "delivering stuff", such as training our consumers, but these are all critical areas for the success of the DS. | |||||||||||||||||||||||
15 | Yes | Hardening our core capabilities | Visual refresh (top down ask) | |||||||||||||||||||||||
16 | No | Establishing processes, writing documentation for it, doing user interviews. | The work we are doing is valuable, but it been been a weekly ping-pong of topics because we don't have weekly sprints established yet. | |||||||||||||||||||||||
17 | No | Currently, I really need to start thinking about scalability: scaling the navigation, scaling the commands, scaling the filtering, ... All to handle more complexity as our application grows. | Marketing, office management, front-end development. I have to balance the needs of the design system with the needs of the rest of the startup and make sure that what I'm doing is contributing to adding more customers. | |||||||||||||||||||||||
18 | Yes | Top priorities for my team that we are actively working on - enhancing our layout and navigation; incorporating AI to assist engineers that do not have UX support in order to more easily use our DS; server side & client side rendering support | I'm the product manager so my team shouldn't be working on anything that isn't valuable to our users. If they are, I'm going to stop that and redirect to what is valuable. | |||||||||||||||||||||||
19 | Yes | Understanding what users of the design system need at any given time. And, yes. As a team, we've inherited an existing community-led design system. Research has shown that trust in the design system is low. This is what we're working on; to improve the trust that users have in the design system. | AI patterns We're not actively working on this, but there is a call from others in the organisation for us to be looking at it. We're resisting due to other work that we deem as much more important. | |||||||||||||||||||||||
20 | Yes | Tokenization. We are working on it and it's helping with alignment in many ways. | Maintaining design artifacts that have little to no use. We haven't been able to dedicate enough time to deprecate. | |||||||||||||||||||||||
21 | No | Start with the idea of building one! | Unfortenally on my current company we don't have yet design system! | |||||||||||||||||||||||
22 | Yes | Designer support. I try! | N/a | |||||||||||||||||||||||
23 | No | Fixing fundamental HTML (and related CSS / JavaScript / accessibility issues) and documenting those patterns in a component library. Then, aligning them with Figma library, and removing duplication/bloat in Figma. The project currently suffers from zero componentisation, and lots of bloated/duplicated/inaccessible code. Client's priorities do not align with mine. I've prototyped a simple Stroybook implementation to demonstrate the value of working with a component lib. It also serves to demonstrate how inaccessible a lot of the "simple" HTML patterns are in the client's web app re-development project. | I'm spending the majority of my time building a new ZeroHeight docs site, with primary focus on documenting the "back-end" for its consumers. Not a CMS, per se, but an "engine" that generates front-end code for their web app... I'm essentially a "technical author" for a system I know very little about. | |||||||||||||||||||||||
24 | Yes | Prototype ready components that maintain best practices and apply accessibility | Lottie file animations. Focusing on flashy things vs making the foundations useful and usable. But was at a an ad agency | |||||||||||||||||||||||
25 | Yes | Updating our language so that it can better handle the intricacies of being a multibranded system. We were working on it at the time. Not sure if the team completed it after I was let go. | Refactoring existing components. Although a great goal to have, it can feel like a bit of a hamster wheel. We couple that with trimming fat (removing bad or old components) so all was not lost. | |||||||||||||||||||||||
26 | No | We are working on doing an overhaul of our components because the system has gotten too complicated. There are too many duplicates and specialty items, and it’s made the system unlearnable and hard to maintain. We are theoretically working on this, but we have very few centralized dev resources, so we are counting on product teams to implement most of the work. From past experiences, I am not confident that this work is going to get prioritized. | We are in the process of switching our system to use MUI (material design) components. This direction came from the CTO, over the concerns of the design team. I think that the CTO is mistakenly seeing this as a quick fix. If we were going to use MUI, we should have made this decision 5 years ago. This is going to be too much work to switch out, it’s not going to be 1:1, and I am concerned that we are going to use all our design system political power and resources to basically end up with what we already have, with none of our current problems solved. Very frustrating. | |||||||||||||||||||||||
27 | Yes | Strategy for our DS architecture: we need to build on it, but what pieces need to be in place for us to scale? | I feel like everything we do is valuable in the sense that it will benefit someone. However, I think we need to prioritize based on initiative more than one-off requests. | |||||||||||||||||||||||
28 | No | White labeling and versioning components and making them more useful across multiple clients working at different speeds | Conducting universal component updates and uptake across all client instances rather than utilizing more component versioning allowing folks to move at different speeds and levels of maturity | |||||||||||||||||||||||
29 | I’m new to this group so I’m not sure exactly how to respond here. I don’t currently have a team. I did, but I got laid off. I’ve been freelancing for the last year and a half or so. | I have a design system I use across all my work but it’s a bit loosely defined. I get a lot of value out of using it - work is quicker and quality is higher - but I’m not sure how to better leverage it. I struggle to write about the system because I want to address multiple audiences with different levels of technical understanding and different contexts. I feel like documenting the system is a high priority but because I’m the sole user it’s difficult to prioritize over more pressing tasks. How do I show the value of systems to external stakeholders? | I currently have no team but my answer hasn’t really changed. Most of my/our time goes towards client work and it’s difficult to find time to implement systems. I wouldn’t say this working not valuable, but it has limited value related to systems. This gives me a thought though, maybe there’s a way to turn client work into design system documentation. Will ponder this | |||||||||||||||||||||||
30 | Yes | For us, its building our Alpha and preparing for our Pilot launch in Jan 2025. We have a list of deadlines we're working against (mainly, the team) while I plan a mediator role helping solicit teams for participation, holding info sessions, etc etc. | We, luckily, have full control over our scope and ecosystem (since we're pre-1.0); so the work we're doing, at the strategy level, is the right work for our current stage! | |||||||||||||||||||||||
31 | Proper adoption of newly released components. | Educational moments such as teaching designers how to use Auto Layout. Most of our designers are Senior and higher but don't keep up with the latest advancements of Figma. | ||||||||||||||||||||||||
32 | Yes | Completing a fruitful pilot program with 3-4 teams (and yes!) | Currently, I think it's ALL valuable! There are a lot of foundational pieces in progress at the moment, but I don't think we have prioritized anything that won't be needed. Yet. | |||||||||||||||||||||||
33 | Yes | Component enhancements (design and code) to meet the needs of adopters. Yes, it is one of a handful of things currently being worked on. | Nothing. | |||||||||||||||||||||||
34 | Yes | What I'd most like to be able to work on, is revisiting the set of components that were in our first design system release three years ago, all of which need improving to some extent. (Some have already had a v2 iteration but need further improvement, some have hardly been touched in that time). We have a bunch of user requests for new features to add to them, plus general improvements and simplifications to make based on everything we've learnt since, and advances in tooling (e.g. in Figma). We're discussing the work, scoping and refining tasks, and I would like us to start soon, but realistically, I know we probably won't get to it in a meaningful way until next year. | I don't think we're working on anything that has no value, but we are not necessarily working on the most valuable things. Lower value things that we're working on include supporting contributors with components that they want to work on, but which wouldn't have been top of our list. I would say that we had a huge stakeholder focus on component number, which only dropped off once we hit 50 components! Some of those components were not high priority and we'll may end up removing some of them from the system eventually. That was a huge source of frustration but we just could not move the conversation on until that was seen as 'done' by stakeholders. | |||||||||||||||||||||||
35 | Yes | Grid's. Specifically mobile. Doing a ground up new DS moving to Figma from Sketch and there's multiple grids in play. Trying to dig into available analytics to help steer a definitive selection before work moves into componentry. | Looking into replicating legacy iconography approach which has different line weights for different size application. Never seen it 'in the wild' before and seems a little heavy handed to me. | |||||||||||||||||||||||
36 | Yes | Getting our components stable for out V1 and LOTS of education across the company. We are working on this but were also doing other things that pull our focus away from doing this fully and well | We spend a lot of time helping teams integrate and answering one off questions about component styles. While i believe the time spent with these teams can help to build relationships, its only necessary because of a lack of leadership clarity about where our products are going and how our brands are supposed to either collaborate or own differentiation. Without spending time on that, we would be more free to work together on the build of the system and broader education. | |||||||||||||||||||||||
37 | Yes | It depends on your goal, the stage of your design system. If the goal is adoption, and you have a new design system, what are the elements of a design system that will attract users to implement it? Top most used components, components used by most teams, design tokens and foundations? A proper assessment and a strategy should help guide the answer to this question. | I really can't think of anything. | |||||||||||||||||||||||
38 | Yes | tough question for, we are doing 50% of the right thing: launching, evangelizing, and integrating with existing products the other 50% of our time SHOULD be spent integrating our biggest product BUT integration is low due to the tech debt associated with the product. | supporting a team/product with the lowest visitor, engagement and revenue of our entire property/product portfolio because it's an exec's focal point. we are continually brought into discussions with this team because they want exceptions to the system. | |||||||||||||||||||||||
39 | Yes | Building tokens and components that are directly tied to features that the business has prioritized. We are working on these things, but at a slightly slower pace because we had until now focused 1st on tokens and things we considered "foundational". Now we're a little more willing to "jump ahead" i.e. build the component that a product team needs and then come back and to refactor its "guts" so it's using design system tokens after we've finished defining the tokens. | n/a | |||||||||||||||||||||||
40 | Yes | We are currently working on elevating the quality and coverage of our design system in our product teams. We've been focusing first on design teams as they are the first part of the delivery chain, and have dedicated people from our central team providing ongoing and direct support. At the same time, we are focusing in upskilling team members by sharing knowledge and providing training sessions, with the goal of leaving them wit hat least one "internal DS expert" to be their first point of contact. On the engineering side of the system we are focusing on enabling teams to consume themes and components in a more flexible way so that they can deliver their features using our current available assets. | We are still spending time in trying to improve existing components instead of getting closer to product teams to help them utilise the existing features and assets in order to gain more insights and learnings in order to make better informed decisions on what to work next. | |||||||||||||||||||||||
41 | Yes | Complete foundational components to drive adoption across more teams | We're still in our first year so everything seems valuable. | |||||||||||||||||||||||
42 | No | Patterns of use. From more nuanced component interaction to larger building blocks, page templates and common flows. (Example: PayPal had a frightening number of credit card input patterns. Would be one thing if we were testing performance, but this was just legacy, lack of looking laterally, rush to market) Historically, we had not been working on patterns as core components, cross platform parity, trust, transparency and adoption had be higher priorities. This shift to pattern work, architecture, scaling models were initiatives I was starting right before I exited. | Following up with individual teams and contacts. While establishing and maintaining these contacts, it's not an efficiency for scale. I love Atlassian's design 'sparring', once a week forum that brings everyone to the table, design, eng, etc. to really duke it out. Builds visibility, and a 'show up to be heard or hold your peace'. We had office hours, slack forums, other share outs, leadership check in, etc however they didn't really bring the level of engagement. | |||||||||||||||||||||||
43 | I have the feeling that we are doing our best but I am not sure if it is the good way | We've been trying to start a new DS, we already have one but it is old and we have to maintain it at the same time. | Our company is asking us about results and what we are going to realese new and we had many components already | |||||||||||||||||||||||
44 | Yes | Releasing the new iteration of our design system. The previous design system first released about 5-6 years ago and designers and developers have been growing increasingly dissatisfied with it. The design system team is undergoing a large effort to update to a design system to modern technology and improved experience. I am currently working on the effort through mainly through working on foundational elements like tokens, building Figma plugins, and acting as a liaison with the general practice. | Most things we are working on are essential as we are a small team so we are hyper-focused on making the most out of what we can. Most non-essential and, in my opinion, not valuable efforts have been put to post-launch or much lower in capabilities. One item we are working that I am a bit hesitant on is custom code generation. This includes not only component code, but entire screen code as well i.e. the code of a card and all the content within it. This was a big selling point for our design system to improve the hand off experience, however, I have my doubts on the usefulness, feasibility and maintainability of a feature like this. | |||||||||||||||||||||||
45 | Yes | Currently I am working on a multi brand, multi product design system. The stage we are at now currently, the number one priority is to complete the global components we are working on and invest a lot of time in educating product teams on the usage and also about how to best work with design system. Simultaneously we will continue to build components for our internal libraries as well. | Our current component styling aligns with each brand's existing visual identity. As our design teams becomes more familiar with the design system, we anticipate adjustments to these styles to better reflect its principles. This is a necessary step toward enhancing the overall user experience. While adopting the design system was a significant achievement, universal agreement on all aspects wasn't immediately feasible due to various stakeholders. Our initial focus is on widespread adoption. This will lay the groundwork for future refinements and improvements. | |||||||||||||||||||||||
46 | Yes | Getting off the ground with design decisions we feel are solid and can work without having everything figured out. | Not applicable to our current state. | |||||||||||||||||||||||
47 | Yes | Migrating old pages to new UI using design system, and customizing Material components to work better with desktop tools | Using Angular Material instead of custom components. It feels unnecessary | |||||||||||||||||||||||
48 | Yes | Obtaining alignment between DS team & product on prioritization of design system work. (Ex: addressing design debt vs supporting feature work) It’s a work in progress. | The DS team is small (team of 2), and DS is young, so were able to focus on work that is valuable, thankfully, but there is sometimes lack of alignment between design & product on what gets prioritized. Design debt accumulates when product constantly wants to prioritize feature related work. It’s still valuable work, especially from the business perspective, but addressing accessibility issues is valuable too. | |||||||||||||||||||||||
49 | Yes | We have a few components we are committed to building, to help the business deliver on a brand refresh. We also have a bigger bit of work supporting a second brand within the business. But we also need to improve our documentation, and the way we facilitate other teams to adopt the system and contribute/share their downstream products of the system. | There is ambiguity on the long term aims of the systems team, and what we should ultimately be working towards. The organisational structure is also constantly shifting and further complicating this picture. This changes not so much the 'what' of what we're doing but the 'how and why'? If we only need to cater to two brands, versus potentially many others, we would approach things in a very different way, but there is competing messaging on this. | |||||||||||||||||||||||
50 | Yes | Better sync between design & dev | Nothing | |||||||||||||||||||||||
51 | No | I'm only filling out because I didn't see invite | I'm only filling out because I didn't see invite | |||||||||||||||||||||||
52 | Yes | Building out new components | Building out new components in order for product teams to spend less time building UI elements/styling and more time focusing on product features | |||||||||||||||||||||||
53 | Yes | We are at version one - finalizing our build and preparing for implementation. There are so many things we want to do and should do that just can’t be prioritized now because implementation of infrastructure we’ve never had before is number 1. | Currently working on constant selling of our need for support. Product management isn’t supported by our DPM team so it’s relegated to my team, which could be fine if we were staffed appropriately to take on that additional capacity. It’s simultaneously the work that needs done now but the ops and orchestration takes away from the ability to do the system work and support adoption as well as we’d like. | |||||||||||||||||||||||
54 | Yes | |||||||||||||||||||||||||
55 | Yes | Elevating quality of foundations and core components | N/A | |||||||||||||||||||||||
56 | Yes | Current priority is building V1 of a design system for an editorial experience. Yes, we're working on it. In the past - with larger teams - I've prioritized design systems initiatives based on prioritized product team initiatives, reserving capacity for self-directed systems work. To break out of the "build more components" cycle, I've found it helpful to provide a greater range of abstraction levels and configuration. Train and educate around the outcome, not just focus on the output. | Not currently, but in the past, short-term marketing experiences, landing pages, edge-case components. Some of this work, in part, was due to stakeholders not understanding the role of design systems. | |||||||||||||||||||||||
57 | No | I would like us to find a better tool to build our design system on so that we can help prevent future in efficiencies as we made additions and updates. | Blog posts that highlight different aspects of the design system. I don't think anyone is going to read them. | |||||||||||||||||||||||
58 | I may know soon… if I get the job offer! | Clearing the backlog and prioritizing | Clearing the backlog of components to resolve bugs | |||||||||||||||||||||||
59 | The top priority should be making communication simple, regular, and digestible. There is so much focus on good work, but there is no strategy in place to market it to the consuming teams that people are not aware of any updates. We have tried over and over again to prioritize this, but it is always pushed out because the sprint ends. | Trying to merge multiple design systems together from different sub-brands. There is no clear business reason for doing so for consuming teams, but has been distracting both design system teams for months. | ||||||||||||||||||||||||
60 | No | We are working hard on making all of our components accessible so that our products using the design system will be closer to meeting accessibility requirements needed to retain current customers and attract potential customers, and of course, because it's just the right thing to do. In addition to accessibility, my colleague and I believe responsiveness should be another priority. For years, we have asked leadership to prioritize this, but every year, some other priority would take its place (recently, that was creating some AI elements). As we close 2024 and head into 2025, management has now deemed responsiveness a priority along with accessibility, and just as we had feared would happen, we now find ourselves way behind and playing catch up on this. We are a small (but mighty) team of two designers and three developers, but we will work hard to deliver this and everything else as fast as we can. | The members of our team are always being asked to help with things outside the scope of our design system (some marketing related, some tech writing related, etc.) but we comply without question or complaint. Perhaps that isn't the most "evolved" approach, but I guess it is just in our nature to be helpful. And, I think we are also just grateful to be employed when so many others in the tech industry have been laid off this year. One of my colleagues often says, with sarcasm, "What a time to be alive" - and she's absolutely right. "Do more with less" seems to be the mantra of businesses operating in the 2020's. | |||||||||||||||||||||||
61 | I think we need to better define the line of what is part of a design system and what is not. | The design system should enable product teams to move faster solving customer / user problems without blocking them or becoming a bottleneck. | We maybe also need to redefine the boundary between design system and design system team, and what healthy governance looks like. | |||||||||||||||||||||||
62 | No | Consolidate many siloed teams in order to unify the UI/UX of several different products, which will, in turn justify and inform the design system. | We're starting over from scratch to build out a third attempt at a component library, but still adding to the second iteration, which doesn't seem valuable to me. | |||||||||||||||||||||||
63 | Make the system more re-useable for customers, making sure the dev side is fully in sync, making sure there's solid token export to css variables. | n/a | ||||||||||||||||||||||||
64 | No | Build fewer components. Reduce the number of components. Improve documentation and engagement information. | Building more components. | |||||||||||||||||||||||
65 | Yes | The adoption strategy by the development team | Costs saved with the introduction of the design system | |||||||||||||||||||||||
66 | No | Support the usages and understanding of the design system and how to use it. And providing solution to Design System User's real pain points, instead of providing the maximum of component in Figma, and if we're lucky, on Storybook | The maximum of component in Figma | |||||||||||||||||||||||
67 | No | (1st) Tokens; establishing the common language between dev and design. (2nd) Fixing a poorly composed component library. (3rd) Establishing the design patterns. We're working on #3 right now. | Working on establishing the patterns that everyone should be using, but without understanding the fundamental construction and usage of the components that comprise that pattern. We're working on it because management feels it provides more immediate return. | |||||||||||||||||||||||
68 | No | The smallest thing possible | Larger, more complex components. I feel like Dan Mall's "Your Next Component" talk kinda threw me off in some ways. | |||||||||||||||||||||||
69 | Yes | Probably governance - how can we enabled teams to build more consistent experiences with our building blocks? How do we figure out a working model for teams that want to extend components to test? How do we figure out an effective ops model to incorporate more collaboration and federation to supplement our small core team? We are working on this, though it is harder to get the visibility for more process-focused work | Building complex components for consumer teams to 'plug and play' - which was specific direction from our leadership, though I'm concerned it will create bottlenecks, lead to more rigid components that teams will have to break to use, and is just more challenging for the core DS team to have enough domain context to create. | |||||||||||||||||||||||
70 | No | Not using Angular Material. | Angular Material. | |||||||||||||||||||||||
71 | Yes | making our design system healthy and accessible. | adhoc requests that can be answered with the help of design system documentation | |||||||||||||||||||||||
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 |