A Comprehensive Guide To A Successful Design Delivery While Building A Design System

Hi. I'm Davy. I'm here to talk to you a little bit about how to build a successful design delivery process while building a design system. And I've spent time with a team of federated platform leads and design system practitioners, experts in crafts and deliverables as a part of being on the design systems team for Disney streaming. And we found extreme success in being able to really break down the communication barriers between design and engineering by being brought up under design ops and under our former leader Bailey Brenner Brosius, who is also presenting here at UXDX.

I have a deep interest in podcasting and being out in the design systems community. So earlier this year, my colleague, former colleague PJ Onuora and I had started a design system Office Hours podcast and really taking the sentiment and the excitement of our office, and our practices and having a spirited conversation between two design system practitioners about how we scale design systems in our separate company. So myself, at Disney Streaming, and PJ from Pinterest. So there's always going to be two neat points of view. And we're here really to discuss things all the way from design management to tasks, task management, Jira, and also the elusive Figma Out of Design System, which is our Episode five.

So the Disney streaming design system really supports primarily Disney+, Hulu, and Star+. And these are the product teams that we work with day-to-day. There are approximately 60 designers and about 8 design system folks that support this.

And we've had the pleasure of really working on this growing multi-brand multi-platform design system. And when we talk about multiplatform, the very most unique one that you may see here is the television and game console. So we support web, responsive web, mobile and tablet, and a wide array of television platforms. Our product design goal is to reach as many Disney fanatics as possible, no matter what device you're on, whether you're on a very high-powered gaming console to your Chromecast and your fire and Roku stick. So we're really trying to design for everyone in all locales.

In 2020, we really took the effort to take 100,000, which could be an arbitrary number here. But really looking across, how might we design, design system patterns across various brands that are under our portfolio. So we took this time to form a horizontal design team supporting all of our brands and our designers on all of these brands are able to design across multiple platforms at once. And what we're looking to do as design system folks is really encourage patterns to be brought over not only across platforms but across other brands. So a perfect example would be if you're designing something for Disney+, we really encourage you to talk to your Hulu partner and see if there's a need for this pattern to really extend this beyond as far as we can.

So, Growing the team. We did have limitations of design systems being under, originally only under Disney+. So that was our support model and we don't have embedded engineers on our teams and how we really set up on that platform. Previously, engineering had its own distinct client engineering platform teams, and what we really try to do as platform leads in this federated world was we would just really work with our engineers in a very pair programming, pair design sort of way. And previously we would start with one designer per screen size. So like I was a web platform lead, we had a mobile platform lead and a living room platform lead. And amongst our platform expertise, we really tried to pair as much as we can on our own and really build those relationships when we were in a federated model. And really, the key point here is that you could really start no matter what maturity level you're in.

So this is a very typical product design story. So in the times where we were federated and we were only really working with engineering later in the process, designers really like to work at their own pace, so they feel the time that's allotted to them. So a lot of the design decisions by the time the discussions make it to our engineering partners are already more or less made, and we've already biassed ourselves in specific design solutions.

And one of the major things that we've seen when we don't have pods or squads is when design development teams don't sit with each other. There's really a little bit more of a disconnect because there's not this continuous conversation happening. And what really occurs then is designers bundle this work as a gift from above, so to speak, to deliver to engineering at the end of the process.

And this is really what it felt like for a lot of us working in design systems is that this is a real truck and. No kidding. It felt like this truck was going to be backing up beeping and about to give us all of this work. And then the traditional handoff as siloed teams is not agile as we like to think. Even if the product teams and design teams follow these agile processes and plan the work in this way, if they're really holding the work to be handed off all at once at the end of the process, it really negates the Agile process.

Another thing just to note, especially for people that are new coming into teams, is that any process that has worked in the past can always be challenged and can always be improved. So don't be afraid to ask a product person and engineer what might make this process better.

So the main problem that we're looking to solve is that Disney+ product design teams and platform engineering teams do not work with each other on a regular basis so that there is this disjointed process that we've seen, that there's really more of a collaboration between product managers and design and design systems was a little left out and then engineering was a little left out.

I like to think about sort of wireframes and sketches like this beautiful one of this cake on the left. So, We're very, I think used to designing as designers something on the right. So we'd like to build something as beautiful as possible and what is in our vision. So this beautiful, gaudy cake is the final output. But what we really want to promote is doing some more low-fidelity explorations and being able to be comfortable with talking to engineers when there's something just like a sketch that has annotations and a distinct point of view. So while the fidelity of the picture on the left may not be to your liking, we could develop requirements against this. And it certainly is enough to really spearhead a conversation with engineering and the design systems team is here to facilitate this and here to get you a better starting point. And we're here to help and invite everyone to come and work with us.

