EXT Episode 005 Raw Data

	A	B
1	Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 005. You can check out the Episode 005 FigJam file, watch Episode 005 on YouTube, or read the Episode 005 Wrap-up Post! Major thanks to zeroheight and Sparkbox for their sponsorship of The Question this week. ----- This week, we’re investigating a pattern that our friend Dan Mall recognized in some of his conversations: How much of a rascal are you? In his article, Dan shares this advice: “...how do you change something if you don’t have the approval to do it? Do it anyway, but don’t tell anyone you’re doing it. Only share the results when your work is done.” The first part of this week’s question is about whether you agree or not. The second part is a collection of your stories supporting your choice. Is it ok to break your organization’s existing rules and policies in an attempt to establish a design system? Based on your previous answer, tell me a story about a time on your design system journey when you made the choice to either break your organizations existing rules or to honor those existing rules—and then tell me what happened.
2	Question 1: Is it ok to break your organization’s existing rules and policies in an attempt to establish a design system?	Question 2: Based on your previous answer, tell me a story about a time on your design system journey when you made the choice to either break your organization’s existing rules or to honor those existing rules—and then tell me what happened.
3	Yes	We have a policy that only coded components are published in the design system proper, and that the Figma should map to the coded version as closely as possible. We recently made an Alert component (to sit in the body of a page; there's a separate Toast/Snackbar component as well). The design intent was to have controlled and continence visual approach, and to avoid cognitive loading onto users by not allowing this component to do to much: Only one CTA Link and a single line or paragraph of text, with no additional links or images/icons offered above what the design system team offered within the component. Then we were approached by a squad: Squad: "We want to use this Alert component, but we need to put a paragraph with bullet points in there... A single string of text with no paragraph formatting won't do. Can you open the component up to receive a React node?" Us: "It was actually a deliberate move of ours to restrict what you can insert here... Consistency, cognitive load, are you really using the right component for what you want to say/do? etc...Can you get your content designer to review the copy, or think about how you could use the alert to link to a different place/component (e.g. a modal, or separate page) which users can opt into if they want chapter and verse about the issue?" Squad: "We actually have no designers of any kind currently in the squad, and need to get this live by some arbitrary deadline." ___ So we decided to open the coded component up to receive a React node, but not to update the Figma component accordingly, or publicise the fact. We didn't want to stop this new team adopting the system and component, but we also didn't want to advertise this measure to all designers and thereby open it up to a Wild West of abuse leading a thousand flowers blooming of weird content inside alerts. Sometimes, you have to break your own rules in service of the greater aims: adoption and user support.
4	Yes	The design system was built using Sketch. As components grew, Sketch slowed to a crawl. Manager was against rebuilding and switching to Figma to improve performance. Against the manager's instructions, I rebuilt all Sketch components in Figma in one week and presented as 'an experiment'. Team was thrilled at the improvement and we switched over to Figma. Manager not so thrilled. ;-)
5	No	I would say that being a rascal pays off when building product features (essentially experimenting and seeing if it has an affect on user behaviour), but can really have a damaging effect in design systems. Design system is an internal tool for product teams and if you can't win them over and try to go rogue you risk with product teams not adopting and losing trust in the system. I believe a big part of design system work is listening to everyone's needs and trying to accommodate them the best way possible with reasoning.
6	No	There is no need in my current organisation to break the rules. We are lucky enough that our main stakeholder and our managers truly believe in us and usually take our advice on changes of process, ect. We, as a team, have introduced a lot of change, anything from the way we use figma, to accessibility, to definition of ready and breaking the silos... ect... In fact, it has worked on our advantage to follow the rules as we are often observed with a magnifying glass (by some detractors of the system) to make sure we are doing things the right way... I do think the answer of the question really depends on the culture of the organisation. I certainly have broken the rules before, and I have done so, for the good of the design system and the final product. It was something I did with my best intentions and knowing that I would sleep well at night. The most rascal I have been was after giving my notice on one of my last positions (in Ireland you have to work one month in your position after you quit your job) I felt liberated and I broke so many rules and challenged so many processes, again, with my best intentions and to leave a better place for the amazing co-workers that I was leaving behind. I did so until the day before I finished my work. It felt good!!!!
7	No	It should not be OK to break the existing rules if design system is young. We have created components variants early in the process, and it leads to extraneous explanation when introducing the design system to partners.
8	Yes	I don't think the first question is as cut and dry as it seems — at least in my experience. It was more like solving a problem I was hired to solve, but not in the way that was expected. It was literally sitting where I wasn't expected to sit (with developers) and trying to bridge a relational gap that wasn't on the list of deliverables. When I joined the org, it was an unwritten rule that design sat in one building, and developers in another. Maybe an unwritten expectation is a better way to phrase it. I think it's the unwritten rules and policies that are harder to challenge because they're more engrained in the culture. Designs were launched over the void (a 5 minute walk across the parking lot), and we anxiously refreshed our browsers to see what transpired. It was like framing up the perfect scene and waiting for the Polaroid to develop. We could do better. So I started spending more time in the development building, trying to establish trust in the design team, and also finding an advocate or two that was willing to give the design system another go (there had been a few attempts before I joined). Eventually, our design team had permanent spots alongside our development counterparts. The design system was advocated for throughout the org, and the culture had shifted to be more collaborative. This same org was also 100% an Adobe shop when I joined. All digital design and artifacts were in Photoshop. Through IT policies we were unable to install software that hadn't been approved. If I remember right, I ran a few apps from my desktop (including Sketch) to prove out the value for product design. I eventually helped the entire design department adopt Sketch for digital work and also the design system's UI assets. Both of these examples started with cultural "workarounds" that created an environment where a design system could thrive. I didn't worry so much about where time was spent as long as I was delivering on what I was tasked with.
9	Yes	Don't have a DS-specific story, but always have been an practitioner of 'better to ask forgiveness than permission'.
10	Yes	I answered yes, because I recognise that in some situations, it may become necessary to break some rules in order to do things at speed to make some ground quickly on establishing your system, which is very relevant if you've only been given resources for a specified time. However, for us it hasn't really been necessary to actually break any rules; we've been very fortunate to have always had the support of senior stakeholders. As we've been able to demonstrate that the desired change a design system brings isn't possible "overnight", we continue to have their support so no real rule breaking needed. We probably do need to be a bit firmer with some teams adopting our system but no "rascalness" needed here. One caveat to this is that very recently, I did bypass our procurement process slightly when it came to meeting suppliers for a new documentation platform for our DS- this was done so that our team could quickly meet with suppliers to get some key information to help build a strong business case for getting funding for the platform licensing costs. I'm currently continuing on that path for the moment but I know I will have to backtrack and engage with procurement- having to ask for forgiveness may elongate the next stage of the process but I'm confident I can manage this :)
11	Yes	Other than sticking to web components when people are arguing for React I don't really have a story. My team is more ignored than told what to do so it's hard to break rules if no one makes any.
12	Yes	We didn't have enough resources assigned to the design system: PMs and execs had to focus 100% of their time on product on paper. So we did an underground/part-time plan: we talked to a lot of people, gave them access, and guided them along. Unofficially. And we had little architecture meetings in the form of "would you like the design system be this way or that way" and made those changes. We got people to start talking and creating the build system. So, before the project actually kicked off, we had a decent amount of structure in place.
13	Yes	There was a modification to an existing component that was needed for an application. The design system team at the time was trying to insist that the application design needed to be altered in order to stay within the rules. As much as we tried to show why it wouldn't work, they wouldn't budge. In the end, our team made the alteration in a new version of a component and put it into production. We worked to make sure it followed the styling and fit as best it could within the system so it was transparent to the users. The code was made available back to the systems team to decide to incorporate the change, or leave it out and consider it an edge case.
14	Yes	I agree that sometimes you need to break the rules to show value or move forward when needed. But I wouldn't call myself a hard yes or no on this question. I have two stories. ----- Early in my career, when I first fell into design systems (by pure accident), I had to combine five products into one platform suite. At the time, getting buy-in or spinning up a team wasn't a thought that crossed my mind, mostly because I had no idea what I was getting into. I instead ran a side project with a front-end dev without telling anyone and reskinned a framework, creating the beginnings of that company's first design system. It was far from perfect, but it solved a fundamental problem the business had, and teams wanted it; as a result, that system remained in place for around two years after I left, after which they decided to rebuild it as a custom system with a dedicated team. This is an instance where if I had the opportunity to go back, knowing what I know now, I probably would have done things a bit differently to get buy-in and treat it like a product to create a more sustainable design system for the long-term. ---- At my last company, we were slowly getting buy-in, but we didn't have the fundamental resources to kick us off properly. At the time, the business used Sketch (without any version control software). The business also had fairly strict rules on tooling and changing tooling, which would be a huge issue in creating a scaleable system for our designers (~50). I shared this problem with my Head of Product — who also knew it would be impossible to move us over quickly and convincingly. So he gave me his company credit card, which we used to purchase a Figma license. We started by creating our team and library, then slowly onboarded designers onto Figma and the system. The benefits of having a shared library were immediately apparent, and the business had no choice but to shift over to Figma entirely — and we got an Org licence quite quickly thereafter.
15	Yes	In my last position, I made an agreement with the engineering team to develop a design system. We basically didn't discuss it outside of our teams. The founders would not have been bought into the work given they only valued short term, fast gains. They also had marketing backgrounds and didn't really understand engineering. So, we moved forward by attaching a little design system to every story that went through our roadmap. We got a lot done in a short amount of time this way without disrupting normal workflows. We also reduced time to launch for product launches by 40% for our marketing team.
16	No	N/A too low level for this to be applicable
17	Yes	We decided to build a header component for our DS and once we had a redesign for one of our platforms we invited teams across the organization (also those who were not using the header yet) to come in and share their needs so that we could come up with a navigation that could work on all platforms. We wanted to honor the omni-channel strategy of our company but many teams feel the need to build their own navigation and that's where we clashed in some cases. We didn't have an official mandate to bring our header to other teams so we broke the rules of involving everyone in the new concept phase but that opened a lot of good discussions that made our navigation more flexible and definitely more consistent if used on all areas of our web channel.
18	Yes	It has been a tumultuous process at my current org to even get the ground wet in order to plant the seed that I hope to become our design system. Historically, the leadership on the product side has wanted complete ownership of the system so that components meet their expectations while ensuring there is no wasted effort down the road. As a result, we've made next to no progress in the 18+ months I've been advocating for this. Every minut detail had to go through a lengthy discussion and approval process that would stall even the most mundane of ideas. I was frustrated and my technical manager could tell. One day during our regular 1:1 after what i can only imagine to be a lengthy rant about how it felt that I was letting my peers down on account of not being able to accomplish my main responsibilities, he told me to screw the red tape and just do what I thought was best. I was the subject matter expert as as such he would go to bat for me with any repercussions that came from going rogue. So with his support at my back, I went to work. And in the course of a sprint, built the foundation of our platform components and their subsequent variants. We demoed the system at our monthly innovation happy hour to a product and engineering core that was very much in the dark about this new progress; and it ended up being very well received. So much so that even the leadership that was causing us headaches at the beginning of my tenure admitted that they had overcomplicated the process and have since entrusted my ability to make the right decisions without a litany of meetings to discuss and analyze. Asking for forgiveness rather than permission ended up creating a partnership between the two disciplines rather than a proprietary ownership of the process.
19	Yes	I brought the team together in a workshop to inclusively define what the system team's feature workflow would be (not really "under the radar", but certainly bucking the then-existing company culture of "speed in design systems"). The workshop(s) went well (engineering wanted to rush things, naturally), and the results were stellar - subsequent retros found feedback from both design and engineering enthusiastically sharing the process and workflow benefits they were realizing in their own work. Of course, months later leadership started asking why my other responsibilities were perceived as "slow", and even later all the work we did on the system team's workflow was deprecated in favor of an engineering-driven "component development lifecycle". Symptoms of larger culture challenges, for sure.
20	Yes	We're going through a large transformation from having a "design system" (not really a DS) to creating a true system with coded components, dev<>design connections, and a multi brand way of working. Almost every barrier has to be broken down now, and a lot of it will change how everyone works. Throughout this process of standing up version 1, almost everything I have proposed has been done by way of being a rascal, and its always been the right thing to do. When working through complex token strategies, Ive had to prove my proposals by doing the work despite objections and then walking people through. Ive also had to do this by creating strategy decks where I see gaps and have not seen answers. The decks arent always the thing we then use but they ALWAYS enable solid, focused conversation that leads to clarity and decisions. Ive never found that someone (a manager or peer) feels negative about me doing something despite objections - they may not agree with the approach but then it can be used as a way to move us forward based on a tangible starting point. Having nothing to go off of is what often creates ambiguity, misalignment, and wasted work.
21	Yes	In a previous organization, I wanted to move away from Less to Sass for our CSS architecture. Instead of requesting permission from the engineers (since I belonged to the design organization), I utilized a converter and rewrote part of our codebase myself. When I eventually announced my intention to make this switch, while I still needed to highlight the benefits, the discussion was significantly simplified because most of the work had already been done.
22	Yes	Just recently I redesign the whole company iconography. And many rules needed to be broken to modernize and make some icons actually recognizible. I redesign the whole set and afterwards shared the result with all justifications, in the end they loved the result and approved. So I tend to always deliver what I believe, not matter if we need to bend some rules.
23	No	Previously has tried to break organization’s existing rule but failed multiple times led to me think that it might be impossible to break the rules in order to establish the ideal system, sharing two examples - Wanted to break company’s existing process rules - ask for input and establish a new way of working (with marketing, branding, tech division) for building up the new design system but leadership level across the organization are not aligned and buy-in on this - ended up no team got time to work on this together nor have time to review as every team has siloed goals and objectives assigned that needed to achieve quarterly/yearly which ties to teams incentive and performance - “help me help you” is not applicable when teams are on different timelines and priorities. Reaching out without leadership level aligned and buy-in ended up becoming “love this idea that’s awesome but I don’t wanna/have no time to talk about this”. Wanted to collaborate with vendors together on the design system effort and ask for vendor feedback on the direction to make it actually usable than UI style guide (vendors have existing more mature design systems and resources to develop and implement, company often sign up for out of box solutions than API solutions which make more business sense but it led to us faced challenges to establish that vendor-design system working relationships because that design system effort usually wasn’t in the priority of the discussion when signing up contracts with vendors, and out of box solution makes the design system changes very limited and rigid. Wanted to change that to make it more flexible - it requires to revaluate the vendor contracts and beyond the team controls.
24	No	Leaning into the rules will help build relationships with the leaders you need on your side to hold your org accountable. I exist in the design org but I needed to make changes in the tech org. If I went on my own it would have been seen as a major over step and would have cost me the trust of the engineering community. Instead I created a deck that stated my case with proof and resources and shared it with my leadership team. They then went an influenced to make change happen. I think to assume that change can only be done by YOU is an arrogant and often costly mistake. Please reference Michael Bloombergs presidential run as a perfect example of this hubris.
25	Yes	When large corporations decide to invest in a design system they often treat it like a conventional product team. And depending on the maturity of their engineering culture, this can be at odds with the mission of a design system. They want an easy to consume set of outputs that will transform the org without the org having to change its habits. But they often miss the point of a design system, which is to provide a set of values and processes that teams have to adapt in order to make it sustainable. The often unspoken rule I believe needs to be broken is that engineering can function without direct design collaboration simply because a design system has a component library. The worst manifestation of this comes in the form of adopting design system components for legacy code bases that do not have a dedicated design and/or UX partner. Big orgs assume that the design system can flourish in the absence of design support simply because they have a codified artifact to share. But what happens when the design system components do not align with legacy designs, and there are only engineers around to make decisions? At this point you have to encourage engineers to push back- to break the unspoken rule that they have all of their requirements met simply because leaders believe all a design system is a static toolbox. Maybe this isn't the most succinct example, but in my experience design systems need to break the walls down between disciplines and demand newer networks of communication and support.
26	Yes	I couldn't cite how I broke rules but I did knock on a lot of doors big and small to build alliances for the DS. The DS for a long time was the ignored child so a lot of times being the friendly neighbour helped get through some projects. - No one asked for a Web audit, we did it anyway. Found multiple bugs and found people to help fix it - Started the conversation of Accessibility at my organisation, just went ahead and asked the questions and started channels. We now have a working group & teams helping plan for it across disciplines
27	Yes	I've been lucky enough to work at companies where the DS was usually getting official resources, so I've only had to do this in smallish ways, but it's a great way to be resourceful and to show impact/value. A few examples: — Way back in the day, trying to get resources for a "style guide"/component library. Being able to pitch that we could do it as part of the homepage redesign without adding scope, and if so, then could we...? And delivering. — Writing Sass utilities to simplify some repetitive styling and getting devs to use it in their own code (rather than from the DS) to help them learn it wasn't scary/hard to use mixins, because they were balking at adding that complexity to the system. — A failed time: working with a designer to improve consistency/update some minor visual tweaks. This was stalled because of fears that visual changes would affect key metrics (tl;dr more space = less on screen = fewer clicks, something that was untouchable, even tho the experience was demonstrably worse in other metrics, but I digress.) We got the PR and screenshots ready, and everyone agreed it was great... but hard no because metrics. — This week: "hey, I have this metrics tool ready to go, here's a screenshot of what you were asking about last week, but I need security check/budget to keep it." Really I just want to come to this convo because of this: there's a big difference between being a "rascal" a Dan describes it and being the lone wolf asshole. Rascals might work on something and get it halfway done and start sharing results, because that's compelling. Lone wolfs go off and change things, regardless of whether or not it will disrupt anyone else's life, and ship it without taking others into consideration. Lone wolfs have strong opinions strongly held. There's a fine line, perhaps, but a huge difference in experience.
28	Yes	I think for us, one good example would be how we obtained Figma. Before, our organization was primarily a Sketch/Adobe shop, but we knew we wanted to utilize Figma for its shown successes with design systems and their components. To start we had our agency utilize it for all of our replatform designs and build our first draft system components there. Because we also wanted to use design tokens, we had our developers integrate with the design team and the Design Tokens plugin to pull them right into the code, this gave it a link to two different teams and showcased to external teams and leadership how one tool could pull them together. Once we started distributing assets and working closer to other teams, we explained how they could use Figma directly (if they had it) to utilize our components right in their designs instead of needing to replicate in Sketch. This shifted a few teams (now in addition to our own) to start asking for enterprise and slowly it snowballed until it was finalized in October.
29	Yes	In my current role, I've been "approved" to create a Design System specific to only one of our products. However, I know that many of the components in this system are relatively simple common ui patterns that could be leveraged across multiple teams. Instead of sticking within the confines of my scope, I've chosen to conduct an audit to identify the amount of overlap happening across our organizations different design systems and quantify the impact of streamlining patterns and efforts into centralized teams and libraries. I wouldn't say this is breaking the rules but more so doing what I know is right for the organization.
30	Yes	it has to be gentle rule breaking, if it is flagrant it can actually turn people off some rules are dumb and should broken.
31	Yes	Well the place I work at is pretty lawless, so breaking rules is the norm. In my experience people care much less if you broke the rules and created something of value. When we were creating token themes for other organizations outside of ours, we received a warning from mgmt on not spending too much time on it. But it ultimately lead to a stronger token foundation for that organization and allows them now to scale to other brands. Because of the success of this, we haven’t heard a peep and in face celebrated it on our performance reviews.
32	Yes	I feel a little conflicted on this one, but I'd definitely say YES! I was working for a company that had the beginnings of a design system but didn't want to spend too much time on building and maintaining it. I made sure to make components where I saw they were needed in our design library and I documented them to the best of my ability while battling deadlines for my projects. Often times I got told to not put a lot of effort into the design system as it wasn't a high priority for the business at the moment. fast forward a year later when mergers and acquisitions started to happen and a lot of people in the business were extremely happy that the design system was maintained because development could rapidly build all the components with the right context, and all the new acquisitions could directly link to the system and build their digital presence using it. Do you get a pat on the back for it? No. But I believe us design system enthusiasts get a huge kick out of such an end result anyway and that's why I love doing it.
33	Yes	I’m weird because I’m a steadfast rule follower until the rules don’t make sense. Then I’m a rebel. Never in a bad way but in the sense that I want to provide the best product and I’ve realized over the years that I’m not good with verbally communicating my ideas very effectively. It’s mostly a me problem but because of it I don’t feel like people can always make the most informed decisions. So to solve this I typically will go against decisions to create both paths for a project. My recommended path and the path that the group agreed upon. I’m much better at visual storytelling so when I create both it’s much easier to see the differences between them. It’s the show don’t tell kinda thing. I also try to reframe this from being role breaking to collaborative design. Because I do it for just about every project. I’ve gotten really good at creating a very low fidelity visual representation of the potential paths we can go down for any given project. Showing the pros and cons and presenting the topic as an open discussion between all parties involved. The intention is never to be a rebel but to work smarter. Once I can show how singing can save time and make us more efficient people usually come around.
34	Yes	I haven't broken any rules but in the year + that I've been building and advocating for the design system, there has been a consistent reason for some pushback. With the posing of this question, I'm wondering if it's becoming time to break a rule, stop asking permission, and simply ask for forgiveness after. At least at that point, there would be something to react to.
35	Yes	There was a time where Security prevented the entire organization from allowing inputs/text-fields to autocomplete a user’s data (such as date of birth) to create lower effort forms. Asking Security to review their policy to make it more reasonable provided no results. So instead, I created a specification of autocomplete rules for the design system and told them this is what I was going to publish. Only then did they respond, and after some discussion, autocomplete is now allowed in most cases around the enterprise.
36	Yes	Theres a lot of nuance to the question. Mainly the difference between having "permission" vs having "autonomy". Autonomy means youve established trust within your org, that you have the experience and skills to build tooling that supports the company’s mission even if it means breaking some rules to get there. But these rules are typically internal and center around processes. There are some rules that should not be broken, and these usually extend to public perception of the company or security. In my case, I've been so used to building in public, in open source, that now I'm in a very closed environment which means I cant lean on community or setup tools with piblic APIs. We also have a very talented marketing team who, rightly so, wants to manage our public brand outside of product. These are rules I will not break. However, internal processes, "hierarchies", "lanes" be damned. Luckily I'm supported in that thinking. And as a mentor, I push the same mentality. "Try it and see!"
37	Yes	The rule I broke was a CSS rule. “The monolith” application my team(frontend platform) was trying to move product teams out of defined a 10px font-size. So, 1rem=10px, which…why? In the design system’s component library, we defined a 16px font-size in our css reset. So, 1rem=16px. This was just one of the reasons teams couldn’t use the component library in the monolith. In the end, we were successfully able to get all the product teams to move their frontend out of the monolith, accomplishing the frontend platform team’s objective. However, the marketing team still maintains pages in the monolith that cannot use the shared components. As a result, we need to update the monolith styles to keep up with the design system in addition to maintaining the component library. Hopefully they fully move out soon.
38	No	I usually try not to break the rules of an organization, but rather do a little bit of what I want to change in my spare time and then present the benefits to my team. In this case, if my idea looks good, I usually get more support from my colleagues, which sometimes leads to positive changes and official resources for my idea. But, if I have the chance to hide my idea behind current tasks and do it within the already planned features, then I use it. I just add extra time to each task, and no one even knows how much I care about the product or how much money the organization has to spend because of my care.
39	Yes	I created an internal tool as a pilot for our design system project. Unsanctioned move, barely sanctioned DS team, which was disbanded afterwords.
40	Yes	I suppose it's not quite breaking the rules, but I find myself constantly pushing the rules. Trying to get our DS components adopted is a herculean task as there is a general aversion to redoing anything. My role allows me to see across multiple work-streams, so what I do now is identify new builds and broker the conversations with them to adopt DS components and push for better design and build outcomes. We shall see how this works.
41	No	No but Yes. Majority of the time we honor the rules of the org because we are working with the org. The decision we make as a design system are what's best for the org so majority of the time we work within existing rules and policies. We always try not to break but the outcome is what will be best for the org and sometimes that comes with change.
42	Yes	Much of my design system experience in orgs has been less about battling existing design system guidelines and more about trying to assemble them in the face of outdated or calcified systems. Less breaking existing rules and more building grassroots consensus where leadership was either not bought in, didn't understand the value, or was afraid the effort might fail. One example: I worked on a content-production team that was siloed off from the application development teams and filled with designers who were building a lot of blue-sky user experiences. Leadership thought the team's most important priority was innovative, creative experiences, but this stood at odds with a competing engineering priority: the applications that served the content had strict requirements for content delivery. I established the framework for a design system that worked with existing application requirements, but because I didn't involve leadership (especially engineering leadership), the initiative died — another engineering team's direction (that I wasn't aware of) was selected.
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100