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

Davy Fung at UXDX APAC. Video: https://www.youtube.com/watch?v=1dFx1cCNU3U

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. As part of being on the design systems team for Disney Streaming, I've spun up a team of federated platform leads and design system practitioners, experts in craft and deliverables. We found extreme success in really breaking down the communication barriers between design and engineering by being brought up under design ops and under our former leader, Bailey Berner [?], 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 excitement of our office hours 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 points of view, and we're there 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 who support them. 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 ones you may see here are 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, your Fire or Roku stick. We're really trying to design for everyone, in all locales.

A horizontal team across brands and platforms

[00:02:55] In 2020 we made 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 under our portfolio. We took this time to form a horizontal design team supporting all of our brands, and our designers on all 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: 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.

[00:03:52] Growing the team, we had limitations: design systems was originally only under Disney+, so that was our support model. We don't have embedded engineers on our teams. In how we're set up, as in that platform chart previously, engineering has its 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, pair-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 within our platform expertise we tried to pair as much as we could on our own and build those relationships while we were in a federated model. The key point here is that you can start no matter what maturity level you're at.

The problem with the traditional handoff

[00:04:57] This is a very typical product design story. In the times when 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. By the time the discussions made it to our engineering partners, a lot of the design decisions were already more or less made, and we had already biased ourselves towards specific design solutions. One of the major things 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 bit more of a disconnect, because there aren't continuous conversations happening. What occurs then is that designers bundle the work up as a gift from above, so to speak, to deliver to engineering at the end of the process.

[00:06:02] This is 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, 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 and design teams follow agile processes and plan the work that 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 to note, especially for people who are new coming into teams: any process that has worked in the past can always be challenged and can always be improved. 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 the Disney+ product design teams and platform engineering teams do not work with each other on a regular basis. There's this disjointed process where we've seen more collaboration between product managers and design, while 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 cake on the left. As designers, I think we're very used to designing something like what's on the right. We like to build something as beautiful as possible, like what's in our vision, so 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 just a sketch with 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 it, and it's certainly enough to spearhead a conversation with engineering. The design systems team is here to facilitate this and get you to a better starting point, and we invite everyone to come co-work with us.

From waterfall phases to continuous design

[00:08:51] Our product design life cycle is very similar to the double diamond, 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 the first two phases for exec approval that drive us to the next phase. Product and design are represented here in blue and butterscotch. For the most part, in the first two phases product and design work 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, and through refinement there's another gate at the bottom that denotes a go or no-go from execs.

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

[00:10:29] This is what the old way looked like. Designers would work autonomously on their own for what could be multiple two-week sprints, usually a few months, and at the final spike to deliver, 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 looking to improve on is this iterative, continuous design cycle: working with design not only to intake their requests for variants in our component library, but working continuously with them as they go through the discovery process, to work in parallel, follow along, and build alongside them.

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

The Star+ pilot: two parallel working groups

[00:11:56] The pilot that we wanted to take on was an application, Star+, which was more or less a Latin American version of the Disney+ app. We rebuilt a new application for the Latin American market. It had similar content, even more licensed content like sports, 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 between this approach and the previous approach is 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:26] The engineering cross-functional piece is also about pulling that earlier into the process. As soon as designers are able to build a starting point with our components, they get early cross-functional feedback from engineering, which de-risks not showing engineering something until the end of the line. I think we've done very well at establishing these lightweight 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 between the design ICs and engineering ICs and have an open-door office hours process, where we set aside half-hour chunks of time on a weekly basis, and designers who 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.

[00:15:20] We want designers to feel okay and to feel safe, and to create a culture where sharing work that is not finished is okay. Previously there was a 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 is not fully baked and finished. If we continue with that philosophy and work that 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, "Oh, you've got to work with the design system team early and often," and I have the same point of view on that. 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 get early feedback, and we should solicit implementation feedback from engineers rather than dictating how design thinks something should be built.

Brand agnostic first and the Jedi council

[00:16:48] A 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. Distinctively, this means being brand agnostic first, for flexibility. Previously I mentioned the example: if you're building something for Disney+, talk to a Hulu counterpart to see if they want to utilize that component. That's a distinct example that ties back to this value. It means 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, but it means that we're designing a framework that works across brands 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.

[00:18:09] One of the major outputs that we had was this front-end and design Jedi council meeting that we've formed together with engineering management, just 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 really 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 use this group to talk about how things are working with the artifacts they're receiving: can we reduce the design delivery artifacts, and how might we make them easier for engineering to consume?

[00:19:24] One of the major improvements was that as we opened this up to individual contributors, bringing them in as needed, 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 look further ahead so that we don't have to revisit large chunks of work further in the process.

Continuous design and development support

[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, it's probably about two to four hours a week from members of the design systems team, just meeting 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 with asynchronous conversations in Slack, by having 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:21] 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, for brand colors and utility colors, and for 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, and because of the type alignment work we've done with typography tokens, we were able to extend to support four new non-Latin typefaces. A lot of the work we did early on, thinking about the future, has been paying off very quickly. There's a notion on the design systems team to work smarter, not harder.

[00:22:26] 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 things that way. With Figma and with Zeplin, there's already the ability to do inspection, so you don't need this sort of thing. One of the major outcomes for Star+ was that we were looking to deliver in a smarter fashion: deliver things in much smaller, discrete chunks rather than one large delivery of assets. This allowed us to focus on what information we wanted to convey, and what the deltas are between what existed in the past and where we are going.

[00:23:23] This was something that is really fun to look at in Zeplin. In Zeplin we're able to deliver 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 for educating engineers and designers about the idea of reusable components as well.

Templates instead of screens

[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 on 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. They all include a background dimming scrim, number one. 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 these different detail pages. We 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. This delivery looks vastly different from what it used to, which was delivering screens with all these different states.

[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 the 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 of referencing documentation on how and when different components are changing, via a release log and a change log.

Takeaways

[00:26:01] If you take anything away from this, this is the end of the movie here. Meta-agile work streams work very well for designers, and for design and engineering working together. 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 can also help you facilitate better design and engineering partnerships. And try to deliver in smaller, discrete chunks. No piece of a component, a subcomponent or any piece of design is too small to engage someone in a conversation about. 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.