Clarity Conference: Beyond the Toolkit: Spreading a System Across People & Products

At Clarity Conference in San Francisco, Nathan Curtis talked about making design systems and how to make sure they take root at your organization. Here are my notes:

  • Google hit a home run with Material Design, but is it all really that consistent? There are disparities across their products still.
  • Type, color, and iconography are three big elements that we pay a lot of attention to when evaluating consistency.
  • People might design a bunch of different card designs. Are they solving the same problem? Should they be normalized?
  • Component cut up workshop – Print out screens and have people cut up the UIs. Afterwards, start categorizing those components. It’s a great exercise to get teams thinking about components and establishing a shared vocabulary.
  • Making design systems involves defining the parts, products, & people.
  • Establish a roadmap – what are the expectations of this initiative? What can we tackle first, and where do we want to end up?
  • Mission accomplished – we just launched our living style guide! We love our artifact! But then the discussion stops and it immediately stops being useful.
  • A successful design system has to create a more cohesive user experience, encourage collaboration, and create efficiencies.
  • The design system can be broken into parts, people, and products
  • Parts – what does the design system encompass? Voice and tone? Components? Code? What are the priorities? Nathan has a worksheet and exercise to help teams figure this out.
  • People – who is the design system supposed to reach? Meta tools for other builders (Foundation & Bootstrap), Material Design (people making things within Google), Harmony (a portfolio’s guides), A team’s playbook
  • Sometimes a style guide fails because it didn’t live up to expectations and aspirations. Not everything needs to be Material Design, but it should be useful. When they don’t take root people become discouraged.
  • In order for the design system to be successful, you have to define what’s going on
  • Choose the flagships products: what are the main products that are going to be used to create the design system? What are the auxiliary products. Define what the priority of products would be, and sse their launch dates to establish your roadmap.
  • What’s your get? Portfolio of web properties – (Home Products, Support, About us, training)
  • Avoid distractions when establishing your design system. What are distractions for the design system? Homepages! Very political, often bespoke designs that don’t necessarily fit in with the rest of the UI. Start elsewhere.
  • Build one-offs. It’s alright to build things that are one offs. Not everything needs to run off of the design system. (Related: design system flexibility). Doesn’t need to be a dictatorship.
  • Hook system access via code they’ll  use first. Get the basic shell of the page (header, footer, etc) to work across the entire experience and people will be excited to normalize more of the UI.
  • For Marriott: they have web sites, web apps, native apps. Success with a design system means moving meaningful metrics, such as increasing bookings.
  • Radiate influences from web apps – Web apps are often the most trackable,transactional, utilitarian things and can be good candidates for leading the design system creation.
  • Demonstrate value across the journey – Rather than working in independent streams making a bunch of static PSDs, make integrated, responsive, clickable prototypes. Livia Labate – “The [clickable prototype] demo convinced me anyone in 1 minute, leaving me 59 minutes to dig into heftier topics.” Show don’t tell, and showcase the entire journey rather than one stream.
  • People – How are people set up to make and manage the design system?
  • Model 1: Solitary – One person makes it, and everyone should (or has to) use it. Doesn’t get used because it often doesn’t take other people’s considerations into account. Overlords don’t scale – Sun had one guy who made a style guide, but it doesn’t scale.
  • Model 2: Centralized – Build a centralized team to service the design system. This is great as you have dedicated people maintaining the system. But those people lack of specific product context, so it can be difficult for those folks to know whether the system is working or not out in the real world.
  • Design systems are evident in modern organizations. Modern organizations are reorganizing to make design systems a priority. Change titles – Jina Bolton changed her title to explicitly mention “Design Systems” rather than just “Product Designer”. That stuff matters.
  • Model 3: Federated – People are distributed across teams, but contribute to the centralized design system. There may be dedicated people on a design systems team, but there are people on individual teams who contribute to the system.
  • Find your inner connector – Some people will want to drive change, some people influence change, and some people won’t care. Watching people who are driving, influencing, ignoring, design changes.
  • @cap’s sliding scale of giving a fuck – Create a framework around how strongly people feel when there’s a disagreement.
  • Designate “go to”s, not deciders – in a federated system, Go-tos are people who are embedded in teams across different disciplines who are aware of all the decisions made around the design system. Still dedicated to their teams but are the go-to people when there are questions around the system.
  • Mix doers with delegators – The doers are in the design tools dealing with the problems and constraints of the design system. Delegators are directors that have power to make change. Mix those people together for successful results.
  • There will be people who will make the design systems, but those people need to be aligned with other people across the organization. Who are those product owners and other people who will be impacted by the design system, and how can you make sure the design system aligns with their needs. Help them become advocates.
  • After every design system project, Nathan’s company asks the team members: what was satisfying and what was dissatisfying? Some feedback: “Alignment is too squishy and is hard to define.” Not as tangible as other aspects of the process.
  • Embrace new responsibilities: you might be a maker, who’s used to designing, writing, collaborating, reviewing, etc. But as the design system grows, new responsibilities emerge: product manager, editor, seller, evangelist, connector, aligner. Not everyone is cut out for these tasks, but it’s important for some people to own the design system.
  • Have a CEO or executives make the design system a priority. “First things first: you muse have total support from the top.” Having top-down initiatives helps make design systems happen and take root.
  • A design system is a living, funded product.