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

Davy Fung at UXDX USA. Video: https://www.youtube.com/watch?v=MSgEugCnZyI

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and the Disney Streaming design system

[00:00:00] 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. I've spun up a team of federated platform leads and design system practitioners, experts in craft and deliverables, as a part of being on the design systems team for Disney Streaming. We found extreme success 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 Brazilian [?], who is also presenting here at UXDX.

[00:00:48] I have a deep interest in podcasting and being out in the design systems community. Earlier this year, my former colleague PJ Onori and I started a Design System Office Hours podcast, taking the sentiment and the excitement of our office hour practices and having a spirited conversation between two design system practitioners about how we scale design systems in our separate companies: myself at Disney Streaming and PJ from Pinterest. There are always going to be two new points of view, and we're here to discuss things all the way from design management to task management, Jira, and also the elusive Figma is out of design system [?], which is our episode five.

[00:01:47] The Disney Streaming design system primarily supports Disney+, Hulu and Star+, and these are the product teams that we work with day to day. There are approximately 60 designers and about eight design system folks that support this. We've had the distinct pleasure of working on this growing multi-brand, multi-platform design system. When we talk about multi-platform, the most unique one that you may see here is the television and game console. 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 or your Chromecast and your Fire and Roku stick. We're really trying to design for everyone in all locales.

[00:02:55] In 2020 we took the effort to take a 100,000-foot view, an arbitrary number here, looking across how we might design design system patterns across the various brands that are under our portfolio. 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. What we're looking to do as design system folks is encourage patterns to be brought over, not only across platforms but across other brands. 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 extend it as far as we can.

Growing a federated team

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

The typical handoff story

[00:04:57] This is a very typical product design story. In the times where we were federated, we were only really working with engineering later in the process. Designers like to work at their own pace, in the time that's allotted to them. So by the time the discussions make it to our engineering partners, a lot of the design decisions were already more or less made, and we'd already biased ourselves toward specific design solutions. One of the major things that we've seen when we don't have pods or squads is that when design and development teams don't sit with each other, there's a little bit more of a disconnect, because there aren't these continuous conversations happening. What 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.

[00:06:02] This is really what it felt like for a lot of us working in design systems. 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. The traditional handoff between siloed teams is not as agile as we like to think. Even if the product teams and the design teams follow these agile processes and plan the work in this way, if they're holding the work to be handed off all at once at the end of the process, it really negates the agile process.

[00:06:49] Another thing just to note, especially for people that are new coming into teams: any process that has worked in the past can always be challenged and can always be improved. So don't be afraid to ask product and engineering what might make this process better.

[00:07:10] 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. There is this disjointed process where we've seen more of a collaboration between product managers and design, and design systems was a little left out, and engineering was a little left out.

[00:07:40] I like to think about wireframes and sketches like this beautiful, whatever this is, cake on the left. As designers we're very used to designing something like the one on the right. We would like to build something as beautiful as possible, like what is in our vision. This beautiful gaudy cake is the final output. But what we really want to promote is doing more low-fidelity explorations, and being comfortable talking to engineering when there's something just like a sketch that has annotations and a distinct point of view. 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 spearhead a conversation with engineering. The design systems team is here to facilitate this and to get you a better starting point, and we're here to help and invite everyone to come co-work with us.

The product design life cycle, old and new

[00:08:51] Our product design life cycle is very similar to the double diamond cycle, where there are three distinct phases of the work: explore and define, refine, and deliver. As you see, it's three phases of work that are linear and waterfall. We may not think of it that way when we're in it, but there are explicit gates at the bottom of these first two phases for exec approval that drive us to the next phase. Here product and design are represented in this blue and butterscotch. 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. There's a gate at the bottom of explore and define for exec approval. Through refinement there's another gate at the bottom that denotes a go or no-go from execs.

[00:09:57] Once we get to the delivery phase, historically that's when you see the pink and green, which is the design system and engineering groups, getting involved in earnest. 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.

[00:10:29] This was what the old way looked like. Designers would work autonomously on their own for what could be multiple sprints of two weeks, usually for a few months, and at the final spike to deliver this, they'd tap us on the shoulder and need our help to push the delivery forward. That was the old way, with the barf emoji there. What we're really looking to improve on is this iterative, continuous design cycle: working with design not only to intake their requests for variants on our component library, but working continuously with them as they're working through the discovery process, to work in parallel and attempt to follow along and build alongside them.

[00:11:30] The reason we're doing this now was post-launch. We launched Disney+ in 2019, and we wanted to take a break from sprinting and sprinting to the finish line to get this app to market, and look at how we can audit and scale our component libraries in our design system further, and even expand on adoption.

The Star+ pilot: two parallel working groups

[00:11:56] The pilot that we wanted to undertake: we were looking to develop an application, Star+, that was a Latin American version, more or less, of the Disney+ app. We built a new application for the Latin American market. It had similar content, even more licensed 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. We took this opportunity to form two distinct working groups: a product and design working group, and design and engineering pairing together.

[00:12:48] You see these two parallel tracks that we're looking to promote. 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 them through different parts of the process. As product finalizes their requirements, we are there with design to help them triage, pull whatever templates are available, and get them to the best starting point possible.

