Panel: Design Systems and Documentation
Dave Malouf, Director of Product Design at DigitalOcean
David Cronin, VP UX Design at GE
Adelkunle Oduye, Product Designer at JustWorks
Amy Thibodeau, Content Strategy Lead at Shopify

Submitted by Natalie Hanson (Official Tripnoter)

From the Design Operations Summit website:
Designers need to work with developers. One of the core ways they have learned to do this is by taking something from the designer’s playbook—pattern languages—and mapping that against one of the chief learnings from contemporary engineering: componentization. By using design systems and associated object based documentation systems, design leaders have helped to reshape the designer/developer universe and improve operations within the software development lifecycle. Facilitated by Dave Malouf.

This morning we are going to talk to people who are working in organizations with a strong operational culture. To get started, Dave is going to help us get to know them by asking what is inspiring them today.

Adelkunle is a product designer at JustWorks. Outside of work, he is inspired by travel. The most inspirational place he’s been to is Paris. Being influenced by how other people live, and how they eat. Traveling is time to decompress and step away from day to day work. Dave is VP of UX at GE Digital. His current inspiration comes from reading fiction. MK Jemison just won a Hugo for her trilogy – emotional landscape to historical forces, and it puts you in a place you can’t get to any other way. Amy is Senior Lead for Shopify’s application platform. She just renovated 100+ year old house in the south of France. She has been in places where everything was quick – London, Silicon Valley. In the south of France, things just don’t move quickly, so you have to slow down to match that pace. But now she is back to reality. 🙂

First, a question from the audience.

They have design systems, but not the governance to support. How have you addressed that?

Jen – Shopify launched Polaris in April, and they were rushing to launch they hadn’t thought about governance much as all. She spent a big part of the summer thinking about advocacy and governance. How do we balance control of the system (for clear standards, components) and clear ownership. But a system that isn’t dynamic, doesn’t allow for contributions across the company. So, they have established some clear contribution guidelines, for components or documentation. They have a reviewer structure set up on GitHub, which is triggered by adding the right tags to contributions. Its not about enforcing rules. There are documented Dos and Don’ts.

Dave – At GE we’re on our fourth major generation of design systems. We have stuck to ‘tools not rules’, because no-one is excited to follow a bunch of rules. It is important to achieve alignment through co-creation, as Jeff Sussna said yesterday. We do this when we are creating new components, and also when we help users of the design system actually use it for their own product – it’s better than an unhappy design review at the end. That has worked best for them. They have also done report cards (for executives). In that case, the main value is not buy-in, but it does create executive respect for the work effort involved in re-factoring.

Adelkunde – It has to be easy to use. If you want people to use it, and use it properly. For more complex industries. It has to be easy for everybody – designers and developers. Designers have to make developer jobs easier.

There was a moment where you had the idea – or someone came to you – for the idea of a design system. What was the mandate or desired outcome? How did you envision it and help make it happen?

Adelkunde – As the team grows, how do you make it consistent. NASDAC has a design system before he started, but he knew they needed something to make it easier, especially for front-end prototyping. They started using Bootstrap, and then their own custom design system. They went through three iterations, each solving a specific problem.

Dave – For them it was both developer productivity, and efficiency in design. We had 300 developers and we went from 10 to 50 designers. The demand was high, so we also needed developers to be able to work without design.

Jen – Increasing complexity, a larger organization working across different platforms. And we acknowledged inconsistency across touch-points. We were wasting a lot of time – we had many versions of the date picker, for example. Someone on Reddit had come up with ridiculous ways to come up with one simple task. It wasn’t quite that bad!

How much are design systems focused on usability? But the larger question to talk about is how we question / not question the divide between usability and product strategy / product value. Are you further divided from those conversations?

Dave – He sees a direct connection between usability and value. The customer outcome is something specific – saving money on fuel costs, or reducing downtime on a big piece of equipment. Usability is at the bottom of Maslow’s hierarchy of needs. The design system enables the design team to focus on the meaty problem without worrying about the nuts and bolts. We have asked the design system team to not work in the abstract – they work with a specific product team, and then generalize it.

