Our vision is to be the go-to resource for design for other teams across the WordPress open sourceOpen SourceOpen Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. project.
During Wednesday’s design meeting, the design team started discussing how to better organise Figma libraries.
Because the WordPress Components (aka “WordPress for Figma/WP5.0_Library”) file has been expanding on an as-needed basis, the file is beginning to get a wee bit messy. It’s turned into something of a grab-bag of different elements: logos, colours, GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/UIUIUI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing., wp-admin UI, icons, type styles…
There isn’t a consistent structure to the components and several different naming conventions are in place. As the library grows and expands, it’s likely this problem will get worse.
By establishing shared guidelines for how the design team organises, builds, and adds new library components and resources, it will be simpler and more straightforward for all design contributors to find what they’re looking for or contribute new patterns.
This breaks down into three different improvements:
Splitting one library into a few smaller libraries.
Establishing naming conventions for components.
Establishing an organisational structure for components.
Once an approach is determined, the design team will document these guidelines in the Figma files themselves as well as in the handbook, so they’re easily findable.
1. Splitting up into multiple libraries
Splitting one big library into a few smaller libraries could help to keep things structured and organised by ensuring components are organised according to their purpose.
Here’s a suggestion:
Foundation → The coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. elements that make up visual design across the project. These are design tokens (like variables, but for design!) and core styles that don’t change often once established. Colours, type styles, icons, spacers, etc.
Components: The smallest UI components, broken down into pieces. Ideally, this file would be a direct mirror of the @wordpress/components package in terms of naming, structure, and content. Buttons, inputs, checkboxes, etc.
Patterns: Larger patterns made up of individual UI components combined. Blocks, navigation bars, Gutenberg’s sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme., etc.
You can think of this as a progression, with foundation containing the smallest core tokens, components making use of those tokens to create discrete UI elements, and patterns containing compositions of those elements:
Prefixing these all with “WordPress:” so it reads “WordPress: Components” or “WordPress: Patterns” may make it easier for users who belong to multiple Figma organisations.
There’s also a “Utilities” library that stores things like Figma covers, sticky notes, and diagram and wireframing components, but let’s discuss that later.
2. Establishing naming conventions
Components should ideally use the same naming conventions. Right now, components are a bit all over the map:
Let’s agree on a shared approach. Here are some options to consider:
lowercase-with-hyphens:Easier to type, harder to read. Creates good file names when exported. Matches folder name in wordpress/components package, but not component name.
Title Case With Spaces: Harder to type, easier to read. Matches how WordPress tends to use capitalisation of labels in the interface (Title Case, not Sentence case). Matches component names in wordpress/components more closely, but not exactly.
3. Folder structure & organisation
This one is going to be the trickiest!
Here are some options:
Forward slash naming (Buttons/Contained/Hover): This is the method Sketch uses. It can result in longer component names and can be hard to find individual components in the library file since they’re all on one page.
Pages and frames: Use Figma pages and frames to define top-level organization for components. Components can be found via the headings and collapsible subheadings in Figma’s asset panel..
Combination of the above: This would allow us to reap the benefits of both the above approaches. Component names might still end up long, but they’d be better organised and it would remain clear what component you’re using at a given time.
Ideally, the design library should be as close as possible a mirror to the code it represents. This establishes a shared mental model between devs and designers, making it easier to communicate and know everyone’s talking about the same thing.
With that in mind, it’s worth noting that the @wordpress/components package is a flat structure, with all components at the top level. A more aspirational approach to library organisation could be required here so that it’s easier to find things.