My Dear Friends of Figma in Foreign thanks so much Nick good morning everyone I want to share with you my favorite conference tip so right now all of you have badges that are beautifully designed and you have them on and.
They’re sitting right on your little tum tums not doing anybody any good so when you’re sitting down in any Obsession of the sessions take your badge you can do it with me take your badge hold it up and flip it to the other side of your back so that the people behind you can read your name and know who you are right after and can introduce themselves.
To you all right cool how many people here have ever made a mistake at work I’d like to meet all of you with your hands not raised laughter this I’ve got some questions for you let’s take a look at a quick video about what it feels like to make a mistake at work oh.
I think it’s a safe assumption to say that we’ve all seen videos like this before some of you can guess how this is going to end some of you may have even seen this video before even if you have seen this video there’s still drama here right you feel bad for this girl her name is Abigail and you’re like oh man there’s a reasonable chance.
That she’s not going to be able to to finish this race she’s not going to be able to come back from it at some level we as humans sometimes feel like even if we stumble once that’s kind of the end of it my name is Dan Maul up until last year I ran a design system consultancy called super friendly and we worked and.
Consulted with some of the most recognizable brands in the world like United Airlines and Pfizer and Puma on their Design Systems and I want to share with you some of the observations and patterns that I’ve seen over the last decade so that you can learn from them too I’m going to highlight a couple of inquiries from prospective clients over.
The years that are representative of some of the inquiries that we got in that time period so let’s start here back in 2014 this is the kind of inquiry got please forgive there’s a lot of text on the screen but I’m going to read it aloud so this inquiry from 2014 from a prospective client is the subject is international.
Website framework and they said I’m looking for the next step and where we could be I’m looking for someone to rewrite the visual style in a way that makes it extremely modular like Atomic design I’m not interested in abandoning our original design I want users to see this as an evolution and this would be for the design of HTML and CSS and a.
Style guide pattern Library only not implementation on our CMS Etc I don’t want to get overly detailed in this email but is this a project that you would be interested in discussing further so make no mistake about it this is a design System project but in 2014 almost none of our prospective clients had that.
Vocabulary yet they didn’t even know what to call it they didn’t even know to use those words and a lot of us didn’t know how to use those words now fast forward to 2018. four years later this is a DM that I got on Twitter from a prospective client yo Dan we’re forming a design system team at our company and I know that your company.
Works in the space is there a way we can work together so four years later a very specific message that acknowledges design system work so a lot happened in those four years I think a lot of that is due to a lot of you out there in the audience too so thank you for the contributions for that.
Three years later in an email the subject is design System project we currently have a design system for the web experience of our company but it’s fragmented and we have a number of component libraries and silos throughout the org we’re revitalizing and funding a new core systems team tasked with defining a new component and pattern.
Library we’d like a partner to help our core system Squad execute designing and developing the components and patterns necessary for an internal release at the end of H1 2022 we’d love adoption of the entirely new design system by Q4 2022 you’d be working directly with myself and our system Squad two designers two UI Engineers one pm and one technical.
Writer so we’d like to be in execution mode if possible and bang out a list of defined components and patterns that amplify the brand and expressiveness of our company holy design system bingo all the buzzwords are in here right so again many years later there’s lots of design system terms here it’s kind of.
Reflective of how our industry has matured and how we talk about Design Systems a lot more more detail around teams timelines expectations things like that and then just last year the subject design system help curious to know if your team helps establish design system teams become better or need of some help specifically around.
Governance your company popped up in the discussion because you all worked with our new executive and she works with us now is this something that your team can help with so if I were to summarize that if sum up the differences between the inquiries that we got almost 10 years ago in 2014.
And the ones that we got this past year last year I’d say in 2014 most teams that came to us wanted help making a system and then in 2022 just last year teams wanted help getting people to use that system that is eight long years of hoping for something that apparently hadn’t.
Happened yet so the teams that reach out to us for help usually find themselves in one of two situations I like to describe them in two ways the first one is where there’s been a significant effort already put forth to create infrastructure and components and figma files and architecture and still.
No one really seems interested or they prefer to kind of do their own thing and build their own systems on the team I call this a design system Ghost Town it’s kind of a sad desolate place to find yourselves all right even worse the second situation is where teams get even more desolate and more desperate they’ve.
Given up hope they say things like we move way too fast here for a design system to work for our teams or we’re way too large of an organization for a design system to be useful at these kinds of companies you often find stories of several times over the last couple of years that they tried to.
Make a design system and it failed I call this one the design system graveyard so spooky here’s the point of all this whether you’ve had a design system for years that hasn’t gotten adopted or you’re starting from scratch today or tomorrow or next week when you get back at work.
You can be successful and it all starts with the decisions that you make about your next component which is the title of my talk today no matter where you are in your design system process the journey the decisions that you make along that journey of your next component can make all of the difference it can turn it around if you’re on a bad.
Track it can accelerate a good track that you’re on if you’re there too now last year I tweeted about a team that I’ve been working with and I said this I’m still thrilled for a design system team I’ve been working with the team formed on February 7 yesterday only 61 days later the ship design system version 1.0.0 and a feature team.
Implemented a component which was checklist item into their code base saying it saved them a week of Dev time I think that team might even be in the audience today I’m not going to tell you who they are oh a round of applause can we have a round of applause for this team thank you all right.
I’m not going to tell you who it is but you can go and find them later you can be like hey did you ship a design system in 61 days no did you that’s how you can introduce yourself to people now this is a company that was on their fourth try at a design system so it’s never too late to get your design system up and running that doesn’t mean there.
Aren’t hurdles but you can always get there you can always do it so maybe you’re thinking something that a lot of my former clients would come out and ask they would say okay Dan you’ve helped hundreds of companies with their Design Systems what is your process and I think honestly they’re looking for something like this like a fancy diagram.
With circles and arrows that show up when you do Google image search for like design process you know like they want me to say like well first we celebrate then we congregate then we fornicate then we triangulate the like you know something something like that instead I usually say something like I don’t know there’s like 50 things that.
We would do over the next three or four months and they go okay well what kinds of things and then I would try to like describe it in a way that more of a way that I should on a sales call I kind of stumble over these things and and they get really confused so instead what he tried to do is my friend Crystal vitelli and I.
Decided that we would write it all down in detail and that became uh this workbook that we put out called design system in 90 days this version of the workbook is not available anymore I’m currently working on the new edition of it but that’s okay don’t worry about it you don’t need that you don’t need to take pictures of the slides I’m going to.
Spend my time on this stage today telling you the four or five best tips in this workbook I’ll just summarize it for you today that’s what this talk is about I want to share what I consider some of the most important steps in getting your design system adopted as quickly and efficiently and effectively as possible.
Okay so I said the next component that you tackle has a Major Impact which kind of begs the question so where do we begin where do we start that and to answer that I want to share with you two quotes that I love sharing with design system teams this kind of helps round out a strategy at the highest level very very thematic very conceptual not very.
Practical yet we’ll get into the Practical and I’ll share with you kind of the big Vision stuff the first quote is from the late Stephen Covey he’s the author and educator whose most popular book was The Seven Habits of Highly Effective People some of you may have read it and I love this principle from this book the principal says begin with.
The end in mind I love this quote so simple so rich begin each day each task each project each component each page each pattern with a Clear Vision of your desired Direction and destination so how do you know where the end is or what the end is how do you find that well the first activity in the workbook.
Is this assemble the North Star it says the mission network strategy and vision Define the Strategic direction for a business they provide the what who how and why necessary to powerfully align action in complex organizations what does that mean your company’s mission and vision statements exist to help keep everyone aligned that’s why they’re.
There ideally Your Design system team can take some of that heavy lifting from the mission and vision of the company you’re not supposed to Define that for yourself you take the the one that your company already has so it makes sense to tie the two together so for example let’s look at the mission.
Statement on Uber’s website anybody here work for Uber some free Consulting okay on Uber’s homepage it says or in Uber’s mission statement is we reimagine the way the world moves for the better so the question that every team at Uber should be asking to keep them on track is how can our teams feature or product.
Reimagine the way that the world moves for the better how can our app do that how can our customer service department do that how can our design system do that how can our design system reimagine the way that the world moves for the better so what do we do with that I mentioned I.
Had two quotes that I like to share I share with you the first one begin with the end in mind here’s the second quote and it is from Dallas master lautsy and it says a journey of a Thousand Miles begins with a single step design system teams are responsible for making Vision happen not making the vision.
Right you look elsewhere in your organization for the vision that’s likely already been established so your job as a design system professional and expert is to make that vision and Mission actionable to take that first single step you want your design system to go the distance to go that journey of a thousand miles now components are the.
Lifeblood of every design system so what is the first component going to be I don’t don’t shout it out just think it to yourself for the first moment you know for a moment or two what is the first component you should work with on a design system now whatever you just thought in your head.
I want you to remember that answer for a minute just hold it hold it there because I believe this is the single biggest misstep that leads to design system ghost town and graveyards this line of thinking sets design system teams off on this unproductive journey and they fool themselves into thinking that they are doing worthy work what do.
Most design system teams think is the first step in their Journey Of A Thousand Miles the first no-brainer component that you’re supposed to tackle when you work on a design system how did you know I was going to say I wouldn’t ask anybody to raise their hands but everybody kind of shouted it out take.
Stock of it was the first thing that you thought of seems obvious right it’s so simple every product team needs a button somewhere in their features in my experience though innocent simple button has been the slippery slope of and the downfall of many Design Systems now let’s explore why button is such a.
Poor starting point the first reason that I think most of us want to start with button is that it is a quote simple Atomic component very quickly we get to this point there’s a tweet from Matthew batamani says is it normal to have 850 instances of a button in figma asking for a friend with the amount of variations and.
Options most digital organizations need in a button it is anything but simple much less the simplest now Apple recently made their first submission to the figma community earlier this month with their iOS 17 design library and of course massive shout out to Joey banks for his tireless volunteer work for all of the previous.
Apple UI kits that he created and maintained as I explored this and looked deeper into it there are 288 different variations of button in this UI kit those that think that button is the simplest component to start with very quickly experience a rude awakening now the next reason that button is a.
Tough component to start with is that once you have button done you think well we have button so we should probably have some general typography Styles and then maybe a base color palette to find and some other Basics like form elements and headers and Footers button is a slippery slope to trying to work out all of the foundations in.
Advance now I won’t get into it too much here I wrote an article called the Folly of design system foundations that talks about how I think the idea of quote foundations is one of the biggest threats to creating a design system that people actually can use let’s go back to Uber here can we make a good argument for why the button component helps Uber.
Reimagine the way the world moves for the better now you might say well I mean if we added a little bit of Animation that shows some movement and the key there is when your voice goes high like that probably in hot water what about a map component though yeah I can make a really strong argument.
For how the map component literally helps Uber reimagine Envision and communicate the way that the world moves for the better that would be a much more useful component to start with now another reason I’m convinced the button is a terrible early component is that it flies in the face of everything I’ve.
Learned from a very prolific source of inspiration in my life movies how many people here have ever been to prison I’m just kidding don’t answer that don’t answer it what do movies teach us is the best and quickest way to get respect when you’re the new inmate on the Block.
You go and fight the biggest guy around don’t you want your product designers being like I’m with them if you go to product teams offering little old button component they’re going to laugh you out of the room what team needs another team to provide a button to them no one but if you decided to take on one of the most complex.
Nastiest most intimidating components in the company that might earn you some respect we often hear the Mantra in this industry The Design Systems are a product and who builds products in our world startups so it stands to reason that some strategies that startups use to grow successful products could serve.
Us well too so let’s look at what kind of strategies those are meet what seemed a hair he’s the founder and the CEO of pilot which is a startup that provides accounting CFO and tax services for startups and this is a post on LinkedIn that he made he says my first startup was acquired by Oracle my second startup was acquired by Dropbox.
My third and current startup is valued at over one billion dollars so clearly we’ll see him as a track record that indicates yes some kind of product and and startup wisdom and under his belt now here are the principles that he shared that led to success for all of his companies since my co-founders and I have used the same set of principles to.
Start all three companies first one find a problem that’s huge and painful principle number two understand that problem more deeply than anyone else number three assemble a team that’s uniquely qualified to solve that problem number four never stop talking to your customers if you want to make a design system and.
A design system as a product these are great principles this is the Playbook right here for how you can create a design system that people use that get traction this is a great approach to take with any product and a design system is no exception specifically in regards to Design Systems there are three sets of.
Activities that I recommend in my workbook that help you accomplish these steps in detail so let’s talk about some of the detail of that the first one is to collect feature teams roadmaps get your hands on whatever is used at your company and organization to plan quarterly initiatives you know find those H2 planning documents and things.
Like that and to facilitate conversations about prioritization what are the features that are coming up over the next three months what’s being planned how are they broadcasting those plans that’s what you’re after you as a design team want to capture those things and capturing this is really easy you don’t have to do.
It in a very formal way you can do it very informally my teams do it in fig Jam right we make little areas and sections for each of the teams that we’re going to work with and talk to the payments team or the booking team or the social team and we just paste all the things that we can find about their upcoming plans so that we always have.
One link we’re always one link away so that could be links that could be screenshots it could be jira tickets it could be any of those kinds of things the kind of catalog what’s coming up in our in our roadmap in our company’s roadmap so that we can help that effort we can intercept that effort and help with it.
All right the next activity is to interview potential design system customers make a list of 15 to 20 people who you think would benefit from using a design system interview each person for 30 to 45 minutes and listen for stories of how product gets made you’re not asking them about components you’re not asking them about design system stuff.
You’re not asking them about your work you’re asking them about theirs how do you all make product what do you do first what do you do second what do you need what is usually lacking what do you already have the reason that this is an important step is that this is how you avoid the slippery slope of button.
Including the button component is an answer to a question that no one asks this is that question what components should we have in a comprehensive design system no one asked that question the honest truth of it is that the only people who care about the answer that question or even ask it are people like me who speak.
At conferences like this and people like you who attend them doesn’t matter to anyone else a better question is who can we help and one of my favorite answers to this question comes from author Rory Vaden and here’s we’re already in an interview I’m gonna play a clip here he’s in an.
Interview with motivational speaker Ed mylett and they’re talking about the importance of their own experiences when helping people let’s watch this all of us our most powerfully positioned to serve the person you once were oh wow your most powerfully positioned to serve the person you once were.
And so when you look at the problem you solve right it’s going what what challenge have I conquered what obstacle have I overcome what setback have I survived we see this a lot right designers want to make a design system to help engineers build it higher quality what that really means is that designers.
Are tired of redlining and doing multiple passes of design QA on a build it’s well intentioned and it’s also pretty selfish designers can’t help Engineers if they’ve never seen a line of react code Engineers can’t help product managers if you think release Cycles are garbage remember in the quote in the in the.
Video your most powerfully positioned to help the person you once were if you’re a designer and the token Studio plugin helps you design more consistently show others the other designers how to discover that skill too if you’re an engineer and the Design Systems approach to composability helps you code faster then teach other Engineers how to do.
That too that’s why the interviews are so important you can discover people who are on the same path as you but just one or two steps behind you went ahead of them so that their Journey can be a little bit easier and that’s the point of Design Systems all right next activity schedule product walkthroughs and feature walkthroughs.
Track down the emails of promising teams product owners and leads and start scheduling some times to walk through their products with them find time that could be on Zoom it could be in person where you just want them to show you what they’re working on it could be their current product or their current feature it could be wireframes.
Of the upcoming feature or even sketches that they might have even if they have not or full comps or even prototypes whatever they have coming up that gives you a sense of what they’re going to be working on ask them to walk you through that and start cataloging some things and again this is easily tracked in a fig Jam or something similar my team.
Always use fig jams for these so like for example the teams that you’re working with the payments team or the social team whenever whatever they’re walking you through just make a note of all the components that you see you don’t even have to use the right names it doesn’t matter but just use Post-it notes just write down the names.
Of the components all right they’re showing me some screens here I’ve seen accordion see some tabs there’s a toggle here there’s a tool tip here all right all you’re looking for is components and then go on to the next team you work with the social team they’re walking you through their new products take note of their components and then the next team.
And the next team after that and this is where the magic happens now that you have an inventory of all of the components that teams are working on across the company as many as you can catalog now you start to make a heat map now you start to tie things together now you start to connect things which is the point of a system you’re connecting all.
Of the disparate products and features of your organization through the system that’s what makes this system so you highlight the ones that are commonly used not everyone uses accordion it’s cool if the payments team is using accordion that’s fine they can build their own accordion they’re the only one using it but this team and that.
Team and that team are using the badge are using the tables are using tabs and then you can organize this by these green stickies here you can kind of pull those aside to one side of the Fig jam and organize them by priority so what does this view tell you what is the toughest meanest component that you should take down according to.
This autocomplete why because it’s the toughest and meanest one I think one of the primary responsibilities of a design system team is to take on the most difficult complex work so that it becomes easier for everyone else okay so let’s say you decide to tackle.
Autocomplete you talk to every team that’s going to need it soon you understand intrinsically that some teams needed to support an icon other teams don’t you get what props are required and what can be optional before your design system goes off to build the component from scratch what you should do is look to see if a.
Team has built it already design system teams should rarely start from scratch I think that’s another Pitfall that I see a lot of design system teams do they do their inventory and they go okay we’re going to invent the best autocomplete don’t do that I’m sure autocomplete exists at your organization maybe not.
Fully but go and find those parts starting start by amplifying the good stuff that already exists it’s time to instead of trying to create your own good thing from scratch the difference will be that everyone built their own version of autocomplete to serve their features needs they didn’t build it to be reusable by.
Other teams if they contributed their versions right which is what we expect all the time well why don’t they contribute our versions to us that would be a problem we don’t want them to contribute that for most people it’s better to spend time on their core role instead of design system contribution.
Let product designers design products not contribute to Design Systems you actually don’t want them to contribute because it actually creates more work for everyone what’s faster and better is for you the design system expert the design system team who sees more broadly across all the teams in that inventorying exercise.
That you’ve done for you to figure out how to merge all of the different requirements and the options into one or a few harmonious usages one of the biggest pitfalls that I see is that design system teams should be the one doing the contribution and most teams don’t think so they want the product teams to be able.
To do that but the design system team should be doing the contribution work once you have that as soon as you have that then you use ability test it with teams immediately time to see if your product teams can use the component on their own so what you do the process is you go and find all the good parts of autocomplete that everyone else is.
Working on you figure out how to combine it together what things become optional what things become required and then you give it back to them that’s adoption so that’s how the cycle goes you the design system contributes and then and then get it re-implemented back into product teams through usability testing anybody know these guys.
This is Patrick and Patrick Collison and John Carlson they’re the founders of stripe I know we have some stripe team members here who did a great talk earlier yesterday there’s a famous urban legend in Tech about these guys I don’t know if it’s true or not but it’s a good story it says when they first started stripe they would demo it for people in.
Person they would show show stripe to them and for anybody that seemed interested they would do what came to be known as the Collison installation they would say hey can I install it on your laptop right now that’s how they got such great adoption early on for whatever reason in our industry we have this mythology around.
Design system adoption like if we make the perfect design system then adoption will just happen magically and automatically people will find the system they’ll be drawn to it it’ll be so compelling they can’t help but install the components in their builds and we can just sit back in our design system headquarters and watch the.
Adoption graph hockey stick up and to the right no this never happens getting adoption is active we have to sell we have to Market we have to evangelize and sometimes beg yes beg teams to use our components as soon as they say they’re willing there is no time like the present let’s get it set.
Up right now on your laptop can I see your laptop right now let’s get let’s get it installed the team that I mentioned at the beginning of this talk that did it in 61 days that’s how we did it lots of demos followed by immediate installation with dedicated and quick iteration and Bug fixes okay so you’re actively working with.
Teams usability testing components and you’re getting them implemented and adopted that’s going well now what well now you document s I hate this not the idea of documenting but but the word I think the connotation of this word is is it takes us down into a terrible territory you can’t expect an.
Organization to entirely change its way of working because somebody wrote it in some documentation right but isn’t that how we always write it when when we document we only write down our ideals this is how it should work in a perfect world and this is not really helpful it’s aspirational but it’s almost never used.
There’s a scene in the movie Harry Potter and the Half Blood Prince where Harry and his friend Ron arrive late to their first year of class of advanced potion making so Harry tells Professor Slughorn that they don’t have textbooks yet so Slughorn says like go to the closet and you know go go get some there are two books left in the closet there’s.
A brand new one and there’s this old beat up used one so Ron and Harry kind of tussle over it and Harry gets stuck with the old one now the first assignment in the class is to brew an acceptable draft of a potion called living death and whoever can do this will win a vial of liquid luck as a prize now sluggorn says the recipe for.
For living death is on page 10 of the textbook but he also warns that only once did a student ever brew a potion of sufficient quality to claim the prize so Harry opens his textbook and it’s labeled he finds that it’s labeled property of the Half Blood Prince and it is full of notes written in the margin of this textbook to show how to.
Successfully Brew this potion he knew that he had a cheat code he knew that he was following not just the textbook but the instructions of someone who had done this before someone who came before him to actually do this too and that person left notes for him left a breadcrumb trail right in the book The Textbook said to cut but this.
Person wrote in the margins crush with blade because it was impossible to cut I think we as design system maintainers and makers we try to write the textbook which is a good thing but what we never do what we almost never do is go back and annotate and go actually now you should crush instead of cut and in fact that’s where other people can interact.
With us we might be the writers of the textbook but we want we want people to write in the margins when we think about making reference sites for design system we often think about them as instruction manuals but they’re not they’re not supposed to be instruction manuals they’re really just historical record.
That can be updated over time of this is the latest way to do this thing successfully try to follow the textbook and make notes in the textbook where it where it just isn’t right that’s the design system not the textbook itself the design system is a textbook plus the notes in the margin that’s the kind of contribution that we.
Can expect from product teams not fully baked components that are reusable and scalable and Abstract that’s too hard for them to do that’s too big of an expectation but what we do want them to contribute is their stories is their Solutions of how they tried to use the textbook where it worked and where it didn’t.
So instead of thinking about documentation I like to think about it as chronicling instead of thinking about documenting Your Design system or documenting the API or documenting the components which are all important things instead let’s reframe it as chronicling the stories that’s what document design system.
Documentation should look like the problem with documentation is it generally it can be written before you ever design and build anything and in that way it has more of a tendency to be a dry instruction manual chronicling chronicling can only happen at the earliest while you’re doing something and most times after the fact.
So after you do something successfully then write about it so that other people can do it when we create things we often don’t use them ourselves so how can we Chronicle it that’s where we can partner with product teams to be able to to pass that knowledge along in a much more uh a much more effective way a couple years ago I was lucky to be.
Able to work with the radio free Europe Radio Liberty team and what they do is they report the news in countries and regions where the Free Press is outlawed or banned now this is the home page that we built with the new design system that we made together if we scroll down to the middle of this page on this on this home page what we see here is this kind.
Of dark component that goes all the way uh a full row with kind of this dark background now in the world this component goes by different names so let’s do a little poll here with the audience how many people here would call that that full width element how many people call it a carousel okay a few hands up how many people call.
It a slider anybody would call a slider okay a few less hands okay how many people here would call it a Fred No Hands okay the name of this component in that design system is actually called Fred they call it Fred if you don’t believe me you can go to their home page right now you can view source and right there.
You know it’s highlighted here right there div class equals Fred content it’s called Fred if you ask anyone at radio for Europe Radio Liberty there is no question about what this thing is called they know it as Fred and they’ve known it as Fred for seven years I’ve worked with them seven years ago and this is on.
The home page this month this is when I learned one of my biggest lessons in Design Systems that I carry with me to this day and I try to share it with as many teams as I can it’s that it doesn’t matter what you agree on it just matters that you agree is Fred the right name for this component absolutely not.
But who cares the team has clarity they’re together and it allows them to move forward everyone makes a such a big deal about naming naming is hard no it’s not getting people to agree on something is hard so don’t spend a lot of time finding a name for a component pick a name quickly and then spend all that.
Time trying to get convince people and evangelize people to use that name you all know who this is you shout it out if you know yeah just Princess Leia from the Star Wars franchise uh probably know who this person is too this is Luke Skywalker also from the Star Wars franchise this person here this is Darth Vader from the.
Star Wars franchise um how about this guy anybody know this guy Dash rendar we’ve got some nerds in the audience awesome this is great this is Dash rendar now how many people are like I don’t know who Dash rendar is I’ve never heard of Dash render right Dash Rengar is sort of like Han Solo.
Light he’s like a Smuggler without care a pilot of his own freighter he’s kind of known for his ability to get out of sticky situations but unlike those other three characters that I showed Dash rendar is not a Canon character he’s off Canon so the the three characters are Canon characters in Star Wars and basically.
What Canon means in the Star Wars universe is those are the immovable objects of Star Wars history characters and events to which all other Tales must align so all of the movies are Canon but some of the books or the video games or the comics a lot of those are off Canon a lot of those are the extended universe.
So what that means is they’re not officially characters they might become characters one day someone has to bless that to happen but they’re not at least not right now and when I think about Design Systems I think a design system is kind of an organization’s Canon right it’s kind of the way that we do things the things that are official here it’s.
All the stuff that we’ve agreed to agree on over time the reasons that we’ve agreed on these things fade away I don’t know why that component’s called Fred it was called Fred before I got there it’s called Fred after but the agreement is the thing that stays and lasts that’s what Canon is.
It’s a collection of the stories and the outcomes of those stories it would be good if all of those stories would be or official but I think it’s also even better that some of those stories are unofficial they might just take time to become the official thing and that’s good that means you could have an extended Universe outside of your design.
System the design system doesn’t have to be the whole universe there are things that are Canon and there are things that maybe one day can become Canon even if they’re a snowflake right now so I shared a small slice of combinations of plays and activities that you can run to put your design system on track or get it back on track.
What’s cool is that you can do this process anytime you want if your design system is eight days old you can do this if your design system is eight years old you can do this if you’re discouraged about where your design system is right now it is not too late to turn it around remember Abigail let’s finish Abigail’s story.
Hey Abigail she actually won that race she stumbled she felt like all of us do at work but she won the race and even more important how do you think she felt after that well no better way than to ask the source Abigail how’d you feel about all that.
I kind of expected that stutter after I went over with the wrong foot but I literally didn’t expect to like lay out and like Superman fall so I think I was kind of just startled but like I was It was kind of more like a you gotta get back up and finish this more than like a oh my God what just happened you know what I mean.
Adorable I think that’s probably the best note that we could end on if you enjoyed this talk please do connect with me on all of the socials check out my new design system University as a way to connect with a great community of design system enthusiasts and grow together I just released or I’m about to release a new.
Design tokens course that incorporates the new figma variables functionality and with that I want to say thank you to everyone here to the AV crew to Tim and Reuben and John and everybody on the AV crew that made this awesome to figma for allowing me to be here and config and finally of course most of all thank you to all of you for being great listeners.
I hope you enjoy the rest of this amazing event thank you
Speaker: Dan Mall – Founder, Design System University The next component your design system team chooses to take on is …
Figma Official Channel,your,next,component,figma, design, product design, tips, tricks, UI design, ux design, app design, figma design, design for figma, FigJam tutorial, prototyping, collaboration, UX tutorial, Design tips, Figma tutorial, Config, design system, tutorial, product:figma_design, audience:designer, language:english, format:standard, produced_by:other, theme:design_systems, event:config, series:other, type:other, level:none, primary_feature:comp_props, secondary_feature:library,