{"id":15549,"date":"2017-05-16T14:50:37","date_gmt":"2017-05-16T21:50:37","guid":{"rendered":"https:\/\/www.uxpin.com\/studio\/?p=15549"},"modified":"2020-04-22T06:35:37","modified_gmt":"2020-04-22T13:35:37","slug":"githubs-design-system-interview-diana-mounter","status":"publish","type":"post","link":"https:\/\/www.uxpin.com\/studio\/blog\/githubs-design-system-interview-diana-mounter\/","title":{"rendered":"Github&#8217;s Design System: Interview with Diana Mounter"},"content":{"rendered":"<p><span style=\"font-weight: 400;\">Diana Mounter is a Product Designer and Design Systems Lead at Github. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">With nearly 15 years of design and development experience, she joined the Github team in late 2015 after being a Sr. Designer at Etsy.<\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-15618\" src=\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2017\/05\/diana-mounter.png\" alt=\"\" width=\"512\" height=\"512\" srcset=\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2017\/05\/diana-mounter.png 512w, https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2017\/05\/diana-mounter-300x300.png 300w, https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2017\/05\/diana-mounter-200x200.png 200w\" sizes=\"auto, (max-width: 512px) 100vw, 512px\" \/><\/p>\n<p><span style=\"font-weight: 400;\">We spoke with Diana on best practices she\u2019s applied and lessons learned from building and maintaining their internal design system. &nbsp;Watch the full video or read the transcript below!<\/span><\/p>\n<p><iframe loading=\"lazy\" src=\"https:\/\/www.youtube.com\/embed\/nneaQMcWo4E\" width=\"560\" height=\"315\" frameborder=\"0\" allowfullscreen=\"allowfullscreen\"><\/iframe><\/p>\n<p>To know more about the benefits and processes of design systems, download the free e-book&nbsp;<em><a href=\"https:\/\/www.uxpin.com\/studio\/ebooks\/design-systems-why-build-one\/\">Why Build a Design System?<\/a><\/em><\/p>\n<h2><span style=\"font-weight: 400;\">How did you join the Github design systems team?<\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">Well, when I joined Github, I was actually hired as a product designer to work on their core product things like issues and milestones and stuff like that. So there wasn&#8217;t actually a design systems team. I started at a funny time of year just because it was the end of the year. So I had a bit of down time before projects really kicked off. And so I just started to dig around in the CSS and start taking stock of things and asking questions.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">So from there I started feeling like we needed to make some improvements to the style guide and Primer was already in existence then but there was a lot of CSS that was not in Primer and styles that were not documented which seemed like a bit of a problem. It seemed like as a new person it was hard to hit the ground running and be able to design in the browser really quickly which is something I had been used to. I helped work on a style guide there and we had a really great setup for proto typing and stuff.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Yeah, so there wasn&#8217;t a design systems team and I guess I just sort of started to say that I guess we should have one. And Oscar, the design leads and a couple of other people who were interested in working on this stuff started meeting and talking about some of the problems.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">And then it became a more serious thing and it became clear that it was important that we really needed to continue with this work. And it became my full time role after a while because it became too difficult to work on product work and that at the same time.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\">Was it difficult to get buy in to create a design system?<\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">I don&#8217;t think it was too difficult to get buy in that we needed something because there already was &#8230; we weren&#8217;t starting from scratch. There was Primer. And also I think it helped that Mark Coudray was the head of design and he felt pretty strapped so he sort of understood those sort of needs. I think what was difficult is to get people on board with restructuring how Primer worked and how that CSS was written and getting designers and engineers to really use the system. So that took a bit of time.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\">What type of restructuring was needed on your end to accommodate the design system?<\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">In some ways, yes. And in some ways, no. I guess the main thing was that we had not very flexible styles. One of the first things we did was start to introduce utilities or atomic classes. Because that was something that we could add on top of what was already there without having to refactor every single component in the system. So that gave us some quick wins and allowed us to start introducing actual systems behind the styles like typography scales and experiment and test it out with utilities and start to bring those systems over to our components. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">It&#8217;s going to take us a long time to get through refactoring all of our CSS. We don&#8217;t really have the opportunity to start with a clean slate. So it&#8217;s a lot of iterating on what&#8217;s already there. And then there&#8217;s some things that have been bigger sweeping updates. But a lot of it has been small additions and iteration.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">So I think it took a bit of getting used to for people who weren&#8217;t really familiar with functional CSS or atomic classes and things like that. Once people started to build out pages with that stuff it kind of clicked and people started to really love that way of working with CSS and started asking for more.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\">What were some of the issues you wanted to resolve with your design system?<\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">I think there&#8217;s two sides to it for me. One is improving the design to development work flow. So making it easier and faster to design in the browser. Making it easier for people to not have to worry about primitive decisions in design and can spend more time thinking about the bigger user experience problems and product decisions. So that&#8217;s definitely a really big part of it is improving that design development workflow.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">And then the other side of it is consistency in user experience. So if we don&#8217;t build with consistent styles then the user doesn&#8217;t see consistent styles. And it&#8217;s not just styles it&#8217;s also interaction patents and page layouts. So a lot of projects that we do, have that kind of dual benefit of making our style guide easier to work with. And then making the UI easier to use.<\/span><\/p>\n<p><a href=\"https:\/\/www.uxpin.com\/studio\/ebooks\/design-systems-why-build-one\/\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-15613\" src=\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2017\/05\/Screen-Shot-2017-05-16-at-2.12.05-PM.png\" alt=\"\" width=\"940\" height=\"522\" srcset=\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2017\/05\/Screen-Shot-2017-05-16-at-2.12.05-PM.png 940w, https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2017\/05\/Screen-Shot-2017-05-16-at-2.12.05-PM-540x300.png 540w, https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2017\/05\/Screen-Shot-2017-05-16-at-2.12.05-PM-768x426.png 768w\" sizes=\"auto, (max-width: 940px) 100vw, 940px\" \/><\/a><\/p>\n<h2><span style=\"font-weight: 400;\">Has the design systems team expanded or are you still the sole owner and manager?<\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">Well there&#8217;s two of us on this full time and then we have a group of contributors. So we organized a resource project with core maintainers and contributors are spread across product and creative teams. And so I&#8217;m the lead for the designs systems team and one of the designers John Rayhan, he has been working on Primer quite a long time and has also got more of an engineering background and we&#8217;re the two that are on this full time. And we&#8217;re about to open a position to hire a new designer on the team. So we&#8217;re hoping to expand that to three.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\"> What does your design systems maintenance and updating process look like? <\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">We don&#8217;t have anything as formal as a proposal that people have to make. But we do have contribution guidelines for the team. Some things come through and they are smaller requests like, &#8220;I keep finding I need this thing and it doesn&#8217;t seem to exist.&#8221; And so I&#8217;ll do a quick review of the code base and see how much we seem to be using that patent and whether it does already exist in a patent or component or a utility or not.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">And so it would just be a case of opening and issue and we just try and get to it when we can. We do hold regular prioritization and planning meetings. So that&#8217;s usually to look at bigger projects. And to help us get through smaller issues, we have a monthly bug rotation which isn&#8217;t really just about killing bugs, it&#8217;s about tackling smaller tasks like missing documentation or extending a component style. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">And then sometimes product design is part of the work if they&#8217;re doing something that is quite a big redesign then there might be a need for a new component. That doesn&#8217;t happen too much yet but when that does come up one of the contributors will pair with that person and just walk them through how to construct that component. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">That will result in a request and feedback not just from design systems but also from other design teams. Because we are trying not to work in isolation. There&#8217;s a lot of moving parts to Github and so getting eyes on this stuff from the product design will help us find out that this is similar to this thing over here and we need to rethink how we styled this.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\"> What challenges have you faced over the years as you\u2019ve built and evolved your design system?<\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">Many challenges. I think really it is finding ways to inspire and excite the rest of the team to get them on board and to try and explain the why behind what we are doing. And why we are changing how we construct the CSS. That&#8217;s something that has been challenging. I think walking into this I was very much thinking about the CSS and the design development work flow and hadn&#8217;t really considered how much would be about communication.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">So we&#8217;ve had to work on a number of things like from how we propose the changes and getting eyes on that from the rest of the team to broadcasting the updates that we&#8217;ve made a bit more widely. So we have an internal team blog and we just post stuff on there. Also communicating through the style guide so we make sure that we put clear statuses on everything and link to an issue for feedback and have a change log. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">So that communication aspect, we hit a few bumps in the road before we realized how important that was. So that was definitely challenging. The other thing is just balancing doing the maintenance work and the big refactoring work that is a little bit invisible. It&#8217;s stuff that&#8217;s like is behind the scenes that is not necessarily changing how things look. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">And balancing that work and showing that we&#8217;re actually doing constructive work with the more innovative and new stuff. The stuff that paves new pathways and introduces new patents or increases workflows. Because they&#8217;re very different mindsets and different types of work. And also as we have grown as a team, people know that we exist. More and more teams are using the design systems. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">We also get more notifications to review requests or to help people out with stuff or to give feedback on things. So you get a bit of noise from that. And that&#8217;s difficult when you&#8217;re trying to do a big code refactoring. You need to be focused. We have had to figure out ways to manage that.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">We introduced an on call GT system which many of the teams at Github do. It&#8217;s called First Responder. And so each week someone&#8217;s a First Responder so they can deal with most of that noise and make sure other people get responded to quickly so that people can be focused on more of their project work.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\"> You mentioned that one of the challenges was getting people excited and on board with the design system. What tactics did you find were particularly effective at evangelizing and spreading the methodology? <\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">I think being really helpful and being very available to start with. Anytime someone was working on something and pinged us or maybe they didn&#8217;t ping us be we saw they were working on something, try to say, &#8220;Hey, did you know that these patents already exist. You don&#8217;t need to write new CSS here. &#8221; And just being very available when people needed help. We needed to win friends to start with. Another thing was trying to get everything documented because we had all of these styles that weren&#8217;t in Primer and that had no documentation.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">So people aren&#8217;t going to use something if they don&#8217;t know it exists. We have put a huge amount of effort on trying to get as much stuff documented as possible. Now that the documentation is more thorough and it is more valuable to people they use it more. And then they know that exists. &nbsp;If it is easier to use than writing in CSS then that&#8217;s going to win people over. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">And I think the final thing is that once people do use the new stuff, if they enjoy using the new stuff more than writing and battling with old styles then that&#8217;s going to make them want to keep using that style. So making sure that your design system actually is enjoyable to use does make that design development easier to use and makes the work flow faster and easier and better. I think that&#8217;s an important part of it. &nbsp;<\/span><\/p>\n<h2><span style=\"font-weight: 400;\"> When you were first auditing all of the existing design components, did you uncover a lot of unexpected inconsistency?<\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">It wasn&#8217;t a surprise. It&#8217;s not the first time I&#8217;ve worked in a company that has many, many people contributing. And I think that&#8217;s to be expected. That&#8217;s going to happen over time and I think older companies don&#8217;t start out thinking that one of the first things they are going to make is a design systems team. I think it&#8217;s when things start to become quite painful that they realize that they need people focused on this.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">It has been around for quite a few years and it&#8217;s had hundreds of engineers and designers contributing to that so nothing was really super surprising to me. Probably the one thing that did surprise me the most was the lack of a color system which I recently worked on and I am a little baffled about that not existing for a while. <\/span><\/p>\n<h2><span style=\"font-weight: 400;\"> As a designer, do you find that having a development background on a design systems team is particularly useful in everyday work?<\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">Absolutely. It means that you can help build the design system. It&#8217;s more likely to be successful and be implemented if you can actually take part in building it. You have to work probably a lot harder in building a relationship with an engineer to say you made up all the stuff and say, &#8220;Can you please build it for me?&#8221; Not saying that can&#8217;t happen but I think it&#8217;s very empowering if you can build it yourself.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">And then I think you have a much better understanding of what this also means to engineers. When we design the design systems it&#8217;s not just for designers. It&#8217;s for anyone that&#8217;s working on the front end. Absolutely, I don&#8217;t know how I would really approach this if I didn&#8217;t have those sort of skills really.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\">For a design system, Is it a challenge to balance consistency with allowing enough freedom for creativity? <\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">I think unless you&#8217;re the sole person building the thing that you&#8217;re always going to have to collaborate with people and make some compromises. And for a design systems team all of your colleagues are the primary users. Everything you do for them does also benefit the customers too. But your first and primary user is all of your colleagues.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">And so if you&#8217;re designing anything you need to have empathy for them and take those needs into consideration. And that means understanding the pain it might cause the engineer if you do things the way that is preferable to a designer. It&#8217;s about having conversations around that and seeing if you can find a way that works for both.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">I think it doesn&#8217;t take away creativity. It&#8217;s just implementing stuff. I think this actually removes some of the mundane decisions and things that they shouldn&#8217;t even need to think about and gives them more freedom to think about much bigger problems. Edwin always uses the &#8220;what color should the button be&#8221; example. There&#8217;s a lot of problems to think about when you&#8217;re designing a new feature and the last thing I want designers to have to think about is how do they want to write the CSS.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">And it&#8217;s really interesting that you mentioned that sometimes there&#8217;s compromises that you have to make because this is something that serves both designers and developers. Are there any that pop up in your mind through the years of having worked on this design system that were just necessary to get this implemented and useful for both groups of people?<\/span><\/p>\n<p><span style=\"font-weight: 400;\">I think the only one that springs to mind that feels like a compromise but I think I&#8217;m okay with that is that we have some patents that could be achieved all with utilities and single purpose classes. But for some patents you end up paying for that in the markup because you can end up with quite a lot of markup. And if you&#8217;re repeating that stuff in many places it doesn&#8217;t feel dry to engineers. And it also can mean people are worried about keeping consistency.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">There are solutions to that. I think a lot of people are using things like react and are extracting things at a component level which has the CSS and the JS all together. We don&#8217;t have something quite like that in our stack at the moment. There are ways that we can extract patents. But sometimes we decide to group that up into a CSS component rather than having a lot of utility classes repeated.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">That to me is a compromise but quite a reasonable one in the way things are right now. But if I was working on a personal project then I might not do that. Otherwise I am maybe really persuasive and get everyone to agree with me eventually. I don&#8217;t know. I think that&#8217;s one of the things I like about working on teams is when you feel like you&#8217;re making decisions that everybody is excited about and doing things that everyone wants. Compromise isn&#8217;t always a negative thing.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\"> Has the technology stack GitHub evolved alongside the design system or perhaps as a result of the design system?<\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">I think we&#8217;re starting to get to that point now. I think honestly we have had a lot of work to do to get our base design systems into place. At the moment we&#8217;re rethinking how we package up stuff and how we pull in Primer. And at the moment it lives in GitHub because we just felt like we needed to get all of the design systems together and get it pushed out to the repo.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">And we want to change that. And we&#8217;ve been talking with the Web systems team who sort of support us in an engineering way as the rest of the company. And they&#8217;re helping us come up with a solution that helps no just with them but other teams as well. I think we&#8217;re at that point where it&#8217;s starting to happen. But there hasn&#8217;t been huge changes quite yet.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\"> How does the team measure the success of the design system? <\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">Again that&#8217;s something that we are starting to get a bit more serious about right now. We do track metrics and we&#8217;ve been talking about what are metrics for success. And so one of them for us is that we not just GitHub.com but that we have a lot of external other sites for things like our conferences but also things like our developer site. &nbsp;Not all of them are using the design system yet.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">So one of our metrics for success is that over time, all of them use the design system. And not only that, but makes it easier to stay up to date with that design system. Which is one of the reasons we sort of thinking about how we distribute the packages and things like that. So that&#8217;s certainly a metric. And then I&#8217;ve been looking at stats in terms of how many view in our code base use our design system. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">And I&#8217;ve been tracking individual projects like what percentage of the code base is on the new color system and tracking that as the new project progresses. So I think it is really important to have visibility to see if that is successful. But it&#8217;s not just about how much of our site is using the design system. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">It&#8217;s like are they using it in the way that&#8217;s intended. Or are there a lot of overrides or is there a component that is only used once. So those sorts of metrics are things that I would like to start tracking. That&#8217;s something that we&#8217;re actually working on at the time.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\"> Has the design system lead to any improvements to either the efficiency or the overall consistency of product updates?<\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">Yeah, there&#8217;s been a fair amount of new features shipped over the last year. And that&#8217;s been great to have the new system in place. People tend to when they are rebuilding something anyway, they are more easily able to use the new system. And we&#8217;ve had a lot of positive comments from designers and engineers that just find it a lot faster to build stuff out. There was one project where they wrote without a designer for part of the project.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">And two of the engineers were able to get really far just by using the new styles and referring to the documentation. Which is great because that the designer wasn&#8217;t a complete bottleneck for that project to get underway. A few of us were saying that we should keep track of all the nice things so when we&#8217;re having a bad day that we can go look at it. &nbsp;<\/span><\/p>\n<h2><span style=\"font-weight: 400;\">Without a design system in place, can design be a bottleneck in the development process? <\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">That&#8217;s an interesting question. I think that there&#8217;s a lot of companies that don&#8217;t have as many designers that they would like to have. I don&#8217;t think that for us that there was no design process involved before the engineers started building something. There was all ready product thinking and design expiration early on they just didn&#8217;t have someone there at the beginning to implement that. So I don&#8217;t really know if I have a great answer to that question to be honest. I think you&#8217;ve got to have design thinking in there somewhere. But I don&#8217;t think that always has to be from a designer.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Engineers and product managers can make great decisions too. And having some of the really simple design decisions documented that&#8217;s something that doesn&#8217;t require the presence of a designer to help you get through. But I think at some point in the project you need help from a designer to make some bigger user decisions and things like that. <\/span><\/p>\n<h2><span style=\"font-weight: 400;\"> Looking back at the whole design systems journey at Github, would you do anything differently? <\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">Yes. One as we started to be pulled in different directions, in hindsight, earlier on I would have been a bit more strict about focusing on one or two things at a time. And not try to do a bit of everything. That I think resulted in us feeling like we were always busy because you were trying to do a bit there and bit there and a bit somewhere else. It was hard on the reputation of the team because it wasn&#8217;t so obvious in what we were doing.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">So I would have seen what was important to prioritize this work and be protective of our time and our reputation as a team. And say that all of these things are important but we are going to have to pick a couple of them so that we can be able to give more attention to fewer projects at a time and do a better job.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">That was probably like one of the hardest lessons that I&#8217;ve learned which sounds so simple and really obvious right now but it took a while to figure that out and plan a better prioritization process. It just felt like everything was important to start with. So that was probably the biggest one. A really funny but very specific story was don&#8217;t do things that make builds fail.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">We introduced a letter that failed if you added new styles if you fabricate and that just frustrated everybody. But on the other hand nobody knew our team existed so maybe that wasn&#8217;t the worst thing. Don&#8217;t block people&#8217;s work without really good reasons.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\"> Now on the design systems team, &nbsp;do you focus more on just a handful of tasks instead of doing a little bit here and there?<\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">Yes, as much as possible. I think it is just the nature of this type of work that we&#8217;re going to get constant request for help or questions. Because there&#8217;s still more work to be done. It&#8217;s just getting to the stage where I feel like the design system is kind of maturing. But there&#8217;s still a lot of refactoring work to do. So I think we&#8217;re trying to be focused on a couple of projects at a time. We&#8217;re just trying to use the First Responder schedule and CSS bug rotation to try to deal with the smaller but frequent requests. And it feels much better like that. It feels like we can be more focused and it feels like we can ship things a bit more often.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\"> How does a team prioritize its work? Is it done together or more autonomous? <\/span><\/h2>\n<p><span style=\"font-weight: 400;\"> &nbsp;&nbsp;&nbsp;&nbsp;<\/span> <span style=\"font-weight: 400;\">I think it depends on the level of the project and the size of the task. So on smaller tasks the team makes their own decisions. Sometimes if they are a little bit unsure then they&#8217;ll just ping me or ping a few of us on a select channel and we&#8217;ll have a quick chat about it.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">And if it&#8217;s something that feels like we need to have a wider discussion then we will schedule that. And then the bigger initiatives I meet with my manager who is also a contributor on the Web and creative team and the head of design. They&#8217;re both able to look at projects across the company a bit more and give me a heads up if they&#8217;re somebody that I need to sync up with that I don&#8217;t realize. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">Or just a heads up about some of the projects down in the pipeline. And then I also bring out things that happened in the day that I thought we need to give more attention to. So it&#8217;s a bit of both. It&#8217;s some higher level larger product planning and then generally day-to-day people that I trusted to make their own decisions.<\/span><\/p>\n<h2><span style=\"font-weight: 400;\"> If you could sit down with somebody who&#8217;s about to embark on creating their design system, what would be the urgent advice that you give them?<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">I think I would tell them to document everything from the beginning. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">Document as you go but don&#8217;t worry too much about how beautiful that documentation is. That would definitely be high up on the list. Like I was just saying, try to focus on fewer things at a time. Which I think is just generally sensible advice. And figure out what are the biggest points that people are experiencing. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">Because if you can solve them for the rest of your team then you are going to win some fans and those people will become your champions as you grow and expand a design system.<\/span><\/p>\n<section class=\"uxpin-trial-widget\"><h2>Join the world's best designers who&nbsp;use UXPin.<\/h2><span class=\"white-info\">Sign up for a free trial.<\/span><a href=\"https:\/\/www.uxpin.com\/sign-up\" class=\"btn btn-flat sign-up-btn white\">Try it for free!<\/a><\/section>\n","protected":false},"excerpt":{"rendered":"<p>Design systems insights from Github designer Diana Mounter. <\/p>\n","protected":false},"author":9,"featured_media":15617,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,199,174],"tags":[],"class_list":["post-15549","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","category-design-systems","category-enterprise-ux"],"yoast_title":"","yoast_metadesc":"Diana Mounter is a Product Designer and Design Systems Lead at Github. We interview her on the importance of design systems.","acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v27.5 (Yoast SEO v27.5) - https:\/\/yoast.com\/product\/yoast-seo-premium-wordpress\/ -->\n<title>Github&#039;s Design System: Interview with Diana Mounter | UXPin<\/title>\n<meta name=\"description\" content=\"Diana Mounter is a Product Designer and Design Systems Lead at Github. We interview her on the importance of design systems.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.uxpin.com\/studio\/blog\/githubs-design-system-interview-diana-mounter\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Github&#039;s Design System: Interview with Diana Mounter\" \/>\n<meta property=\"og:description\" content=\"Diana Mounter is a Product Designer and Design Systems Lead at Github. We interview her on the importance of design systems.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.uxpin.com\/studio\/blog\/githubs-design-system-interview-diana-mounter\/\" \/>\n<meta property=\"og:site_name\" content=\"Studio by UXPin\" \/>\n<meta property=\"article:published_time\" content=\"2017-05-16T21:50:37+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2020-04-22T13:35:37+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2017\/04\/4-18-launch.png\" \/>\n\t<meta property=\"og:image:width\" content=\"800\" \/>\n\t<meta property=\"og:image:height\" content=\"600\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Jerry Cao\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Jerry Cao\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"23 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/blog\\\/githubs-design-system-interview-diana-mounter\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/blog\\\/githubs-design-system-interview-diana-mounter\\\/\"},\"author\":{\"name\":\"Jerry Cao\",\"@id\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/#\\\/schema\\\/person\\\/e58da1b4c401eb288436977eb9810a18\"},\"headline\":\"Github&#8217;s Design System: Interview with Diana Mounter\",\"datePublished\":\"2017-05-16T21:50:37+00:00\",\"dateModified\":\"2020-04-22T13:35:37+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/blog\\\/githubs-design-system-interview-diana-mounter\\\/\"},\"wordCount\":4652,\"image\":{\"@id\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/blog\\\/githubs-design-system-interview-diana-mounter\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/wp-content\\\/uploads\\\/2017\\\/04\\\/4-18-launch.png\",\"articleSection\":[\"Blog\",\"Design Systems\",\"Enterprise UX\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/blog\\\/githubs-design-system-interview-diana-mounter\\\/\",\"url\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/blog\\\/githubs-design-system-interview-diana-mounter\\\/\",\"name\":\"Github's Design System: Interview with Diana Mounter | UXPin\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/blog\\\/githubs-design-system-interview-diana-mounter\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/blog\\\/githubs-design-system-interview-diana-mounter\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/wp-content\\\/uploads\\\/2017\\\/04\\\/4-18-launch.png\",\"datePublished\":\"2017-05-16T21:50:37+00:00\",\"dateModified\":\"2020-04-22T13:35:37+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/#\\\/schema\\\/person\\\/e58da1b4c401eb288436977eb9810a18\"},\"description\":\"Diana Mounter is a Product Designer and Design Systems Lead at Github. We interview her on the importance of design systems.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/blog\\\/githubs-design-system-interview-diana-mounter\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/blog\\\/githubs-design-system-interview-diana-mounter\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/blog\\\/githubs-design-system-interview-diana-mounter\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/wp-content\\\/uploads\\\/2017\\\/04\\\/4-18-launch.png\",\"contentUrl\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/wp-content\\\/uploads\\\/2017\\\/04\\\/4-18-launch.png\",\"width\":800,\"height\":600,\"caption\":\"4 18 launch\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/blog\\\/githubs-design-system-interview-diana-mounter\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Github&#8217;s Design System: Interview with Diana Mounter\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/#website\",\"url\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/\",\"name\":\"Studio by UXPin\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/#\\\/schema\\\/person\\\/e58da1b4c401eb288436977eb9810a18\",\"name\":\"Jerry Cao\",\"description\":\"Jerry Cao is a content strategist at UXPin where he gets to put his overly active imagination to paper every day. In a past life, he developed content strategies for clients at Brafton and worked in traditional advertising at DDB San Francisco. In his spare time he enjoys playing electric guitar, watching foreign horror films, and expanding his knowledge of random facts. Follow him on Twitter.\",\"sameAs\":[\"http:\\\/\\\/uxpin.com\"],\"url\":\"https:\\\/\\\/www.uxpin.com\\\/studio\\\/author\\\/jerrycao\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Github's Design System: Interview with Diana Mounter | UXPin","description":"Diana Mounter is a Product Designer and Design Systems Lead at Github. We interview her on the importance of design systems.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.uxpin.com\/studio\/blog\/githubs-design-system-interview-diana-mounter\/","og_locale":"en_US","og_type":"article","og_title":"Github's Design System: Interview with Diana Mounter","og_description":"Diana Mounter is a Product Designer and Design Systems Lead at Github. We interview her on the importance of design systems.","og_url":"https:\/\/www.uxpin.com\/studio\/blog\/githubs-design-system-interview-diana-mounter\/","og_site_name":"Studio by UXPin","article_published_time":"2017-05-16T21:50:37+00:00","article_modified_time":"2020-04-22T13:35:37+00:00","og_image":[{"width":800,"height":600,"url":"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2017\/04\/4-18-launch.png","type":"image\/png"}],"author":"Jerry Cao","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Jerry Cao","Est. reading time":"23 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.uxpin.com\/studio\/blog\/githubs-design-system-interview-diana-mounter\/#article","isPartOf":{"@id":"https:\/\/www.uxpin.com\/studio\/blog\/githubs-design-system-interview-diana-mounter\/"},"author":{"name":"Jerry Cao","@id":"https:\/\/www.uxpin.com\/studio\/#\/schema\/person\/e58da1b4c401eb288436977eb9810a18"},"headline":"Github&#8217;s Design System: Interview with Diana Mounter","datePublished":"2017-05-16T21:50:37+00:00","dateModified":"2020-04-22T13:35:37+00:00","mainEntityOfPage":{"@id":"https:\/\/www.uxpin.com\/studio\/blog\/githubs-design-system-interview-diana-mounter\/"},"wordCount":4652,"image":{"@id":"https:\/\/www.uxpin.com\/studio\/blog\/githubs-design-system-interview-diana-mounter\/#primaryimage"},"thumbnailUrl":"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2017\/04\/4-18-launch.png","articleSection":["Blog","Design Systems","Enterprise UX"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/www.uxpin.com\/studio\/blog\/githubs-design-system-interview-diana-mounter\/","url":"https:\/\/www.uxpin.com\/studio\/blog\/githubs-design-system-interview-diana-mounter\/","name":"Github's Design System: Interview with Diana Mounter | UXPin","isPartOf":{"@id":"https:\/\/www.uxpin.com\/studio\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.uxpin.com\/studio\/blog\/githubs-design-system-interview-diana-mounter\/#primaryimage"},"image":{"@id":"https:\/\/www.uxpin.com\/studio\/blog\/githubs-design-system-interview-diana-mounter\/#primaryimage"},"thumbnailUrl":"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2017\/04\/4-18-launch.png","datePublished":"2017-05-16T21:50:37+00:00","dateModified":"2020-04-22T13:35:37+00:00","author":{"@id":"https:\/\/www.uxpin.com\/studio\/#\/schema\/person\/e58da1b4c401eb288436977eb9810a18"},"description":"Diana Mounter is a Product Designer and Design Systems Lead at Github. We interview her on the importance of design systems.","breadcrumb":{"@id":"https:\/\/www.uxpin.com\/studio\/blog\/githubs-design-system-interview-diana-mounter\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.uxpin.com\/studio\/blog\/githubs-design-system-interview-diana-mounter\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.uxpin.com\/studio\/blog\/githubs-design-system-interview-diana-mounter\/#primaryimage","url":"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2017\/04\/4-18-launch.png","contentUrl":"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2017\/04\/4-18-launch.png","width":800,"height":600,"caption":"4 18 launch"},{"@type":"BreadcrumbList","@id":"https:\/\/www.uxpin.com\/studio\/blog\/githubs-design-system-interview-diana-mounter\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.uxpin.com\/studio\/"},{"@type":"ListItem","position":2,"name":"Github&#8217;s Design System: Interview with Diana Mounter"}]},{"@type":"WebSite","@id":"https:\/\/www.uxpin.com\/studio\/#website","url":"https:\/\/www.uxpin.com\/studio\/","name":"Studio by UXPin","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.uxpin.com\/studio\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.uxpin.com\/studio\/#\/schema\/person\/e58da1b4c401eb288436977eb9810a18","name":"Jerry Cao","description":"Jerry Cao is a content strategist at UXPin where he gets to put his overly active imagination to paper every day. In a past life, he developed content strategies for clients at Brafton and worked in traditional advertising at DDB San Francisco. In his spare time he enjoys playing electric guitar, watching foreign horror films, and expanding his knowledge of random facts. Follow him on Twitter.","sameAs":["http:\/\/uxpin.com"],"url":"https:\/\/www.uxpin.com\/studio\/author\/jerrycao\/"}]}},"_links":{"self":[{"href":"https:\/\/www.uxpin.com\/studio\/wp-json\/wp\/v2\/posts\/15549","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.uxpin.com\/studio\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.uxpin.com\/studio\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.uxpin.com\/studio\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/www.uxpin.com\/studio\/wp-json\/wp\/v2\/comments?post=15549"}],"version-history":[{"count":0,"href":"https:\/\/www.uxpin.com\/studio\/wp-json\/wp\/v2\/posts\/15549\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.uxpin.com\/studio\/wp-json\/wp\/v2\/media\/15617"}],"wp:attachment":[{"href":"https:\/\/www.uxpin.com\/studio\/wp-json\/wp\/v2\/media?parent=15549"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.uxpin.com\/studio\/wp-json\/wp\/v2\/categories?post=15549"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.uxpin.com\/studio\/wp-json\/wp\/v2\/tags?post=15549"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}