A Business-Centric Approach to Design System Strategy

Alex Wilson at UXDX USA. Video: https://youtu.be/ROUOwxdvmAo

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

The design system as an internal business

[00:00:00] Hey everybody, it's so good to be here today, and today we're going to be talking about a business-centric approach to design system strategy. So let's get right in. Design system success really hinges on a team's ability to identify product market fit within their organization and tactfully introduce change. But what that made me think of was that maybe we need to rethink design system strategy, because design systems often start off with a few people who really have a passion for the space, who want to get this started, but that ends up being treated a bit like a project in the early days. And suddenly you're thrust with a ton of different responsibility and it's hard to figure out where to take the next step. So what it's helpful to do is to envision the design system team as an internal business entity.

[00:00:45] So let's define a design system as a business. Well, your system tooling, that's your product. Your application teams are your users. Your system team is your workforce, and your organizational leaders are your external stakeholders. And finally you have your system focus areas, which are your business functions.

[00:01:05] Now before we dive any deeper I want to get into some of the outcomes and benefits that we've seen at T. Rowe Price. So the design system is now an essential part of the firm's design and development strategy. We're getting a ton of adoption, we're seeing a lot of value come out of that. We've expanded the design system product suite to better cater to user needs, which I'll get to in a little bit, but we're now making more offerings. We started with web, we're getting into the mobile space, and we're also providing content authoring solutions. We've used data insights to guide component development choices about which we should create, what makes sense for our business. And we've also had more team growth opportunities within the team. We've been able to promote people, give people more opportunities and really push them along in their career.

[00:01:51] So now we're going to get into breaking down our objectives into different business functions that you might see in a regular business, and we'll go over finance, marketing, sales, customer service, business development and people operations. When we go through each of these I want you to think about how this might apply to your design system, and I want you to also think about when you want to introduce such patterns, about the business tools and methods that you could use and introduce to help drive processes forward.

Finance: funding, investment analysis and budget

[00:02:27] So our first function is finance. Finance ensures the design system is well funded and delivers on the expected value that the firm is looking for. Our first objective is to develop a sustainable funding model for your team, and this looks different for every organization and it may take different periods of time to get through. But this provides financial stability and really long-term support for your initiatives.

[00:02:53] We started with an inner-sourced capacity, so we took capacity from different teams, brought it in and delivered an MVP, and that was to show value. Once we got that off the ground then we were able to get full funding through a single source, through a single department, and that's been pushing us forward ever since. The MVP helped get us past that initial resistance from stakeholders that I think a lot of people see. That MVP period also took quite a bit of time, it took over a year for us to get that funding, but at the end of the day we've been able to excel and have great success ever since, because we went through that process.

[00:03:28] The next objective would be to conduct feature investment analysis, and this would be to compare the cost benefit between how much it's going to take your team to build something and then what the value is that that component or feature brings. I think that in the design system space we often look at other design systems to gain inspiration, but those design systems also started somewhere, and those components were meant for that organization, they may not be meant for yours.

[00:04:00] So it's good to take a look at those as an example, but then what we do is we take the data from our application teams, how long it takes them to build something, we take data from our team, figure out how long it takes us to build something, and we get an estimated count of how many users we think we're going to have of this new feature or component.

[00:04:17] This optimizes resource allocation and encourages value-based planning, which gets us into a space where we're only building things that people are actually going to use. The challenge here is data availability and the quality of data. But if you're early on in your design system journey you could always go with the count of three, where if you have three consumers then you build something. But as you get more data about the design system then you can make more sophisticated decisions around your component library.

[00:04:47] The last objective of the finance function is to assess budget against strategic initiatives. Here we're looking at how long it takes to build something, and comparing that and the capacity that you have with all of the requests that are coming into your design system team. I think at a certain state of maturity, once you get a lot of adoption, people are going to start requesting more and more from you, and you probably will have to say no at a certain point. But the question is how do you say no, and the way that I think is easiest to do that is to have the data that backs it.

[00:05:20] This data can also help set you free and expand your team in the short or long term, because you could then go to senior leadership and say, hey, we have this gap, we are unable to fulfill it, it could provide this significant value, and if you could provide us with some short or long-term resourcing we would be able to achieve that. Now of course the challenge here is data availability and organizational budget constraints. Maybe that might not work for your organization, but at least you'll be able to push back on something that you may not be able to achieve, and that's better than not hitting that deadline.

Marketing: communication, events and tailored content

[00:05:54] The next function is marketing. Marketing heightens awareness, interest and demand around your design system with existing and prospective users. Our first objective is to enhance communication around those features and updates. This keeps an informed user base and makes sure that they're engaged. What we do is we send out newsletters to different people, we send out Teams chats. We create a Teams chat with every team that we work with so that we're in constant contact. We also send information about our deployment strategy and when we're going to be doing deployments over the next month. This really gets them in the mindset of being able to test often and use the new features that are coming out of the code base and into the design workflow.

