Bestand wählen
Merken

A Design System at Scale

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
but this kind of and I find few hey and maize most Roman and I'm excited to be speaking to you today about design systems that scale was stated to be speaking at the pre-conference because this is a lawless and reading and in 2000 offers on a holiday they get sick with reliable they answered a couple days ago so I'm a little bit and try to avoid sneezing coughing at you and
so that's me and I've been a developer to go find him as discussed in working with Member for about a year and a half and you can find this handles loading I've tweeted maybe twice in my life so it's not the most exciting thing to follow so why don't even wanna design system where am I speaking to you today and a lot of that kind of similar problems come up with different companies the that cause someone to want to implement a design systems so 1st Bearing Implementation of similar components throughout your apps and products are this means more work for engineers less consistency across products and different components and also means that you i engineers are able to reuse code so everyone's creating their own components and again last consistency more work and there's Morris that these components are going to be up to date with current designs so we start out this and basic
terminologies just so we're all on the same page and people use different terms that can have overlapping meaning in context so I wanna define hobby using cell guided pattern library and design systems and these arts absolute definitions but they're fairly well agreed on and how I mean to be proceeding so starting with style
guide and this is your branding guidelines your editorial tone color palettes all that stuff without data so this is what directly influences look and feel of your pattern library brings the panel libraries so here you got static UI elements common Web layouts this is ultimately what the developers again using and then the design system itself encompasses both of those previous of the style guide and the pattern library then all the iteration in communication between everyone involved so it's it's basically the entire process it so as hasn't
anything it's important to figure out what your company's you're teams goals are and when you're implementing something like this so that everyone's building this with the same key goals in mind and that to get flying we actually had several conversations that can I came back to what our on where key goals were so that we're making sure we're building toward the same things I instances here listening to my talking my recommendations for your goal should be will argue the process of help keep your designed system currents and compatible with all your existing product features as laws allow for a smooth upgrades noun into the future so regardless of if your brand new to programming or few been coding in using designs for years and initially had implement manage a working design system so the 1st
schools we only have is to create 3 1 enable engineers to create consistent products out of the box using the comprehensive sharable components that you created 1 enable engineers to move
fast through code reuse and collaboration and beautiful documentation yeah we will laughter smooth
upgrades um and then a lot of support and our communication around those upgrades and possibly
most importantly we want to be able to scale so we want was designed system to the to be set up to scale but a current project teams and as consumers and whatever we may see into the future it really just needs to work so however bigger or smaller your team starts at now you wanna have this in mind so that your system set up to scale yeah
so issues that come up on both within take a fly working with our design system and also talking with some other companies there are a lot of common things that came up time and time again answers system different obstacles where the biggest things that companies struggle with is actually getting support to really build something like that so it does take engineer working there for time and so getting management to be on board with their with understanding the importance of building designed system is kind of the 1st obstacle and once you have that in place and figuring out best ways to distributing communicate about this and and really how to make this a part of the culture so there are plenty of other companies out there
building design systems and you often see the end products so 1 of the most well known ones is Google's material designed but not a lot of us know kind of a process that goes into it so we have this product of 100 and they come up with that actually spoke with people from each of these companies about different and processes documentation and obstacles they ran into things you wouldn't it done differently and is actually good learning experience on even more companies have started a design system but if it's in place current and are really is that's really a big obstacle for them so many companies start something but it's not documented a distributed properly there's not really a system in place to have that at to have all the communication avenues there and they quickly goes extinct so the real test is this is that the designed system is still in place and current 6 months a year 2 years after it started to ask me next year and work on how to get quite doing and so the product so I don't want a great pattern library it sounds pretty easy this code at some generic components make sure the teams in where the repo is did quickly because it's not actual product work rate while not so much not if you want some that actually works when everyone really needs to understand is that the the Pattern Library is your product and that the the consumers are the entire company specifically the engineers organ using this and so just like actual product work there needs to be an iterative process to create implement release inversion all all features and this involves designers developers and documentation every step of the way and so you may be thinking the sound lot like source still problems and you're right I especially on a smaller within a smaller company a smaller team and we don't have the typical soft skills support as a regular product team you need to keep that in mind the often around p and sales teams support team as well as engineers another issue that came up was keeping all those things in sync so we need a JavaScript and CSS to be in sync for all major versions so that we don't have conflicting styles within our components so for example if to get flies that take if i assesses that version 2 . 0 . 4 we see to make sure that all of our jobs for components are also version 2 . something point something so this fall's kind hand-in-hand with just having strict adherence to semantic versioning which were probably all familiar with and but it just seems to be clear that everyone to everyone who's using us that if major versions are out of sync then things are going to break so again communication with that as well and the current
tendency trap which I'll actually go into a little bit more in detail later but basically if you can avoid having modules that are dependent on each other than that that helps a couple things to make things you better the
and distributing so how do we actually get these components into the hands of our developers in the simple seamless male possibly easier for smaller teams are companies or you're just sitting on x to each other but thinking about scaling lesson on making sure all teams of a bigger company can use these on those issues need to be considered if the communicating so how can we communicate knowledge announcements changes upgrades migration past all that stuff to the organization at large and we really want power teams to deliver simple accessible consistent experiences to all our users and pleasing so
this is something we ideally don't we wanna have to deal with the more companies spending on policing different things a lesser really focusing on building a great system and also the last teams are going on users of there being hounded about what they're using what version there on all the time and so we wanna make this this UI development as much as no self-service as we can I just again
a recap are issues of and so really recognizing that the library is the product that you're building are keeping everything in sync and trying to avoid pure dependencies and then distributing communication and policing right semantic ideal a bit
about to get final I and and things that when we're all things that we can ran into some of the ideas that came up as we were working on this time to go fly i is our design system with into I'm so like many companies we have several apps and they all had varying implementations of these very similar components and we also had attempted something try and build a pattern library a few years ago and but it wasn't really well organized we'd inhabitants support around it and so it it quickly just kind a got out of date time and wasn't maintained well so last fall some of the front and developers and designers came together and we wanted to do something about this the we wanted a pattern library that could really be used across the company to maintain our standards and and consistency in the styles throughout our apps so we likely had a lot of support from management they understood the importance of building something like this so with that support we're able to form a small team of developers and who was focusing on this project
and so our basic process here was from design to developer to the users are you are end users of the team's engineers URI using this as pattern library so sometimes you can't do this feature by feature as with to get fly design at RT come up with a bunch of designs for different components so in an ideal world we would probably sit together future by featuring go through that but in our case we can I looked at which were the most important components to start with so which components reuse across most of our actually really wanted to focus on those and we also wanted to start small and simple with the more basic components so we sat down the designers and went all a sketch files absolved any questions figured out any like outlying cases that we might need I'm and really camera things out with them we decided to save things like animations a more complicated things until down the road it we don't really have a good understanding of across management design and engineering that there was only and and a goal of finishing the pattern library so we're making it to make it easier for designers and developers to iterate on a product and on different features but this end the goal is really just to have an up to date on I consistently maintained and consistently use pattern library to something that would keep going there's not like a hot stop on that it is also critical to get a good understanding especially from management higher up that this wasn't something that was going to return results overnight there is really a long-term investment so next thing we did was we actually brought pattern library stories into our product spreads and so we have a dedicated team that was focused solely on to get flight light and we other projects that we are working on so bringing these stories into our sprints really helps in 2 ways so 1 accountable for actually working on to get file during regular Sprint work so we would allow a certain amount of time to that and also made it more of the cost of a bigger part of the culture stop yams you about at the back and engineers so just became more of a of a common standard across the company the migrations so
ideally you really want is to be easy an iterative so whatever you are currently using you want to use a variable to I use the new system or upgrade things easily and with mountains of building our system we actually realize that we probably could have done it got about a little bit differently in an easier migration path and we had kind of started with just building this new project that we're excited about I mean we had architected how we thought would work best the but I'm sorry am and and so that's that's fine but in hindsight we were thinking well if we started with what we're currently using which was system be based on Foundation which if you're not familiar with that's like bootstrap and and we can just kind of added and removed custom components as we went and then eventually added removed all the CSS using something like embassy assess models and so in hindsight that might something we we we're going to do we started on this new path of a new product and but just something to think about when you are assessing this you want developers to be able to migrate to new system as easily as possible so I might feel really great to build something from the ground up but if no one's is using it then it's not that exciting and so to start building we broke things into 2 main groups so we have our foundations in our components and so the foundations of the smallest most indivisible pieces a library so things like colors
spacing topography and fonts period and their components as
you can see a patterns are built from multiple foundational elements so for Tigger fire
we've got like our buttons menus and drop downs selection controls fields informs dialogs toasts excetera
so here's a list just of what we had to go and this would obviously very per company and varied depending on what kind of components you need in your acts and but can you can see the basic structure of how we broke this apart so here we've got this over to fly CSS the foundations and then the different components which are are just pieces I afloat thought about some
best practices of I naming
consistency so this came up early on when we are developing to get file you I do not something a modal a dialog is this an elevation are drop-shadow is that colored gray neutral so the answer to this questions isn't necessarily what's important it's just making sure your consistent so across the teams and or it's a lot of times developers and designers especially have different terms for the same concept so if designers points in the gray and developers recalling something neutral there's going to be confusion there with that design handoff from the development process so whatever is agreed on consistency is really important that for all the meaning the 2nd from we found pretty quickly and was the scalability of our naming system in our sizes so T-shirts sizing can be difficult but it does work well for certain projects over certain teams and but if you have something like that and you need something between small and medium sure they're small medium or medium small but does get a little bit confusing and there are only so many pieces you can go and so it's better to use a numeric scale or if you want to avoid having decimals of fractions and even anything in between those you can actually use the actual measurement or pixel sizes and then you don't have to really worry about scaling
yeah the place you want consistency is naming around classes and attributes so this is just an example of all of our 1 of our are typified button and so for all of our components we have a TF pretext for that so TF button TF toasty of dialog whatever it may be and and then our foundation styles we have just a few different classes river based setting so that's like our bond variables topography variables so you can see that TF color indigo 5 that's part of our base settings I am really utility classes so that the you prefix so that flight and sizing display positioning so you can see you with 50 and you vertical line all and we have our garnish classes so that's that's the GV fixed assets like cursor style font weight so G font bold the I'm and we actually also have an 0 prefect prefect for our object patterns and that's just our grid so such a OK so whatever you decide for your company is great on but you just seem to be consistent and everyone who is contributing to this system needs to be aware of that and keep consistency there too the other thing was
the 1 is semantic names and not descriptive names incidence using something like shiny button you wanna use something more standard like primary but and this probably will go hand in hand with designed so that helps with that consistency issue as well the I
phenomenon that let's build a component so here is the little snippet of 1 of our button components I'm and talk a little bit about how you would use all this stuff within your app the so each component is just the easy-to-use amber out as was the 1 used to get fly you you'd embarassed all to get fly CSS and Ambrose all with the amber to defy buttons so again this would be an act with all our foundation styles and just a bunch of buttons case and you have access to those throughout that any act at CSS file you can import whichever pieces from that typify CSS module that you need so tell review settings furnishes except I'm and then you can use those throughout your direct rap so how these components work together and
so there you gotta M wrap and then you're really just importing all this stuff so you got your CSS and then again whatever the components that you're gonna means in this case of your buttons check boxes toast those are all an accessible now inside your app is they're all the same major version arms of all work together i it so then how do components actually
work together with all other APs and decide what's little insane and so we're going step through it and over a little bit the solid lines are your direct dependencies I'm and I'm actually going to focus on the dotted lines here who the pure dependencies and I mentioned that a little bit earlier as 1 of the issues that so take apply CSS is delivering the core styles to all your app so that's where they get the foundation cells from but the components also depend on to CSS for their internal sales so that's where the dependency it's I'm and it's it's a pure dependency so when the components and the CSS are installed in the parent up and there's installed alongside each other so what that means is that the components are going inherit the to get fly CSS from whatever version apparent that is using them and that's why there needs to be that major version agreement so as to get fly CSS is that written 3 but buttons only at version 2 when they both get installed together alongside each other it's going to inherit from that higher version and things could break itself so we have that major version agreement this is spying on as long as that's communicated and everyone's aware that I
but period this is in general why are they bad if and or if you can avoid them it's a good idea so everything is coupled there's really no opted for certain updates it's really hard to bump versions of both for the consuming AP and then for the designed system because literally if 1 thing bumps up everything else has to go to
so we know that a little bit more so let's say let's say we want upgrade toast version 3 there was a major upgrade we operated toes so any act that's using toasts now means that typify CSS also to be at that but the version 3 so are always induces to apply CSS we upgraded toast so take apply CSS now also has to be upgraded to version 3 so since so that'll work for the toast that's that are consuming mitosis and but let's say then that these other acts also are using to defy CSS that upgraded version has to be the same the same version as all these other components so what that looks like is basically this whole bottom half of the graph all had to be upgraded just because we made an upgrade to toast a major a major upgrade and so that's where the whole design system actually has to be released in that new versions that makes things a lot more complicated and so
a way to avoid this I'm using the underlines the soul but a crazy mass but the the No . otherwise the non-worker dependencies so if you can actually pre-build your components with the foundations cells they didn't you can take out the care dependency so in this case each component is actually rely on a specific version of CSS for their internals and you can then precompiled this published time deliver a CSS reset style sheet for the component internals themselves and then it we've we've decoupled the dependency and you take out that that pure dependency entirely and
another thing with best practices probably engineers least favorite part of this on but it's the release process and it's a really important part of the system to keep your system managed and maintained in used I'm so documentation we need good documentation on how to use things is something of an upgraded different versions of the codes that that's all that stuff but communications strategies so different companies communicate that changes in new features and upgrades in different ways some people send out a newsletter and some people have monthly meetings about this some people have a slight channel whatever works best company is great but just make sure that there is a lot of communication around new things and changes and support so in an ideal world there is a new feature there's an upgrade and everything works super easily there no issues no bugs everyone's on board with the new thing but we know that doesn't always happen so it's really important to have support for teams who do run into issues or find different bugs and so that they will want to continue using your system I and then
is inside of a couple things that are ahead for to get flight like I am and
something is a kind of think about is if you start building design systems are for yourself so we currently don't have a mobile patterns as part of a pattern library and and so ideally at some point we would have all this stuff together so I less engineers front engineers have 1 place to go designers were everything is on altogether and through work on removing any carrier tendencies that we do have in our system the other thing that we will be moving toward so we currently use icon thoughts which icons on pretty cool and the vectors and you can change a CSS on the fly but let's say you want to make that out so that star icon gradient inside and go you can't do that OK so I want I need those fancy colors anyway but let's say I want hover over something images part of that I can move you can't do that either so there are 2 limitations with icons fonts and so we've already had discussions about moving this way in the future going toward SPG so they're pretty amazing on and as you can see so as the years have custom styling CSS animations CSS interactions there also scalable and resolution independent and you have solid browser support and they're they're basically accessible by default has a really just marker so if you're already on the STG train then on it's a good place to because they allow you for and a lot of a lot of things I fonts another image FIL sizes don't allow I'm away so that that brings us closer to the end of my talk and i want to leave you with just a few things as you go into the rest of the summer conference with X 2 half days and basically the the goals that you have here for wider building was designed system on a main thing here is we want to enable usability a mentioned this before if you're building a system that's that's hard to use are hard to migrate to then developers and teams are we gonna only user and it's going to die out and we wanted OK components that have that are easy to upgrade and not break all the different maps the and then alternately you really want to make the system a party or culture so this enables our long-term adoption maintenance in use and a lot of companies and actions and that I talked to they made it so much a part of the culture that there actually is now designated team that is focused on creating and maintaining and upgrading these features and support around that and so that's how you know you've really really me that when you have that team and that is a party put company's culture and that's it the
questions yeah my
my
Physikalisches System
Maßstab
Physikalisches System
Subtraktion
Implementierung
Zellularer Automat
Term
Code
Computeranimation
Homepage
Physikalisches System
Code
Mustersprache
Programmbibliothek
Zusammenhängender Graph
Softwareentwickler
Widerspruchsfreiheit
Gammafunktion
App <Programm>
Videospiel
Strömungsrichtung
Ähnlichkeitsgeometrie
Physikalisches System
Biprodukt
Kontextbezogenes System
Widerspruchsfreiheit
Arithmetisches Mittel
Betrag <Mathematik>
Telekommunikation
Umsetzung <Informatik>
Prozess <Physik>
Iteration
Element <Mathematik>
Gesetz <Physik>
Computeranimation
Hydrostatik
Physikalisches System
Benutzerbeteiligung
Mustersprache
Programmbibliothek
Elektronischer Programmführer
Softwareentwickler
Hilfesystem
Gammafunktion
Prozess <Informatik>
Elektronischer Programmführer
Gebäude <Mathematik>
Strömungsrichtung
Telekommunikation
Physikalisches System
Biprodukt
Mustersprache
Kantenfärbung
Programmbibliothek
Schlüsselverwaltung
Instantiierung
Kollaboration <Informatik>
Quader
Zusammenhängender Graph
Glättung
Code
Telekommunikation
Maßstab
Projektive Ebene
Strömungsrichtung
Physikalisches System
Gammafunktion
Telekommunikation
Subtraktion
Prozess <Physik>
Punkt
Selbst organisierendes System
Versionsverwaltung
Implementierung
Synchronisierung
Whiteboard
Code
Computeranimation
Eins
Datenmanagement
Regulärer Graph
Prozess <Informatik>
Mustersprache
Programmbibliothek
Umkehrung <Mathematik>
Zusammenhängender Graph
Biprodukt
Softwareentwickler
Softwaretest
Synchronisierung
Gebäude <Mathematik>
Güte der Anpassung
Strömungsrichtung
Quellcode
Physikalisches System
Bitrate
Biprodukt
Mereologie
Versionsverwaltung
Repository <Informatik>
Telekommunikation
Bit
Distributionenraum
Migration <Informatik>
Mathematisierung
Zusammenhängender Graph
Softwareentwickler
Modul
Peer-to-Peer-Netz
Leistung <Physik>
Telekommunikation
Distributionstheorie
Bit
Synchronisierung
Gebäude <Mathematik>
Versionsverwaltung
Telekommunikation
Ideal <Mathematik>
Physikalisches System
Biprodukt
Synchronisierung
Computeranimation
Programmbibliothek
Biprodukt
Softwareentwickler
Peer-to-Peer-Netz
Inklusion <Mathematik>
Resultante
App <Programm>
Subtraktion
Prozess <Physik>
Güte der Anpassung
Implementierung
Physikalisches System
Elektronische Publikation
Biprodukt
Computeranimation
Datenmanagement
Regulärer Graph
Migration <Informatik>
Mereologie
Mustersprache
Programmbibliothek
Projektive Ebene
Zusammenhängender Graph
Softwareentwickler
Widerspruchsfreiheit
Standardabweichung
Bit
Bootstrap-Aggregation
Physikalisches System
Migration <Informatik>
Frequenz
Eins
Service provider
Komponente <Software>
Bildschirmmaske
Informationsmodellierung
Iteration
Font
Migration <Informatik>
Programmbibliothek
Zusammenhängender Graph
Projektive Ebene
Kantenfärbung
Softwareentwickler
Tabelle <Informatik>
Chipkarte
Tropfen
Mailing-Liste
Gradient
Element <Mathematik>
E-Mail
Computeranimation
Komponente <Software>
Mailing-Liste
Bildschirmmaske
Datenfeld
Trennschärfe <Statistik>
Mustersprache
Zusammenhängender Graph
Bildschirmsymbol
Booten
Modelltheorie
Tropfen
Datenstruktur
Gammafunktion
Bruchrechnung
Prozess <Physik>
Pixel
Punkt
Physikalisches System
Term
Widerspruchsfreiheit
Modallogik
Dezimalsystem
Skalierbarkeit
Emulation
Projektive Ebene
Softwareentwickler
Einflussgröße
Widerspruchsfreiheit
Subtraktion
Gewicht <Mathematik>
Ortsoperator
Datensichtgerät
Social Engineering <Sicherheit>
Klasse <Mathematik>
Softwarewerkzeug
Physikalisches System
Objektklasse
Inzidenzalgebra
Computeranimation
Objekt <Kategorie>
Deskriptive Statistik
Variable
Font
Menge
Mustersprache
Mereologie
Zusammenhängender Graph
Kantenfärbung
Gerade
Widerspruchsfreiheit
Cursor
Unternehmensarchitektur
App <Programm>
Bit
Quader
Menge
Installation <Informatik>
Versionsverwaltung
Zusammenhängender Graph
Elektronische Publikation
Modul
App <Programm>
Bit
Pauli-Prinzip
Versionsverwaltung
Zellularer Automat
Physikalisches System
Frequenz
Computeranimation
Entscheidungstheorie
Richtung
Arithmetische Folge
Vererbungshierarchie
Speicherabzug
Zusammenhängender Graph
Versionsverwaltung
Gerade
Peer-to-Peer-Netz
Umwandlungsenthalpie
Bit
Emulation
Graph
Minimum
Versionsverwaltung
Zellularer Automat
Ruhmasse
Zusammenhängender Graph
Physikalisches System
Weltformel
Telekommunikation
Subtraktion
Prozess <Physik>
Prozess <Informatik>
Mathematisierung
Versionsverwaltung
Telekommunikation
Physikalisches System
Newsletter
Computeranimation
Strategisches Spiel
Programmfehler
Verbandstheorie
Mereologie
Strategisches Spiel
Codierung
Stereometrie
Wellenpaket
Punkt
Browser
Gruppenoperation
Interaktives Fernsehen
Gradient
Physikalisches System
Font
Code
Mustersprache
Programmbibliothek
Inverser Limes
Zusammenhängender Graph
Softwareentwickler
Default
Bildgebendes Verfahren
Cross-site scripting
URL
Freier Ladungsträger
Benutzerfreundlichkeit
Stochastische Abhängigkeit
Gebäude <Mathematik>
Mobiles Internet
Physikalisches System
Vektorraum
Bildschirmsymbol
Mapping <Computergraphik>
Softwarewartung
Verschlingung
Mereologie
Bildschirmsymbol
Kantenfärbung
Innerer Punkt

Metadaten

Formale Metadaten

Titel A Design System at Scale
Serientitel Ember Conf 2017
Autor Roman, Melissa
Lizenz CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben.
DOI 10.5446/33653
Herausgeber Confreaks, LLC
Erscheinungsjahr 2017
Sprache Englisch

Inhaltliche Metadaten

Fachgebiet Informatik

Ähnliche Filme

Loading...
Feedback