Discussion: How do we organise Figma libraries?

During Wednesday’s design meeting, the design team started discussing how to better organise Figma libraries.

The problem

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, Gutenberg UI, 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.

The solution

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:

  1. Splitting one library into a few smaller libraries.
  2. Establishing naming conventions for components.
  3. 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.

Let’s dive into the details!

#figma, #wordpress-components

X-post: The Get Involved table at WCEU 2019

X-comment from +make.wordpress.org/community: Comment on The Get Involved table at WCEU 2019

Video: Site Building Research Q&A

Last week, @jarahsames and I hosted a live video session in which we walked through the process, methodology, and results of the site building research—then answered lots of questions!

For those who weren’t able to make it, here’s a video and a transcript.

Transcript after the jump

Ask me anything about: The site building study!

As you may remember, back in December a small group of curious-minded people embarked on a research study with the aim to learn more about how end users think about site building.

Since the results have been out for a little while now, @jarahsames and I are going to be hosting a walkthrough of the results as well as a Q&A session, live on video! Join us at 19:00 UTC, Monday, 18 March to learn more and ask all your burning questions.

The session will cover:

  • The goals and aims of the study
  • How the research was planned and performed
  • Findings and insights
  • How you can get involved with future research efforts
  • Answers to all your burning questions!

The session will be recorded and shared here, so if you can’t make it live, you can always catch up later. It should take around an hour, depending on how many questions there are. If you can’t make the session or would like to pre-share your question(s), please drop them in the comments below, and Sarah and I will be sure to answer them during the Q&A portion.

The Zoom link for the session is here, and will also be shared to #research just prior to the session. See you Monday!

#gutenberg, #research

Open invitation: Become a WordPress researcher!

User research is key to ensuring that software meets users’ needs. With user research efforts ramping up across the project, now is a great time to get involved!

You don’t need to be a designer (or a developer, or a tester!) to become a researcher. All you need is a curious mind and a desire to help improve products for users.

Upcoming studies

With the site building study wrapped up, the next research efforts will be focussing on usability testing of new features. Coming up this month:

Get involved!

Anyone can become a researcher! You can start as a silent observer. This is the easiest way to get involved. You join the call as a silent, invisible participant to see how it works, and you can share your observations with us in Slack after the session.

If you’re ready for the next step, you can help by taking notes or even running a session. You can also help by contributing your observations after the fact, watching video recordings, or compiling results. There are guides and support available for all of these tasks, as well as lots of friendly faces in the #research channel in Slack to answer any questions you may have.

If you’d like to be involved in one of the research studies listed above, please comment here or ping myself, @sarahmonster in Slack, and I’ll get you set up and ready to go.

#gutenberg, #research

Video: Accessibility walkthrough of navigation menu block designs

Yesterday, @lukepettway was kind enough to sit down with me and walk through my and @melchoyce‘s initial ideas for a menu block design, in order to catch any areas that could be problematic from an accessibility standpoint.

Video recording and transcript

#gutenberg, #menus

Proposal: Navigation menu block design

After collecting feedback and discussing areas of the problem individually, @melchoyce and I have circled back to a proposed combined direction for the navigation menu block.

What problem are we trying to solve?

Building navigation menus for a website is a fragmented process that’s difficult to understand and visualise. It relies on a pre-existing understanding of the model WordPress uses to organise menus and doesn’t map to users’ understanding of how navigation menus should work. There are multiple different ways to create a menu (Customizer, Appearance > Menus, widgets) that all offer slightly different experiences, increasing confusion. Creating a link to certain parts of the site often requires manual work.


The core principles followed here:

  1. Any interactions that are required by a majority (over 50%) of users exist in the block interface itself.
  2. Advanced controls are moved to the block inspector in order to progressively reveal complexity.
  3. Switching between advanced and basic interactions is made simpler by links.
  4. The editing state of the block itself should mimic as closely as possible the front-end output.
  5. Use technology and data to make smart decisions for the user so as to limit the number of decisions they need to make.
  6. Users should be able to create pages from the menu interface if these pages don’t already exist on their site.

There’s a great deal of complexity that goes into a navigation menu (multiple levels of nesting, mega menus, social links, etc), but the majority of users require a very simple menu—a collection of links to the main sections of their site.

After a productive discussion in the #design meeting of 13 February, Mel and I decided to create slightly different experiences for core interactions and advanced interactions. For the majority of users, everything they’ll need to build a simple menu will be available in the block interface itself. Smart defaults help users get up and running as quickly as possible, so they may only need to make a few small adjustments to the out-of-the-box configuration of the block. For advanced users who want fine-grained control of complicated menus, a suite of advanced tools is available in the Inspector.

You can see how these interactions are classified in this diagram:

Diagram of core and advanced interactions.
Core interactions are blue, advanced interactions are pink.

Proposed Solution