[00:06:39] But you also have to manage information overload, because if you put too much information out there, as we all do and ignore emails, so are other people, they'll ignore your emails, they might ignore your chat groups, and that's the opposite effect we want to have with our community.

[00:06:56] The next objective would be to engage with the community through events. If we think about the last objective really being targeted at our active users and making sure that they're involved in what's available, these events that you can be a part of would help gather prospective users, so that they would know a little bit more about the design system and how it might benefit them.

[00:07:16] When I talk about events I'm thinking about things that may already exist. Maybe you have all-hands meetings that you could speak at, maybe there are communities of practice within your organization around design and development. If you speak at those events that could gain more adoption of your entire design system. But you might also have the challenge of the events not being available to you, so then you have to actually create those events yourself. What we do is we have a showcase that we host every few months where we invite the entire community, and we tell them all about what the design system offers. We also do onboarding events with teams, we can host question and answer sessions with teams, just to make sure that everyone's really informed.

[00:08:00] And then our last objective is to customize the content for different user groups. I think this is probably one of the more sophisticated areas of design system marketing that you can get into, and it's something that we're just starting now at T. Rowe Price. The challenge here is resource constraints. It takes time to create content videos that are tailored towards an audience. So what we're doing is we're slicing up our demos, so we send those demo clips that are short form content that people can easily digest, to our designers, our developers, our product owners, our content strategists, and then they will likely be more likely to engage with that content because it's meaningful to them.

Sales: the acquisition pipeline, testimonials and market demand

[00:08:42] Once we have our marketing strategy down and people are aware of the design system, then we can get into our sales function. The sales function converts those prospective users to active users through a number of different methods, and our first objective here is to streamline the user acquisition process. I love this slide because it actually takes a business pattern, a business method, and applies it to your design system. This is a sales pipeline that most businesses use today.

[00:09:11] So prospecting: you gather all of your different teams that are available to you. Qualification: you identify whether those teams are front-end teams or back-end teams and which would more likely use the design system, so you can target them throughout the rest of the process. You do a demo, an integration proposal, you get a commitment from that team that they're going to be using a set of components, or maybe that they'll onboard and they have a plan for use. You get them onboarded and then you retain them.

[00:09:38] As part of that communication strategy in our marketing section earlier, I mentioned that we have chat groups with each of the teams we work with. That's part of our retention strategy, is to really get the engagement up through those chats and make sure that we're always available to them after they've onboarded. This of course increases adoption, but it also has a challenge, that it takes time to get people through this pipeline. So whatever you can do to reduce that process down and keep it as small as you can would be beneficial to you.

[00:10:12] Our second objective would be to establish and enhance trust with consuming teams through testimonials, and this helps increase brand credibility and customer confidence. Now I think of a design system as a business, and a business has a brand, and you have to uphold that brand with all of your users. So if we think about testimonials, that shows all of the successful stories that people have had over time and could help push somebody, or some team, over the line to use your design system, maybe over a third-party product or another internal component library. But obtaining testimonials requires existing users, and it requires users that may be using that design system for a longer period of time, so you have to get them through the sales pipeline first before you can get to this stage.

[00:11:02] And our last objective is to align solutions with market demands. By this what I mean is that we want to make sure that we're building products that people are actually going to use, and use soon. We don't want to just sit on these products and wait for someone to come use it. So what we do is we are involved in all of the integrated planning sessions around all of the different departments, and make sure that we understand the requirements that teams have for the design system where we are a dependency of those teams, or could be. So if these teams have a set of components that haven't been built yet but would be great for a design system, we then put them on our roadmap before they need them, so that way when we deliver we automatically have a set number of consumers.

[00:11:51] This improves product market fit within your organization, because you're only building for the needs that exist, but also increases the system value, because you're having more consumers, meaning that the value outweighs the cost, going back to our finance function. But the hurdles are really anticipating shifts in priorities. So we don't just involve ourselves in the integrated planning sessions at the beginning of the year, we also check in quarterly to make sure that roadmaps have shifted, so that way if something falls off and a component is no longer really necessary or doesn't have the consumers that we need to build it, we don't build it, or we push it off.

[00:12:28] And we also need to prevent overcommitment. It's easy to want to have so much adoption of your design system, but if that's at risk of you not delivering on time or making your consumers unhappy, it may not be the best decision for you. So you have to figure that out as you go through that integration planning process, of what really adds the most value.

Customer service: documentation, support workflow and feedback

[00:12:48] Once we have our sales function down we've got consumers coming through the door, and now of course we have to focus on customer service, facilitating strong user experiences through proactive report and issue remediation. Our first objective is to educate users through comprehensive documentation. This improves user proficiency and reduces support inquiries.

