Building a design system in XD

As a product designer who works at an agency and specializes in design systems, I spend most of my time building systems from scratch, or auditing and improving systems that are used by large enterprises. Some of that audit work includes migrating systems off of Sketch/Figma and onto Adobe XD…so I figured it could be worthwhile to dedicate some posts to tips and tricks I’ve found along the way that help make your XD design systems as fluid, scalable and functional as possible.

Make a cover sheet

This is a small, but super helpful task that takes less than 5 minutes to do and makes all the difference. Because the Adobe CC doesn’t currently support folders, cover sheets make it super easy to spot your file in the Cloud without scanning through a long list of titles. Plus, if you’re sharing your file with clients or colleagues it makes delivery feel more buttoned up.

Start with colors, type logos, and icons

These will be the building blocks of all of your components, so I find it easiest to start by laying down my colors, type specs, any logos (which I always convert to components to make things easier later on) and icons! I add everything to the Asset Panel, and label the colors and type with the HEX value, use case, and any design tokens necessary so it’s easy to search for down the road.

Quick tip for icons: Don’t use Responsive Resize! If you know you’ll be resizing some of your icons later on, turn off Responsive Resize for all of them. You can do that by dragging your cursor to select all of your icons and then disabling Responsive Resize in the property inspector.

Publish those assets as a library

After I have my file with all of my assets (colors, type, logos, icons, elevation styles, etc.) I publish that as a library. This is particularly helpful for larger systems where there are enough assets and components that one large file would be too big, or too disorganized. Plus, CC Libraries makes it easy to publish changes to your assets and have those cascade across all files using that library!

Build your base components first

For larger systems, create a new file for components. I suggest creating two artboards, one for base components and one for larger, more complex components. Enable your assets Library within your component file so you can easily grab colors, typefaces, icons etc. as you create your components. Build your base components first, utilizing Component States, Stacks, Smart Padding and Responsive Resize where appropriate.

Use atomic design

Create components for each piece of the component you’re trying to build. For example, if you’re building an input that will have different options on the right for simple text, a dropdown, search, a date/timer picker, or units, build a component for the just the right piece of that input with a state for each of those options. Then build another component for text, with different states for placeholder, disabled, active, success and error text. Then use the right atom, your text atom, and a rectangle to build the molecule that is your input.

Be mindful of how you name your layers and components

Organization is key to having a user-friendly design system. I prefer using forward slashes to separate my components, variants and states from one another. If we go back to the input example, that would look like input / right piece for the right atom, and input / default for the molecule.

Use your base components to build your complex components

Sticking with atomic design, your base components (or molecules) come together to create your more complex components (or organisms). That would be like taking a bunch of text inputs, adding a button, applying some Stacks and Responsive Resize and making a form field.

Add usage guidelines

In order for a design system to be functional and scalable, and truly decrease the working time of those using it, you need usage guidelines. These tell whoever opens the file exactly how to use each component, the dos and don’ts, and how to group components to create larger interfaces. Be descriptive and visual…I’d recommend building out some pattern resource screens with your components to demonstrate how to put all of the pieces together.

Organize your assets

Once you’re finished building all of your components and adding your usage guidelines, organize your Assets Panel. Depending on the team, this could mean grouping colors by use case or design tokens, or ordering components alphabetically!

Share your system!

Once you’ve finished building everything, start inviting teammates to use your system! The best way to iron out any inconsistencies is through putting the system into practice and making refinements. Good luck!