Fig. 22 A Guide for Developers

Empathy Systems

Won't you please think of the developers?

Written by Andy Rossi August 16, 2017

It’s important to note that when a design system is being built, it is not always being consumed by the team building it; design systems are developer systems too. The ultimate goal in a design system is to create a package complete with specs, examples, reusable items (in design files or in code), and plentiful documentation.

Unfortunately, some decisions may have been made during the design process without taking developers’ needs into account. When building components to be passed on to another developer or team of developers, there are some points to consider:

  1. How does the current component fit into an existing codebase (if there is one)?
  2. Does the API make sense for how the developer works with data?
  3. How helpful is your documentation? Does it make things more confusing?
  4. Did you talk to a developer at any point during component implementation? Did you request feedback?
  5. Was there any follow-up after “throwing the system over the fence”?

Let’s go through each of these points one-by-one, shall we?

Snowflakes and The Wheel 2.0

The design system might be starting from scratch, but usually the target codebase isn’t. Design systems get a slow-burn integration in some cases, so there will be time to add each new component to a thriving ecosystem and see how it fares.

There you go, little guy! Live! Be free!

But how easy to integrate is this new component? Is it a drop-in replacement or does it have slightly different requirements than the previous version?

// Before
<Component data={someArray} />

// After
<Component data={someOtherDataStructureWhichBreaksEverything} />

If the component was supposed to be a drop-in replacement for an existing component, why did the requirements change slightly? Was this communicated or expected?

Let’s address this again in a minute.

Wait… How do I use this API again?

So a component was built, it has a quote/unquote simple API, and the developer should just get it. Boom. Your job here is done.

Well, no. Actually your job is just beginning. Before the component was built, some time should have been taken to see what standards and practices are currently in place. You might have the go-ahead to create an API and data model from scratch, but you might not.

It’s best to implement standards that are already in place, even if they feel strange to you as a developer. Why? Because you are building a component for other developers to implement as quickly as possible. It was your job to build the component in such a way that other developers’ productivity won’t grind to a halt while they make heads or tails of this thing you gave them.

Here’s this thing. Good luck. Design systems!

Documentation is key

If documentation fails, the design system fails. Try to answer questions in the documentation that would be asked before they’re actually asked. Head confusion off at the pass, right?

Example of simple React component:

Prop PropType Description
links array Takes an array of link objects. See below for usage.
const links = [
  {
    title: "Home", // display text for the link
    link: "/", // href for the link
  },
  {
    title: "About",
    link: "/about",
  }
];

<Navigation links={links} />

You could even create a table for the link structure if you don’t feel like adding documentation to a code snippet. The possibilities are endless.

Talk to a developer about your feelings

I have found that the most successful component is one built with the developer who is tasked with the implementation. Sure, you may have the design and specs, but this might not be a perfect match where the rubber meets the road.

Don’t be afraid of rejection. The first idea might not be the best one.

I have built the same component different ways, documented the pros and cons of each version, and spoken with a developer about my findings. Returning from that conversation gave me a greater understanding of the ultimate goal of the component. It’s almost like pair programming, but with ideas!

If possible, have the developer work from your experiments and play around with your ideas inside their own development environment. The feedback you receive will result in the best possible outcome for you, the developer, and the business goals of the design system.

Never build in a vacuum. Never throw it over the fence and move on to the next thing without following up on what you have created. It’s not realistic and it’s very irresponsible. Quickly address any bugs or quirks and send it back. Momentum is a very powerful force for iterative development. Keep it going!

The one important takeaway

You’re building for a developer, not always yourself. You’re building tools to make someone’s work life easier and more productive. Make sure that the result isn’t the opposite.

Work with others to make a meaningful tool that makes both parties happy. Build a design system with a framework formed with empathy.