So our product design life cycle is very similar to the double diamond cycle where there are three distinct tracks or not tracks with three distinct phases of the work. So there's explore and define, refine and deliver. And as you see, it's three phases of work that are linear and waterfall. We may not think of it being that way when we're in it, but there's an explicit gate at the bottom of these first two phases for approval that really drives us going to the next phase. So here, product and design are represented in this blue and butterscotch, but for the most part in the first two phases, product and design are working extremely iteratively as they go through product requirements and iterate on them. And there's a gate at the bottom of the and defined for exec approval through refinement. There's another gate at the bottom that denotes go or no go from execs. And once we get to the delivery phase, historically, that's when you see the pink and green, which is a design system, and engineering groups really getting involved in earnest. And at this point, you see that designers are refining their final design solution. And in the past, that's when they tapped our team to help build these cross-platform deliverables. This would then feed into engineering intake and then this would feed into the build process.

So this is what the old way sort of looked like. So designers would work autonomously on their own for what seemed like it could be multiple sprints over two weeks. Usually, it's for a few months. And at the final spike to deliver this, they tap us on the shoulder and really need our help to push the delivery forward. And that was the old way. With the barf emoji there. And what we're really looking to improve on is this iteration, Continuous design cycle, and working with design to not only intake their requests on our variants on our component library but work continuously with them as they're working through the discovery process to really work in parallel and attempt to follow along and build alongside with them. So

The reason we're doing this now was post-launch. So we launched Disney+ in 2019. We really wanted to take a break from really sprinting and sprint to the finish line to get this app to market and look at how we can audit and scale our component libraries and our design system further and even expand on adoption. So our pilot that we wanted to intake was we were looking to develop an application star+ that was a Latin American version more or less of the Disney+ app. So we rebuilt a new application for the Latin American market, had similar content, and even more, licensed like sports content. But it was built on the bones of Disney+. The goal was that we needed to build this application with a different brand voice. So we really took this opportunity to show two distinct working groups of that product and design, working group and design and engineering pairing together.

So you see these two parallel tracks that we were looking to promote. So design and product are going to be working together in lockstep. The difference in this approach versus the previous approach was that we're interjecting our design system. Practitioners and engineering and weaving it through different parts of the process. So as the product team finalises its requirements, we are there with design to really help them triage, pull whatever templates are available and really get them to the best starting point possible and the Engineering Cross-functional piece also is able to pull that earlier on into the process. So as soon as designers are able to build a starting point with our components, really get early cross-functional feedback from engineering and really de-risk not showing them something until the end of the line. And we've done very well at, I think, establishing these lightweight cross-functional shareouts so that they're very similar to the office hours that the design system team runs. And what we try to do is sort of facilitate this discussion with the design ices and engineering ices and really have this open door office hours process where we set aside half an hour chunks of time on a weekly basis and have designers that are ready to show work to engineering just really show and get early feedback.

So we're really trying to connect the dots as a hub and spoke so as design system team working on design delivery we've been the single point of contact for design deliverables and that really put us in a good faith position with engineering to really partner and grow and really spread the gospel, so to speak, of working and this really collaborative fashion. And we're able to connect designers together to engineers and really break down the barriers of our traditional handoff process. And it becomes building with design, design system building with design and utilising their contributions and their feedback to really build back into the system via components and templates.

And we want designers to feel okay and to feel safe and create this culture where sharing work that is not finished is okay. And previously there was this philosophy, I think, from a lot of the engineering leads that we really wanted to guard the engineering team's time. We don't want engineers to work on anything that was not fully baked and finished. And if we continue with that philosophy and work in such a way, teammates across functions will never really get to partner with each other.

We hear this phrase a lot. I work with engineering by getting them involved early and often. And I always like to ask, do you in earnest. This typically means that you're not working with engineering in a continuous fashion. We get a lot of this also with hearing, oh, you got to work with the design system team early and often. So I have that same point of view on that. And while we don't have pods or true cross-functional teams, we really strive to have all partners in meetings as soon as we're ready to really get early feedback and we should solicit implementation feedback from engineers versus dictating how design thinks something should be built.

It's a really good value that we really like to leverage and look to and continue to look at on a regular basis while we're working is that we want to empower product teams across all brands to build from and for our design system. So this means distinctively being brand agnostic first for flexibility. So previously I'd mentioned the example of if you're building something for Disney+, let's talk to a Hulu counterpart to see if they wanted to utilise that component so that that is a distinct example to tie back to this value. And that means that we're not brand forced and have the idea of limited scalability, so we're no longer trying to design patterns that are only for one specific brand. This also means that we get to jump into the fun of design tokens and expressing brand voice through these foundational tokens. So we'll talk a little bit more about that in a few slides. But that means that we're designing a framework that works across branding and can be extended to accept even more brands. And this does not mean that we're working on subsystems that are different from each other.