The core (in-block) UX flow.
The core (in-block) UX flow.

When you first add the navigation menu block, Gutenberg will use some underlying code-magic to try to automatically generate a menu for you, based on a number of different factors including any pre-existing saved menus, where you’re inserting the menu on your site, and what content you already have set up. 

What your default menu might look like.

Once you’ve created a menu, you can delete items quickly using the delete on your keyboard, or you can delete them using the traditional block settings ellipsis menu.

To rearrange elements in your menu, select the menu item you’d like to move and either use the drag handle or the “move left” and “move right” buttons to shift it. Advanced options and hierarchy management exists in the inspector. 

Navigation item settings.

One level of hierarchy is visible in the block itself. By default, sub-menus are hidden in the block interface, but they can be toggled on and off using the drop-down icon. For more complex hierarchical structures, an inspector panel opens and allows for legacy-style reordering and nesting of navigation items. 

A sub-menu displayed.

To add an item to your menu, start typing or use the “+” button. The placement of the “+” button shifts depending on which item is currently selected, so you don’t need to add new items at the end and then move them up.

Adding a new item to a navigation menu.

Adding a new menu item pulls up a search interface, similar to adding an inline link or a button. The search returns all relevant content across your site, regardless of what content type it may be. Icons are used to provide additional context as to what type of content is being returned. From here, you can also opt to create a new page or enter the advanced mode to browse your content and bulk-add items.

If you’d like to dive more deeply into the finer points of discussion, there are a series of Github issues for discussing different parts of the interaction:

There’s also a Figma prototype that you can play with or leave comments on directly. Note that it’s under construction, so not everything works perfectly yet.

Get involved

At this stage, broad feedback would be extremely useful. 

  1. Overall, does this feel like a sensible direction? 
  2. Is there another approach that might work better?
  3. What’s the most elegant way to handle nested menus?
  4. How can advanced reordering be made as simple and user-friendly as possible?

If you have feedback on a specific element or interaction, it’s best to leave that in Github or Figma. If you’d like to remix or improve this work, please feel free to create a new page in Figma, or duplicate the whole document itself, and share here in the comments.

Next steps

These designs are a work in progress and will be iterated on based on your feedback as well as usability testing results. 

@lukepettaway and I will be meeting up later this week to do a walkthrough of the proposal and identify any potential accessibility problems in this design.

Mel and I will be working on a plan for usability testing of this prototype. If you’d like to be involved or sit in, please join us in #research at 18:00 UTC tomorrow, Tuesday 26 February for a text chat. More details will be posted here once those details have been hammered out. If you’re interested in helping with usability testing, there will be lots of opportunities to get involved!

#gutenberg, #menus

