So you’ve gotten buy-in, you’ve made an inventory of designs and components, and you’ve set up your team’s first design system. What happens next? This talk will explore maintaining a design system, as well as new challenges that arise once your design system matures. Topics that this talk will cover will include: documentation, adoption, support, tooling, and architecture.
Una Kravets:
Rolling on into our first/last set of talks speaker. Our next speaker is Isha Kasliwal. Isha is a senior ux engineer on the Design Systems team at Salesforce. You may have heard of it. Isha worked as a front end engineer and ux designer. She designs, builds and maintains functional components and visual designs.
Please welcome Isha to the stage.
(Applause)
Isha Kasliwal:
Is this thing working? Okay, cool. Thank you for that awesome introduction, Una. Hey, everyone. My name is Isha. I've most recently been a UX engineer on the Lightning Design System at Salesforce. I want to talk to you about maturing Design Systems. I know this talk is right after lunch and you might be tired and groggy but I have real juicy content in here for you so make sure you keep your eyes and ears peeled.
Many of you may have recently set up your team or company's first Design System. Which means that you might have made an inventory of designs and patterns across your app. This could include user interface patterns, branding patterns, like color pallets and typestyles and so on. You must have also gotten by from at least some stakeholders. The stakeholders who saw your inventory and realized that the number of inconsistencies across your app were costly and the product value would increased with an organized system focused on design.
Then, you might have created a repository for people to access your components and guidelines. For many teams, this is a website that contains a library and usage documentation of your components but it could also be a sketch file that holds all your team's unified patterns or GitHub repo with grab and go code.
So, what happens next? What happens after you've set up your first Design System framework? As the Design System matures, it needs a lot of love and it needs that love in a lot more ways than you might anticipate. So, how many of you played with Tamagotchi's in the 90's? It was a hand held digital pet you had to take care of. So, consider it. You have to feed it. You have to give it training, you have to keep its stress levels low. You have to nurture it. And believe it or not, that's kind of what you have to do with your Design System once you get it off the ground. You have to treat it like any other product and you have to make sure you give it the attention it needs in all areas in order for it to succeed.
The Lightning Design Systems is one of the few Design Systems out there that's truly maturing at this point. It was launched back in 2015 and it has come a long way since then. I'm going to share some case studies about how we scaled Lightning Design System. The path we chose to follow might not necessarily work for your system because every system should and is different.
So, over the past three years of building, launching and keeping up with the Lightning Design System, the team learned to focus on certain key areas in order to sustain the Design System as it matured. This is not a definitive order. But the different areas are maintaining components, adoption and implementation, support, documentation, tooling and strategy and architecture.
So, when you first launch your Design System, you will definitely find yourself building a lot of new components or UI from scratch from a button to a walk through modal. You will mostly be adding things to your system that will be implemented in your app for the first time. As your Design System matures, however, a lot of your focus could shift to maintaining those components. You may always be building, but the amount of building you do will most likely decrease and instead, you might find yourself adding variations or modifications to a lot of components you already have to make them more flexible. Building new one off components would not work for the Lightning Design System and I believe it's not what a Design System should be about. Adding flexibility to your components ensures that your component library will scale and will be able to be used by a larger number of people.
We focused on making sure our components are flexible by adding variance, states, modifiers and examples to our base components. Variance are different versions of that component, states show what happened when you interact with the component, modifiers are different style changes that you can apply to a component by adding a CSS class and examples show how that component could be used out in the wild. These are always we can update and maintain our components instead of having to create new ones for every little design change or for every little usage change.
Next up, adoption. As your Design System matures, you'll want more and more people to start using it while at the same time, more and more people will start using it on their own, in their own ways. So, how do you make sure you're able to spread the word about the benefits of using your system while also focusing on helping people learn how to use your system properly? Socialize a system to the people you want consuming it. Teach them, help them and most importantly, work with them. And not only the ways that make sense to you, but in the ways that would make sense to them, too. These are two birds working together.
(Laughing)
Isha:
For the Lightning Design System, we focus heavily on adoption and implementation across the entire organization. Some ways in which we reach out to people is office hours twice a week where anyone can ask us about the Design System. We hold brown bag lunch meetings. When I say these out loud, I feel like they're no brainers but there are a ton of people who don't realize how frequently you to do this in person outreach to be there as sounding boards for them.
Because we have three major releases a year, prior to each release, we have two week long standards reviews where we watch out for patterns that deviate. We watch out for new patterns that might come up. In our recent standards reviews, we saw a recording component that was slightly different each time from four different design teams that we were able to standardize for our system simply by having this platform and by having this conversation.
Also, many times, dev teams believe they need brand new components all the time. But in reviews, we find that their component can actually be constructed from smaller patterns that already exist. We give them guidance on pulling those patterns together and sometimes we decide to create an example on our website just to showcase that example, as well.
All in all, we found it necessary to work with people who would be consuming our product and the more Design System matures, the more we need to help the people who are actually using it, in the ways that they're going to understand.
And in the spirit of helping people, that brings me to the next area. Support. Support for all those people who are adopting this Design System of yours. So, Salesforce has historically made the promise to never break customers. But UI isn't the same as an API, with the Lightning Design System in the mix, that's just HTML and CSS, talk about being both excited and scared to death at the same time. That was our team. Being adopted across the entire organization meant our internal devs were starting to be encouraged to begin to change their, you know, pages that they made and their components and to start adopting the Lightning Design System markup. For the size of the company we are and the number of devs we have, this went surprisingly smoothly. Yes, we definitely had teams that resisted giving up UI control. The large majority are self confessed UI phobic devs who are happy to pass on the responsibility to us. Some would like us to do their job in adopting Lightning for them.
Each release, more and more of our pages are converted to Lightning. And the new ones are built directly from our blueprint.
So, while office hours and standards reviews are great points of support contact for us, there are areas that are under our control. Being a team that works on the internet means that people will use any and every avenue of the internet that they know to contact you the second something goes wrong with your product and so, it's important to plan your support strategy before you need it.
It might start off small, it might be manageable in the beginning. It might only be a few avenues to begin with. But what we've experiences as our Design System has matures, is an endless amount of support channels that we have to pay attention to. We have internal and external support channels, which include Slack, Hangouts, Twitter, two internal Salesforce social services called Chatter and Gus. We have our support activities, like standards reviews, office hours and brown bags. We have a GitHub repo and an internal GitHub repo. Internal is 20 internal GitHub repos. We have a Salesforce specific gamified learning system called Trailhead. There's obviously endless amounts of email and this is a candid picture of me answering support emails, like, a week ago.
(Laughing)
Isha:
So make sure you establish a system that makes handling your support easily. We've grappled with a support ticketing service similar to regular customer service and adding slack spots that can pull answers from questions to a database. We're still working on it, but definitely need to improve as we move forward.
And next up, documentation. Documentation is extremely important as your Design System matures. On the Lightning team, we're severely lacking in documentation and one of the biggest reasons why is because we were going so fast in the beginning and zipping through the building phase that docs got left for later. When it comes to documentation, there is no later. Also, a hole that I've learn that a ton of people fall in is assuming people will know how to use the thing they built right off the bat. A component as simple as a button seems like a no brainer. However, there are two different ways to implement a button and a difference between those implementations matter a lot, especially for accessibility.
Our team has been doing a ton of research and experimentation around how to make documentation contribution easier and more accessible for people outside of our immediate team. One group we wanted to empower to add contributions was our design team. As an experiment, we made a separate GitHub repo called guidelines where they could contribute documentations for their designs in markdown. It was connected to our Design System repo. It would show up on the site for that component's page.
Our struggle there was getting designers to feel comfortable using GitHub and that became a huge learning opportunity for us.
We're still trying to figure out what works best, but the point is to open avenues for anyone to contribute so that your core Design Systems team does not end up becoming a bottleneck for documentation.
And next up is tooling. Focusing on tooling after your Design System has taken off is a good step to ensure your adding efficiency to your workload. It's common to throw things together and put something out there. After you spend more and more time on it, you might want to start building or implementing tooling to make sure you're not throwing resources toward tasks that could be potentially automated.
This is a tool that our team built and uses for the Lightning Design System called the Previewer. An interactive tool for creating components. It runs at the designated url on startup. It live updates as you make changes. You can choose the component, variance, modifiers and it previews our Sass docs. Using the Previewer has replaced using the actual website when viewing component specific changes for us. We don't have to wait for the entire site to build and load every time we hit save and we can view all the different variance and states side by side. It's helped us speed up development at a ton and given us a space to focus on components while building.
While building your own tools isn't necessary, it could help alleviate the workload and looking into open source solutions for tasks you do frequently could be a really good idea, too.
So, I wasn't entirely sure what to call this section, so I bucketed my thoughts into strategy and architecture but what I mean to say is when you first start building your Design System and you anticipate growth, have a plan and strategies. When you first release a system, it's most likely going to be small and it won't consider all of the potential use cases for your users. However, it really pays off to do a deep dive into your intended audience and consumers and make a plan for how to scale the architecture of your system to fit your users needs.
With Lightning there was a dissatisfaction with the information technology layout. It came out of a mad rush of building the entire system as fast as we possibly could. Since the system has finally gotten a ton of adoption, it was time to work on a way to re create a scalable hierarchy of information and surface all combinations and context and separate atomic verses composite and show a separation of states, variance and examples. We decided to add metadata to each part, which our team calls annotations, to include additional information to our system. We started working on a new taxonomy to classify the parts of our system which was prompted by the possibility of a new documentation tool and a new API that could better codify the subsatisfactory information and hierarchy that we had at the time.
We had several layers of definition for our taxonomy. We had patterns, which are pieces of the user interface. And, a pattern could be described as a small, reusable piece of a UI or a full teacher. We had systems which are subsystems, category groups. These groups described the pattern's implementation, thing like building blocks. Types, which defined user needs within the application. And properties, which are extra component information that specifies user interface.
We believe type systems are powerful for enhancing tooling around a growing system, which in turn will help us manage the framework at an even larger scale. We did this so we could establish sound parent/child relationship that would encourage proper use of patterns and reusability. Had we done it from the beginning, before the Design System had matured completely, we could have had improved communication between our designers and developers by having a more controlled vocabulary about all the different parts of our Design System and we could have had a sound classification of need based patterns provided by our Design System.
But, as our Design System matured, it's something we learned we desperately needed. It's important that you have at least somewhat of a road map, beyond just building designs and components, so you can maintain a solid framework and consider future use cases and ideas.
Moving on to my last point, shared governance. Initially, it wasn't hard for our small Design Systems team to keep track of and maintain governance over patterns. More acquisitions have been made and research has demanded change, it's become a lot to handle for a small team of people.
As your Design System matures, it's important to expand beyond just your core team so that everyone has buy in. And, so that everyone feels like they're contributed to the Design System that the whole company is moving towards using.
At Salesforce, we've been experimenting with how to share that governance. Currently, we've expanded beyond just the initial core Lightning Design System team into three different teams that split responsibility and stay in close contact via standards reviews and office hours, where there's representatives from all three teams. We now have a platform foundation UX team responsible for patterns and design guidelines. We have UX creative, which is visual design and UX engineering and Design Systems. By divvying up the work, each person has had more time to focus on what they're specifically best at and it's given us a clear path work to scale.
So, I've told you a lot about what we have done, an area that's a huge question mark for us, where we're still really trying to figure out what the best option is, is communication. What is a good way to communicate changes that happen to your Design System, to all of your users? These changes can range from component additions to component updates, to design modifications and beyond. We're still unsure of the best way to report those changes out to everyone who consumes our system.
At Salesforce, not only do we support our internal product teams, but we also support external contributors, as well. So, how is it possible for us to just have one specific avenue of communication for this entire ecosystem of people that comes from all different places? One thing we've tried is automating release notes, but that hasn't scaled for us in all the ways we would have liked it to.
So, I have an open question to you all. How does your team tackle communication for your Design System? I've started a thread on Twitter. If your team does something that could work for us or others, please let us all know, or just @me and I can compile it.
So, just to recap, a couple good areas to focus on, as your Design System matures, range from maintaining your components to setting up good documentation, to building tools for efficiency.
Because a Design System should be a living product, taking care of it will never end. You can buy a new Tamagotchi, but it would be a huge pain to start a new Design System. It's to be sure you're considering key areas to making sure it scales and succeeds.
So, I want to close this talk out by saying that, as a design community, we need to keep empathy at the forefront of our jobs. Empathy is going to be what helps any design product of your scale, especially your Design System.
It's important to make sure that you remember to have fun while you're building this stuff because at the end of the day, it's just the internet and shout out to design Twitter because some designer bros can get really mean out there. Let's contribute positively to this space to make it a safe space to be in because, well, why wouldn't we?
Thank you.
(Applause)
Una:
Thank you, Isha. Please take a seat. And, thanks, Jason, for putting the chairs up.
Jina Anne:
He's my brother.
Una:
This is Jina's brother.
(Laughing)
Una:
Oh, do you have a mic? All right. Take mine.
So, I have a couple questions for you. Some are from Twitter, the internet. So, the first question is from Twitter. It's from @alleybarber. Say your Design System's very successful, how do you deal with other developers, engineers and stakeholders from overloading it, for example, turning it into a JavaScript frame work, testing system, organization tool, et cetera.
Isha:
That's a really good question and that's something that my team endures on a daily basis and it's not just for developers, it's also from designers, it's also from PMs. Everyone really sees the value in the Design System and they want to try to leverage the Design System and by way of the Design System, you and your team, to help them in the ways that are most important to them.
So, for us, it's super important to make sure that we keep a roadmap of what's important to us and we make sure that we have our managers communicating what our ideas are so we can be shielded from the others who want us to work for them.
Una:
Yeah, totally. So, what percentage of your time, would you say, is divided between building new components and support and adding?
Isha:
That's a really good question. Our team is still trying to find the best answer for that. Something we've done, right now, because our team is super, super small still, there is only six or seven of us. We let whoever is best focus on that. We have people most passionate about building, they focus on building while there are others more passionate about adoption and advocacy and support. Just while our team is literally six or seven people supporting, like, 30,000, we could keep our heads on the shoulders.
Una:
Is that split between the categories?
Isha:
That is just the ux engineering team. They have to do the same well on their own to make all the other teams are maybe six or seven people, at the most, too. So they have to focus on what they can do best in order for their team to be able to scale.
Una:
Is there any Design System tooling that you wish you had? What would you kind of change in your existing tooling, if you could?
Isha:
Sure. So, something that our team has been trying to get right, release after release, is testing. And so, it's hard for us to figure out what the best avenue for testing is because we only provide HTML and CSS, we don't provide JavaScript. So, there aren't that many tools out there. We are building some in house, but it's an ecosystem that keeps changing with every version of React or whatever the next hot thing is. It's been hard for us to get right and that's definitely something we want to get right.
Una:
Your team's focus is making it platform agnostic? Cool. Are there a lot of different frameworks being used within Salesforce?
Isha:
Yeah. Because Salesforce is such a big company and we make different acquisitions and those acquisitions have their own tech stacks, we are building our own in house version of React. We have in house versions of JavaScript and Java. So, it's important for us to stay platforming agnostic as much as we possible can.
Una:
How do you deal with updating legacy code while building new designs? It's kind of like both ends.
Isha:
Yeah. How do we manage that? We try.
(Laughing)
Isha:
We try to communicate and we have those standards reviews, we have our office hours. We try to just do as much outreach as we can so that we're there for people when they have questions, so they don't resort to just doing things their way, but they kind of have people to help them.
Una:
So, one more question from Twitter. Sarah asked, in your talk, automating release notes didn't scale for you. Where did it break down?
Isha:
Sure, an area where it broke down for us was figuring out how we wanted those release notes to look for people so they could be consumable. We started following patterns and messages that would end up compiling to clean release notes. The way those release notes ended up looking for the user was not super consumable and maybe more consumable for developers, but not consumable for designers so we still don't know the best way to make it so that it works for both. If that makes sense?
Una:
All right. Last question. So, you talked about expanding beyond the core team, how do you make people feel comfortable contributing that aren't on the design team?
Isha:
One way people get excited is when they get to contribute to our GitHub pub. There's also standards reviews where there's multiple people from multiple teams there who are open to giving feedback and their opinions on the way we do things. But generally, we like to make sure that we keep the conversation open with everyone so that if people do have any feedback, we can try to implement it the best we can.
Una:
Awesome. Thank you so much.
(Applause)