One of the major outputs that we had was this, we have this front end and a design Jedi Council meeting that we've gotten together with the engineering management. And we really formed this to just have a weekly cadence to discuss a design system, to work with engineering. And I had started this with another design manager a year and a half ago, and this really includes designers on the design system team and then platform engineering leads from each team to design, design, and work in this cross-functional way. And we were able to talk a lot about theming and reuse of type ramp across apps, which really led to us speeding up the engineering sort of a timeline for Star+, we talked about unifying a colour app across all of our brands and platforms and we continue to utilise this group also to talk about this stuff. How are things working from the artefacts that they're receiving? Can we reduce the design delivery artefacts and how might we make this easier for engineering to consume? And one of the major improvements to this was as we opened this up to individual contributors, we've been bringing them in as needed and they've been able to de-risk a lot of the work by getting ahead and getting potential very early feedback on implementation details and really allowing us to take a further look ahead so we don't have to revisit large chunks of work further in the process.

So it's this continuous design and development. So we've sort of in our own ecosystem formed this meta agile workstream with designers and also with engineers. And we're unblocking work as early as we can by delivering smaller chunks of work as well. So the support model does take a bit of commitment. So from a designer and feature designer point of view, design systems, and feature design a point of view, there's probably about 2 to 4 hours a week from members of the design systems team just to meet with future designers, to continue to educate people about how to utilise the design system, how to build in this component fashion, and really how to extend your work as far as you can. And we've also had great success just having these asynchronous conversations also in Slack by having a support channel that we're really able to triage requests as soon as they come up and any designer on our team has been very open about answering support questions as quickly as possible. And it's really created a very good relationship between design systems designers and feature designers.

It's a little bit about design tokens, the foundational tokens that have been very successful. So we dove deep into supporting design tokens just for typography, which includes things like type size, line height, letter spacing, brand colours, and utility colours, and spacing in general. So the first two have immediately paid dividends to Disney and Star+ are two brands that live in separate locales. Disney+ has launched in many different languages and including in Asian Pacific, where we needed to introduce new typefaces. And because of the type alignment work that we've done with typography tokens, we were able to extend the support for new non-Latin typefaces. So a lot of the work that we're doing early on to think about the future has been paying off very, very quickly.

So there's a notion that the design system seems to work smarter, not harder. We used to, in a sketch, many, many moons ago. Do a lot of hand redlining. And we had assumed that our engineering partners really preferred to look at stuff this way and with Figma and with Zeppelin and their ability to really do inspection where you don't need this sort of thing. And one of the major outcomes for Star+ also was that we were looking to deliver in a smarter fashion. To deliver things and much smaller discrete chunks versus this large delivery of assets. And this allowed us to focus on what information we wanted to convey. What are the different deltas between them? What may exist in the past versus where we are going to?

And this was something that is really, really fun to look at in Zeppelin. So in Zeppelin, we were able to deliver components and export components as we finished them and as we export frames, that includes that component you're able to see in Zeppelin where the dependencies are. And that was just a really powerful thing just to educate engineers and designers about the idea of reusable components as well.

So we have sort of really gone through and tried to look at the atomic design model from Brad Foss and really try to leverage a lot more work on the templates and then also handing over like organisms. So a great example of what this looks like is a page template for star+ details. And there are a lot of similarities between the detailed pages in general, so they all include a background dimming scrim. Number one, they include a background image that is tied to the asset. And then number three is just the details, metadata block, that is the unique difference between all of these different detail pages. So we've found from speaking and workshopping this with engineering that we really only need to deliver one base template and then all the different variants of what that metadata block looks like. So this delivery looks vastly different from what it used to look like, which is we used to deliver screens with all these different states.

So future-proofing and looking towards what's next. We're surveying designers to understand how we could better help them deliver specs. We've also included engineering in this survey to understand how our delivery artefacts are being consumed. Do we have adequate coverage for templates? And then how easy is the system to use? So we've also established a cadence of communicating our releases and versioning and then referencing documentation on how and when different components are changing via a release log in a changelog.

So if you do take anything away from this, this is the end of the movie here. Meta agile work streams work very well for designers and working together and design and engineering. Don't be afraid to ask for help from the design systems team. We're here to help you get started. The Design Systems Team could also help you facilitate better design engineering partnerships and try to deliver in smaller, discrete chunks. So no piece of a component or a sub-component or any piece of design is too small to engage someone in a conversation with. So I'm Davy. You could follow me on Twitter. You can visit my link tree and the link to the podcast is there. It's been an honour and a pleasure. Thank you.