[00:13:14] Now we started off with Storybook, where we had all of our documentation in there, and Storybook is a great platform to use, not saying it's not, but it was really geared towards our technical audience. We found that we had documentation in Storybook, we had documentation in Figma, we had documentation for our content authors in a content management system, and we really needed to combine that all together into one comprehensive solution, and that's what we are in the process of doing now. We're transitioning over to using a product called Knapsack, but there are other products in the space that you could also take a look at, ZeroHeight, Supernova, others that might fit the same need, so take a look at what's available.

[00:13:51] But the documentation relevance and accessibility of that documentation to a wide audience is really important. If that documentation gets out of date then it's more likely that people will ask you questions, go to you directly, than actually use the documentation.

[00:14:07] Which gets us to the next objective, which is to manage community feature requests and support inquiries through an efficient support workflow. So going back to an example at T. Rowe, we started off with GitLab issues. Everyone put all of their support requests, their defects, anything that they needed help with, they would put through our GitLab issues. But what we realized was that that was a little bit too tailored to our technical audience, and our designers and our product owners weren't really familiar with that experience. The other problem was it wasn't providing us a ton of structured data that would help us improve in the future on our customer service function.

[00:14:47] We have now moved over to Jira Service Management, where we have a full workflow that caters to all of the different users and provides us with very fine-tuned data, so that way we can say, oh well, we've gotten a number of requests about data visualization, but it's not just data viz, the area chart of our data viz category is actually having a number of problems that people are raising. And because we have that data we can then inform our roadmap and improve the product quality, and this is going to really help us in the future.

[00:15:19] Our last objective of this function is to proactively request and evaluate feedback, which extends a little bit beyond that support workflow. We don't really get user sentiment through that support workflow, and so the best way to do that would be to send out surveys. This is an area that we're starting to navigate now. We're coming up with a set of surveys that we plan to send out to consumers that we can consistently use. So we'll have one for the end of onboarding, how did it go for you? We'll have one for when we wrap up a defect, maybe it won't be lengthy but it'll just ask the question of how did this work for you, and maybe ask for some actionable feedback.

[00:15:59] But that is one of the hurdles really, is identifying actionable feedback. So your surveys, or however you're requesting this feedback, has to be written well, so that way it can inform your team of something that they can do to help. Because if you don't, you're not going to get the benefit of strengthening user connections. If we're talking about listening to our consumers and we're actually going to do something about that, that will really feel great to them. But if we just continue along our path, continue working on features and never evaluate the feedback, what's the point?

Business development: risk, partnerships, mergers and acquisitions

[00:16:34] Which leads us into our next business function of business development. So we now have our finance down, we have our sales down, we have our marketing down, we've got consumers coming through the door and those consumers are happy, so now we want to look at expansion opportunities.

[00:16:49] But before we get into expansion we need to make sure that we mitigate risk. This is a crucial part of the business development function, because you want to ensure that you can scale as you go and limit the amount of issues that come up along the way. I've mentioned a few already. We've scaled our defect process going from GitLab to our Jira service workflow. We've scaled our documentation strategy going from Storybook to Knapsack. All of these things were done in preparation so that way we didn't hit a risk later on.

[00:17:24] But the challenge here is knowledge of those potential risks. I think that in a space that is evolving it's hard to understand what could come next, what that challenge is that you're going to face, so you might have to look external, beyond your company, to find out what other challenges other people have faced along their journey.

[00:17:43] And our next objective is to foster strategic partnerships, and now we're getting into that growth and improvement of value. So I've got two examples here. We have analytics and accessibility, both of which have requirements that all teams need to solve for, that all teams need to embed into their applications. Now if we're able to shift those requirements into the design system, we're increasing the value of each component and feature that we build, because the teams don't have to do that themselves. Now I'm not saying that the design system will solve for all of accessibility and all of analytics, there is more to do in that space. But if we're able to collocate those requirements it does make an increase in that value that teams will see coming from those components, because they don't have to deal with the same challenges.

[00:18:31] Just as important, this enables cross-promotion, because when you're working with those partnership teams they're more likely to recommend the design system solution that they've then vetted, over a custom solution that a team will look to build. But the challenge here is goal alignment and team capacity. If you're not aligned on your goals then the partnership could fall apart, and the team capacity is really important here because you need time for them to review the code that you're writing or the designs that you're putting out there, and you need the time to fix any issues that may come up along the way.

[00:19:06] And our third objective is to explore expansion opportunities through mergers and acquisitions. An example of a merger could be that you have two or more design systems within your company. I often question whether or not a multi-design system architecture is actually necessary. Maybe for some massive businesses that's the case, but in smaller businesses having multiple design systems could actually be an efficiency problem, and it's part of siloing. So if you end up working with multiple design system teams to collocate requirements, merge those design systems together, have a single set of consumers for them and then overall boost the value of one system instead of both, that could really be a massive potential area for your design system.