Jen – Yes, agreed, the UX / design system team has to work on real problems. In their team, they have front-end development, content strategy, design, and research. They have to make sure the components are accessible and responsive, regardless of screen size, or if the user is using a screen reader.

Adelkunde – They weren’t testing for color-blindness, and they had to start thinking about how to make those people’s lives easier.

Jen – For every single component, we talk about it’s purpose. Each component is framed around a merchant need, which grounds us in the user experience. Documentation is also written that way. Anyone who wants a new component needs to document in a similar way – not in abstraction.

A lot of the conversation is Design Operations assumes that design systems are there, and are necessary. Dave wants to challenge that. What do you feel about the criticism that design systems are a limiting factor to the value design can bring to an organization?

Jen – Constraints are key for creativity. Without them, a design practice churns and is not grounded. And business needs are a constraint. The design system allows the team to focus on the core strategy and goal.

Dave – He does see the point. There are good systems, and not good design systems – and he has had a hand in both! In their four generations of design systems, they were creating a new generation of the design system for a new product line. The one that was produced for one product line was due to the need for speed. But some people found that the design system was limiting, there weren’t enough tools in their toolkit to create better outcomes. So a good designer also needs to think through whether they need to invent on top of the design system that has been provided.

Adelkunde – He likes to live outside the box, and design systems keep you in a box. He was a painter before he was a designer, he needed time to explore, put more emotion into the work. Focused only on solving the problem is good – but 20% needs to be able to explore newer design. That makes you focus on experience and how you can add on top of that.

What makes up the operations of your design system? How do you operationalize it?

Adelkunde – It requires dealing with tools. Maybe it’s front-end prototyping with documentation about how to use the tool. Or you might have a Sketch design system, for people that are not so comfortable with code. A change in the code base should result in changes across the design system. No one tool does that well – operations and scalability within the system. How easy is it to update?

Dave – They treat it like a product, it has a product manager, there is a backlog that is managed and groomed, they have quarterly releases, daily stand-up. It is a pretty healthy Agile culture. We have a Kanban board too, so people can see progress. They run tons of automated tests before anything is checked into GitHub, and the documentation is build off of GitHub. There is a Sketch stencil that can be modified (but with impact on developer effort). They have release notes, a dedicated QA person – the design system is truly treated like a full blown product.

How many total people?

Dave – It’s between 10-15, with some people (like interns) coming and going. Today it is 14 people with QA, product management, engineering, design leader, design team, and an engineering lead. Frog built it for them initially. They had 10 people even for the initial version. But because of how the code and stencils are consumed, we have to be diligent about getting that right.

Jen – We have a smaller team, it’s first generation. We don’t have a QA person. We just recently got a product manager (Jen used to do that role). It has been messy, but the team is looking for other ways to operationalizing tools into the process. They have a tool that has content rules – RoryBot will flag things that don’t follow the content standards, for example. They are looking at more and more of that. Of course we want people to use documentation, but it doesn’t always happen so we are trying to create checks and balances to give people feedback.

What are the pros and cons in a multivariate testing environment?

Jen – We do some A/B testing, we have a research dedicated to the systems team who does a range of usability testing and monitors how components are functioning. But we leave a lot of that to the designers – to poke holes in our approach. We are pretty inconsistent about how and when we do it – it’s pretty scrappy at the moment. We do share out what we learn – both within their team but also to those building third party apps on their platform.

Adelkunde – It was two designers and they were building a system. He never worked in a place where it was his main job. They needed to do what they could in 10% of their time. The goal is to have the ability to test it out – but they haven’t done a good job at that.

Jen – how have you managed that balance?

Adelkunde – He was him and a data viz expert, they added a content strategist, a visual designer, a front-end developer. That enabled him to become more of a project manager. That allows people to get ownership of some aspect of the system, too.

If you are just starting a design system today, what would you tell people to think about?

Dave – It doesn’t replace UCD. Don’t skip sketching and go right to high fidelity prototyping, just because you have a design system.

Adelkunde – Make a proof of concept before investing too much into it.

Jen – Break your design system, your components. We create best-case scenario, beautiful components. Things like translation will break them. Stress test them so you can account for that in what you are building.