Diana Mounter is a Product Designer and Design Systems Lead at Github.
With nearly 15 years of design and development experience, she joined the Github team in late 2015 after being a Sr. Designer at Etsy.
We spoke with Diana on best practices she’s applied and lessons learned from building and maintaining their internal design system. Watch the full video or read the transcript below!
To know more about the benefits and processes of design systems, download the free e-book Why Build a Design System?
How did you join the Github design systems team?
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’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.
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.
Yeah, so there wasn’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.
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.
Was it difficult to get buy in to create a design system?
I don’t think it was too difficult to get buy in that we needed something because there already was … we weren’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.
What type of restructuring was needed on your end to accommodate the design system?
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.
It’s going to take us a long time to get through refactoring all of our CSS. We don’t really have the opportunity to start with a clean slate. So it’s a lot of iterating on what’s already there. And then there’s some things that have been bigger sweeping updates. But a lot of it has been small additions and iteration.
So I think it took a bit of getting used to for people who weren’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.
What were some of the issues you wanted to resolve with your design system?
I think there’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’s definitely a really big part of it is improving that design development workflow.
And then the other side of it is consistency in user experience. So if we don’t build with consistent styles then the user doesn’t see consistent styles. And it’s not just styles it’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.
Has the design systems team expanded or are you still the sole owner and manager?
Well there’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’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’re the two that are on this full time. And we’re about to open a position to hire a new designer on the team. So we’re hoping to expand that to three.
What does your design systems maintenance and updating process look like?
We don’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, “I keep finding I need this thing and it doesn’t seem to exist.” And so I’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.
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’s usually to look at bigger projects. And to help us get through smaller issues, we have a monthly bug rotation which isn’t really just about killing bugs, it’s about tackling smaller tasks like missing documentation or extending a component style.
And then sometimes product design is part of the work if they’re doing something that is quite a big redesign then there might be a need for a new component. That doesn’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.
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’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.
What challenges have you faced over the years as you’ve built and evolved your design system?
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’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’t really considered how much would be about communication.
So we’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’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.
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’s stuff that’s like is behind the scenes that is not necessarily changing how things look.
And balancing that work and showing that we’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’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.
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’s difficult when you’re trying to do a big code refactoring. You need to be focused. We have had to figure out ways to manage that.
We introduced an on call GT system which many of the teams at Github do. It’s called First Responder. And so each week someone’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.
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?
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’t ping us be we saw they were working on something, try to say, “Hey, did you know that these patents already exist. You don’t need to write new CSS here. ” 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’t in Primer and that had no documentation.
So people aren’t going to use something if they don’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. If it is easier to use than writing in CSS then that’s going to win people over.
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’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’s an important part of it.
When you were first auditing all of the existing design components, did you uncover a lot of unexpected inconsistency?
It wasn’t a surprise. It’s not the first time I’ve worked in a company that has many, many people contributing. And I think that’s to be expected. That’s going to happen over time and I think older companies don’t start out thinking that one of the first things they are going to make is a design systems team. I think it’s when things start to become quite painful that they realize that they need people focused on this.
It has been around for quite a few years and it’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.
As a designer, do you find that having a development background on a design systems team is particularly useful in everyday work?
Absolutely. It means that you can help build the design system. It’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, “Can you please build it for me?” Not saying that can’t happen but I think it’s very empowering if you can build it yourself.
And then I think you have a much better understanding of what this also means to engineers. When we design the design systems it’s not just for designers. It’s for anyone that’s working on the front end. Absolutely, I don’t know how I would really approach this if I didn’t have those sort of skills really.
For a design system, Is it a challenge to balance consistency with allowing enough freedom for creativity?
I think unless you’re the sole person building the thing that you’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.
And so if you’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’s about having conversations around that and seeing if you can find a way that works for both.
I think it doesn’t take away creativity. It’s just implementing stuff. I think this actually removes some of the mundane decisions and things that they shouldn’t even need to think about and gives them more freedom to think about much bigger problems. Edwin always uses the “what color should the button be” example. There’s a lot of problems to think about when you’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.
And it’s really interesting that you mentioned that sometimes there’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?
I think the only one that springs to mind that feels like a compromise but I think I’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’re repeating that stuff in many places it doesn’t feel dry to engineers. And it also can mean people are worried about keeping consistency.
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’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.
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’t know. I think that’s one of the things I like about working on teams is when you feel like you’re making decisions that everybody is excited about and doing things that everyone wants. Compromise isn’t always a negative thing.
Has the technology stack GitHub evolved alongside the design system or perhaps as a result of the design system?
I think we’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’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.
And we want to change that. And we’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’re helping us come up with a solution that helps no just with them but other teams as well. I think we’re at that point where it’s starting to happen. But there hasn’t been huge changes quite yet.
How does the team measure the success of the design system?
Again that’s something that we are starting to get a bit more serious about right now. We do track metrics and we’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. Not all of them are using the design system yet.
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’s certainly a metric. And then I’ve been looking at stats in terms of how many view in our code base use our design system.
And I’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’s not just about how much of our site is using the design system.
It’s like are they using it in the way that’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’s something that we’re actually working on at the time.
Has the design system lead to any improvements to either the efficiency or the overall consistency of product updates?
Yeah, there’s been a fair amount of new features shipped over the last year. And that’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’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.
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’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’re having a bad day that we can go look at it.
Without a design system in place, can design be a bottleneck in the development process?
That’s an interesting question. I think that there’s a lot of companies that don’t have as many designers that they would like to have. I don’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’t have someone there at the beginning to implement that. So I don’t really know if I have a great answer to that question to be honest. I think you’ve got to have design thinking in there somewhere. But I don’t think that always has to be from a designer.
Engineers and product managers can make great decisions too. And having some of the really simple design decisions documented that’s something that doesn’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.
Looking back at the whole design systems journey at Github, would you do anything differently?
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’t so obvious in what we were doing.
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.
That was probably like one of the hardest lessons that I’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’t do things that make builds fail.
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’t the worst thing. Don’t block people’s work without really good reasons.
Now on the design systems team, do you focus more on just a handful of tasks instead of doing a little bit here and there?
Yes, as much as possible. I think it is just the nature of this type of work that we’re going to get constant request for help or questions. Because there’s still more work to be done. It’s just getting to the stage where I feel like the design system is kind of maturing. But there’s still a lot of refactoring work to do. So I think we’re trying to be focused on a couple of projects at a time. We’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.
How does a team prioritize its work? Is it done together or more autonomous?
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’ll just ping me or ping a few of us on a select channel and we’ll have a quick chat about it.
And if it’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’re both able to look at projects across the company a bit more and give me a heads up if they’re somebody that I need to sync up with that I don’t realize.
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’s a bit of both. It’s some higher level larger product planning and then generally day-to-day people that I trusted to make their own decisions.
If you could sit down with somebody who’s about to embark on creating their design system, what would be the urgent advice that you give them?
I think I would tell them to document everything from the beginning.
Document as you go but don’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.
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.