[00:19:53] Then the next part is acquisition. So say you don't have that design system problem, or you don't have any type of merging opportunities. Well maybe you could acquire another team that's working on something similar to the design system that could push the design system forward. The example here is mobile, but a practical example that we've seen is our Adobe Experience Manager team that we have now incorporated under the design system umbrella. This team worked to build out component authoring experiences and UI components that authors could drag and drop onto a page to create a site.

[00:20:28] Now if we think about how we can get our design system out to users as quickly and efficiently as possible, having an authoring strategy for the components that we're building could really lead us in the right direction. So we talked with that team, realized there was redundancy at the UI level, and if they just focused on the authoring experiences and our team focused on the UI parts of that page, we could drive forward with a singular vision. And that team was around before the design system was around, so the model was a little bit outdated as well.

[00:21:02] Once we brought them in we've seen massive success. People are really excited about the fact that now authors have the ability to drag and drop design system components onto the page. But you need multi-party agreement, you need to assess this pattern, whatever you introduce, and you also have risk of market saturation. By that I mean that there's a design system vision, and the more that you take on, you don't want that vision to keep expanding so that way you're doing too much. You want to keep your vision tight, but anything that aligns with that vision is something that you might be able to bring under the fold. This is not an easy process. This took a year for us to get through with that team, but it is adding significant value to our design system.

People operations: culture, innovation time and career paths

[00:21:44] And our last business function, I think this is a great way to end, is people operations, which promotes a positive team work environment where people can do their best work and grow. The first objective is to develop a positive work culture. You can see our teams here, we've got our web team up top, our authoring team down below, and it's one of the best organizational cultures I've been a part of. People feel that they can have transparency with one another, that they can ask questions, that no one's too good to push back on a question that someone might have for them. People feel mission driven and excited about their work, which I think is a great way to move forward our design system business, because they are the backbone of this design system. This helps improve team morale, productivity and retention. If people are happy working on the product they're more likely to stick around.

[00:22:37] The hurdle here is addressing diverse needs and sustaining motivation, because you might have people that work remote, you might have people in different locales. Our team down below, our authoring team, is in the UK, and so how do we make sure that the teams are working well with each other, that they're communicating, that everyone's still very happy in their work environment?

[00:23:01] Our next objective would be to establish an environment that encourages innovation and creativity, and this is something we really focused on last year. We created an innovation program for our development team where we set aside eight hours of time for a developer per sprint to work on something that they think would benefit the design system. This really brought about a number of different great solutions that we were able to use. But what we realized was that we ended up getting a backlog of a ton of these ideas that the team had, and this really helped us realize that we had changed our thinking. We no longer needed this program, instead we were thinking differently and now we just need to set aside capacity to take on these tasks over time.

[00:23:49] So now we have our business needs, we have our support, our KTLO, anything that we need to do to help our community, but then we also have dev and design innovation time set aside to make sure that we can differentiate ourselves from the market. And by the market in this case, you can actually think about it as an internal market and an external market. Internally this may push the design system, that feature, whatever you build, that tool could make it that much easier for someone to use and want to use that design system over something else. Externally, maybe we've optimized a design experience and that helps get someone through a user journey just that much faster. That really is driven through this type of creativity, so I think it's important to set aside time for it.

[00:24:30] And lastly, the last objective here is to provide opportunities for career advancement in the team. In such an evolving space of design systems we have to be really careful, because as we've seen in this industry, people are getting laid off, people are having a hard time finding work, people are having a hard time progressing through their career goals and their career ladder. So we want to make sure that people have opportunities to grow within the team and we have a plan for them when we continue throughout our design system journey.

[00:25:00] So we have our junior, mid, senior, principal levels, we have our managers and directors, but we also could create other roles. Since we started those partnerships that I mentioned in our business development function, we now have domain leads for accessibility, so we have an accessibility lead, we have an analytics lead, we have a testing lead now because we just partnered with our developer services team to come up with a really strong testing strategy for the design system.

[00:25:28] In this way people can enhance their skills, it'll improve their job satisfaction, and also make sure that we retain that talent in the team. I think a great story just to quickly tell is that one of our developers wanted to be an architect. I didn't have any architect opportunities on the team, but what I could do was offer them a place on our support team where they could learn about the architectures of all of the different teams that were building out applications.

Takeaways

[00:26:00] And that wraps up our business functions. But before we go today I wanted to go over some takeaways. The first takeaway is that a business-centric approach to design system strategy can help increase adoption, because you're so focused on your users when you're building out your products and features. You can also improve scalability, because now you have business practices, principles, methods and tools that you can use and apply to your design system to drive growth in a safe way. And lastly, this helps strengthen your focus, because now you have your business functions with organized objectives in each, where you can apply pressure at the right time to efficiently and effectively manage your design system. Thank you.