Findings & recommendations (Site building study #5)

These are the results of a user research study investigating mental models related to building and customising a website. Results are split across five posts:

Background | Segments: Bloggers · Small Businesses · Site Builders | Conclusions

Key findings

  1. Big changes in software present cognitive challenges, particularly to long-term users of a product.
  2. People don’t care about the process of building a site—they just want to build something that works as quickly as possible, so they can focus on their core interests.
  3. People struggle to build a site that looks and works the way they want. Themes are a source of friction because they don’t match the way people think about building a site.
  4. Many people who build sites don’t have a pre-defined vision in their head of what it should look like. They tend to play around until they find something they like.

Recurring themes

Personal circumstances

A website is an opportunity to pursue a passion. That passion often begins as a side project, but the hope is that it will expand further. People often don’t have huge lofty goals for their sites or their businesses: they just want to pay the bills.

I’d like to be working for myself, but I’m not super good at hustle.

Sometimes a traumatic life event (accident, medical, personal) triggers a change in circumstances and brings people to a more entrepreneurial place, at which point a website becomes an essential tool.

WordPress allowed me to overcome difficulties in my life I couldn’t overcome without it.

Site building

A website is a tool for achieving a goal, not an end in and of itself. Building a site is often a necessary distraction from that goal. People aren’t really interested in the process of building a site, they just want to get a site out there.

WordPress uses too much jargon.

I wish there was a site builder that was for [non-technical] people like me.

Extensibility is the #1 thing people like about WordPress.

People have defined structures for how they build WordPress sites—they learn one approach, and then they repeat that for other sites. Often this means investing in learning one complex “do everything” theme and using that across all their sites.

Now I know these settings like the back of my hand because I’ve been using them for 10 years.

Generally speaking, people prefer when there’s a direct connection between element controls and the element itself. This aligns with Gutenberg’s approach, even though many people we talked to either didn’t like or hadn’t tried Gutenberg yet.

It’s so much easier and visual to float the blocks around.


People find making child themes to be an arduous process. They’ll often end up using a plugin to make the child theme, or editing the theme’s CSS directly via Appearance > Editor.

The term “theme” doesn’t really mean anything to people. A lot of people use the term “template” when they mean “theme.”

A lot of people spend a great deal of time choosing a theme, and they’re often unhappy with what they land on. often unhappy with what they land on.

A lot of times I will be unhappy with the layout. Often, everything else about the website is good, but the homepage isn’t right. I want the interior pages to look different than the home page – often not just look, but structure and mechanics.

Learning & delegating

Casual bloggers and people who may not consider themselves technical experts search Google to find answers to their questions. They assume documentation will solve their issues and are willing to learn more so they can make their website better. 

People will delegate as much work as they can afford to, so they can focus on the core of their work. Often a website is one of the first things they’ll delegate.


Technology moves too quickly for people to keep up with unless they’re directly involved in the tech industry.

If it wasn’t broke, why are we fixing it?

People need to be sold the value of learning something new, because they see it as an investment that needs to be worth their (often limited) time.


People rely heavily on referrals and reviews for advice when choosing software to use, whether that’s in person or via Facebook groups.


People are concerned about their personal online security. They are also concerned about their site getting hacked and about data loss.


  1. Consider splitting themes into “styles” (colour, typography, spacing, pattern, and visual styling) and “templates” (structure and placement). Users often struggled to find a theme they liked and to make their site match the representation promised by the theme.
  2. Consider providing different paths or options for power users and for beginners. More technical users have very entrenched ways of doing things and just want to get on with it, but beginners prefer more hand-holding.
  3. Be very intentional with how changes are rolled out. Learning something new presents a huge cognitive load and users are resistant to investing the time to learn a new approach. Provide more gradual transition paths, make it easier to roll back to prior versions or “undo” an upgrade, and only ask users to learn something new when it’s totally ready and finalised. Consider implementing the minimum viable product when introducing new patterns and then adding features and functionality incrementally, so that users don’t feel overwhelmed. (Slack’s “What’s new” could be a great model.)
  4. When introducing new concepts or patterns, it’s important to clearly communicate the value offered by the change. There were a number of occasions where someone who was resistent toward trying or learning Gutenberg would likely have benefitted from it, but they didn’t recognise the value of investing their time to learn the new model. 
  5. Make room for people to build by experimentation and play. The majority of people aren’t likely to have a defined idea of what they want until they see it. 
  6. Documentation and help should be baked into the product, especially when introducing changes. 
  7. Adopt a more data-informed approach to the introduction of new features. Always start by asking “what problem are we trying to solve?” Test new features with end users prior to development, especially when they’re critical to the user experience. Ensure testing is done with a wide range of users who represent the breadth of people who use WordPress. Consider the merits of opt-in data collection to improve the product experience and remove features that aren’t being used. 
  8. Avoid adding clutter to core if it isn’t integral to the core experience. One of WordPress’ key strengths and sources of appeal to users is its flexibility and the additional functionality offered by plugins, but the plugin marketplace can be difficult for users to parse. Consider providing plugin recommendations or bundled packages for different use cases, and only include in core those functionalities that are universally relevant.
  9. Clearly communicate project vision and roadmap in order to ensure that everyone is working from a shared understanding. Decisions and the arbiter of those decisions should be clearly communicated so that the process doesn’t seem opaque. Establish clear metrics for success and ways of measuring this success. hello

Learning about site builders (Site building study #4)

These are the results of a user research study investigating mental models related to building and customising a website. Results are split across five posts:

Background | Segments: Bloggers · Small Businesses · Site Builders | Conclusions

The research group sorted participants into three segments, based on their current understanding of how people use WordPress. These segments are based on a handful of data points and warrant further study to confirm the categories. For now, these segments allow researchers to group WordPress’ extensive userbase into behavioural categories and learn characteristics specific to each group.

For this study, we focussed on three segments: bloggers, small businesses, and site builders (people who build sites for others). Today we’re going to learn more about site builders.

Site builders are people who make sites for others. Site builders often start as bloggers or small businesses. Having taught themselves to build websites, they are now progressively leveraging their skills to earn additional income. They tend to work for friends, acquaintances, or people in their professional networks and often barter or don’t charge much for the websites they build.

Let’s learn more about site builders!

#gutenberg, #research

Learning about small businesses (Site building study #3)

These are the results of a user research study investigating mental models related to building and customising a website. Results are split across five posts:

Background | Segments: Bloggers · Small Businesses · Site Builders | Conclusions

The research group sorted participants into three segments, based on their current understanding of how people use WordPress. These segments are based on a handful of data points and warrant further study to confirm the categories. For now, these segments allow researchers to group WordPress’ extensive userbase into behavioural categories and learn characteristics specific to each group.

For this study, we focussed on three segments: bloggers, small businesses, and site builders (people who build sites for others). Let’s learn about small businesses next.

Small businesses are the most varied group since businesses range widely depending on their nature. This is a difficult group to generalise about and researchers observed a diverse range of experiences.

Let’s learn more about small businesses!

#gutenberg, #research