Please Don’t Make Me Guess: A Design System Guide for Designers and Developers

August 6, 2024

Please Don't Make Me Guess

“I don’t know what I want, but I’ll know it when I see it”

Vague feedback often adds a lot of frustration to the software creation process. As a design technologist, I’ve seen a fair share of design and development work happen in silos, with black boxes and ideas thrown over the fence in hopes that things work out. The communication gap is real, with designers not always knowing what options are available or which changes are easy to make. Developers don’t always know why design decisions were made or how they should fill in the gaps. By reducing the number of these blind spots, we could collectively stop thinking, “please don’t make me guess”.

Start Collaborating Early

As designers add custom components into their design systems, it’s helpful to have developers actively participate early in the design process. This enables designers to more easily weigh technical tradeoffs with other feature requirements.

These tradeoffs range from complexities that are inefficient to render, to limitations with current browser technologies. On the other hand, designers can give context and reasoning behind certain components so developers aren’t left to guess what static components are meant to do.

It could also be helpful to bring inspiration and influences to the table early on. For example, a developer could inspect a website that a designer brought as inspiration. This inspiration could take the shape of a functionality the designer wants to imitate, or down to the exact timing of an animation. Developers could also bring up existing websites and coding patterns they have seen before and provide inspiration for designers to ideate on. Some development frameworks, like TailwindCSS, also include default values, like spacing and text sizes, that are helpful to bring into a design conversation early on.

Both disciplines have their own form of peer reviews and feedback; Developers often review pull requests while designers have critiques. Reaching across the aisle and working collaboratively throughout the process allows everyone to be on the same page and have context into each other’s work. This transparency improves the workflow’s efficiency and general cohesiveness, especially for an interdisciplinary project like a design system.

Bridging the Gap with Existing Tools

On Figma’s end, there’s an abundance of tools in Dev Mode to reduce ambiguity in a design. There is the Dev Mode Annotation tool that allows designers to leave comments on specific implementation details. It also allows the designer to reference token values directly.

Inserting a note and measurement with the built-in annotation tool

Without Dev Mode, there’s the option to leave normal comments in the default design mode or to add text box notes on the sidelines. This allows designers to highlight what specifically is important for developers to pay attention to. For example, an image with a specific max-width may be important to a designer, but could be easily missed by a developer. By adding a note about it, designers can provide clarity to otherwise ambiguous specifications. In some cases, it can be helpful to pair designers with developers to annotate a design together.

Adding a comment into the file without Dev Mode

Designers can also leverage tokens and variables so values stay consistent. This also allows the different permutations of a component to be previewable in the Dev Mode playground. The developer no longer has to ask what a component looks like in different contexts, like a different screen-width or color-scheme.

A designer using variables to dictate spacing values

These values are now reflected in Dev Mode when inspected. It also adds options into the dropdowns in the preview.

A developer inspecting and using the component playground

On the developer’s end, one can leverage a sandbox-like tool such as Storybook to send to designers. Storybook can be deployed on a feature-by-feature basis and sent to designers. Designers can then verify changes and collaborate on exact implementations if needed. There are plenty of plugins available, in addition to the base version of Storybook to take advantage of. For more information, read about Unlocking the Power of Storybook.

Having a Checklist

To improve collaboration, designers and developers could agree on a checklist of tasks to complete as part of handoff. This checklist helps define for everyone what takes place as part of “handoff”. Here’s an example of what those checklists could include:

A Checklist for Designers

  • Have I designed for all the expected screen widths or have I notated how elements should scale based on the screen width?
  • Have I stress tested my components?
    • What happens if there’s a lot of text?
    • What does an empty state look like?
    • What happens if the element is a different color? Is it still accessible?
    • Do I need to support characters in different languages?
    • If it’s a list of items, what does it look like with many items or only a few items?
  • Are values consistent?
    • Is the spacing and padding in elements consistent or intentional?
    • Do they make use of existing color or text styles?
    • Are any new colors or text styles added and notated?
  • Did I double check the different variations by going into the Dev Mode sandbox?
  • Did I annotate any ambiguous measurements in Dev Mode?
  • Did I check for any accessibility considerations?

A Checklist for Developers

  • Are there notes left by the designer in Dev Mode?
  • Can I tokenize any of the values to be referenced in the code later?
  • Are there questions that could be answered with the Dev Mode Playground?
    • It isn’t always clear that the designer has accounted for various permutations of cases. The designer could have used variables that could be toggled and swapped in a sandbox known as the Dev Mode Playground.
  • Are the different component states clear, and do I know how the component should transition between states?
  • Are there any accessibility concerns?
    • Is it clear where image alt text should come from?

Conclusion

Fostering collaboration between designers and developers is crucial for overcoming common challenges like vague requirements and isolated workflows. By integrating developers early in the design phase, teams can align on project goals, leverage each other's expertise, and reduce misunderstandings. Tools like Figma's Dev Mode and Storybook facilitate this collaboration by providing platforms for detailed annotations, variable management, and interactive previews, ensuring that both designers and developers have clarity on implementation details throughout the project lifecycle. Ultimately, bridging these gaps not only enhances productivity but creates a more cohesive and efficient environment.

Related Posts

Harmonizing Design and Development: The Power of Mirrored Components

April 22, 2024
Maximizing the parity between designed and developed design system components

Unlocking the Power of Storybook

October 13, 2023
Going beyond the Design System: how to use Storybook to develop, test, and validate all parts of a frontend application.

Why Have Design Technologists?

April 8, 2021
A Design Technologist can move between the design and engineering worlds seamlessly. They can change their shape and blend in depending on the environment, and therein lies their power: they are powerful advocates for holistic thinking.
Paula Lavalle