DesignTalk Ep. 65: Design systems—Zero to one


– [Margaret] I’m Margaret Kelsey and this is the 65th episode of Design Talks webinar series brought to you by InVision. Today Paul Farino discusses the life cycle of building a design system. Let’s listen in. – [Paul] Hello everyone and thank you Margaret for having me. And thank you Invision for
giving this opportunity to reach so many like-minded people in the community. I want to show my face first to say thank you for everyone who joined and who will be joining. If you can’t stay the whole time I know it’s probably busy
during your birthday. This will be recorded. So no hard feelings. Without further ado I’m going to get into my presentation and I’m gonna X out of the camera just to save some bandwidth and look forward to the next hour and some questions afterwards. So the title of my talk is called Design Systems Zero To One and the title is kind of a play on Peter Thiel’s book Zero To One. He was one of the original
founders of PayPal and then he now sits on
the chair for Palantir and in the book he talks
about taking an idea from 1 to n which is taking an idea
that already exists and adding something of value and something familiar to the world. And then he talks about adding something going from zero to one which is creating a new idea and kind of operating in the dark and kind of figuring it out as you go. It’s a really great book. Fantastic read. I encourage everyone to pick it up and if you prefer listen
to the audio book. You can follow along and tweet out questions using the hashtag #designtalks or you can contact me directly @paulfarino and on most networks, github and Medium and Instagram and Twitter and so forth. So a little bit about me. I’m a product design manager at Pivotal. Pivotal is both a product and service company. I work in the the consulting side. So we do two things. We build software with clients embedded in our office and kind of work hand by hand with them teaching them best practices of agile and extreme programming and user centered design. And we do the enablement part and we also actually build
the software with them. The other thing I do is I’m a design advisor at x.ai. X.ai is an AI company located in New York. They facilitate meetings and kind of ease the pain of email negotiation and ping-pong with setting up meetings. I’m so involved with that team. My experience is over the last four years I’ve been working as a
consultant at Pivotal. Kind of seen a lot of
different organizations from startup to enterprise and kind of lately been doing a lot more enterprise projects. And I’ve seen a lot of companies try to take on the initiative of building a design system. So I became really passionate about design systems about four or five years ago and started exploring kind of what a design system meant and what a design language meant. A few years ago we weren’t really using
the term design system. Some people were and there’s a lot of vocabulary that kind of surrounds what this means. I design code front end
a little bit of back end. PM and do some pre-sales. And my background is at product companies particularly doing predictive analytics and systems design. And over the last few years been focused on design systems, tools and helping growing design advocacy with the organizations. I really really focus on tools and unfortunately today I’m not going to be speaking about their technical tools on how to build a design system and all the translation layers and all the things like that that go into actually
distributing a design system to a larger organization. I’m going to be talking a little bit more about the soft skills and building up advocacy within an organization. So the next here is I really wanted a shout-out Gina. She’s a former designer at Salesforce and was leading to the
Lightning design system. There is a conference coming up in November at the end of November in San Francisco called the Clarity Design Conference or Clarity Conference. It is a systems design conference. If you’re really
interested in system design I really highly suggest that you attend. There’s also a Slack
channel that she’s created called designsystems.herokuapp. If you go there you can
enter your email address and you’ll get an invite
to that community. So first thing I want to do is define what is a design system. There’s a lot of different words that are used to describe a design system. Some people will consider a design system a style guide which may have implementation methods and code snippets. Some people will describe a design system as a visual language, a pattern library which
will show like atomic and subatomic particles. Other design systems
could be brand guidelines, voice and tone or really a full-on design language consumed by third parties. I really consider a
design system something that encompasses the whole, all of these things, but if you’re in an organization that doesn’t use one or the other a design system really could be just a pattern library or just a voice and tone for your product and marketing. So I want to show a few examples of what they are and some resources that you can go to. Voice And Tone is a site by MailChimp that shows a bunch of different copy for success messages and error states and things like that. It put a lot of thought and process behind kind of what the messaging they want to the use or what the tone is and how maybe the customer will perceive the tone. Another site to check out is material design guidelines. You’re probably mostly familiar with the material design guidelines. What I really like about their site is they constantly update with new guidelines whether it’s key lines, recently they added offline states to their guidelines. So they’re kind of always
iterating on this system and I consider it a design language because they have a lot of third parties that take part of their language and then they explore kind of what does material design look for my brand of product. And particularly on the Android platform. And the first style guide. This is pivotal style guide. It’s open sourced. I was one of the original team members for the Pivotal UI. I only worked on it for a short time but the team has really taken this project from kind of just an idea, an inception to what it is today and it’s a great component library. Pretty good styleguide. A bunch of apps consume the pivotal UI which I find really interesting and it brings its own challenges. And kind of the North Star of what I consider a design system is LIGHTNING DESIGN SYSTEM. I’ll refer to it a lot. The Salesforce team has a whole team kind of dedicated to building and iterating on this design system. It has everything from design principles to things like design tokens, implementation methods. It is really really a great system and something kind of to look towards and to build towards. They have a bunch of tooling surrounding their design system and I think it’s a great resource if you’re looking to build a design system of what you know further iterations could look like. I really like the idea or if we’re going to define what a design system is I like the way Nathan Curtis defines what a design system is. It’s a living funded product with a roadmap backlog
serving an ecosystem. And I’ll break down each of these kind of conceptually in the next few slides but I also like the way he explains what a styleguide is. And a styleguide is just an artifact of the design process. So there’s a bunch of
design decisions made. These design decisions kind of turned into software or components or principles and the artifact is just
the living style guide. And what I interpreted or translated as living is really not
a right and done effort. So creating a design system is iterative process that combines everything from research, UI design, development management, and consensus. So it’s something that
is constantly ongoing. It’s something that constantly needs to be iterated upon. And the last part here
is a little bit touchy. It’s talking about consensus. So although you don’t really kind of think of building something as getting consensus if you work with in any type of medium to larger size organization there is some areas of selling that you need to do and adoption that you need to do within your own company. And I’ll explain a little bit more later of what I mean about that. Funded product with a roadmap and backlog. So it requires a team with a clear measurable path for success. And that measurable path for success differs from team to team cause every team or every organization has different goals and it’s really important when you start to build
out a design system that you first define why you need the design system and the second part is
kind of defining the goals and those goals may be quantifiable. There may be qualitative goals. And I’ll talk a little bit more about that and I’ll break that
down a little bit later. And the last part here is it has to serve an ecosystem. So a designing system only exists if products make use of it and people adopt it. When you’re creating a design system you really need users. It’s a product. You need that feedback from people whether it’s qualitative or quantitative. You have to understand their pain points and you have to understand how people are using this system. And the lofty goal of
creating a design system is really a team independent of whoever created the design system can ship software, translate what the design system means, and interpret the system
with little or no guidance. And that kind of goes against really the last four years of what I’ve been teaching and learning at a glance. We’re really strong and opinionated on building with an agile methodology but when you’re building a design system kind of really the end goal is for teams to be autonomous enough to use a design system without having others be the bottleneck. They should be able to kind of look at the design system understand what the sciences decisions were made and be able to go and implement and ship software and to understand kind of what direction to go into. So who’s involved in
building a design system? First I’m going to talk about the users of the system. These could be individual contributors. IC on the top right. They may be product designers, developers and PMs. On the bottom right product teams. So teams will have
slightly different needs than individual contributors. Individual contributors may be more interested in tooling and how they’re going to use the system more from a tactical standpoint. And teams have a kind of more broader view of how they’re going to use the system and they may have different needs especcially if you work
at a larger organization. Third parties sometimes consume design systems. If you’re working with the vendor and vendors may want to have a type of app that kind of looks like a Salesforce or looks like a certain application third parties will sometimes be the user of your system. And then also business. Everything from marketing to legal can use a system for branding guidelines and for copy and so on and so forth. The core team of who
actually creates the system. If you work at a smaller
to mid-size organization you’ll have journalists for design. You’ll have engineers probably front-end and maybe some back-end and you’ll have PMs and stakeholders. So the stakeholders will kind of be the liaison for the business. They’ll be driving the agenda at the management level and kind of the executive level. If you work at a little
bit larger organization you’ll have more specialization which is normal. You’ll have visual designers, motion, copy and content, UX
interaction designers, front-end and product managers, sometimes producers, sometimes project managers. But the reason why I
want to go over a team is like I really want to hit home on this concept of team size and how important it is to kind of stay small and nimble. So as you start to increase the amount of people on the team communication and consensus just gets so much harder. It actually gets exponentially harder. So if you stay small let’s say six to eight people communication becomes a lot easier. So it’s really important when you start out
building a design system that you have a team that is nimble, that is
able to make decisions and kind of create momentum and create progress and actually building something out. If you start trying to
get too much consensus you wind up losing momentum and you wind up taking too long to actually ship software or ship the design system itself. So when do you start
building a design system? First you got to start with the why. You need a clear understanding of why you need a design system and there’s a few different things you can think about for the why. And I’ll go into them
in another slide or two, talking about different bullet points of why you need a design system and when you should
actually start building it. But the I want to like preface this with saying that don’t create solutions for problems that you don’t have. If you’re a small nimble team you probably do not need a design system. If you’re a start-up of you know five to eight people and you’re really trying
to find product market fit I see a lot of companies really try to start this initiative
with design system which is great but if they’re a smaller team and they’re still trying
to find product market fit. What happens is there’s
a lot of design churn. There’s a lot of development churn and you’re really
producing a lot of waste. So I really encourage teams to start building a design system when things are slightly more stable and when they hit like a
little bit larger scale. So when to build a design system. These are some of my opinions and points on when to build it. So when your team hits scale there are naturally going
to be some inefficiencies. So it’s gonna be technical and design debt. So there’s going to be redundancy of code. There’s going to be multiple designers. Their workflows are going to be creating elements
over and over again. There’s going to be too many grays within an application. You’re going to start to accrue debt. So that’s usually an inflection point where the team starts to feel the pain of that technical and design debt. You start to ship one-off solutions. So different landing pages and different stuff within the app that kind of doesn’t fit with the consistency of
the rest of your app. You also want to start
building a design system to increase the bus count or bus factor and some people call this lottery count. So let’s say if I’m the sole owner and sole builder of a design system. I have all the knowledge and context of building that design system. And God forbid I get hit by a bus, all that knowledge kind of stayed with me and the team does not have context. So the idea of increasing the bus count is kind of encouraging other team members to compare and get context on the design system that you’re building. And you want to remove knowledge silos. Another reason to build a design system is to make your app more consistent. And that usually means visual design but it also can mean interaction design and behavior. And you want a seamless experience across a different product portfolio. So you may have or work at a company that has a TV app an Xbox app, a desktop app and an iOS app and you wanted to make sure that if a user is on any of those devices, multi-platform that they’re experiencing the same quality and
consistency of design. You also want to reduce the interpretation and translation of different specs that designers or developers may create. So designers traditionally a few years ago would create red line specs that outline what some visual styles are, whether it’s height and margin and different things like that. Developers sometimes
don’t really understand what those specs mean. So they go out and actually implement something different from what the spec actually. You also want to reduce
implementation decisions. So when you have a design system and you have components and the pattern library,
front-end engineers and even sometimes back-end engineers, depends who’s working on the system will have these components ready and they’ll be able to
choose specific things that are already created and it reduces the amount of decisions that they need to make. They can focus more on kind of the user and business value and they can focus on kind of the features and behavior. And the last thing here that I put is you want to reduce waste. So red line specs and over documentation. Waste doesn’t ever go into the product. So when you’re spending time on documentation it doesn’t really translate into anything that the end user will see. So it really doesn’t
provide a lot of value. So the byproducts of a design system. These are the really
interesting things to me. These are a little bit kind of softer I would say softer skills
or softer byproducts of building a design system. The output and it empowers engineers to build with comments. So they have components. They have kind of design decisions and reasoning why you
should build something. And encourages contributions to the core product. So if everyone on your team or multiple people
within your organization are contributing to
your core design system, engineers, designers, developers, PMs will all have empathy
for the different wants and needs of those particular teams. You’ll reduce cycles
on legal and marketing. So branding guidelines, colors, things like that, you’ll have a single source of truth. You have defined principles. So for designers who are coming in, onboarding you have different principles and different kind of items for them to look towards a nd understand a little bit how design is consumed at a particular organization. You’ll minimize duplication. You’ll amplify design driven culture and this kind of helps recruiting. Those companies who do have design systems usually open sourced those systems. And some of them are actually internal but it really creates the same process where I noticed a lot of recruits are looking for companies that are more design driven and that value design and it really really does
help with recruiting. And the last part here is it reduces the cost
of building software. If you’re spending less time on recreating components and the redundancy of
writing additional code it reduces the time and cost of building. So with all these great things why is it so hard to sell a design system? And they talk a lot about
selling a design system and I think selling is probably one of the most underrated qualities for a designer to have. And I really over the last few years have been working on selling and negotiation and all
these kind of soft skills that surround you know these designer attributes and qualities and what these designers should have. So it’s really hard to sell design system because there’s trade-offs. There’s this opportunity cost that if resources are being spent on building a design system they aren’t being sent
spent on shipping features. So this is really hard
to kind of argue against and it’s totally true if resources are allocated to one thing they won’t be reallocated
to something else. So you should expect pushback. Selling the design system won’t be easy and it won’t be done overnight. And also sometimes you’re not aware of other factors that
influence decisions made at within your organization. So that it could be the way you’re getting financed and funding within your organization. It could be the way you’re hiring and getting more people onto a team and then they’re not quite suited for something like a design system or they’re more suited
towards something else because they have specialization. There’s a lot of decisions that get made at your company that you probably don’t
have visibility to. So what do you do to
sell the design system? I kind of broke it down and you need really three things. You need advocacy. So you need support from your peers saying that this is something that our organization needs. You need education. So you need to show and educate others the value of design. And also the value of design systems. And I think they’re
kind of tightly coupled. I think most organizations still need education on value of design and then kind of the next step is the value of a design system to their organization. And the last thing is you have to embrace constraints. You have to understand
kind of realistically and pragmatically what
the business product and user constraints are. For your organization and for your users. So I’m gonna talk a lot about the idea of being an academic versus pragmatic. I really really love this image. It was originally taken for explaining differences between a junior and senior designer but this is really the path
that you’re going to take for building a design system. There’s a lot of ups and downs and rollercoasters of actually arriving at a decision and creating the product which will be the final
result of the design system. So I just kind of want to let everyone know that
building a design system isn’t really just this linear path and following the process. It will differ from every organization and every team. So who should I be selling to? Kind of the one of the
principles of selling is you need to find
people who have budget, authority, need and a timeline. So B.A.N.T. And budget could mean resources. It could mean a lot of different things depending on what company you’re in. Someone who has authority. Could mean autonomy to make decisions and say go ahead, build the design system. You need to find people who have need. So need maybe a team within your organization that has been having
trouble with consistency within their app and you need to find a team also that has a specific timeline that kind of suits what the design system’s
timeline would be. And with that you also have to prevent too many cooks. So as you’re going out and kind of talking to
different potential users and internal stakeholders you have to understand that the more people you talk to the more you’re going
to try to get consensus, the harder it is to kind of come to a specific solution. So the teams and the outreach that you do, you want to make sure
that it is really focused on teams that may need or use your design system at least in the beginning. There’s a lot of different ways to sell and kind of the way I think
is most effective to sell and there’s a lot of different kind of theories around this is you really need to have advocates for your design system. And this may start with one person or a small team and the idea is that you go out and you show the value of a design system to these advocates and these advocates may be business folks. They may be designers or developers and you really got to show this design system is going to bring a lot of business value, it’s going to bring a lot of user value and it’s going to make your life easier. And when you’re selling those advocates what you’re really doing is you’re also training those advocates to sell to others. So if you’re speaking to advocates who are middle management or have reports or our
leads on specific teams what happens is they’ll go off and actually explain the value of a design system to others. And it’s kind of like the
spoke and wheel model. And for each kind of group there’s different buying triggers on why they would want
to use a design system. And I broke it down for developers and also for business here. So for developers you know they really want less time figuring out what UI to use. They want less time refactoring code and they want more consistency in implementation methods. And different activities that you can do or show how using components can make their life easier you know you really want to show them an actual prototype, something that maybe
in code pen or Sandbox. You want to plan out inconsistencies in the product. Too many grays, naming inconsistencies, things like that. So you really want to show the developers where the pain is. For business a lot of business decisions or if not all business decisions are made on three things. If something could make you money, if something can save you money, or provide a better better
customer experience. Those are the three things that business is looking for. And the different activities
you can do for business is show areas in your
app that are inconsistent and how creep and divergence may equal consequence for the end user. So this could be something like a suboptimal shopping cart checkout flow. Could be a drop-off in specific users. You also want to kind of do the back of the napkin math on hours, time spent on
rewriting logic and UI. A lot of times business will respond to quantifiable numbers. So it’s important to kind of like look through your backlog, speak to the developers, speak to the designers on how much time there’s redlining, how much time they’re spec’ing out work, how much time they’re actually creating UI and kind of try to translate that into either dollars or estimations or working hours. So you can show hours versus when you’re at scale. So if you’re a group of
30 let’s say engineers and designers when you scale up to 100, that’s going to become exponential. And that’s just increasing the risk. So what you really want to do is you want to model out
the cost for realignment. So if you continue to grow which hopefully you will at 100 people it will be X amount more. And that’s really a good argument for the business is kind of showing them where you’re at currently and where you’re kind of heading to and what that cost would look like. And then also you want to show the byproducts of building design system, so more of the qualitative stuff and the the value that you get out of not just saving money but also how it may improve team culture and things like that. So one of the big things
for business especially is you want to present data. So you want to create different models. Efficiency saving. If you have a design, development, QA you want to mine data as much as you can from project management tools whether JIRA or Pivotal tracker or so on and so forth. You want to understand what stories were created to create
different components and different UI and see where the efficiency savings could be. You also want to speak their language. So talk in terms of design debt and technical debt. And you really want to shy away from using jargon when speaking to business folks. You want to also evaluate trade-offs. So be realistic about what things will kind of get pushed
further down the backlog if you start taking on building a design system. And the last thing you want to do is create t-shirt size
estimation of milestones. So these would be milestones that you’re kind of looking to do for the first version of design system and following versions after the first version. These will be good to kind of put the estimations and all the data that you’re presenting in context. So I’m gonna talk a little bit right now about life cycle design system and kind of switch gears from selling a bit. So the life cycle design system kind of looks very much like a user centered design process when you’re doing research. The first initial stage is seed and that’s where you just
kind of just get the idea of building a design system and there’s that need and want to build it. The second stage is
where you diverge a bit and you do some discovery work and speak to users. The third stage is framing is where you start to converge on one or multiple solutions and then the solution stage is kind of when you’re building out the design system and you’re iterating on different versions of your system. And I’ll go into each one more in detail. So the seed stage here is the start of a design system comes from the need to
higher the bus count which we were talking about earlier within your organization and a desire to increase
efficiency at scale. So you’re really starting to feel pain and this is really a time where you’re going to start deciding to head on with the initiative
of building a system. The second stage is where you’re starting to conduct research. You’re starting to
collaborate across disciplines and you’re starting to
understand the scope of your system or systems. So if you’re working within multi-platform you may have multiple systems and you really want to
get an understanding of what is this design system look like for a first iteration. What does it look like
for a second iteration? And so on. And the different activities that you do for discovery is really trying to figure out the why. You’re doing things like a UI audit. You’re exploring existing interactions. So you’re taking a bunch of UI elements that you have within your application and you’re also trying to consolidate them down into a few. You’re trying to speak to users and potential users of the system. So these these users may be internal or they may be external. You’re trying to understand
the business goals you’re trying to solve for and you’re also determining goals whether they’re OKRs or KPIs. And you’re also trying to figure out how success will be measured. On the framing section here is where you’re starting to converge on scope, priority,
strategy and technology. So here’s where you’re starting to look at different tools that can help you with
building out the system. The goal here is to have a clear and realistic path to move forward. So you you want to have
a strategy in place for actually building out the system. And you’ll kind of want to start thinking about how will I roll this out to users. So in the framing section you’re really trying
to figure out the how. You’re trying to explore technology, stack and tooling. You’re evaluating complexity whether that’s timeline
scope and resources. And you’re solidifying design principles. You’re prioritizing epics in a backlog and you’re creating a strategy for system adoption. In the last section here, solution, I broke it down into two parts because I think there’s
different challenges as you move from version one to a second version and so on. The first challenge here is you’re starting to build and continuously test your product. So in the first section of the solution you’re building the design system. You’re creating anti-goals. Anti-goals are things that you want to accomplish but maybe not in the the first milestone. They’re things that you want to accomplish further on. You’re identifying areas of risks for building the system whether they’re technical or whether they’re business-wise you’re getting usability feedback. You’re socializing
learnings with stakeholders and this is really important. You have to create a cadence of sharing out your learnings of when you’re building design system. What have you learned and what is the progress
that you’re making? And you’re starting to
roll out the design system to a group of users and usually that group is a small subset of people within your company. And the last thing here is you’re starting to create processes. So how do you contribute
to the design system? How do you file bugs
for the design system? Things like that that you’ll probably wind up figuring out as you’re in this stage. So in the solution continued it’s we’re really
starting to look at scale. And you’re facing a lot
of different challenges, such as scale, adoption, and all while you’re continuing to test your assumptions. So there’s different
challenges that you have. Platform specific needs, VR and TB. There’s localization, accessibility, versioning, distribution of your, whether it’s pattern library or styleguide, this performance. So different things and benchmarks like TTI, time to interaction. And you start to redefine goals. So you want to make new goals whether it’s based on adoption or different organizational goals that you have. You also probably try to start to rear up the team. So you want to rotate people on to the design systems or give them a little bit more context as you’re starting to scale up the system. And the last thing here is you want to tighten the feedback loop. Build, measure, learn is kind of the agile explanation for a feedback loop. If you’re familiar with lean, you may see something
like think, make, check. In this last section here I have a bunch of tactical vignettes. These are kind of different things that I’ve noticed over the last probably four or five years of organizations trying
to build design systems and some things actually to look out for. So the first thing that
you should consider when building a design system is you need to allow contribution. So the idea of a design system is you may have a small team originally starting to build that system but you want to have collective ownership. So what that means is you want to have multiple people within your organization kind of owning this product and it’s not really just
falling on one person. If you remember about bus count and bus factor that’s something that you don’t want to have. And when you higher the bus count and bus factor what you really do is you actually make the
organization more resilient. When people leave the organization for natural attrition
or whatever the case is the context is usually lost. So a collective ownership is always something to strive for. You want to have a
process in place for PRs and pull requests and adding stuff to the design system. And that should be in
a centralized location. And also for filing bugs you need a centralized location for that. You want to reduce the amount of systems that you’re working with to manage the actual system itself. And you want to have
an accessible backlog. So everything that you’re doing, building the design system, you’ll be much more effective if you make things transparent and clear. The other thing is you want to make it easy to maintain. So look for opportunities to simplify and this means do not over engineer or over design. Usually what you see is engineers maybe they’re a little bit
more strong in front-end and they’ll create this clever code for other teams to consume and what happens is those teams really don’t
understand the code or they don’t understand
some of the decisions that were made. You really want to create a simple system that people can quickly get onboarded to your design system. And this will benefit
people both internally and externally. You want to invest in
tooling a technology. I kind of always think about as this way is tooling really scales. If you’re doing a lot of things manually and deploying manually and doing all these things eventually it’ll get caught up. You’ll get caught up on it. So tooling is a way for you to kind of move a little bit quicker and it’ll pay dividends
as you scale your team. You need to find a middle ground. So when you make a design system it needs to be opinionated but also it needs to provide flexibility for the teams to make decisions. So a design system should never be a blocker for a team. If there’s a team working
on a specific product and they don’t have a specific element that should never block them from moving forward. You should always allow for snowflakes and these like one-off cases. If they’re gonna use that snowflake or one-off cases that is subject for going back to the design system and requesting that a particular component or a particular behavior
is added to that system. You should provide examples in your design system. Examples really help when they’re in context. So showing what a particular
element looks like in a dashboard or marketing site or a landing page. Those are really the best ways to kind of show the end-users how they should be used. But sometimes you need to provide counter examples and sometimes it’s actually faster than writing every rule or guideline. You can write too many rules and what happens is in my experience teams tend to ignore when there’s a lot of writing. So sometimes counter examples. You’ll see it a lot
with branding guidelines of what not to do actually helps people understand what you’re talking about
in the design system. And also one use vignette or a fake brand for third party. So if you’re a company like Google who’s creating the
material design guidelines as consumed by people from third parties a lot of times fake brands
kind of give the people consuming the design system an idea of okay this is how I can use this and not look like a Google product or one of your products
in the organization. You need to have a sane release process. So this is more on the technical side. Semantic versioning. You need to ensure
backwards compatibility. So when you release new versions of your design system or style guide they need to work for older versions. Continuous integration and continuous delivery and you need to allow teams to update at their own discretion. So there’ll be certain
teams in the organization that have features that provide higher business value or user value than updating
a specific component. So you have to understand that the user, the company and product needs may differ and that they may have
more important things to do than update specific elements. So allow teams to update their own discretion. It shouldn’t be rolled out to every team to every product. You’ll have a lot of upset developers and PMs that way. You also need to distribute
the design system through every channel. So I’ve seen cases where the development designed the system, the style guide, the pattern
library things like that, were updated to match something that maybe a newer idea but the design system quickly became outdated. It’s important as you update things to make sure that every
channel is updated. So that there’s always
that one source of truth. And generally what works is that the source of truth will be some type of URL that a team can go to to kind of look at what’s the latest component? What’s the latest on the design principles and the context there? What’s the latest on the brand guidelines? And while you creating a design system you really need to create feedback loops. So you have to ask teams who are using the design
system for feedback. They are your users and you’ll be surprised about the things that they find and the issues that they have for with the system. They’ll have different needs and they’ll also be the different things that you know the core
team did not think about. So you have to listen to the teams needs and prioritize. So if you work at a larger organization a lot of times you’ll have multiple teams trying to consume this
one design system product and every team, let’s say if you’re a VR team you’ll have very different needs and wants then a team that is building an iOS application. So you have to understand kind of what what the needs are and how to prioritize them for the business and also for the larger organization. You also have to constantly
speak to customers. So this could be discovery research to understand a little bit more about that wants needs but it can also be to do usability testing for specific things that you’re working on within the design system. Here talking about socializing learnings. So when you’re building a design system you really want to share learnings versus just reporting on the progress that you’re making. I think both are important but sharing learnings is
really really important. You have to tell a narrative of what works and what doesn’t work. So as you launch this product. What has been working well for developers what has been working well for designers and what hasn’t been working as well. This may be finding things like updating to the latest version. May not be a smooth process. It may be the tooling has change and the development
environments are different. It may be the marketing and legal assets aren’t in the same place and they kind of spread
across different systems. You really need to tell a narrative and kind of escalate
that to the right people. And you gotta explain what action items will be driven from your findings. So as you’re reflecting back on what works and what doesn’t work. You also have to create action items on these are the things
that we’re going to work on to improve and to mitigate the risk of the things that we
recently talked about. You have to have documentation transparent and accessible. So this means having something that everyone within your
organization can view. And it’s okay if it’s
just a read-only document or read-only repo that people are using. You want to have it accessible so people understand what the team is actually working on. Here talking about enforcing the system. So as your team creates a design system they should adhere to the patterns. So for a PM in particular they should enforce these rules during story acceptance. So if something doesn’t look like the design system, if something is off from whether it’s visually or the behavior they should reject those stories. So I’m actually making it to different environments whether it’s production or some type of QA environment. And this should also be moderated by the team versus owners
of the design system. So each team should be enabled to actually make these decisions. This should not go to production because it does not look like or the patterns are different from kind of what’s in the design system. And the last thing here is talk a little bit
about design decisions. There’s a lot of different decisions that you’re gonna make that are really not tactical but they’re more like philosophical on how you’re thinking
about design systems. So when do you create a new component versus modify an existing
one with helpers? And these are different questions that you need to get consensus from your immediate core team. And these are things
that you’re gonna work on and iterate on and probably wind up changing your opinion on on how to do these things. Another question here is like when do you consider
creating a new component? And one idea may be if you copy and paste code more than three times that may be a time we then say okay I got to create a component for this. If you’re a designer you may try to consolidate components. And then if you create a new product you may need to create another component. And then also what tools should we use the stress test the UI? So what tooling should we use for different things such as showing additional copy within a component or build tooling or profiling and things like that. The last section here is we’re getting close to wrapping up is I want to give some some resources and some things that I’ve been looking at that I find really interesting. There’s a bunch of people
that I follow on Twitter and on Medium and stuff like that. Gina was a former designer at Salesforce with the clarity conference and the design system Slack. Matt Rothenberg, former designer from Pivotal. He works at a startup called Catalyst. He built an app called Runway which generates a styleguide. He works on a bunch of tooling around building style guides and design systems. Daniel, a designer at Facebook, has been writing a lot of blog posts on what design systems actually mean. John Gold from Airbnb. He works on the design systems team and he’s created a bunch of different tooling react sketch app. Ryan from Dropbox has been doing some great things, showing a bunch of his prototypes on different design
tools that you can use. And Nathan Curtis once again. He has a bunch of information on Medium. I really suggest you’re read it on modeling what teams look like for building a design system. So I have a few resources here on different blog posts and different resources on github t hat i’ve been looking at. So some articles by Nathan Curtis. Awesome Design System. So a gallery for different style guides and systems. How Your Company Benefits From Building a Design
System by Projekt202. They have some actually quantifiable data about X amount increase in efficiency by using a design system. So there’s a bunch of
good resources out here. Feel free to reach out to me through email or on Twitter and I can
send you over those links. I highly suggest you reading through that and trying to kind of formulate your own opinions about
building menu systems. – [Margaret] Paul, thank you so much for chatting with us and sharing your knowledge. And also a big thank you to everyone on the line and who attended today. I hope you all have a
great rest of your day. And keep designing awesome things including design systems. – [Paul] Take care everyone. Have a good one.

9 comments

  • Hamish McMaster

    Very helpful breakdown of your process @Paul.Farino. Invaluable advice @invision. Someone give that man a grant.

    Reply
  • Matt Sensenbrenner

    Are these slides available somewhere to download?

    Reply
  • llednew olejed

    can you share the slide pls? great presentation!

    Reply
  • Bandsintown Montréal

    Thanks. That is helping us to prepare ourself to use the new Invision DSM pluggin for Sketch ! Great presentation !

    Reply
  • Kristin Burnett

    Thank you!!! This was really helpful and exactly the information needed to learn in a way I understood! Would you mind defining a few of the terms for me? Ensure backwards compatibility, Allow for "Snowflakes", and t-shirt size estimations of milestones. Thanks again, great job!

    Reply
  • Gavin Stokes

    Super vid and answers a lot questions

    Reply
  • Vishal Kumar

    I couldn't stop myself from taking screenshots of the bulleted slides every 5 minutes. Very valuable and well formulated. Thank you so much!

    Reply
  • Jayaram Ramanarayanan

    Crystal clear and very useful for every designer and business development.

    Reply
  • manish thapa

    *styleguides.io 😀
    thank me later 😛

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *