Design systems with Jina Anne
A transcript of Episode 163 of UX Podcast. James Royal-Lawson and Per Axbom talk with Jina Anne about design system. What they are, how to get started and how to manage one.
Transcript
[Music]
James Royal-Lawson: This is UX with me James Royal-Lawson.
Per Axbom: And me Per.
James: Coming to you from Stockholm Sweden. We have listeners in 170 countries from Gibraltar to El Salvador.
Per: I love that. But somebody has to keep track of what countries. Are you keeping track of what countries are listening?
James: I’m starting to document but I have not completed the audit yet. So apologies if I have already mentioned your country or congratulations for saying it twice.
Per: Today we are talking about design systems and I’m really looking forward to it. We are interviewing Jina Anne who created her first style guide in 2004 and I’m going to blatantly steal from the UXLX website because they have a nice paragraph about Jina from her workshop she did this year at UXLX in Lisbon. So Jina Anne has been a designer, a developer, a writer and a speaker on design systems ever since she created that first one in 2004. And at Salesforce today she is lead designer on the lightning design system and there she also created the design system slack which led to start the San Francisco design system coalition and she organizes Clarity the first ever design systems conference.
James: So there’s plenty of design systems included in that little intro.
Per: Plenty. Let’s talk to her.
[Music]
Per: So Jina welcome to UX podcast. Thank you for joining us.
Jina Anne: Thanks for having me.
Per: And we’re talking today about design systems and I’m going to be really honest here and say that I haven’t worked much with design systems I know sometimes I’ve thought I should have a design system here but mostly I built a prototype and so that is the design systems that people use and I’m realizing there must be a better way of doing this and I guess I suppose that’s what you work with. Tell us a bit about what design systems are because I’m not sure I would even be able to explain that.
Jina: Yeah it’s funny because everybody seems to have a different definition. I think these days when people talk about design systems, it’s in the context of web and software or otherwise product design. So in that context it is how you scale design and UI across an application and maybe even different formats of that application like web, native, you might even have different forms of native like android, IOS, and so on.
Some people don’t actually scale to that many platforms so it may just be in the context of a web application but because of all the different ways that a design system can be used I think everyone sort of has a different idea of what they are. But something that I’ve kind of told people is you know it’s definitely a context thing because when I think of the graphics standards manual that you know NASA has or the New York public transportation from back in the mid century days or the 70s like to me that’s still a design system.
It’s just over time it’s kind of evolved and grown into a platform you know usually there’s tooling and a style guide and component library and there’s all these different pieces that come together to be a design system.
James: Right so I mean you will have, Per, in the past worked with style guides.
Per: Yeah like the graphic profile of the company I mean you have to adhere to different I guess fonts and colors.
James: Yeah.
Per: Stuff like that.
James: Yeah but that’s not considered to be sub element of a design system right?
Jina: Yeah I guess, you know the NASA system is definitely more brand based across all the different shuttles and uniforms even bands but you know brand is only a small part of what design systems are today because now we have to concern ourselves with components and interaction patterns and animations and sometimes even sound. So the concept of scaling the system is a much broader context now.
James: In some cases I guess with Salesforce you’re spanning not just devices and platforms but you’re spanning products as well. There is a suite of products that should adhere to a design system.
Jina: Yeah, and some of those products fall into alignment with the overall Salesforce brand and some of the products kind of keep their own brand such as Heroku and Quip so there’s a lot of different factors to think about.
James: One of the things a lot of us will find with this is how much do we need to stick to design systems and that point you made there about different branding across different products is one aspect of it. So when you’ve got kind of like a black sheep amongst your platforms or products, how much do you need to care and how much does it matter?
Jina: I think special snowflake is a nicer term but —
James: Oh okay special snowflake instead of black sheep okay I could go along with that. How do you deal with special snowflakes?
Jina: You know special snowflakes have their place. I think a lot of people think that design systems are very rigid and you’re not supposed to do anything outside of that and that’s not really the case. If you think of the design system as a tool box and you’re building a house you have everything in your tool box but you may actually go do something unique that’s not in your tool box. Like maybe you grab some purple paint and you paint your house a certain color that of is unique and different. Like you’re not only stuck with what’s in your tool box.
So I kind of think a design system in that way. A design system helps enable you to be more creative more quickly and you definitely want to use the tools so that you can be more efficient and more thoughtful about how you build things but you’re not stuck to that like you can definitely still bring in your own brand or bring in your own creativity.
James: I guess one thing that’s almost universally true is that every platform or every product has it’s own unique problems. So a design system would only guide you in solving those problems rather than offer the solution on a plate.
Jina: Yeah so I see a lot of people writing up “here’s everything a design system should have” and I think that’s like a great to aspire to but in reality not everybody needs all those things. Like for some companies it might just be a CSS framework or a UI kit done in sketch whereas Salesforce because we have so many different products and platforms and even other levels of abstraction that we have to think about, for us the design system is much more than that. So it’s — what I tell everyone is it depends it’s all in context of what you need.
Per: So I guess one of the challenges has to be how do you get the organization to actually do what the design system says because I mean looking at the style guides in the past and the design patterns I put up sometimes, people just, “Okay you have that but I’m going to do this because I sort of, I know better or I’m going to do separate research to find out what is going to work.” How do you make sure that people actually try to stick as close to the design system as you want them to?
Jina: In our case it’s part of our process and how we ship products. So it’s not something on the side that you look at like an attraction manual rather like to build a component you need to use markup and most of the markup patterns that we have defined you use that mark up and you’re already getting the styles because we’ve already put the styles into core you know the production core base we call core. So it’s just already there, you don’t have to style it but because it’s already there.
We also have other things in place like a lot of tooling and testing. If somebody is over writing styles or you know mixing styles, we actually have tools like one of them is a chrome inspector tool that we made that actually will grade your screen that you are building your UI and tell you like, “Hey you kind of did a bunch of custom stuff here, you might want to take a look at that and see if you can clean some of this out.” But you know in some cases you have to do an overwrite or a change and it’s just kind of a case by case basis thing.
James: Right so even though you’re saying that design systems can be really, really rigid and 100% followed as such, by including the use of the design system in the process you then police it through auditing or through system testing tools to help then I guess to get another component included in the design system. They would then be some kind of process that you guys have for applying for that or investigating that and coming with the pattern to be included, so it’s included in your core.
Jina: Yeah and it’s been a very iterative process. Initially our team were taking these component requests and building them, distributing them, documenting them and then each release we would have reviews and tell people, “Instead of this you should be using this pattern”. But as you know more and more people are adapting the system and the needs are growing, it’s not really sustainable to put that all in one team.
So we have a shared ownership model where whoever is designing that feature should be in those review meetings and we are putting the documentation in a shared ownership model where other designers can contribute it’s not just us contributing anymore and it’s part of the whole release process where if it’s not already documented then you document it and add it into the system and we collaborate with each other rather than having the service based model that we used to have.
James: Right So you could say the sponsor of the component the one that’s come up with the problem and the need for a new solution they become shared. They have a shared responsibility to make sure it’s included and followed through.
Jina: Right.
James: Do you have designers that work imbedded with the product and then a central team that’s in charge of the design system?
Jina: Yeah I actually have an article I wrote in response to an article that Nathan Curtis wrote about T models. He went over three models, what he called the overloads like the solitary model and the second model is the centralized team, the third model is all the teams contributing together as a federated model. So the model that we have that I wrote about was you know we have a centralized team focused on the design system. It’s actually a mega team it’s comprised of multiple teams. Then we have all these federated product designers and researchers and prototypers that can contribute to the system and so we all own it together.
Per: Wow that’s huge. How do you get buy in? I mean obviously so I like what I’m hearing and this is something that I would want to try out. How do I convince a client or a team that this is the way forward because I’m guessing there’s a long time to set everything up because it’s not only the design system, it’s the whole framework with all the CSS and everything?
James: Well can I hijack your question a little bit Per? I think what you’re probably asking is how do you start small because Jina here is working with Salesforce and it seems like when we’ve talked about material design in Google the scale at which you’re designing the designing system and where you’re starting from and the resources at your disposal is completely different to maybe when you’re working with an organization that’s based in Stockholm with a few hundred people.
Jina: Yes so we did actually start small. We focused on one product initially which was Salescloud and that’s our flagship product. And we did an audit of all the different UI elements and components and once we kind of did that inventory we narrowed down like the most commonly used patterns. That was the list that we started from. Initially the idea was that we were going to built this out for us to use on the UX team and then once it was kind of in a state that was ready to start showing people. So we have an external developer platform of people, other companies that build tools and products for Salesforce ecosystem.
We were going to offer it to them as something they could use so that they could make their tools and their apps look and feel like Salesforce. Then if that proved well then we were going to bring it into our own product and the reason I thought this was the order was from just the people I talked to. I talked to engineers and they were like, “Yeah this sounds great but we’re busy and it will probably be years before we can adopt this.” So that’s what we initially sort out for.
However things changed. We released a prototype of the documentations site and some of the components like buttons and media objects and cards, all the basic patterns and then we found that production engineers saw it and liked what they saw and started copy and pasting our CSS into their CSS. It’s not really what we wanted because now they’re just duplicating CSS. We were trying to work with them to clean up their CSS. If you’re going to use our CSS delete some of the old CSS and so on.
What I think it came down to us we had to do a huge overhaul of our navigation. Our navigation was on the left and then there was a big executive decision to move the navigation to the top and I believe that was the situation where we had to like make this quick change and execs actually saw that we were able to help the engineers do this change much more quickly and efficiently because we had already built it out.
It kind of comes down to showing and not telling because when I ask people or show people things and my other teammates were doing this, people push back but when you show them the results and like how much faster the engineers were able to move then people get it and then next thing we knew it came down from on high that everybody had to use our system and it was like, “Okay, this just got real.”
Per: So what you’re saying then is if you do really good work then somebody up top will notice and they’ll say everyone has to do the same.
Jina: Yeah I mean especially if they know. You know Salesforce has been around for like I guess 17 or 18 years and they know the pace at which we ship product and then they see this like major feature happen so quickly, like they want to see more of that.
Per: Exactly.
James: I guess that’s one of the advantages by making the strategic choice of documenting or doing the design system for the flagship product first.
Jina: Yes.
James: Although that probably has it’s risks because I can imagine there’s the whole you know, the big brother thing, that the flagship product is the one takes up so much space and then the smaller products then would feel dominated by the big one.
Jina: Yeah it’s a tricky situation because you want all the different product teams to feel like they have their own autonomy and their own decision making but yet feel part of an overall family. So we were very careful to try to make this more of a not a “you have to do this now” but more of “how can we help you do this?” Because this is the overall goal let’s gets there together.
James: I’ve got a question about, how do you keep track of things that deviate? So like if a product designs that you know they’ve got a… special snowflake or they’ve realized that they’ve got something which they’re just not going to follow it, they are not going to adhere to it for some reason. Maybe they’ve got an executive decision at lower level that says, “We’re going to go with this.” Do you keep track of that? Is there a need to keep track of that?
Jina: I think it’s always an “it depends” situation. Like I have seen companies that we have acquired come into the family that have their own brand and they keep their brand for maybe two to three years and then at some point decide to take on the Salesforce brand and sometimes that’s a decision they make because Salesforce is such a worldwide huge brand and they want to have that name associated with them.
In other cases you know they decide to be completely separate. Like Heroku has been in the Salesforce family for maybe six or seven years now and they’ve still got the Heroku purple and they still have their own aesthetic. I think a big part of that is they’re also a really successful well functioning company so they kind of get to do that but they might do where you know in the communities especially with developers they keep that brand but then when they’re at enterprise conferences or talking to enterprise customers then it’s more of like, “Hey we’re part of the Salesforce family.” So you can change that.
If you look at the Heroku footer, the Salesforce logo is there so it’s kind of more of like the context thing. Quip is another example like they have their own look and feel and I think it’s good that they have their own look and feel because they’re a small business, maybe medium size business offering and it’s very easy to use and they did take our font. Like I don’t know if you use Quip or have checked it out but they changed their font so now uses our font but they didn’t take on the full lightning look and feel and that’s okay.
James: But you don’t keep track of that then? You just know it.
Jina: So we are aware of it and we do have meetings with them from time to time to tell them here is some updated patterns if you’re interested in using it but as of right now they’re still running as their own thing which I personally think is good because I think a good design system allows for that kind of thing. I do believe they’re going to be using some of our stuff just not all of our stuff and I think if you think about it like again like a toolbox like if they just want to use the hammer then that’s fine.
James: I think one aspect of this I was wondering about is that by documenting the places where the things have been applied and where maybe there are deviations that it would give the design system team more of an idea of whether or not to touch something or how big a job it is to alter something. Like some things are obvious like the navigation, you’re not going to just kind of dip your toes into the navigation pattern and shake it around a bit. Well with some other patterns maybe it’s not so obvious and if you’ve kind of had a good idea of how widespread it was used or how many even deviations there were then that gives you input into a judgement call about, “Okay do we prioritize changing this or updated it.”
Per: I actually have that problem in the team. We got three or four different accordions in the system or in the same website. So everybody is always arguing about which one to use.
Jina: Yeah and you know sometimes it’s okay to have more than one, you just need to have a use case like you know use this accordion when this is needed, versus this accordion when this is needed. I think it’s a matter of documentation. We had the same thing for a little while where we were doing a date picker — actually no it was a color picker. And we were realizing we have like four different color pickers and the first initial reaction is, “Oh we only need one.” But then we realized there were a couple of places where it might not be a completely different date picker but they might need like a different variant of that date picker.
James: Yeah I mean but I love that if you can describe the problem that you’re solving then of course it’s okay to have several colour pickers —
Per: But then you have to make people read and motivate them in doing stuff.
Jina: Well it’s not just about reading, we also have standards reviews and advisory boards. My manager Nicole, she’s putting together sort of… I forgot what she called it but it’s basically a design systems I guess she calls it like consortium or something. It’s like people from all these different products and they get together and talk. I’m not exactly sure what she’s calling but I think it’s a great idea because it’s like, “Here is a chance for us all to chat and see what each are working on and be aware of what’s out there.”
James: One thing I do like now is how we’re using the — I know there are various different names for lots of different aspects of this work.. I like the fact we’re saying components now as opposed to maybe design patterns or things that we — UI patterns that we maybe used to say more often. Like the fact that includes a coding aspects of these things when you say components. But…
Per: I think Lego.
James: You think Lego?
Per: Yeah.
James: Even I like components I was thinking well what I have noticed is that you get confusion and push back sometimes from developers because there are components libraries. And you can even buy components libraries with loads of pre — there’s bootstraps, there’s all these kind of frameworks as well with loads and loads of components built in. So when you maybe working with design systems and you’ve listed out your nicely designed components and described them and you’ve said how they should be applied and when they should be applied, how do you deal with that kick back from developers or confusion about, “Well I’ve got a component here.” And they pull in one from you know they pull in a menu from some library that they’ve got.
Jina: Yeah so there’s a lot debate around that type of terminology not just in the industry but definitely inside Salesforce. When we did the prototype we actually had a prototype we actually had it called UI library and the reason that we did that was our production framework already had the concept of components and we did not want to confuse people because our components are basically just HTML and CSS. Like the idealized version of it. But their components comes with all the logic and javascript to do all the different states.
So it’s a very different thing and personally I still prefer UI library for our design system documentation because they don’t have all that other stuff brought into it. However you know a person higher up in the team kind of went out on that decision and decided to use components and it’s has caused some confusion. However our stuff is getting more and more closer to their stuff so I guess maybe at the end of the day it’s all going to be the same thing anyway.
Per: As long as you have the same goal in mind as always.
Jina: Yeah.
Per: Doing a workshop on this must be really challenging because there seems to be so much to cover I mean what would be some — like let’s say I sort of have a design system I just haven’t implemented because I have it in my head, where do I start? What are some of the short cuts I could take to put some of this down so it can be used by others?
Jina: So you said if you already have one?
Per: Well I basically — well I have a design. I have the components in a prototype but I haven’t like implemented the design system yet, where do I start?
Jina: Obviously I like to start with research first because I think at any good product should start with research and a design system in this context is a product. So the answer to this question could be very different depending on what the research shows. But after the research the UI inventory or component inventory, whatever you want to call it, I think is really important because it helps you see where all the different patterns are and it kind of help you realize what things you need to focus on first and I also like to start with a prioritized list of like you know let’s say 10 of the most used components and just focus on that list and don’t touch anything else.
The reason for that it’s really easy to blow up the scope of something and you know keep trying to build things just because you think, “Oh maybe one day I might need a carousel.” Well we decided not to build. a carousel because we actually don’t use one and we’ve even had people tell us, “Oh bootstrap has a carousel, how comes you guys don’t have a carousel.” It’s like, “Because we don’t have one.”
So just figuring out exactly the list of components that you need and focusing on that and getting everything designed and documented and built out and then create a back log of all the other stuff that you want to get to after that. My manager actually has this story she tells. She said it’s called the unsightly clean spot and in her story she… her name is Nicole Sullivan. She said she knows this guy who cleans up cars. He likes to restore and polish old classic cars and rather than trying to do the entire car he’ll focus on like just the bumper or just the hoop car or you know some piece of it.
That’s kind of the way I like to approach design systems and the way I like to approach refactoring is focus on one thing or one small area at a time. The most important one that you think is the one that’s like — it might be buttons or it might be the header or something like that that you think is going to touch a lot of different areas. Get that aligned and you documented and distributed and then move on to the next thing. Don’t try to do everything all at once.
Per: That’s really good advice.
James: So it is ever too soon to start? Or when’s the point where it becomes too costly to get on with it maybe?
Jina: I kind of look at it as an investment. So if you can start sooner I think it’s better because you’ll have a much bigger reward just like an investment. If you wait till later it’s going to take a lot longer to see the value in that. You’ll still get value but it’s not going to be as big of a reward. But I realized the reality is most of us are inheriting projects. A lot of people aren’t getting the opportunity to start from scratch. So even still like it’s never too late either. So yeah I like to think there’s no project too small, no project too big, no project… I think every project could benefit from a design system.
James: I think that is an absolutely excellent note to finish our chat on.
Per: Yeah.
James: Thank you very much for chatting to us today.
Per: That was excellent I learned a lot. Thank you.
Jina: Awesome, thank you so much for having me.
[Music]
James: I really love this entire topic about design systems. As regular listeners probably will know and remember I mean we’ve talked about material design reasonably over the years. A year ago we had a full episode about Material Design and we brought in Richard Fulcher from Google who is part of the team the designed Material Design to talk ti about that design system. And then many years ago now, 2013, we talked to Brad Frost and getting into atomic design a little bit with him in the very early days of when he was discussing and talking about it. So it’s something that we’ve come back to a few times.
Per: Yeah and also listening to Jina it seems like where I am now or where I was actually consulting previously now for four years, it would have saved so much time, solved so many conflicts, made the whole thing more efficient if I had access to a design system or been able to put one together but for me it’s been a resource problem. I was basically the only UXer on the team so having the time to put that together at the same time as you’re doing all the other work it’s a challenge. So that’s why I was sort of I was asking about the sell-in process, how do you get the buy-in for people to actually understand how good it is but I think she gave some really great answers about focus. Focus on the 10 most important patterns or even, I would even say 5.
James: Yeah and I’ve got something to add to that one, it’s good to focus on the most used ones but I think it’s a good idea to maybe start with the one with the most deviations because I think it’s like if you’ve got a situation where people start to point out that you you’ve got deviation. You maybe have a situation where the developers don’t know which bit of code to steal from another part of the product or another product because there’s too many to choose from. And that may be a real good opportunity to quickly show value and to tidy up. You get harmony with that component and then move onto another one.
Per: In Jina’s defense she did say start with research. And in research you would have come to that decision.
James: Yeah. But it’s not necessarily always the most used ones.
Per: Yeah true but the message there is don’t do all of them. Make sure you just do — yeah.
James: Exactly, don’t try and build a design system and then go ta-daaa!. You can…
Per: and I would love to just like… she mentioned buttons and I was immediately thinking I would love to spend some time just on the buttons because that would make a huge difference. This is the primary one, this is the secondary one, this is the one for cancel.
James: That’s one of the tips I’ve seen over the years. You can quickly get a feel of, I suppose, the consistency of a user interface by doing a button audit. So you don’t need to do a complete UI audit, you can actually just do a button audit.
Per: I remember doing one of those.-
James: Yeah and they’re so much fun. I’ve gone a couple of times with kind of like new clients to basically just give them an idea of the scale of the problem. Like you, “These are all your buttons.” And there’s like you do a huge graphic.
Per: 20 to 50 usually.
James: Oh God at least. And then they go, “Oh is that button, I didn’t realize that was a button”. well, it behaves like a button. So then you get into all that kind of stuff too and you see the deviations in it. Then you move towards an understanding of the value of tidying up. But going back to your original point about how you wished you’d started with the work you’ve done recently by having a design system from day one pretty much. I think there is where the importance of having it as a part of your design process. Your personal design process. Effectively what you needed was a way of documenting so you could communicate to yourself. Because I mean I know that I forget stuff all the time.
I come up with a smart idea and I use it one particular place for one particular problem and then something else comes up and I’ve forgotten that I have solved a similar problem earlier. You don’t always join the dots and realize this might be the same pattern or same component. So there I think there’s probably a reasonably simple way you could maybe document that doesn’t cost that much time but allows you to communicate with yourself better before you get into the grandiose notion of a design system because it does sound very expensive when you’re talking to some clients.
Per: Micro system. Design micro system is what we start with. And I don’t know what that is but research will tell you.
James: Yeah I mean another thing I’ve read and has been said about design systems is that you could perhaps, even should, treat them as products in themselves and I think that’s actually a really interesting idea and probably really healthy idea. Because if you follow some of the same processes that you would follow for developing any of your products and apply it to the design system itself you know what with like maybe a backlog of items, you got like a product owner, maybe even a budget or a team. Then at least in companies where you have more mature set of products and a mature design system then definitely I think considering as a product in itself would be excellent.
Per: Yes that makes complete sense to me actually. Alrighty then as per usual find us everywhere on the internet as UX podcast. We’re on Instagram. You usually don’t tell people we’re on Instagram.
James: Don’t I? Oh we’re on Instagram as uxpodcast. If you aren’t already a subscriber then it’s really, really good if you could just press click and add us wherever you’re listening to us now. Whether it’s SoundCloud, or whether it’s in your podcast client or anywhere. Show notes and all our previous episodes can be found at uxpodcast.com and also you can sign up for our backstage mailing list where we usually or quite often give out little goodies and discounts and so on.
Per: Yeah I saw you’ve been sending out some discounts there.
James: Don’t tell everyone
Per: Remember to keep moving.
James: See you on the other side.
[Music]
Per: Knock knock.
James: Who’s there?
Per: A broken pencil.
James: A broken pencil who?
Per: Never mind it’s pointless.
James: Ugh.
[End of transcript]
This is a transcript of a conversation between James Royal-Lawson, Per Axbom and Jina Anne recorded for UX Podcast in June 2017. To hear more episodes visit uxpodcast.com or search for UX Podcast in your favourite podcast client.
