Design Systems London Online #1

hello everybody and uh welcome to dsl online um we are very excited to be here today uh it's been a while since we were here um i think it's actually the conference last back in 2019. hello everybody uh sorry i had a bit of a mute issue there so i'll start again let's try again um so as i said we haven't been live since 2019 conference we were actually allowed to be in person and see people um if you were there and you're back very excited to have you back for anybody who wasn't there but you are here now very excited to have you here as well welcome everybody this is going to be great um my name is luis and i am your host for this evening i'm head of product design at waldi meaning that i'm working very closely with designers and the developer and team um building and delivering all sorts of digital stuff um techy things which i'm sure all of you are very familiar with so i worked on quite a few projects over the last few years in relation to design systems uh and i've also hosted a q a session during the last design system london conference so we are in a very good company here today i've got some fantastic speakers with me i have prepared some amazing uh talks and this is one of the really bonuses of my role is that i get to be part of this community events part of meetups webinars conferences and internal learning launches etc so fantastic as you can probably understand very excited to be here and as i said we got some awesome people waiting to give us some fantastic talks the topics today everything from you don't need to solve a problem twice you just need a design system how the industry went from what's a design system to yes we have a few of those uh evolution of design system kpis and design systems from consultant to client to me it sounds like we all gonna learn a lot and i think there's gonna be some fantastic takeaways this evening before we get started i wanted to do some quick logistics uh we wouldn't be a real online event unless we did that first of all i just want to briefly mention the code of conduct uh which you should be able to find on the youtube page it's pretty standard stuff just keep your language clean be kind to each other and don't share anything inappropriate and uh just kind of general good life advice i guess uh for those of you who have not explored the web path or the sort of youtube platform yet i'm sure you're very familiar with it but there is a section for conversation you might be asked to create a quick account to be able to comment and ask questions but that's absolutely fine if you want to ask questions regarding the talks to the speakers we actually have a slido uh that we have prepared a slider link which you should also be able to find uh just on the youtube page there um we're gonna have a q a session at the end uh for most speakers so fire away any questions you might have and of course we need to mention social media because otherwise people will know that we exist so make sure that you tweet and uh anything that you your favorite learnings quotes uh anything at all use the hashtags hashtag dsl and hashtag design system if you're not already following us make sure that you do on at dsl.conf which we set up for the conference but it works wonderfully for this one as well just a quick reminder of who we are and you would have thought maybe all of you know but considering you're all here but just a quick reminder so dsl design system london we used to be known as a digital product london um but after our big conference we changed name to sort of uh design system london because that's mainly what we're focusing on it doesn't mean that we're only focusing on design systems we are exploring a lot of different topics as well and we welcome speakers with different product and development topics we try to gather product minds to explore and explain and discuss challenging concepts within product design and engineering culture and as i said over the last sort of probably a couple of years we've been focusing mainly on the sun systems if you want to bring your organization closer to our community and maybe you want to host an event in the future once we are allowed to be in person again or maybe you want to speak uh please let us know for anyone who feels that they are ready to speak we welcome new speakers as well as more seasoned speakers we will be sharing information about how you can apply to talk in the future um we welcome speakers from anywhere in the world for our online events of course now we're gonna have a quick word from our sponsors uh so i'm very happy to say that design system london events is organized and supported by yld uh so it'd be a good time to let somebody from wild in i believe that we have maria luis on the line uh you would like to say some quick words uh yeah hi uh everyone and uh thank you luigi for that intro as uh louis said i'm maria i'm part of the talent and people team from yld this event sponsor um just wanted to give you all a very brief introduction on who we are before our awesome talks so yld is a basically a software and a software engineering and product design consultancy we work with quite a big range of diverse clients on different part projects while our goal is to help them improve that digital and technical skills we are able to do this thanks to our collaborative teams of software engineering product design qa and platform our teams are always focused on finding the most creative and new ways possible to help our clients while sharing their knowledge that's why you also can see us sponsoring events such as this one we're also always looking for software engineers and actually at the moment we are also looking to hire both platform engineers and ux ui product designers to integrate our permanent teams regarding the product design role as it seems fit for this event i can tell you that this person can be either london or portugal based but you can besides speaking with me directly through here or via linkedin you can always see these roles directly on our linkedin page on or on our website and even if you're just curious and want to have a chat i'm completely available you can you're feel you can feel free to reach me out on any of these platforms um just a bit of a side note when you go to our website to see the product designer role don't mind the title we're not looking for contractors but we're looking for someone to fill in our perm roles um and i think yeah that's that's it for me luis thank you very much um that's fantastic so yes if you are looking for a new role definitely reach out um one thing we want to do before we move on to our speakers i just wanted to check a little bit because i'm looking in the chat here and it's interesting to see people where they're from so we have some people from the sun system france so hello from paris uh thank you for joining a welcome and welcome uh the sun system advocate gina amazing to see you here fantastic uh people want to tell us where you're from personally i'm based in london uh i know that people on this call or sorry our speakers are sort of based across various places of uk uh but last time when we did have an online event we were talking react at that time we had people from all over the world so don't be shy uh sharing the chats where in the world you're based just so we get an idea because it's always exciting to see now um i think it's time for us to meet our speakers as i said there are some fabulous people with some fantastic presentations so i want to welcome in marta danny ellis james and emily so all of a sudden we're gonna have everybody on the call hello belly hello everyone else there we go alice is here martha's here emily here and james thank you everybody for joining me so before we start with it we'll be um talks themselves i just wanted to give you guys an opportunity to just say hi to all uh our listeners and to tell us a little bit about how you feeling right now where are you based what are you doing what are you working on anything excitement exciting for the holiday season i see that we got some uh holiday festive spirit representation so i'm gonna start with you benny how are you doing today i'm doing good thank you uh i yeah december uh is the time for holiday spirit of whatever kind i never pass up an opportunity to dress up so hi everyone um i'm seeing that some more christmas jumpers appeared as well fantastic excellent thank you benny yes we do have a christmas jumper let's move over to the christmas jumper emily how are you doing hi i'm good i feel like i'm really revealing in a secret about myself i'm obsessed with louis theroux dashing through the snow classic christmas jumper yes i'm really well thank you fantastic and where are you based emily so i'm based in manchester and i'm a product designer for zega fantastic brilliant thank you for being here um you're doing a shared uh presentation with james so i think this big good between say hi to james hello and where are you face james uh so i want to say i'm london-based but that's that's actually no longer the case i'm currently based in uh in lovely bath summerset fantastic awesome and what are you working on at the moment uh well i mean in terms of what i've been working on most recently you'll hear about it kind of imminently in my talk um so i won't i won't spoil it yet but i can confirm it involves establishing a design system okay i'll i'll try to contain my excitement and look forward to that that's going to be awesome um then next one to say hello to i think it's alice hello ellis come in hey how are you very well how are you doing well good thank you yeah we had our um team christmas party last night so you know unfortunate timing i think but um maybe most unfortunate timing maybe was perfect timing i mean you know let's find out if you're not allowed any more christmas parties now and where are you based i'm based in london um in southwest london okay fantastic excellent and uh last but not least uh martha how are you doing hey i'm doing good and you yeah great thank you um where are you by smarter [Music] what are you looking forward to the festive season what are you up to taking a week to relax with my family do you know what i can share i i i sense that the same for me can't wait for that yeah brilliant um so now you have all meta speakers uh one thing that i did sort of ask all of you to think about beforehand is i wanted to talk a little bit about anyone who joined us on react to recognize this question but basically i think that there's been obviously there's been a lot of things happening over the last two years now and i know we keep on saying yeah year and a half but it's coming up to two years now and um some of that stuff has been positive for some people i think we need to try to find some kind of positive things from it and for me one thing that i have discovered personally over the last sort of year and a half two years is that i can do my job from uh remotely um this is probably something that maybe if we have an engineers in the audience they think like oh yeah we've always been able to do that but as somebody who works in product and design i think up to now i sort of had it in my head that that maybe that was harder or maybe it wasn't less easy or maybe it was almost impossible but that has definitely changed that mindset but it's uh i can definitely do my job uh remotely and that has been fantastic i also feel like working for a company where i have offices in different places it actually feels like we all now equally far from each other equally close to each other no matter what office you're working in because we all in the same sort of remote space and the last thing i would say as well is that someone who's looking to hire people just being able to broaden that pool of people to be able to hire people from everywhere has been fantastic so that was my positive takeaways from the period so i want to hear a little bit about our speakers um so i'm gonna go back to you benny what is there anything that happened over the last year and a half two years that you sort of think actually maybe there's a civil lighting i mean i was quite lucky i uh met my future husband as ego so he's actually over there at this currently getting really in the face so yeah i can't complain very much well that's definitely a silver i think thank you um but also yeah uh i do like how lockdown times democratized um and leveled the playing field how suddenly we found ourselves all at home like you could be the ceo you could be the vp of product or you could be the new junior designers we we all knew where we were the night before and we were home watching tv probably so there is there is something there that i actually quite enjoyed yeah absolutely i think that's sort of leveling that play phil is absolutely true it's equal for everybody excellent thank you buddy uh james they're going over to you randomly what what what has what can you think of i mean for me i think it's the just broadly the kind of flexibility of remote working has been really liberating which yeah sounds a bit counterintuitive to say anything's been liberating over the last 18 months but like i've been able to move out of london move closer to my parents get a job you know get a dog and uh and still keep a job that i'm happy in which wouldn't have actually really been collectively possible before so um yeah i think just that that kind of choice and flexibility is um yeah something that i don't think i could ever go back from to be honest fantastic brilliant and i mean getting a dog can't be anything wrong with that that just sounds fabulous um alice what can you think of yeah i mean i was gonna say very similar to what james said to be honest you know i'm probably a little bit behind james in the whole moving out of london uh thing but you know my girlfriend and i would love to move to bristol in the west west of england we'd love to get a dog at some point as well so um it's you know removing the stress of having to find a new job if you if you want to move i think is a big plus excellent absolutely definitely and uh martha for you yeah for me i joined a new company um so uh i i will i asked since i'm already working from home why not open to another possibilities since before i was always looking for companies that had an office here in the city so i've joined single starting and it has been an amazing experience so far brilliant absolutely so it's like in the same way that we are looking for people everywhere we can also look for work everywhere brilliant yeah and last but not least emily similar sentiment from me as well really i think just from saving time of not having to commute gave me a bit of time time to really assess what i wanted from my career going forward and then opened up quite a lot of opportunities so similar to mata i joined ziego just over six months ago so during the pandemic i'm based in manchester and they're based in london so without i think the pandemic and everyone switching to remote working that possibility would have been potentially still possible but much further away than than now so yeah i feel quite fortunate really fantastic okay so the whole thing i've been working remote turns out that maybe it's not such a terrible idea after all for designers so that's good to hear and obviously we have an engineer as well which i'm excited that we have both engineers and designers and product people it's all very good um okay then that case we have now got to know a little bit more about the speakers uh we are going to move in to the talks themselves so thank you speakers for now uh i'll call you back in when we are ready and before we get going i'm just taking a quick look at the chat and it is pretty cool because we have hello from portugal we have hello from hampshire in the uk from france again london obviously quite a lot from london manchester california which i think is pretty cool somebody else from bath getting a buff getting a woohoo hey from stockholm sweden hey hey i'm actually swedish so i'm gonna say hey hey back um so this is awesome and i see also that we have some of our previous speakers from our conference on the call as well who are ready to learn uh i see that somebody's got a set up on the big tv sitting back with a cup of tea and ready to learn and i think that's absolutely fantastic sean um so for short and everybody else who are ready to learn let's get on with our speakers and let's call our first speaker in and we are going to hear from martha first hello welcome back martha i'm gonna hand over to you the digital stage is all yours go ahead thank you okay i'm now sharing my screams screen so i'm assuming you can see it um so okay perfect thanks um so hi everyone i'm marta i'm a software engineer at single store and today my my talk is called you don't need to solve problems twice you need a design system okay so the plan for today is to get started with a simple definition of a design system followed by some tools um then some focus on perks and process and lastly i'm going to talk a little bit about how to implement a library with shared resources okay so what is the design system um the design system doesn't have a very strict definition so i think according to your background you might define it differently for instance designers may define the design system as ui standards or as a style guide while developers can define it like all the ui specs or the assets for the the project but at the end of the day a design system is documentation for everybody in the team for designers for developers for product managers to everyone there are a lot of tools that help us dealing with design systems and i think i can split the tools into two big groups the first one are the tools used for planning so when we need to to plan a design system we usually use this kind of tools we have sketch we have envision figma i think these are the the most known ones um and these tools are mostly prototyping tools so they they are editors based on factor graphics and they allow us to plan and to do some mock-ups of the application and they work as a static documentation on the other hand for for implementation we have storybook beat or zeppelin and this tools are mainly code based that's why they are used by the by developers and they they are used to to test components in isolation so they don't depend um on the page they are built into or on the on the application and they allow us to to test the component um and interact with it change its state and that's why these kind of tools produce dynamic documentation okay and there's a lot of perks and process um for you to to have a design system uh the first one is to solve problems just once um if you implement your solution in just one place you don't need to be duplicating the code every time you need to solve the same problem so you can reuse your solution and have just one well implemented solution and this this allows your product to be very consistent so i think everyone has been in that in this situation um that you have components that should be equal but they are slightly different you have like a button with a larger margin in one page and then then in the other page so if you are using the same component in every page um they that the components should look equal another thing is the connection so if you have a library for your design system everything will be connected so this can either be good or bad and it's good if you actually want to change everything this is very useful for changing skimmer colors or font family or anything across the applications but on the other hand if you change anything you have to be aware that it will change everywhere so this you have to be cautious with that another perk is to have just a single source of truth um having this design system as a single source of truth improve how the team communicates how the team shares information so design system is above all a shared language so we know that the communication between designers and developers is not always seamless so having a single source of truth definitely helps this um reviews are also easier because designers just need to review the component in one place they don't need to review it everywhere where it is implemented um so it's much more easier for them they just review the component once and trust the component will look like in everywhere so for developers as well um they know that they are using the the right and the most updated version so they don't fall in a situation of implementing an outdated version or of not knowing uh the the specs and having to just like the designer to ask so there are a lot of perks here okay the process of developing a design system um you you need to focus you need to to give the importance um the the design system deserves you need to allocate time and resources because the design system is itself a project you need to to bury that in mind and because you you you will always need to iterate redesign and uh the the the process will be an ongoing process and it actually never ends don't expect the design system to be finished from one day to another because it really needs to to grow along your projects and along your company so how to implement a library which are resources so if you want a design system um to be shared across projects the easier way is to have a dedicated project or library for it and the perfect way to to test is to use npm link npm link creates a sim link in a design system and you can then link your project to it so the project will no longer look for the package online it will consume it locally so you can test whichever changes you you are making you can test how the design system will look in the real application so you have a real-time feedback of the changes you're making so this is really useful and i'm going to show you i have here a small screen recording i'm not brave enough to do real-life demos so okay i have here an application and a real simple design system with the button so if i go back to my terminal and i run npm link on the design system it is creating the same link and if i uh link the design system to my project i can see that now the project will not search for the packet online so if i go back to my my project i can now use my fancy button from the design system and my application is updated so we can now see the button if i go to my design system and change the color of the button to a bright red and the design system will change real time as we are used to yeah okay but at the same time my application uh is already uh mirroring the the changes that were made so this is really good to test your changes and to not have surprises when you are updating your package um so yeah give it a try okay i i want to to give you some feedback um at single star we have two products that share uh the same design system that we have uh in a in a common library and we not only have our design system components but we also have entire features and this really works for us it allows it allows us to to reuse code and to not have everything duplicated it it is also very useful to the book so we have everything in that library okay so today i want you to take these ideas with you so after all a design system is documentation um implementing solutions in one place and having just one source of truth have a lot of perks for you and for your team um implementing a design system is a continuous process so it should grow along your projects and your company and implementing a library with share resources it is it is really useful and you can test with npm link to avoid surprises when upgrading to the latest version so this talk was based on an article that i wrote quite a long ago so if you found it interesting um feel free to check my medium profile and to give me some feedback about the article i'm also on the usual social networks twitter linkedin so feel free to to reach out to me and guess what we're hiring at single store so if you want to work for a very cool and fast growing database feel free to go check out our website or reach out directly to me so thanks everyone thanks for having me and i'm i'm glad to to ask your questions fantastic thank you so much martha um thank you very interesting um for those of you who do have questions to martha please use the slido deck that is pinned we're going to come back to that in the q a in a bit uh after we have completed all the talks um before we move on thank you again martha before we move on with the next speaker i'm just gonna revisit the chat and i am going to answer one question that we have um so what somebody was asking about uh youtube the chat is for subscribers only so there is no cost involved is basically just subscribing to our channel so you just need to you just need to hit subscribe to the channel and then you should be able to ask or chat away as you please um i also thought it would be nice to say that we have somebody from giorgiana slovenia who has also said hi in the chat which i think is fabulous i think it might be our first slovenian attendee from the course that we had previously with the other events that we've done uh canada hello canada uh brilliant and we also have somebody who is french but normally based in london but currently in the south of portugal so we do have people from everywhere i just wanted to highlight that because that's what i really love about these online events okay so now we are going to have our second speaker coming in and that's going to be benny and benny before hello hey oh look at that that i am every time i see your skin i just love the christmas hat i just love it it's like festive season galon um so benny i know for a fact that you have a different thing that you have to rush off to so you might not be able to attend the q a so i'm gonna make an exception for benny today uh after her talk we're gonna give a little bit of time for one or two questions directed directly at benny so you do get a chance as well but enough about that now uh handing over to you the digital stage is yours but you take it away thank you okay let me see how to do this without screwing it up i'm gonna share my screen i'm gonna go into presentation mode and are you seeing my presentation yes we are indeed thank you amazing hello hello hello everyone um okay first things first good question who am i i am hi i'm benny um i've been a designer for many many years touching lots of different disciplines no no reason to get into it um i'm currently the director of product designer peers on education but i have no past probation yet so if you feel like sending me good vibes feel free i am the things that i'm mostly known for are having bunnies and how much i love talking about bunnies and showing them on camera doing meetings but you're not in luck today because they're sleeping i also spent most of locked down playing with my hair color this was very amusing for my colleagues or horse i'm told and third i'm autistic and i love talking about that too um as to why i'm here a few years ago i built a design system for the company i was working for college um and i talked about it at a dsl um meetup in new york was fun um that's because it was a fairly successful story as in um i was able to start it get it integrated in most of my company's products um as well as creating a team around it that even kept it going after i left so pat myself on the back um [Music] after that i went to work for a startup where i witnessed the design system desperately trying to come to life over the course of almost two years uh you will hear about that later because it looks like it's finally happening um but i learned a lot from seeing those struggles as well and now i'm working in a massive corporation that has like 15 design systems lying around um for very understandable reasons which i will also cover so what i'm doing now is i'm having a moment of reflection i especially as recently something happened that i couldn't quite get out of my head i was talking to a contractor designer who had been in the same company for quite a while and he said something like this he said first thing when i joined the project i saw that there wasn't a design system so i created one now on the surface this seems okay and i'm sure that there's a lot more context to this than what i got from that one conversation however it hit something sore uh and i couldn't quite quite get it out of my head so what i'm going to do in this talk is take you on the journey that my brain took from here let's start so he said there wasn't a design system now that's that's very possible many places don't have design systems yet uh like small companies or companies where design of content engineering came in late it wasn't a priority that makes a lot of sense maybe not a company with an extensive digital offering that has been around for many many years and has many many designers maybe they will at least have a clickball library or something um it didn't make a lot of sense to me like what exactly did they look for and who did they ask but that's not what was really bugging me they also said i created one now yeah like i know i'm preaching to the choir here but just for the sake of clarity as we've just seen a design system is not exactly something that you just create by yourself overnight i stole this from audrey hack's article on the ux collective because they are much better uh much better uh illustrator than i am um a design system as as we've seen comes from the alignment of a ton of elements multiple disciplines that come together in a beautiful collection of components and patterns that exist both as design and in production ready code back to the story i did some digging and i realized that what that contractor actually meant was that they were designing components and trying to give those components to developers um they were also not having that much luck because lo and behold the developers already had their own library of components and weren't interested in starting from scratch i i did feel for them at that point so okay all of that clarified there was still something that i couldn't quite shake off i said first thing when i joined the project i'm taking this very literally for the purpose of making a point um let's think of aws aws is an amazing supporting tool that has enabled millions of services to scale providing an alternative to costly and clunky physical setups um it's it's it's incredible it's great from the perspective of the customer though it doesn't really matter if you use aws or mac meaning an office or a a hamster on a wheel that was really really really fast from their perspective what is important is that it works similarly when it comes to design um customers don't really know if the service they're using is built on top of a very solid reaper of design components that are reusable and scalable or if there's something that manually has to go and change the hex colors of a button in every single page as long as it works this is where i go a little bit controversial and someone's gonna play me on linkedin sometimes the services don't even have to look that consistent throughout the journey if you take a major product like ebay depending on which part of the site you're on the interface is slightly different just similar enough not to distract but it's clearly coming from different uh sets of components and it's kind of not a problem it's kind of enough it's okay it's not ideal but it's okay it works for them it works well enough for them what i'm trying to stress here is that we need to use critical thinking be strategic and set the right expectations what is it that we want to achieve what are we optimizing for what problems are you trying to solve and start solving that and see where you get to keep in mind all you've learned about how fantastically how fantastic design systems can be when they're perfectly structured and they have a great governance going on but that might be not what you need right now another moment of reflection i do like my stormtroopers apologies um i started building the design system advantage in uh at the end of 2017. i was very fresh-faced and bright-eyed and i knew nothing about anything this was about the time where airbnb was really pumping the hype about design and design coming from companies that produce something else but they they really care about the experience um so it was around that time but it was before um they were really the talk of the town design systems um you didn't get all of these articles about everything you need to know uh how to sell it to stakeholders design system one-on-ones that means that the job i had to do at the time was a little bit more difficult because i had less guidance but when i look at the industry today i started realizing that that was a bit of an advantage for me really because i had to do extensive research just to find out what the hell a design system even was and how and if it was going to help me i also had to go and talk to engineers all around the company um having meaningful discussions and debates around pros and cons and we ended up very much learning together um figuring out the problems together rather than argue over which guideline or philosophy was the right one to follow basically we made a lot of mistakes and adjusted and the pressure was low because we were all we were all in tune it looked something like this so i worked on components that were made up from existing interfaces then i built a proof of concept in html css worked with some local engineers to test upon a product and when that was successful we went on to scaling and that meant establishing governance because we involved then other products and other engineering teams and that's kind of where it started becoming a a a really like evolving loop so we would scale more meet more engineers and stop reassess the governance scale more again and so on and so forth this basically means that we were allowed to have a period of infancy and then grow until we were a fully fully mature internal product building a design system in today's world however means that most designers and front-end engineers we will at least have read articles about the importance of governance the importance of of getting buy-in from the business beforehand which should be good but the fact that there is such an awareness about them does mean that there's a lot of talk that tends to be done up front which again should be good but many decisions end up being taken on paper doing desk research going back and forth until everyone who has to dish out whatever amount of resource for this uh feels comfortable about the road map and the planning and the gains and and you end up you can end up in this situation where you basically laid out a year of work before you actually do anything and this conversation can really go on and on and on it can easily be months before everyone is on the same page enough to actually start building something and by the time you get to the first integration it ends up being so heavily scrutinized that even if it's perfectly successful you likely have to go back and talk to all of the people again and adjust the desk planning to what actually happened in real life and ultimately make everyone feel comfortable about the project again this this happens with many projects it's not it's not special of design system but it is something where we might fall into unaware it happens because all of the upfront planning can give a full sense of security a false impression that basically you can get mature from the get-go and then it's a surprise when you still have to go through the infancy and the opportunity air space also it can undermine the confidence in the whole project because expectation doesn't mean meet reality with some luck eventually you can get all of these results and get onto scaling and maintaining but real life situations are very complex and some expectations need to be reset as we go i'll give you an example so let's say the team a has a big project coming they decide to do it right we properly laid out components from the get-go perfect they involve their engineers who build react components and it's the start of a beautiful friendship but in every company communication has gaps so it turns out that team b started building their product using adapted ant design or something because it's ready and they're in a rush maybe it's an engineering team working on a side project that has less design involvement maybe they don't have that type of research so why not there's nothing wrong with that but by the time team a is ready to extend their mature design system to the rest of the company's product that would be a massive rewrite for team b who has their own roadmap to work on um and let's throw another curveball the company decides to buy a new off-the-shelf service which turns out to be based on material design and built in angular now the organized and efficient view is thinking how do we conglomerate everything into a single system and a single source of truth and the answer to that might be it might not be worth it it might not be worth the effort team a should keep going because they're doing a great job but team b in this circumstances in this environment is also doing good it's just that things are not that black and white so i'm coming to a close here um what i want to clarify is that design systems are an incredible tool that enables faster and more consistent design and development of digital products i am still a major advocate um of them and i believe that a lot of good has come from democratizing them and spreading the good work on how to get that out there however like any other tool it depends how and when you use it it depends on the circumstances and it depends on the need it's very much a journey and you have to get there you can't start from the end and you can't aim for perfection from the get-go it also won't always be comfortable because there will be feedback you don't like there will be disagreements you might not achieve exactly what you set out to get this is the same in every project it's really important to be honest and keep a broader definition of success because there isn't a one size fits all um maybe you will have to adapt an off-the-shelf design system because that's just more viable for your company does that mean failure no that's also a success it might even be preferable because then you won't lay awake at night wondering if the micro interaction for the accordion will work in internet explorer 10 the one real takeaway that i have here is just an invitation to be sensible work with people enjoy the journey and the learning don't try to anticipate the end adapt to what your project needs what your team needs what your company needs you don't have to do what everyone else does you have to do what's right for your situation and that is success and that's it for me i hope that there was something useful in there for you and then leave you with a festive puppy thank you very much i definitely think it was a lot of useful and who doesn't love a festive puppy that is so adorable thank you um so as i said before benny i know that you have to rush off in a minute but one question that i had um listening to you first of all i want to say i agree with you i think quite often what happens is that organizations or companies or teams they just assume that they have to have a design system because everybody else has to then they don't do enough foundational groundwork to actually realize are we even ready mature-wise do we have the capabilities do we even need one etc um but my question to you was that as somebody who has worked uh fast sort of starting a design system building one from the ground up joining a company that are in the process of trying to get theirs off the ground and now working in organization which is very large and has many many many design systems on the go do even though that those scenarios are quite different are there any sort of similarities that you see there that you have sort of can point out are quite important similarities i mean ultimately everyone has the same wishes and for example where i'm now i know that there is a desire to be more consistent and to have one system to rule them all it's just it's more a wish from the company's side rather than solving a customer problem the customers are okay or they have bigger problems um it's internally as a measure of efficiency it is still the wish to have one very very smooth design system experience no matter whether you're a small medium or large size one design system everybody just wants something simple that you can come in on board on that and and build on that and be creative in the rest of your time and i think we all know that the reality does not always look that simple yeah and so as i said because we have to let benny go i wanted to just quickly check if there was any questions that were directed directly at penny from her talk [Music] i want to give people an opportunity so if you have a question for benny this is your moment because she won't be joining us at the q a uh in the meantime um i guess one other thing um sort of the opposite of that of the similarities of these different ones what would you say are your biggest differences that you see being somebody that kind of starting something in something small and then coming in and joining something that's either halfway or there are so many going on i guess so one takeaway that i had as as a as a designer and as an ex design system manager was i had to learn a lot about the needs of a company and how nuanced they are because if you if you put me there three years ago i would have said stop everything we need to do this now um i had to let go of a lot of perfectionism um and uh get a little bit more scrappy it is uncomfortable it is it is uncomfortable but ultimately it's for the greater good and you can always you can always try to reach a good end but in incremental steps it's it's by learning to accept what's good enough for right now and yeah and i think as designers quite often we all struggle with that sort of pixel perfection it has to be perfect it has to be beautiful um okay uh let me see so sun silence instead we this is why we normally set the q a at the end because every time everyone has ever been in a live environment do you have any questions there isn't there is nothing so we do have one question which might be able to sort of just touch on quickly um how do you and we're going to come back to these questions to ask everyone else but this one i think i may be good so how do you find the best way to justify a design system to a very quarterly value or let's say value driven product team efficiency you want to be faster you you want to spend development time building what's actually important you don't want to have to spend it to redo things that could be automated absolutely that's a brilliant brilliant brilliant tip um okay well thank you so much benny for taking the time uh to speak to us uh that's awesome um before we move on with our next speakers i'm just gonna have another little quick gander at the chat um first of all i've seen in the deck actually sorry in the slido link that there are some questions and i'm excited to say i think some of those questions might be touched upon some of the upcoming talks and if they're not we're going to come back to them so please keep entering your questions in the uh slido link the fewer design system the bigger the community internally yes i think i can agree with that i think that sounds very sensible uh there are so betty mentioned a talk that she's done previously uh on our meetup that we had in new york so i can see that we have shared the link to that one so you should definitely check out that talk uh and we also have some fantastic festive emojis uh okay brilliant i am loving this chat it's great so now we're going to move on to our next speaker and that question i was just asking benny about how we can justify design systems on something which is very value driven that was about product teams but in a value-driven organization i can't feeling that maybe this talk will touch a little bit than that and this is alice coming in to speak to us now hello how are you not bad thank you excellent great i'm going to hand over to you the stage is all yours take it away thank you very much cool can you see my screen okay weekend indeed brilliant okay um hi everyone uh i'm alice i am a product manager for news uk so um we've been building a design system now for around two and a half years um you know we we have a number of different brands in the organization across new uk and news corp and yeah today my talk will be on the evolution of design system kpis so let's get going so what is newskit music is the design system um for news corp so we started off in summer 2019 so it's around two and a half years old now uh we have built a ui kit in figma and we have built up a library of rep components so i think we're sitting around 43 components at the moment which is great we also built a theming system so unlike a lot of other design systems they are generally tailored for just one brand so you know if you're looking at things like um bass web for example that is very focused on uber however uh we have loads of brands uh under news called umbrella so you know from the times the sun to talk sport dow jones factiva uh and you know dozens and dozens of brands so we've had to build a theming system in school our system as well which adds another string to the bow we've got a documentation site which is uh publicly available it's called newskit.newskit.com and we've been adopted by around five brands so far across news corp so that's a little bit of an intro into what our design system is so we set out a mission when we began building the design system two and a half years ago and we stuck to that mission and it's uh you know continues to be our mission today so our mission is to improve the process of product development and increase the pace of creation and innovation within digital teams so i found this uh quite nice definition of the kpi from clickfolio so product key performance performance indicators are metrics that measure your products performance they help you understand if the product is meeting its business goals and if the product strategy is working without kpis you end up guessing how your product is performing so i think it's really important to take a step back and realize that design systems are still products um you know having been in talks with uh you know other design system teams it's not too common to come across a product manager within a design system i don't think um so maybe we're slightly unique in this sense uh to have a product manager within our design system but they are still products um they have a a goal and they need to demonstrate value um to louie's point earlier on they're generally quite technical products so you know maybe it's harder to define a kpi for a design system than it might be for you know a web product uh for example like a shop or you know even some of our brands in news uk at the times for example um kpis help set the direction of travel for our design system so um by taking our time and really coming up with meaningful kpis what it means is that we can actually track how we're doing and not end up in a situation that benny mentioned where there are you know four or five six seven eight nine ten different design systems uh within one organization which is obviously uh it can be a it can be a problem uh and it's also really good feedback for for the design system so to have a core set of kpis you know that if you've made a release and you've released a new version and for whatever reason the kpis are kind of indicating that that version bump maybe was uh to the detriment of the users uh then you know that maybe that wasn't the right thing to do you can roll it back when you can adapt so taking on on a bit of the story uh a bit of the journey um in july 2019 uh we had a a massive restructure within news uk so um beforehand the sun the times and wireless group had their individual uh product teams looking after content looking after user data and looking after obviously the the front-end uis um and it was you know a lot of a lot of inefficiency a lot of waste was was being produced and that would obviously end up being technical debt so we decided that we needed a design system and the design system newskit was born um and you know from that we are now two and a half years later and we've come a really really long way so you can see here on the left hand side we've got the the product development life cycle which is i think quite a nice diagram and i'd say newskit now is that we are probably just past or around the introduction stage of our development life cycle so you know in we had to focus on creating components and turning up components for our brands to use and we had to focus on building the theming system so this part of our life cycle was really focused on the foundations and laying those foundations making sure that we do have a theming system in place and making sure that we know we have enough components to fit the needs of of our consumers and our brands so we looked at you know what are the core components needed to build out an article page for example on the times or the sun and the same for the index pages as well and that helped set our base for for what we were doing back in back in the beginning so you know for year one we had a really simple and you know maybe not a useful kpi but it was the number of components and it was useful for us to be able to see the growth of the design system and to be able to say you know this quarter we want to develop x amount of components so it's something to show that we are actually doing work year two so last year in 2020 the first product built entirely using our design system was launched in times radio as you can see there on the right hand side um for the first time you know since its inception we had users um and i think all my team would agree that this time was really useful and important we learned a lot about our system and about the direction that we needed to go in and um for the first time we had users to get feedback off so we sent surveys out to our users and we captured a net promoter score from them so this net promoter score was something used in customer service quite a lot of the time you know back in my days when i used to work at the apple store when i was a student we used to capture the mps um so this is really useful to be able to say hey no on a scale of one to seven how likely would you be to recommend using newsget to a colleague you know six and seven they're promoters uh and then one two three they are detractors they wouldn't recommend using it and then in between their passive um and we also captured a sentiment analysis as well so on their feedback we would run it through a sentiment analysis and we would be able to see okay the sentiment towards news kit is good or it's bad and it was um it's really great to get more feedback and recommendations about what we should do and you know um what we could maybe add into the design system so big year for us year two um which you know gave us our second kpi that we began to track which is uh mps so at the end of the year too we had our number of components being tracked and our mps as well and you know off the back of this we've actually gone and we do weekly user interviews with our various different product teams and speaking to engineers and designers and product people across the organization to to get the feedback from them so this year you know we've had a a really good year so far um as a design assistant team so um we had a product launch uh virgin radio so wireless our kind of audio arm of the business they've launched their new web platform which is essentially going to underpin every single brand so version radio talk sport talk radio talk etc etc etc um and dow jones um built a factiva product the new factory the product which is a b2b um product uh entirely using newskit as well so two big product launches loads of good feedback coming in um so this kpi that we're looking at here is the pace of development so with the virgin radio while the wireless web team built this product with the the goal to then reduce the time it would take them to build their second product so we need to look at the pace of development and for example product a took x period of time to build and cost this much however once that was up and running product b which is the product that came afterwards took this percentage less time to build and save this much money when compared to product a and this really put our theming system that we've built to use and it really tested that and you know we got some really good feedback off the back of it and um you know it works it works very well and um it's really important that you track this it's a lot easier to do this because you know they are using newskit in a whole wholesale kind of way they're not using it incrementally they're not you know swapping out components with our design system components they have built a brand new platform and it is really good to see the place of development improve so this is something that we're tracking um we're also tracking contributions you know i think everyone would agree that design systems aren't and shouldn't be owned by one team they can be maybe set up and governed by one team so the news get team i say we are the governors of new zealand system but you know it's owned by everyone it's owned by the product teams and in the usa it's it's it belongs in the uk as well and whoever else uses it so contributions we want people to be contributing back to the design system and initially we were really gunning for teams to contribute components back because obviously then that will really help us scale our component library but it soon became you know obvious and clear that that was maybe quite a big ask because they've got to get familiar with the design system they've got to onboard onto it so we actually began to relax our kind of what we mean by contributions and we're looking at things like patterns so for example here on the left hand side you can see that we've got this onboarding pattern which will live on the newskit website as well so we're looking at design teams and saying you know if you come up the pattern please contribute back please get onto the website we're looking at component specifications and design so you know we can build the components but it'd be great that if you want an accordion component can you spec out for us can you contribute that that specification back to um back to the newskit team to build um you know contribution and figma and bug fixes and codes so we've had a really um yeah we found that it's a lot easier to get contributions um in these ways and it um it's a really good way to be able to track your um kind of adoption the sentiment towards your design system another kpi that we're tracking is performance so um we are tracking the adoption of new skit over time so there's a really good blog post by cristiano rostelli who was formerly of badoo who are the people who built bumble the dating app he wrote a really really great piece on the adoption of design systems and how to track it in code which is really cool so we have built this design system as everyone does with performance accessibility and seo all in mind so we are going to be working on a new kpi that tracks the adoption as a percentage in a code base to then be against the core web vital score so the idea being is that we would i guess we would you know hope and expect to see a increase in adoption and then as that adoption increases the google core web vitals improve because these components have been built to a really high spec we're not building them in a day you know we're spending some time to make sure that we are we are getting them right so that meant now you know two and a half years in we've got a really great core set of kpis um and you know these kpis don't always have you know relevance to every single product it might be that a team who is incrementally adopting newskits so they're swapping out components they're building new features in their site with the design system they might not be able to you know look at the pace of development and the money saved as easy as for example wireless where they're building a whole brand new product and launching these products one after another however you know they can look at the uh the performance and the adoption versus the call of a vital score when a brand like the times or the sun are implementing news get into their system we should hopefully see that score improve so you can't yeah you can't compare apples with oranges um so it's um yeah you know use these kpis as and when you see fit they're not going to be relevant to every single product so to summarize we've got a nice core set of kpis we've got the number of components we've got the net promoter score we've got the pace of development which is pound saved we've got contributions which helps measure the buy-in for your design system we've got the adoption in code and we've got the adoption versus the core vital score so it's a really way useful way to to prove the value of the zeiss system through real tangible numbers and then you know what's next we are open sourcing our design system this year so in the next coming weeks we will be looking to do this over christmas um we are looking at multi-platform support so we get asked all the time what are we doing about apps and it's you know we need to do it we need to look into that and at least have a strategy for that so if anyone's got any you know recommendations or is available to have a chat about that then please please do talk to us we'd love to know your experience we're going to continue to build on our library we're adding motion into our design system we are adding the versioning to our newskit website so that consumers can see the documentation that's relevant to them depending on which version of music they're running and we're continuing to improve our dock site which is built out entirely using our news kit design system so it's a good way to dog food our component library and our systems some further reading so we've got the documentation site we've got a medium uh blog as well where i i wrote a piece on the this exact topic so i'm gonna have a read of that for a bit more detail and then we've got a video from where um nick and james two of our design colleagues uh met up with charlie from figma did a coffee with charlie session and i'm on all their socials as you can see as well and that's it fantastic thank you slot i've got a lot of uh i think that was really great i've got some really good insights from there and i've got some good follow-up questions which i'm excited to ask you in the q a later thank you so much um if you are looking at this and going oh i also have lots of questions please use the slido deck and pop your questions in there it's going to be a really good q a session i'm pretty sure of it um jumping quickly back into the chat we now got auckland new zealand good morning and uh greetings from greece uh so it's uh it's expanding love it absolutely amazing um we've had some amazing talks but we're not done yet we got another one coming up i mean we are spoiling everyone today and we are so excited that we come back with uh such great speakers and talks so for our last outing i would like to welcome our double duo james and emily who are going to be talking to us about handover to a certain extent i believe yeah that's correct fantastic i shall i welcome both of you uh how are you both feeling very well thank you excellent ready to go okay brilliant i uh i'll hand over to you it's all yours take it away great cool uh can you see uh presentation weekend indeed fantastic yeah so hello everybody and thanks for sticking around um welcome to our talk design systems from consultants to clients my name is james and i'm the consultancy yld and hi everyone i'm really happy to be here and to be sharing some of my experience with you all as i mentioned earlier my name is emily and i'm a product designer at the motor insurance provider at zego and today we want to talk about designer handoff specific specifically our experience in handing off a design system between a consultant and an in-house designer yeah so i'm going to start by giving a little bit of context and background behind the relationship between siegel and wildie and how james and i came to work together so ziego partnered with wilde back in may of this year to essentially consolidate all of the ideas that we had for our product and translate those into one cohesive north star vision that all of our teams could align with and get behind in order to to achieve that north star vision both effectively and at speed our design and engineering teams at zigo needed to be equipped with a design system that would allow us to not only focus on improving our current customer journeys but also give us the opportunity to experiment and test more efficiently so while the zigo design team continued to address the data the needs of the product myself and two other consultants from yld set to work on building the north star and the company design system i led the establishment of the design system from the yld side then i eventually took on responsibility for the design system on behalf of zigo's internal design team so going into the project both wildy and ziggler had corresponding objectives and expectations of what they wanted to achieve for while d our objective was to seamlessly embed ourselves into zigo and eventually leave behind not only the solutions that we've already outlined but also the requisite capabilities and confidence within zigo to build on our foundations and at zego our expectations were very similar ultimately we needed to end the project with a team that felt comfortable in navigating around and implementing the design system without the need for support from the yld team so having a structure that was intuitive was really important we also needed it to enable an efficient way of working for the team while maintaining consistency so in order to achieve that we expected wildey to take some time to really get to know us as individuals as a team and as a business and really understand those nuances and then ultimately we needed this design system to empower our teams to not only reach that north star vision that i mentioned before both successfully and quickly but also give us the space the opportunity to innovate experiment and validate these ideas and concepts by being able to work at prototypes quickly so our expectations and objectives were fairly well aligned but it was clear that the project really hinged on getting the handoff part of it right particularly if we were going to deliver something that was actually intuitive empowering a long-term solution for zigo now i'm sure we can all agree that designer handoff in general can be a fairly intricate process at the best of times and it is further complicated when a design system is involved it can be pretty ominous actually handing over the reins to something that you've raised from a humble collection of atoms to a sprawling network of molecules and organisms and even more ominous being the one picking up the reins to an entirely new system so it should come as no surprise that emily and myself both had some initial concerns and reservations regarding the design system and its handoff firstly from my perspective it was actually really important that the design system structure and its conventions were not too subjective to my own way of working and that it was able to seamlessly align with z goes on from that as the design system was being created in a semi-silo way i was also aware that this could result in us being kind of too close to the work to see potential issues inconsistencies or specific product considerations that might be immediately apparent as ego and additionally as the design system would be used by various teams working on different platforms across the organization i knew we had to take steps that would reduce cognitive load and streamline decision making and then in terms of the practical side of the handoff i was very conscious of knowledge being lost but i was also aware that if the handoff was too much of a brain dump then it could lead to information overload yeah and for me i must admit as james mentioned it was quite a daunting prospect taking on such a huge and significant project and making sure that the handover process was smooth and comprehensive but some of the specific reservations that i had going into the projects were number one just how enormous it was and it was quite scary to begin with i can't lie um i'm sure many of you if not everyone on the call has had interaction with design systems in the past so know that they're really complex things with lots of intricately linked atoms and molecules and it just takes a lot of time to truly get to understand all of that complexity and then yet more time on top of that to understand how to maintain build and modify within that complex network so i was very aware that it was going to take me some time to really understand all this complexity and whether we just frankly have enough time to do that then as well as that it was how the hell am i gonna squeeze all of the knowledge that's in james's brain and absorb as much of that as i possibly could within the two months handover period that we had no one knows this design system quite like james and i was very aware that we needed to protect all of that knowledge and make sure that we didn't lose it when he left the project so it was my job to poke and prod him with loads of questions to try and pass on as much of that expert knowledge as possible which i'm sure james thoroughly enjoyed i was also really keen to work with james to collate some documentation and get all of this knowledge down on virtual paper not only for my benefit but also for the benefit of the wider team to make sure that everyone had a base level of understanding and that the sharing wasn't just with me and then my final reservation might be quite specific to me um and kind of my personality because i'm a horrible overthinker but it was making sure that i was very thoughtful and sensitive going into this handover i was uber aware that this was james's baby that he'd been working on for months and he'd nurtured it from some humble atoms and it was basically my job to come on board and tear it apart try and find holes in it to make sure that i understood it properly but also to test the comprehensiveness of the design system itself so it was really important to me that i do this in a constructive and thoughtful way because ultimately james and i were going to be working together for a couple of months and we needed to establish a positive working relationship and really build those foundations for sharing collaboration so how did we address these concerns and reservations well we were able to respond to them through a combination of iteratively adjusting our design systems set up in figma and in implementing various different rituals throughout the handoff so let's just take a quick look at some of the simple adjustments and improvements that we made to our figma setup over the course of our handoff the first thing is that we all know as designers it can be a struggle to agree upon naming conventions um so one of the ways we found around this was to actually group our components by their function first which really helped to alleviate confusion with this structure designers were basically able to narrow down their desired component based on function which was a lot less subjective than a name now as a result we chose to group all of our components by the following functions base buttons displays feedback filters inputs and navigation now as the design system began to get more complex we also found that as useful as something like figma variants can be it's really important to consider when they're actually helpful and and when there are hindrance um and to ensure that any usage of them is consistent and obvious what we found was that certain variants became lost or their existence required assumed knowledge so we trimmed down the majority of our varying options to just include things like device position type state and size so the designers knew exactly what kind of variance to expect with components and lastly one of the smaller tweaks that we made that actually had quite a large impact was around color so zigo's design system made use of quite a lot of different colors and their usage was fairly broad so we found that grouping and naming our colours to give context to their correct usage allowed for greater clarity over what was standardized and what wasn't thereby reducing a lot of the decision making so rather than just kind of colors labeled as like neutral 30 2010 for example um we actually created a separate color style in figma for our text our iconography our backgrounds and our border elements and then within them we actually included all the potential colors relating to that specific element so for example in our text color style we included things like text primary text disabled text link and so on so it's much quicker and easier to be consistent with color now let's take a look at some of the rituals that we implemented during the handoff so from my side one of the key things was to actually conduct a soft launch of the design system with a select number of designers and engineers before we launched it across the wider organization and this actually presented a great opportunity for zika to raise questions but it also presented the opportunity to disprove some of my own assumptions about the design system now that being said it was also really important that we maintain some high visibility on the progress being made on the design system across zigo and so to do this we frequently showcase updates in design reviews and we pushed out written updates via a dedicated design system slack channel now sometimes showing people isn't enough and it's actually better to familiarize them by doing so once the design system was at a mature enough level we actually ran an interactive design along workshop with the wide as ego team where we set about creating some screens using the design system and this really helped to actually familiarize people with some of the basic structure and again presented another opportunity for questions to be raised finally um it was actually really important to bear in mind that people won't always remember all the rules and regulations of the design system so we tried to keep it to just a few kind of distinct rules things like our atomic approaches we've already touched on um or using four-point grids for a kind of more consistent structure and then we ensure that everything else was actually more documented in depth separately for me some of the things that i found to be really useful and really effective over the handover period was firstly just not to dive in headfirst and start with the most complicated thing that i wanted to achieve by the end of the handover period that's a surefire way to just completely overwhelm yourself and not want to engage with the design system so my best piece of advice is just to start by getting familiar with the file itself just have a nosey around see what's in there get familiar with what's included and the layout and then from there start by adding something small so i think the first thing that i added was an icon it was a really nice way to get familiar with obviously the rules around how we want to create icons themselves but then the sizing conventions naming conventions how they then engage with colours and that sort of thing so it was great to to then get familiar with the rules and the conventions and compound by understanding of the basics and then build up my confidence to add something a bit more complex after that then the second thing comes quite naturally to me as a product designer but just to really release you're in a toddler and keep asking why about absolutely everything which again sometimes you can feel a little bit awkward doing that but it's really important that you understand why decisions have been made and interrogate that rationale because we've got to use that same rationale going forward so if you don't understand what what what thinking has been done before you can't maintain that same thinking going going forward and then not only i guess in my case asking james these questions but once i felt more comfortable with the design system it was asking myself the questions that i was facing and kind of challenge my challenging myself to go away and dig into the design system to find the answer then also coming on to the project i think design systems can feel quite theoretical and abstract in isolation even though of course they're real-life use cases when they're being built or closely considered but i found it really useful to work up some of the pages that we had live on the website using the new design system for me it made it really clear if something was unclear in the design system or if we needed to modify or add a component it also helps to naturally raise questions that you might not otherwise come across until after the handover which obviously wouldn't be ideal and then finally again this one might be quite specific to me i'm a really list orientated person i love being organized and structured so it's no surprise that i fell in love with the design system and all of that what that involves um but when james and i started to work together i created a rolling checklist of things that i wanted to achieve by the end of the handover it was a really nice proactive way to be constantly engaging with the design system making sure that i was up to date with with the latest what was going on and one of the things that i had on my list was that i wanted to create a complex organism made up of multiple atoms and molecules for my own self-confidence i kind of needed to know that if i could do that with the backup of having wildee and james's support then there's no reason why i couldn't do it after the handover either and it was great to have kind of a tangible to-do list if you like that i could tick off as we were working together and then james and i could both reflect on that list at the end of the handover and confidently say if everything was ticked off that we'd covered everything that we needed to so we're actually coming up to the final week of our handoff uh next week um so it kind of seems like a really good opportunity for us to talk about uh you know some of our kind of parting thoughts on the project and the handover process in general so for me i think while establishing the design system in a semi-siloed way definitely had its challenges i think a combination of the high visibility that we were able to impose throughout uh kept us on a good footing as to what was needed by siego and the incremental pairing work between myself and emily throughout the soft launch in particular really helped us to actually catch a lot of the issues or inconsistencies before the design system was fully available it also ensured that the design system was fully aligned to zig's way of working and it left me in no doubt as to emily excelling as the owner of the design system going forward more broadly in recent weeks it's been great to see more designers beginning to familiarize themselves with the initial design system with minimal fuss or confusion and we've already seen some conversations emerging about how the design system can grow and mature across zigo which is great to see that it's already being embraced by the wider team in its fledgling form yeah and for me it's been a super cool experience and i've learned absolutely loads having the scenario of working really closely with an external designer is not an experience i've ever had before so that's been really interesting really fun and hopefully you can tell from this presentation it's been really successful as well which is obviously very important and two of the key things that i'm going to take away from from this experience and definitely carry forward into future projects is number one just how important it was to take a considered approach from both sides not only in terms of communication how james and i were going to work together i guess ultimately remembering that we're both two human beings and we've never worked together before so we didn't know exactly how we worked and just being kind of very aware and thoughtful about that but also the practical steps that we implemented to target those initial reservations that we had so one of those was bringing james into our team ceremonies from day dot and that was just a brilliant way for everyone in the team to get visibility on what james was working on latest updates get the whole team on board and get them really excited about the new design system which which they are they're absolutely buzzing um and many of them as jane said have already started using it and for me there's no greater sign of success and if you've got a team that are really really excited about it and they're really engaged so you know we've obviously done something right there which is great and then the second thing was just about allowing ourselves the time so having this extended handover period for me was absolutely critical not only to the success of the handover itself but to the long-term success of implementing the design system going forward it just gave james and i time to have one-to-ones and to truly collaborate while also giving me critical breathing space beyond having to maintain my business as usual work so continue to support the squads that i work with and make sure that none of that work was suffering and as i said it just gave me time to really build my confidence and get comfortable and familiar with the design system and now i can safely say it feels like my baby as well i'm incredibly protective and proud of it and i'm really excited to take it forward into this next phase of building it and rolling it out across our interfaces so really really exciting so yeah the last thing is just to say a big thank you for listening i hope we've given you an interesting insight into the experience of handing over a design system from consultant to client and hopefully we've given you some useful tips thank you to the both of you uh super interesting i think this is a lot of insights there that are useful not just from consultant to client but as a general of handover as well some really really useful stuff so thank you um we are gonna get to the q a in a second uh before that i'm just going to comment little bit on the chat again uh in the meantime the rest of the speakers welcome back in uh we have alice and martha uh i'm just gonna have a quick look at the comments because the chat is amazing because there's a lot of people helping each other out giving each other answers to things which is what the community is all about so i'm loving that uh i'm also loving this quote if if looking at starting a design system it's not scary is it really a design system i think that's a great that's a great question to ask is it that um because we all know that that can be a quite scary thing right so i think we also had i saw somebody else from another place far away that i hadn't seen before oh singapore that's what i wanted to say as well we also have somebody in singapore where it's uh in the middle of the night so well done you from singapore for being here and for staying awake um right so i've got all the speakers back thank you all of you uh fantastic talks how are you feeling after that thumbs up great nodding heads brilliant so we have quite a few questions uh to take us through some questions i think are mainly directed maybe at some talks specifically and some questions are quite general so um i'm going to pick a few questions i'm going to throw them out there and then we'll get going for anyone watching if you have follow-up questions on your questions please feel free to share those as well we try to get to as many as we possibly can um so one good place to start and this probably i think is a question for everybody how large is your design system team and is it enough or do you experience bottlenecks um who wants to pick that question up first in that case i'm going to volunteer you ellis how large is the team and do you feel is the team big enough or do you experience bottlenecks or how is that working yeah i think we're quite lucky to have good funding we've got um i think we've got eight or nine engineers and five designers um and then myself and a business analyst as well and we also have a sister team which is a render news get render and they build out actual solutions using design systems so things like account or checkout or you know those kind of things um and they've got four engineers in that team so yeah we're pretty lucky you definitely uh like it how you got a great size team that sounds fantastic i'm gonna come back to you being a pm at the design system because you mentioned it yourself in your talk and i i when i spoke to you last time i've also mentioned this that's not been very common so i'm definitely come back to that um before we do that um martha how big is your team and do you find that you have enough people or or are you guys struggling um we we have i think three designers that work on design system and then we have a front-end team of um around 10 people and we all work either on the product or on the design system implement implementation but we recently hired a design system engineer so we are um growing the the focus on the design system for sure so so part of your team are working across both by you starting to sort of get you gonna be focusing mainly on the sound system that's awesome exactly yeah brilliant uh james and emily uh working on on the zego team so as ego we don't really have a design system team per se um and obviously james has already done all of the design leg work but in terms of building it that will be managed by one of the squads and i'll be kind of the connected designer to that squad as the i think we have three engineers on that squad building it so i'll support them as they um build it and then if there's anything we need to modify going forward then that will fall with me as the sole designer brilliant cool actually that brings me to my next question which i think goes nicely into that emily and james this is for you guys so um obviously we hear from two designers on this but we also know that to get proper buy-in and getting people to really adopt a design system we also need to have buy-in from engineers so how are you guys working with the engineering team to make sure that that sort of handover or the buy-in is is happening as well i don't know if you want to start with that james with the initial combos you had as you were building it yeah no i mean from from my perspective obviously we we spoke with um with engineers as we started the pro process and i think it's very much just about you know selling it to them is how easy it's going to make their lives but obviously we've touched on it with talks here about you you're building solutions once essentially um which ultimately means maintenance is easier and and so on so yeah it was from my side it was that initial kind of getting them on board as to what they stood to gain from it but um also using them kind of the knowledge from their side as to what they would maybe be expecting or wanting um or needing for the design system and the work that we were then providing in terms of specific requirements and documentation stuff like that so i i know for a fact that you guys have quite a lot of conversations with the engineering team and i know that there was somebody from engineering who was kind of also leading the adaptation from engineering perspective is that correct yeah so there was a gareth um who was uh initially leading the uh the engineering side of things and so we kind of spoke and collaborated and did some initial kind of discussions on how we kind of thought ownership and process structures might come into play um and yeah just trying to make sure that we're some alignment on that at least going forward fantastic um martha from your perspective being an engineer uh what's sort of your relationship with the how does that look in your team that the relationship between the scientists and engineers you were touching a little bit on it on your talk yeah we we try to to think um we have a weekly sync between designers and engineers and we always try to designers try to gather some feedback from us and we have a pretty transparent communication so i think that's the most important thing um for us awesome great um so i guess this is sort of about a little bit about adoption and and how how people are sort of taking on to the design system so i wanted me one a little bit to talk about how do you measure adoption and alice you mentioned a few different things from a kpi nps perspective but how do you actually measure adoption of components and and or have you guys done any work around that yeah so the different levels i think and i think you know crudely you can just look at the number of products not brands but number of products that have actually adopted your system to kind of get a flavor of of how well adopted it is but then you know you want to maybe scratch a bit deeper um and then i can see in the chat people have already been posting up around like the grafana like plugins and things and you know we're we're looking into that at the moment so the idea is that whenever um you know we'll know exactly as a percentage how well adopted it will be in a code base for example in the times for example how much of their estate is is going to be built using newskit but then also you know in design i know figma has a really cool plugin as well where you can you can track the the figma component uh usage so you can see how many times a component has been uh dropped onto uh you know a design so um i think there's different different levels that you can look at it and we are currently we're doing the figma thing we're doing the obviously the product count but we're now looking into getting some kind of tracker in the other brand's code bases fantastic um i don't know i know that maybe um jameson emily your team might be a little bit behind in the development comparison to what ellis's team is but do you have are there any plans on measuring or or is that sort of something that's in the future for you at the moment to kind of try and understand how the uses of the design system components and are happening yeah i guess ours is probably quite a unique scenario as well that it's not a completely um it's not a whole rebrand so we're taking quite a strategic approach in how we're going to start rolling it out and implementing it across all of our journeys and websites so we're kind of just going to take a strategic approach on where it's going to benefit best first um and start rolling it out that way rather than trying to do everything at once um yeah fantastic um we have a question here about uh usability accessibility obviously uh very interesting and very important part of it um so i guess this is the question for all of you ultimately are you sort of including testing other components when it comes to usability and accessibility and if you are how are you doing that um want to start with marta this time sure um yeah we we we include some accessibility accessibility features on our unit testing but we have some we have a team focused on ux uh development and they connect some ux testing and that really help us on understanding the user and the flow in our application great awesome and alice from your perspective what are you guys doing or planning for testing accessibility yeah so you know we have a tool uh we use appitool to test our um components from a visual standpoint uh and then we also go through a kind of when we're specking out a component so if we're building a select component for example we'll do like an accessibility audit before even specking out the component to make sure that what we're going to build is accessible and then we also have one of our engineers is an accessibility champion he's kind of looking at the accessibility to make sure where we ship is accessible but you know feedback all the time especially from our american colleagues is that you know i think they are much hotter on accessibility than us over here um so we get a lot of good feedback from them as well brilliant absolutely um james and emily what's the uh effort from this sequel team yeah i mean we obviously when we're building our components we'll follow a lot of the kind of best practice things we keep a lot of a lot of the patterns of our components kind of close to um a lot of the native um components behaviors um and then obviously we always do our double checks of the color contrasts um one of our kind of unending struggles was really about like incorporating brand colors and trying to balance that with accessibility um so that was quite a delicate thing to have to solve but it's been something that we've been yeah just trying to obviously track and keep a handle on as we've been going through and i know that very well uh brands are very protective but then at the same time there is finding a balance between that brand and usability accessibility is super important um so obviously with all the development of components and sort of moving the sound system forwards there is a lot of design history um do you have sort of design history to keep track of design decisions or rationale that you made or if you are how are you doing that is that part of the online open source that you have or where does the history of the development of the design system live i'm gonna sw this time yeah so we've um i think we've just today released version 4.3 or something of our design system so you know we're probably going to do five in a couple of weeks to be honest but um yeah we we're building into our website at the moment um a way to be able to track um and for a user who's on v1 for example um they can go in there and they can then look at the documentation of the design system at that point in time at the moment we crudely keep everything in confluence because we haven't built that into the site yet of things have taken other priorities so that is high up our list of to do's which we need i think that's fantastic you mentioned that in your talk earlier that that's something that you guys kind of be allowing people to do so that's that's exciting um james and emily um i know that the documentation is extremely important then james you are a champion of documentation um how are you guys looking at the history and being able to look back on the development yeah i mean from from our sides um again ours isn't necessarily at the advanced level where we'd have it within its own site so at the minutes a lot of our documentation sits within notion but we obviously go through all the kind of different foundational aspects of the design system or components and what sort of influence decisions and why certain decisions have been taken um and then obviously just like from a figma size we we still obviously house kind of an archive of lots of previous previous versions of components or screens or whatever just so if we ever need to go back to them or whatever they're always there right and martha do you does your team keep log of changes yeah um i can't speak from the design the designer side uh i'm not much aware of that but um we keep a love from that thing that i was talking about before so we have a document where we love and take notes from every meeting um of every decision we we take so i think that can it can be considered a history of our decisions absolutely awesome um i wanted to move over a little bit because i alice um i'm quite fascinated by this and uh i'm sure that there are people out there as well you mentioned it yourself when you talk it's quite unusual your role so we have engineers here that are involved in the science system we have designers who are involved in the science system it's quite unusual for design system as much as we have been over the last few years trying to convince everyone that it's a product and that it needs its own team etc how did you guys manage to achieve a level where you actually have a product manager for the design system itself yeah it is odd like not odd but i think it's unusual um but i think you know in a in a company like news corp you know they own dozens of brands um and it is quite messy and quite political uh in the sense that there's loads going on all the time everywhere so i think the product manager role in news uk in the design system is really looking at you know aligning road maps to make sure that you know how we're prioritizing the build of a component or a feature within the design system and you know if the times and wireless are both wanting to build a new audio player for maybe in article audio playback it might be that you know that helps inform our roadmap to then decide that we are going to build that in the next quarter um and it kind of helps you know shield the team from the other stuff going on as well that maybe they don't want to get into but at the same time we are as i mentioned we've got three products three new skit products we've got the design system we've got a render team who build out whole solutions and we've got an api product as well so the render product is like a consumer of the design system but it's a system team so it works much closely more closely than other other teams um so that team is a product team team is developing web products so it kind of all fits together quite nicely and you know maybe in a small organization with less brands it probably won't be needed but in a company like news uk news corp it's um i think it's definitely appreciated from the engineers and designers i hope anyway so the size of the organization has sort of helped justify that role or the existence of that team yeah i think so excellent i i think there will be many people here who will be uh looking at that going oh i wish we could have our own team set up in that scenario that would be amazing um so just touching a little bit again on the machine's success so i think the other thing as well is the topic that you were talking about at least about kpis within sort of actually so we we have as designers we have tried to get a place at the table as the sign systems they'll try to justify the need for it amongst people and the value of it and now that that has happened we now need to then start actually showing the value of it with numbers and we have one question here which i think is very related to this um or it's to everybody but but i'm going to start with you alice um do you guys have any sort of numbers or studies or tracking the efficiency gained on design and front-end sites so for example we've seen an increase of certain percentage or time saved or engineering time saved et cetera yeah we do and i i'll go back to you know the uh what i mentioned in my talk about different ways of adoption so you've got maybe a more wholesale adoption where a new product is built entirely using the design system which is obviously brilliant for us and you've got the other way where people like the sun for example they are incrementally adopting it so when they build out new features when they build out a new index page or an article page they're using the components in the system to then to build that so um i think as i mentioned the you can't compare apples of oranges they're two completely different ways of using the system and i think that um you know with the virgin radio product the next product they're going to be launching will be talk radio it's the exact same platform they're using our theming system so then we're there we can take the uh the money saved which is what you know the cfo is gonna really absolutely care about and rather than spend six months building this new radio station they've maybe spent three weeks or four weeks um doing that so that's really clear and simple might cost anything straight away and then you know with the sun for example that incrementally adopting it we'd hope to see then the core web vitals from google improve and the accessibility score improve and et cetera et cetera et cetera so um that's kind of how we're approaching that excellent and martha from your perspective an engineering team wise sort of do you have you seen or do you measure at all sort of the time saved here yeah i don't have concrete numbers but i can say for sure that it saves a lot of time because every every time we want to to build a new page or a new new future it is so much easier to reuse components that than being implementing all over again and sometimes it's not even that only the the visual side of it it's validation or logic inside the components so it's much more easier quicker and reliable to just use the component that we know that is already implemented and tested and it's um error proof than to implement everything from from scratch thank you uh awesome i know james and emily you guys actually mentioned in your talk about the increased speed and and that everyone is adopting it so i'm actually i'm going to ask you guys another question so we've sort of heard from you from your side of the things that you guys were worried about at the beginning of the process and at the beginning of the handover you touched a little bit about where you are now but james you said there is one week left on this project or sorry next friday what's going from your sides or going through your heads at the moment what are you concerning yourself the most with i mean i can give my uh my answer first i i suppose it's not necessarily being worried it's more of a case of obviously i think we're in a really good place with it but i think it's understanding that this is kind of just the end of one phase you know kind of initial phase of the design system um and that next phase that involves you know um engineering is going to come with a lot of new kind of challenges and considerations um and that was obviously why it was really important that emily feels comfortable with the design system in his current state is because you know it's going to be basically like reintroducing it again to a whole host of engineers which yeah which is as i say is gonna it's gonna have a whole heap of new questions and challenges yeah for me um it kind of feels like when james leaves the project next week the training wheels are off and i'm on my own and i've kind of just said to myself it's going to be a bit of a steep learning curve and i've accepted that i think that's natural and expected and if it wasn't then we were probably missing something um so i think yeah it's just we've laid all the foundations that we've shared i know i i know all of the rationale um and it's it's exciting to take it forward into the next phase but uh it's really important to me that i carry it on with the trajectory that it's had up until this point um as i said in the presentation i know that this is james's baby and i want to make sure that i look after it and keep it in the gorgeous form that it is now so yeah brilliant awesome and i think that leads on to one of the questions that we have here on the slide deck which is actually talking about what important is to consider when you're trying to incorporate components designed by another product team into your design system or even that sort of adoption or encouraging um contributions that i think alice you mentioned it in your talk as well about uh a sort of encouraging contribution from other people but what are some important things from everybody here that you think that we need to consider them incorporating things that we didn't design but somebody else did emily i'm going to start with you considering you are taking over something that somebody else has been working on yeah and this is where it goes back to me being very protective of it but it's really important to me that we allow collaboration and that if we need something new that we don't have in the design system any designer can design it but it's balancing that with protecting the integrity of the design system and keeping that it's like the ultimate source of truth and the bible um so i guess yeah it's just working with the designers where i think it's important to give them the freedom so if they've kind of highlighted and established that something's missing that they know the the problem that they need to solve with that so to go away and make it but then we've kind of as our governance process that there's a funnel that it has to go through me in order to check again it goes back to all the rationale of understanding all the rules around spacing and things just more of a kind of a validation and a qa check and then it will be solely me adding to the design system going forward so i won't necessarily be the only designer designing the bits but i'll be the only one that's then moving them and adding them again just to protect things like the naming conventions and make sure that that everything works the way it should do so yeah so i think that's an interesting and important point that contribution it should be it should be open for everybody and and it's not about sort of safeguarding who can contribute it's more a question of trying to make sure that that contribution is done and then that it ends up in a good place in the design system and l is from your side what what how is your team working with that because obviously you've got many there's many teams and there's a lot of contributions happening how do you work with that yeah so you know if we've obviously only got a limited resource albeit is is big but we can't you know build everything at once so part of that prioritization kind of process is do more than one brand or product team need this component and yeah okay we build it and if not we always do encourage them to build you know and contribute back however you know what i did say this design system isn't ours we don't own it but we do govern it so i think it's really important to make sure that our standards are adhered to otherwise you know you i think you'll end up in a position you know in 10 years time or five years time where you need another design system because your ones become so crazy and not fit for purpose so you need to keep hold of your core principles and don't um yeah you can't compromise on quality absolutely that point um one question here and i'm going to start directing this one to you here martha um so assuming that a team or a squad uh build components that don't necessarily go into the sign system straight away might be lack of time etc um do you guys keep sort of non-design system work visible that might go into the design system later or like might be harvested for the design system at a different point yeah definitely we have we have two two products that share the the same design system and we we have some components or features uh implemented in each project that are not part of the design system and we are doing the the work of porting uh those features from the product to the design system and we only do that uh generic work around the component afterwards so we pick the component and make it part of the design system and generic enough to be used on both projects excellent and do you have sort of any techniques to prevent any updates of the essentials and to break the implementation of the project yeah and that is a big pain point so i think uh type checking is that uh our best friend so we we use typescript and we we can catch early errors um of properties that we are not expecting or we started um to have uh so typescript and type checking is a really um a really big help and also having enough tests so if we have tests covering our application or at least the most important flows um it is a security net that we have that if we upgrade our our package our design system it isn't breaking the product at all great awesome and we are running out of time very quickly and there are so many questions that i could continue this conversation forever but i am gonna wrap up uh with one last question and uh actually alice i'm gonna ask you this question um so you were talking about the nps or the net promoter score and how have you seen the sentiment towards new kids towards that change uh over time as the adoption has increased yeah um when we first launched i think we kind of got a bit excited and um we had a our product times radio which the times team with wireless built and uh it was when news kit was only about a year old and it was in its infancy and it was you know it worked we got over the line but there were a lot of headaches and a lot of problems would be to be sorted out and the sentiment and the promoter score to news kit there was poor it wasn't it wasn't good at all um so you know using the feedback and the the recommendations that were given to us as part of that feedback um survey we adapted and adopted different things to make the system more robust or better [Music] you know and it as as more products have adopted it and we've become a more resilient system the feedback has got better over time i know users is the key thing here more users means you get more feedback which means you you can improve it more so um yeah it's it's definitely in the right direction so far great very very good to hear fantastic awesome that's all the questions we have time for today uh there are a couple of questions that we didn't get to answer i'm just going to one of them i'm just going to pick up quickly here um how do you get a feedback or concern regarding your components from design community and your companies i think we that question has sort of been answered through other answers uh so i'm hoping whoever asked that feel satisfied with that um and then i think there was one question as well how do you find the best justified design system for value driven product team i want to go back to what benny said here and what you guys have talked about as well about the speed and saving time and streamlining so i think that covers all those questions i want to say thank you to the speakers for fantastic presentations for some great answers i can see here from the chat as well that people are very happy with answers it's nice to hear that people out there have similar approaches for me personally i always find it's great to hear that other people have the same struggles as you do because you know it feels less if less feels less of a mountain when you understand that oh we're not the only team who have these issues so these community sessions are fantastic uh to kind of share in those things so thank you so much speakers uh for your talks and for your questions answering those questions to everybody out there thank you so much for your great questions we are going to wrap up um so but before we do that i need to give some shout out and thanks before we do that um also i want to say hi to greetings from ukraine uh because we have uh one last sort of hello from uh from a location so i thought we need to mention that as well um i want to say thank you to everybody who took the time to join us uh on the live stream and a few great questions after the great chat and for the great topics you can continue the conversation either on a meetup group or in this chat because i think that chat actually stays up there um i want to say again thank you to the speakers i want to say thank you to yld for organizing and to our dsl people behind the scene who has worked hard to make this happen um we will be back in 2022 maybe who knows we might be back in person it all depends it kind of seems to go one day seems possible the next days is impossible so we'll keep on that but one thing we do know is that we will definitely back online uh so that's for sure uh there will be something coming out on meetup very soon on when the next one will be uh if you are interested in speaking and if you think you know what i'm ready to give my talk at uh the next one because i've got some comments that i want to make to the community please absolutely do so uh we would love to uh have you applying uh there will be a form coming out very shortly there will be a meet up as well we would also like to have your feedback from anybody who watched this uh just to get an understanding how we can improve uh so i think that one has just been shared in the chat that will also go out with the um follow-up meetup uh email and that is it for today everybody um thank you so much everybody again it's been fantastic that's it signing off and see you all at the next talk

Channel: Design Systems London

Views: 8,404

Keywords:

Id: VyJEg_g6gQY

Length: 126min 30sec (7590 seconds)

Published: Thu Dec 09 2021