Upwork is the largest online marketplace for freelance talent, with over $1 billion in freelance work paid through the platform so far. As part of a mobile-first initiative last year, the design ops team launched an ambitious design system project to unite broadly distributed design and development teams. They learned that the best way to help developers and designers feel included in the design system was to position it as a product, continuously evolving. InVision’s Rebecca Kerr sat down with Dan Donovan (VP of Design and UX), Kenny Hopper (Director of Product Design, Design Systems), and Roman Vasiutin (UI/UX Designer), to discuss their strategy for socializing the design system as a product. 

Rebecca Kerr: I heard you read The New Design Frontier report recently. How would you describe where Upwork sits right now on the design maturity spectrum?

Dan: We have room to grow, but we’re getting more sophisticated about what we’re doing. Relative to the age and size of the company, I’d say we’re at or even ahead of where we should be. 

Design maturity is largely about how you engage with the broader organization, how design is weighted and thought of in the org. You can see it here in the roles of designers and researchers relative to product roadmapping. It’s about going from a reactive, production type of culture (where requests come in from product managers, and you give them back a spec) to being a strategic thought partner up front, actively helping shape that roadmap, making sure we’re building the right products for the user, not just building to meet monetary needs. 

There’s a process part of that, too, building the infrastructure you need to create the right conditions for that culture. Part of that infrastructure is putting tools like Design System Manager in place, especially as you scale. The more people you have in the organization the more important infrastructure components like your design system become.

RK: You mentioned that up-leveling design ops is a priority right now. How does the design system factor into that?

Kenny: The early form of the design system started back when we were Elance and oDesk, when there was a challenge to level-set the design standards across two different platforms. 

Last year we made a big push toward making Upwork mobile-first. That was when we built a design systems team and started to understand what it means to build a design system at Upwork. We’ve come a long way. 

Last year we had an all hands on deck approach, but the challenges ahead are about learning how best to collaborate with different disciplines. How do we align with engineering on priorities? How do we evolve and iterate our design system when we share dependencies with engineering? What about different segments of our product and different ownership for those?

One thing we’re exploring is what we can do with shared models. Where can we have other teams contribute to the design system? How can a small domain team build a small feature? How do we bring that back into the design system? If we can set up a contribution model we can free up some of the strains on a small design ops team in a large org.

The goal is to think of the design system as a living product and create a roadmap for it. We’re trying to position the design systems team and the system itself as a product that has ongoing refinements.

RK: How do you socialize the concept of a design system to other teams?

Dan: Talking about design system as a product puts it into a language other teams can understand. That was a really big push for us. Kenny is now basically considered a product manager, as the design system lead. 

When you think about it in terms of product you think of regular releases, and communications about those releases. Those are terms Product Management and Engineering understand. And it helps enforce that this thing needs a roadmap. Some of it is just iterating on components and some of it is how we consume it, whether it’s as a Storybook library or something else. And you also start to think about it in terms of the users it serves. 

RK: What are you doing to include other teams in developing the design system?

Roman:  Because it’s so simple for non-designers to access DSM, we’ll be able to use it as a common language for others outside design: researchers, developers, product managers, and copywriters.

Members of our design systems team are always ready to facilitate open office hours where we discuss new components and patterns, and see if they can be applied to our product. We consider a series of questions from a living template we’ve built over time:

• What are you trying to solve?
• Do you have a proposed solution?
• If you have a solution, describe how this will impact other teams and usage.

RK: How do those design system open office hour conversations usually go?

Kenny: At first teams came to the open office hour sessions with more generalized design questions, but we really wanted to steer them toward changes to patterns or to the system itself.

We’ve opened it up to other teams on purpose. We tell people to invite their developer or product partner or whoever they’re working with on the build, so it’s more collaborative across teams. Primarily the attendees are designers, but we’ve had developers come pretty regularly. 

The heart of the meeting is our partners, the UI Engineering team. They built the component library. It’s helpful to have them in the room hearing the feedback after components are out in the world. We bring them in to address technical pitfalls early in concepting too.

The conversations vary based on what we’re aiming for at the moment. Right now a big challenge we have is a migration on the engineering side, moving from Angular to Vue framework. That raises a lot of questions on its own. But we also look into bigger questions, like what are the best mobile patterns? How can we take an old component and move it in a mobile-first direction? 

The patterns and rules we’ve been developing in DSM have helped us streamline communication for sure. Our engineering team doesn’t see DSM as much as we do from day to day, but they do see our pattern guidelines from it. It creates better communication, which leads to better alignment and decision making.

We have documents in DSM rather than formal emails going out, like a change document on patterns. Roman is our lead for maintaining DSM, and he keeps up a change log there. We also have an open Dash channel dedicated to design system and DSM questions.

RK: Do you think using DSM has grown the impact of your design system?

Dan: We don’t have hard numbers on hours saved, but we do know this: When we bring in new designers now with DSM, it’s so much easier to help them get familiar with the pattern library. It accelerates the process of getting them going full speed.

Kenny: There’s also the fact that our design team scaled last year, and I can’t imagine our team operating the old way, with a style guide and an Adobe Illustrator file, at the size we are now. We no longer get pinged with questions like, “Is this the right color/type/size/etc.?” Our team has enough confidence in DSM that they don’t need to ask. It’s a much more solid source of truth. 

RK: How is Upwork building collaboration into the teams and processes outside the design system? 

Dan: Keeping close cross-functional touchpoints with engineering and other teams is always a priority. The team leading the mobile-first effort, for example, was comprised of functional heads from quality assurance, engineering, product, and design. The four of you were part of all the same conversations. You met three times a week, very tight coordination. 

You see that repeated at all levels. It’s a common model for any project at Upwork. The leads are a decision-making body. Together they discuss requirements, talk through design, and sync up at their own cadences, some weekly. 

You see it in our weekly meetings as well. Lots of design conversations are happening that are very inclusive of product and engineering.

RK: How do you think about scaling those partnerships as you grow?

Dan: We’ve got a Design Thinking Playbook 2.0 in the works, made for any team to use, not just design. It starts with problem-framing and goes through solutioning, iteration, release, and evaluation. It gives best practices, templates, and tool recommendations at different stages. It’s a process playbook from end to end. 

We have a rough draft of the entire thing, but the areas we’re prioritizing are areas we agreed are most important. Those are best practices around problem framing (how to make sure you’re solving the right customer problem), a new design review format, and a workstream around how to write user stories. That’s a collaborative workstream with engineering, who consumes those stories. We’re focusing on those three modules first, but we have a lot of meat on it already. 

The secret sauce is not best practices, though. It’s how you roll them out at your company that counts. How do you get that buy-in? How do you deploy it to your teams? If you can figure that with a handbook somebody else gave you, you’ve solved the puzzle.