[00:13:25] The engineering cross-functional piece is also being able to pull that earlier into the process. As soon as designers are able to build a starting point with our components, we get early cross-functional feedback from engineering, and de-risk not showing them something until the end of the line. I think we've done very well at establishing these lighter-weight cross-functional share-outs. They're very similar to the office hours that the design system team runs. What we try to do is facilitate this discussion with the design ICs and engineering ICs, and have this open-door office hours process where we set aside half-hour chunks of time on a weekly basis, and designers that are ready to show work to engineering can show it and get early feedback.

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

A culture of sharing unfinished work

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

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

[00:16:48] A really good value that we like to leverage, and continue to look to 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. This means distinctively being brand-agnostic first, for flexibility. Previously I mentioned the example of, if you're building something for Disney+, let's talk to a Hulu counterpart to see if they want to utilize that component. That is the distinct example to tie back to this value. It means that we're not brand-forced, with the idea of limited scalability. We're no longer trying to design patterns that are only for one specific brand.

[00:17:39] This also means that we get to jump into the fun of design tokens and expressing brand voice through these foundational tokens. I will talk a little bit more about that in a few slides. It means that we're designing a framework that works across branding and can be extended to accept even more brands. This does not mean that we're working on subsystems that are different from each other.

The Jedi Council and continuous support

[00:18:09] One of the major outputs that we had was a front-end and design Jedi Council meeting. We got together with the engineering management and formed this to have a weekly cadence to discuss design systems work with engineering. I started this with another design manager a year and a half ago, and it includes designers on the design system team and platform engineering leads from each team, to design and work in this cross-functional way. We were able to talk a lot about theming and reuse of the type ramp across apps, which led to us speeding up the engineering timeline for Star+. We talked about unifying a color ramp across all of our brands and platforms. We continue to utilize this group to talk about how things are working from the artifacts that they're receiving, whether we can reduce the design delivery artifacts, and how we might make this easier for engineering to consume.

[00:19:24] One of the major improvements to this was, as we opened it 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 very early feedback on implementation details, allowing us to take a further look ahead so we don't have to revisit large chunks of work further in the process.

[00:19:56] It's this continuous design and development. In our own ecosystem we've formed this meta-agile work stream with designers and also with engineers, and we're unblocking work as early as we can by delivering smaller chunks of work as well. The support model does take a bit of commitment. From a design systems and feature designer point of view, there's probably about two to four hours a week from members of the design systems team just to meet with feature designers, to continue to educate people about how to utilize the design system, how to build in this component fashion, and how to extend your work as far as you can.

[00:20:49] We've also had great success having asynchronous conversations in Slack, with a support channel where we're able to triage requests as soon as they come up. Every designer on our team has been very open about answering support questions as quickly as possible, and it's created a very good relationship between design systems designers and feature designers.

Design tokens and smarter delivery

[00:21:20] A little bit about design tokens and the foundational tokens that have been very successful. We dove deep into supporting design tokens for typography, which includes type size, line height and letter spacing; brand colors and utility colors; and spacing in general. The first two immediately paid dividends. Disney+ and Star+ are two brands that live in separate locales. Disney+ has launched in many different languages, including in Asia Pacific, where we needed to introduce new typefaces. Because of the type alignment work that we've done with typography tokens, we were able to extend to support four new non-Latin typefaces. A lot of the work that we're doing early on to think about the future has been paying off very quickly.

[00:22:20] There's a notion on the design systems team to work smarter, not harder. Many, many moons ago in Sketch we used to do a lot of hand redlining, and we had assumed that our engineering partners preferred to look at stuff this way. With Figma and with Zeplin there's already the ability to do inspection, where you don't need this sort of thing. One of the major outcomes for Star+ also was that we were looking to deliver in a smarter fashion: deliver things in much smaller and discrete chunks, versus this large delivery of assets. This allowed us to focus on what information we wanted to convey, and what the different deltas are between what may have existed in the past versus where we are going.

[00:23:22] This was something that is really fun to look at in Zeplin. In Zeplin we're able to deliver components and export components as we finish them, and as we export frames that include said component, you're able to see in Zeplin where the dependencies are. That was a really powerful thing to educate engineers and designers about the idea of reusable components as well.

[00:23:57] We've gone through and looked at the atomic design model from Brad Frost, and tried to leverage a lot more work on the templates, and also handing over organisms. A great example of what this looks like is this page template for Star+ details. There are a lot of similarities between the details pages in general. Number one, they all include a background dimming scrim. Number two, they include a background image that is tied to the asset. And number three is the details metadata block, which is the unique difference between all of these different detail pages. We found from speaking and workshopping this with engineering that we only need to deliver one base template, and then all the different variants of what that metadata block looks like. This delivery looks vastly different from what it used to look like, which was delivering screens with all these different states.

Future-proofing and takeaways

[00:25:15] 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 artifacts are being consumed, whether we have adequate coverage for templates, and how easy the system is to use. We've also established a cadence of communicating our releases and versioning, and referencing documentation on how and when different components are changing, via a release log and a change log.

[00:26:01] 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 working together, and for 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 and engineering partnerships. And try to deliver in smaller, discrete chunks. No piece of a component or a subcomponent or any piece of design is too small to engage someone in a conversation with.

[00:26:42] I'm Davy. You can follow me on Twitter, you can visit my Linktree, and the link to the podcast is there. It's been an honor and a pleasure. Thank you.