 Well hello. Good afternoon everybody. Welcome to the talk with a very long name Designing a design system for module modular modules and building a team to build it My name is Josiah McCann joining me on stage are Marianne Epstein and Josh trout Josh and I are representing the core web development team and Marianne is here representing the UX design team at USA today First I want to start off by saying thank you Polymer team for having us out to speak again last year was a really really fun year Very very practical talks, and I'm really excited about the talks tomorrow and the rest of the talks today It's been a great conference so far So I want to share a little bit about the USA today network and What we're all about and and we're all about making communities stronger and we do that and to and To do that we have to inform them equip them and empower them fostering deep and vital connections between members of our community and the world around them and We connect these communities all together through our national brand USA today and our 109 local media organizations Merging our national voice with the local communities as an award-winning news organization and a modern media company our 500 and plus digital products reach 110 Readers every single month we reach 43 percent of the internet population with our content Resulting in 1.5 billion page views every month, and as you can imagine This level of scale and fragmentation between so many websites has its challenges and Today we want to share our success as a dev and a design team Focusing on very practical points You can immediately walk away with and apply to any size team or project So to give you a little bit of context of you know, here's what we've been up to since we last spoke a year ago We launched our new polymer base web framework We're test driving it with a few we test drove it with a few different Micro-sites we talked about one Last summit our Olympics coverage our data-driven Olympics coverage and after that we launched our continuous Coverage of the election all converging on election night the biggest news night of the year Where the framework made its big stand taking on a heavy amounts of traffic And the entire process it was a great way to see how much faster and more efficient We could build on this new framework while also identifying areas that needed to be improved and at the beginning of this year We began Re-platforming our current sites onto this framework and Doing a complete redesign at the same time right now USA Today comm on Mobile devices is completely powered by this new Polymer web framework Part of this new framework is we want to figure out can we build quickly? Can we build more efficiently and it really really worked for us and But this new approach that we took this module everywhere approach Is key to our success in building for a large? News organization with many developers scattered all over the nation so this is a this approach it's adopting a module way of thinking and Web components on the client are front and center or polymer based approach But also not just our client but our servers. We have server-side Modulization through microservice through a microservice ecosystem This modules everywhere approach is very decoupled allowing for maximum component reuse Across not just our team, but through any of our web developers spread across the entire network reducing the cost of experimentation maximizing shared code use across each and every property and to support this development philosophy Design had to be on board and think modularly as well and here to talk about our new design system That supports this framework is Mary Ann Everyone as Josiah said our design team has spent the past year working on a new modular design system And today I'm going to talk about what a big change this was for us As well as what worked well for our design and dev teams in case your teams might be approaching sort of similar challenges Heading into our redesign last spring We had separate desktop and mobile sites and we'd been adding new things to them for a couple of years and over time our designs had veered off in many different directions Here you can see a story coming into our desktop site and that same story also coming into our mobile site And they look very different from one another and if you were to hide the logo at the top You might even think that these came from two different publications and These differences were causing problems for our business our journalists couldn't predict how their stories are going to look Which was very frustrating for them and from analytics. We knew that our readers weren't as happy as they could be either And because these same sites were being sent to a hundred different newsrooms Our designs were frustrating a lot of people every day, which on the UX team is the opposite of what you want So there were some good reasons behind everything looking so different at this point First a lot of things had changed since these sites were built reader habits our storytelling and response to those And our scale we had grown a lot as a news network in the past few years Meanwhile, we were not set up well for all of this change. We didn't have a style guide So whenever we needed something new which was pretty much all of the time We would do our best to make it match, but more often than not we would have to design it from scratch So we wanted to really understand our problems before diving into a redesign so we shadowed our journalists to find out what they really needed from our sites and Then we took inventory so we screen capped every page of our websites to understand how we were currently meeting the journalists needs And what we found were just hundreds and hundreds of single-use one-off experiences So here's a specific example to show you what was happening We are a news organization So one of the most important things we do is promote stories to help readers find things that they're interested in and We call these story promos and at the time of our inventory we found This so this is 12 versions of a very similar looking story promo, but each one of these could only be used in a specific place So this one only ever showed up on home pages and This one only ever on blog pages This one only ever appeared on mobile article pages and this one only in desktop search results and On and on for all of these And if you look at these more closely almost every style here is unique So every headline has a slightly different font treatment even the hex values of all these grays. They're all different So not only had this same thing been designed 12 times. It had also been devped 12 times And this was just one example So we saw the same sort of duplication and variation happening for our video promos or share tools pretty much everything else on our site So to step back for a second as a designer unearthing all of this was actually very very exciting So seeing the same thing done so many times at such scale And knowing how it was really causing problems for our journalists and our users that meant we had a really good problem to solve And it was actually two problems. We had a lot of design sprawl and a lot of inefficiency and The design team thought a lot about how to solve these problems in such a way that we wouldn't have the same ones again in Another year and we realized our focus had to be reusability So we needed to take anything we were doing over and over and do one thing instead and That meant we needed Smarter modules so for us that meant modules that would either do the same job in different places So for example a promo that can live on a home page or an article or To do the same job across use cases so one promo that could support a video story as well as just a regular story And we needed smarter styles so that we wanted to be able to reuse them across these modules to keep everything cohesive and help fight design sprawl So here's a very short version of how we got there Based on our inventory we distilled the needs of our site into module categories So for us as a new site ours were promo story media adds a couple of others Then we distilled all of our style needs into style ramps So anything we used again and again like type color spacers. We abstracted those into variables and Finally we designed some documentation to help us stay organized and for us Documentation was absolutely the key part of getting all of this to work because if there's one thing we learned from our inventory It is that reusability does not happen by accident So even if dev moved to a component-based approach Design still had a role in making sure those components actually met the right needs and actually fit together visually on the page and We found that reusability only happens when we pay extremely careful attention to details and then write them down So this was quite an adjustment for our team because not everyone loves writing things down But we have come to love what it does for us Which is to help us design things that are in fact reusable and I'll share our version of design documentation in a moment But first I want to show you where we ended up So here's our new story promo which now has a real name promo story thumb small or P1 for short and this was our single reusable module answer to the 12 different versions we had before and This module can live on a small screen Or a large screen It can live in the main content well or in the side rail It can promote a video story or a 360 video story It can promote a story without an image which is often the case for breaking news or a story without a time stamp which helps us showcase our best evergreen content and It can live on a home page or an article page or search results or any other page. We build in the future And It is made entirely of reusable styles So here you can see that everything in this module is pointing to one of our style variables Even the space between elements and Josh is going to talk a little bit about that for a second So we implemented this through the usual ways of styling polymer applications and elements custom style element for our theme and that had CSS custom properties mix ins and some classes The sample shows the colors and typography used in that promo and also shows how we mirror some of the Bixens into classes so we can use that in server side HTML We also built custom elements for some of the more complex design elements like icons and buttons And this example on the screen, which is like a little label header that goes above a lot of our list of promos And now Marianne's going to keep talking to us about more about documentation Thanks, Josh Okay, back to our friend P1 here a lot of attention to detail went into making this one module smart enough to be reused in so many ways And that's where our documentation came in So we wanted to keep documentation as minimal and lightweight as possible while also making sure we weren't missing anything And one exciting thing we learned as we troubleshot that is that dev and design actually needed to know the same things So we found that to make a module reusable. We all had to agree on the answers to five basic questions What is it called? What is it made out of? What variants do we need? How does it scale and what styles is it using and here is a peek under the hood at our Version of design documentation for that P1 module So on the left we have our functional spec and on the right our design spec Which we call our matrix because it's a visual matrix of how this module can look and together these documents answer those five questions So question one, what is it called? We never used to pay attention to this but now anything we build gets a specific name So we can keep track of it and reuse it and we collaborated with dev on a naming system Which includes three parts a shorthand ID so in this case It's P1 and that's just makes it easier to talk about things Category ID here. It's promo and a descriptive ID. So this is story thumb small which tells us this has a small thumbnail image Next question what is it made out of here? We established that this module has a headline plus some optional things like labels and image and other nested modules like a timestamp and an icon Question three what variants do we need? This is where we capture our modules use cases So for the P1 we have our default display then variants for no image different media types advert advertiser content and a couple of others Question four. How does it scale so here? We see we have a narrow version and a wide version and the matrix tells us how these sit on the grid as well as what the two sizes look like and Finally our styles we call out our style variables over here and this helps us avoid those one-off styles. We used to have so many of So I hope you can see that for us documentation is not an end in itself It has really turned into a thinking tool for our teams to help all of us check our work for reusability And over the past few months we've used this method to build out an MVP set of modules for our new site which launched to a hundred percent last week And here it is here is our new story page design And we think it looks looks much cleaner and more on-brand and much more trustworthy than the old one And it's going to be much more predictable for our journalists and our readers But what's even more beautiful to me about this new design is that we now have this kind of x-ray vision into it So anyone on our team can look at this page and know exactly the modules that came together to build it and This x-ray vision makes us so much more efficient than before when we need to change something Which we know we will as we test things and get feedback and as our needs change We can change it in one place instead of 12 and we can quickly build new pages by repurposing things. We've already built The last thing I want to share with you all is that we've been beta testing this for a few months And we can see that our readers are now spending significantly more time with us per visit on the new site So while we love the new the new design system our readers loving it is what we care the most about So we're really happy with that result and we're excited to keep evolving all of this because it's brand new It's a work in progress and there's still a lot to learn. Thank you so much. And Josiah is gonna take it from here Thank you Marianne very good stuff. So Building a team To build stuff we've so we've unified around a module base decoupled web framework We've established a shared design system that organizes our vision behind every component we build But we we need to think about how to structure a web development team around component driven web development Because I believe we're in the post abstraction era of coding for the web and As we unify as a team around a standards-based approach element encapsulation and heavy Reusability we need to structure our team for maximum efficiency and effectiveness We've we've all been building web sites and web things the same way for a very long time now But web components changes this work dynamic entirely and Because of that it was time to think about a new kind of team organization in our internal observation we identified three coding styles that make up our team the innovative artists the disciplined Scientists and the very reliable craftsmen and it's really important for us to understand how these different coding styles work together in order to build an effective team and Every style has its strength and weakness No one's greater than the other and some of us fall don't really fall cleanly into one column or the next But some projects may benefit from one style being more dominant than another style For example a banking application is very focused on being accurate and not time to market While if you're working for an innovative startup pushing that code out the door that's changing the world We want to do that very very quickly for our investors a balance team a Balance team can cover the weaknesses of one single type But only when good communication and empathy driven teamwork is applied So let's learn a little bit more about these different coding styles Let's take the artists the adventurer the innovator the fast-moving The problem solver always figuring out the problem always finding a better way Well cutting a few corners in there. I can identify with the artists the most. It's like tests. What are tests? I don't know. I don't know what a test is, you know Our weakness as ours unique solutions are great for pushing innovation and doing things better But unique means it's harder for someone else to pick up and maintain code How an artist would approach building the p1 modules they would they might say oh I'm gonna use the new grid a CSS grid framework, and that's how I'm going to I mean I make this happen, but We already have a grid framework and the for the company and we've just fragmented company standards All of a sudden someone else comes around to reuse it and they're like what did what did you do the CSS grid framework? So instead artists need to innovate the right way by focusing on things to improve everyone's work for a workflow Not just the current vertical that they're working in The scientists pursues code as a discipline to be mastered They're focused on best practices have very well tested code and this is really really good But it can all come at the cost of overengineering solutions and slower time to market and the scientists They would approach that p1 promo module that Marianne showed us they might look at and say oh We need to use the image resizer for this image. Oh and this image resizer It's it's really clunky to work with it needs some refactoring or how we're fetching data over here for this p1 It's it's not very elegant. I think I'm gonna rewrite it And so all of a sudden we've taken a very small scope module and really really extended the scope But the positives are there work They're continuing to improve on a framework and plugging holes in framework and pieces of code Carefully tested disciplined always seeking the industry best industry standard practices slower time to market overengineering You don't know anyone like that. Do you? maybe The craftsman very very important These are often under look coding styles and people that you work with every day. They are the steady dependable Delivering consistent on-time code. That's very very reliable Sometimes they can lack innovation and deeper technical expertise They might approach that p1 module like this They're using two keyboards and emacs not really Who uses emacs? They might approach it. Oh I wrote 60% of this code last week or code like it. I'm just gonna copy my code I'm gonna bring it over here, and I'm gonna reuse all this code great And that's awesome because we're keeping on the company standards We're doing a lot of reusing but not so good because no one has stopped to think Hey, is there a better way to do what I'm doing? Is there a better way to solve this problem and maybe copying the code that I used from last week is great? But if I'm copying codes from a month ago a lot of things can change in a month Overall The craftsman is a very very important addition to the team often overlooked by the other coding personalities Now adding web components in the mix on top of these styles You know web component development really resonates with each of these styles in different ways The artists they get to forge ahead on these on on these new best practices They get to blaze a new trail because we've been building the things the same way for a very long time They get to go back to the drawing board The scientists well, they get their standards based web development, you know, even though this is a very free solution They get that encapsulation they get clean organized code and the ability to test things logically so the scientists they love this And the craftsman will they get to use familiar tools and technologies that they already know a shimao CSS and JavaScript and Polymer has such a straightforward Simplified API. It's not like throwing a whole new Abstracted web framework at a craftsman expecting to them to learn a completely new API and framework They get to use the tools that they already have that's how web components resonates with each of these styles So an important we know and we understand these different styles a little better So how do each of these styles? Work together. How do you balance a team with these styles? And we have to remember and when you're working with a team with different style coders we're all in this together and We can either be building each other up or tearing each other down and balance is really struck by The scientists bringing that structure bringing the hey we need to harden this and test this to the artist and The artist saying hey, let's solve this problem that no one's been able to solve yet Let's do it you know with innovation and he's bringing that to the craftsman the scientists and the craftsman is like hey reality check everybody We need to be on schedule. We have something to deliver and we just got to go go go so The other interesting thing is that this can also be applied to entire dev teams as entire development teams sort of lean one way or the other and How do you solve for? Team-to-team interaction that's even harder than you know just managing a team and figuring that out amongst a team and it's through Empathy it's through Clear communication and it's through cooperation So empathokies throughout that word. Well, what does that really look like practically? Well, it's like a bunch of scientists on a team saying I Can't believe they don't have a hundred percent code coverage in that project And we do this all the time and let's so stop and let's empathize. What does empathy look like here? Well On epony under empathy and understanding says well, maybe the team is focused on delivering something fast within perfect code Maybe that's what this particular team needs and they're focused on right now and then the artists Why aren't they using the absolute newest way to build things? Well, let's empathize Maybe it's safer and easier to build on a proven industry standard for their project than going off the rails and building something else Because what we want to do we want to fight against extremes and both the artists and the scientists they can look at the craftsman and say They're not real coders They're not up at three o'clock in the morning contributing to open source repositories every night But they're the bread and butter. They're the ones that are they're churning out all this work And we have to fight against extremes We have to remember to empathize or else craftsmen will get imposter syndrome and The walls of hubris and ego will be built up With scientists and with artists So now Josh is going to talk about how we've structured our web component developer experience specifically Josh So we put this into practice on our dev team in a few ways The first is focusing on the API over the element implementation Because there always be times when you must compromise on code quality where speed to market is just more valuable to the business than having the absolute most rock hard rock solid code ever So what that means is like focusing on the reviewing the API, which is the names the properties and public methods of an element The implementation of all those things can be refactored later very safely without having to worry about anybody breaking anybody else's code The way we actually make sure that that refactoring actually happens on our team is we have a program We call adopt a module and that means we just bake in some time to every sprint Where we allow developers to go back and review modules that have been maybe sitting around for a while that we haven't touched and Clean up documentation clean up some JavaScript that might be a little messy Maybe some styles aren't implemented as cleanly as possible And that lets us kind of get code out to market quickly But still come back and make sure we are having really good code that will be maintainable and long lasting So what that looks like in practice is this is a really simple sample element and showing a good API with some bad code So you see there's just horrible little string function. That's Filtering out spaces for some reason But it's got a nice name for the element It's got a good property title and all the bad stuff can be refactored out later on the flip side You've got a bad API good code module, which is Got a really nice implementation for the filtering. It's just much cleaner. It's got some error checking but there's a problem with it there's misspelling in the title change handler and You can't go back and fix that because if somebody else is already using that you can't fix that spelling and the property Is just called t so now all the elements that are set t equals whatever They're gonna have to change that and then the element names not even that great So this is an even bigger problem when you're dealing with other teams Using your code and it's the biggest problem when you're actually open sourcing your code And the rest of the world is using your stuff You don't want to be breaking their applications because you got a little sloppy at the start So to get this focus we kind of build things backwards. We call it demo driven development We start by building examples of how the code will be used how the element will be used and This is pretty easy because of the spec documents We have they list out all the different variants that design has told us that we should account for So we can show what each of those look like and think about how the element will be used to build out each of those things Once we have that solid and we like it Then we actually built the elements implementation and then finally we'll come through and add tests and make a production ready so what this looks like for our promo module is Listing out stuff like the normal variants the version with no no image a version for video Version for galleries and all this lives in a demo file That's right next to the element and it gets heard through our custom dev server So as you're developing your element you can be testing on this this demo page and as you build out the implementation Things start to come to life and when the whole page is working, you know, you're done you ready start building those tests so the last thing that we get from web components is division of labor and What's nice is you can break out who works on which element based on their skill set So if you've got an element that you say well, we're really not sure how to build this thing out very well So let's give that to our artists because they're going to be able to come up with an interesting solution for this If you've got an element that's really complicated and you need someone who's going to really put a lot of tests behind it and Then get that one to the scientist And then if you got an element that you know exactly how you want to build it But you just need it to be built on time and get it out at the right moment Give that to your craftsman And then the great thing is you can always come back and have the other style do the refactoring later And so the the scientist can come in and clean up the artist code and add some more tests Or the artist could come in and say oh craftsman you could have built this a little bit better And so if you get that kind of interaction, it's great So we hope this glimpse into how we build things will help you build great things with polymer as well Thanks for having us here and have a great rest of the conference