Gutenberg Phase 2 Friday Design Update #6

It’s the middle of February now and there’s been great discussion around how Gutenberg might impact some of the WordPress major releases. Because Gutenberg updates often affect the user interface, it’s important to consider these as major updates. Anyways, let’s get down to design!

Widgets to blocks

All core widgets are now converted to blocks! Please take a moment to stop and celebrate this achievement. A big round of THANKS goes out to everyone involved. Design Team, Core Team, Accessibility Team, other contributors, everyone! Great work.

The Classic Widget Block is still underway. This block will display widgets that haven’t been converted yet. Any non-core widgets will be accessed in Gutenberg by being contained in this block.

Other widget blocks are being improved upon: Archives [1464], Recent Comments [1792], Recent Posts [1594].

Navigation block

This complex block is HUGE. So many moving parts, interactions, etc. Distilling it down into key issues has been helping on GitHub. Feedback is coming in, providing different perspectives and thinking. This block is still about a month+ out.

Tightening up

The discussion about the Cover block including nested blocks is laying important groundwork for a Section block.


Some a11y discussion around the block specific responsive controls has been happening. It was mentioned in this week’s a11y chat as well.

Thanks for reading, staying informed, and contributing anywhere you can!

#design, #gutenberg-weekly, #phase-2

Meeting notes

If you didn’t get to attend our meeting in Slack this week, don’t worry! That’s what these notes are for. You can see the previous agenda, and follow the Slack chat log.


Research & recommendations

There are so many great data points and insights here from the research the team has done with WordPress. It’s a treasure trove, thanks to everyone for the work, and it’s well worth checking out. We discussed having a walkthrough of the work. Keep an eye out for that!

What’s next for Dashicons?

We’d love to hear some thoughts on this post. We had a great meeting last week, and a thorough followup, walking through where we’re at with icons in WordPress, and where we can take things from here.


Create style guide for future WordPress pages

Tremendous work has gone into giving a guide for designers or developers to quickly create new pages based on work that’s been done previously. This is really helpful! We discussed in our meeting the work involved to convert the guides to Figma files, as the WordPress design team is able to use Figma for free, and it supports more collaborative design work.

Gutenberg Nav block

We’d love your feedback on all the hard work the team has put into suggesting various approaches to creating a Nav block in Gutenberg. For clarity the work has been broken into five individual issues for discussion.

  1. What happens when I add a menu? (smart defaults, onboarding)
  2. How do I add an item to my menu? (child blocks, link interface, types of content to include)
  3. How do I edit that menu item? (renaming, settings)
  4. How do I rearrange items in my menu? (ordering, hierarchy, sub-menus, still in progress, although this is starting to come up in 3 and 5)
  5. How are menus and menu items presented visually? (focussed state, horizontal/vertical styling)

Feedback on any and all of the issues is welcome. The biggest challenge right now is trying to fit all the complex interactions of a navigation menu into the block area. The team is also trying to follow the principle of putting as much in-context settings next to the block area, and avoiding too many settings in the sidebar.

A great point was brought up about ensuring accessibility is thought of and included in these early stages. We briefly discussed what this could look like, and the design team wants to continually be proactive in soliciting feedback from the accessibility team.

Discussion about bringing it all together (Slack link)

We discussed some of the challenges with making complex Nav blocks, and where the different settings should sit. If you have time, feel free to jump into Slack and read through it; these thoughts are very much in progress, so additional feedback is welcome!

Design feedback

We’d love feedback on a new WordCamp PWA proposal.


X-post: WordCamp PWA: Plugin proposal and designs

X-comment from Comment on WordCamp PWA: Plugin proposal and designs

Design meeting agenda for Wednesday 13th February

This week’s meeting will be at 19:00 UTC tomorrow in Slack #design.

Here are the suggested topics:

If there is anything you would like to see added to the agenda, please leave a comment.


What’s next for Dashicons?

First, a little history–the first icon set used in WordPress was a png/bitmap sprite. The sprite couldn’t scale, which became a problem as display resolution increased. To solve the scaling issue, WordPress version 3.8 introduced a vector-based icon set packaged in an icon font, which was the most common approach for the time.

Outdated Format

Icon fonts are now an outdated format. SVG icons present a number of advantages in terms of performance, accessibility, scalability, and ease of use. There have been attempts to convert Dashicons to SVG, but that hasn’t happened yet.

Modifying Dashicons requires using third-party tools and command-line processes, making the contribution process hostile to new contributors. Adding a new icon and updating the font requires several time-consuming and complicated steps. The desire to keep Dashicons as lean as possible for the sake of performance means any new icons must be considered by the core teams to determine if they are warranted. As a result, there are often requests for new icons that don’t get met, meaning that people aren’t able to access icons they need.

Proposed solution

Instead of building something new from scratch or converting the icon font, we can leverage work already done in Gutenberg to bring a more modern toolset for admin icons to the whole of WordPress. Gutenberg introduces an SVG icon system that includes a process for extending icon sets. This makes it easier for plugin and theme developers to incorporate any icons they’d like and allows for the tried and true Dashicons to remain part of WordPress’ future.

The design team would like to extend Gutenberg’s icon system to the rest of WordPress. An open source and actively maintained icon set such as Material Icons would serve as a base set. This will give us an established set of icons to work with right away, which can then be built on to accommodate WordPress admin, plugins, and themes. This will make it easier for everyone to access the icons they need while bringing a consistent experience across the entirety of WordPress.

Your thoughts

The design team needs your input. Right now, we’re trying to determine if this is the right direction, and then we’ll focus on implementation details. Let us know what you think!

  1. Does this approach make sense?
  2. Are there alternate approaches we should consider?
  3. What should we keep in mind as we start planning?
  4. How does this impact users, developers, and teams?

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

Gutenberg Phase 2 Friday Design Update #5

So many good things! One of my favorite pieces shared by @youknowriad is; there were 52 contributors to Gutenberg 5.0 – the latest release!

Widgets to blocks

@melchoyce recently posted an update on these. But there’s even a few updates since that was written! For instance, the Search block is now merged. It’s moving fast. After talking with Riad, it looks like an estimated 4 weeks until they’re all merged in along with the addition of the Classic Widget block.

Tag Cloud – What do you think if the Tag Cloud block got renamed “Word Cloud” so that it’s clear it doesn’t only include tags? The option to switch between tags and categories would still exist, maybe in the block inspector.

The development of the widget screen for the inclusion of blocks is currently on hold until this PR is completed.

Navigation block

The Navigation block has a new issue with the hopes of refocusing and a deeper understanding of the problems people experience when building menus. Because this is such a complex block, there’s going to be really good discussions, so please get involved.

Tightening up

These small incremental changes are adding the polish to Gutenberg making it a real joy to use. One such example is the Focal point picker added to the Cover block. Speaking of the Cover block, there’s conversations about nesting blocks within it for more options to display over the image. Buttons? Did anyone say buttons?

Animations are also getting added bringing an emotional delight to the interface.

The color picker for blocks is getting some much needed clarity.

There’s also been some great headway on notifications in the editor which just need a code review before getting merged.


Make sure to get caught up on the research posts that have been shared on the make/design blog. These reports are informing the design decisions going forward, so it’s important to have a firm understanding of what’s being shared. The latest one from @tinkerbelly concerns the segment of Site-builders.


A new issue has been opened to address the keyboard navigation of Gutenberg. It’s been a long time coming!

Thanks for reading, staying informed, and contributing anywhere you can!

#design, #gutenberg-weekly, #phase-2

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

Meeting notes for February 6, 2018

This week, the weekly #design meeting was lead by @joshuawold. You can read the full transcript in our Slack-channel, or jump straight to the topics that were discussed by clicking the headings below.

Gutenberg update Phase 2

@mapk gives a quick update on Gutenberg Phase 2. He thanks the accessibilty team for being very helpful with design work being done. There’s a new ticket that directly explores the A11y (Accessibility) tabbing issues in Gutenberg.

Also, the navigation block just got a recent Github issue created to gather focus again. If you happen to have some thoughts on that, please join the discussion in the ticket by adding your comment.

Calls for design

There are two calls for design that need help from awesome designers. If you are looking into something tangible to contribute on as a designer, please check out the following calls:

  • Uniform Search Form Display/Experience – this ticket addresses the problem with  five different search types existing across the WP-admin.
  • Redesign mobile – check this ticket if you’re passionate about working with WordPress from your mobile phone. These pages could use some love and design feedback, first wireframes/sketches are in the ticket.


The basis for this discussion is issue 9647 of block icons SVGs not being reusable.

In his comment on issue 9647 Joen says:

For now we have used Dashicons because it’s the WordPress icon set. But this has not scaled tremendously well, and the icons are small and designed for older screens and interfaces than we use widely today. So we eventually adopted the Material icon set for block library icons, to make it trivial for plugin developers to quickly and easily pick a unique and legible icon that fits their block.

There are constant requests for new icons on Github, some more critical than others. But currently, it’s really hard to integrate new icons in the Dashicons icon font.

In the meeting, there’s a brief exploration on where this could go, and moving towards another open source icon set is suggested. @empireoflight, one of the prominent dashicon builders, says he used to think we could build an icon library for WordPress. But unfortunately, it’s just not happening.

A brief discussion follows on the impact of having multiple icon sets. But it’s good to know people are open to the idea of working with another open source icon set like Material Icons, and have an extended set of specific WP icons on top.

Everyone agrees this will overhaul the admin and will have a big impact. Knowing the logistics, breaking these into steps and setting a timeline would help getting an overview on what’s involved.

@mapk suggests starting with getting buy in other teams first and find people to help on the project after that.

@empireoflight will draft a post on make/design as a starting point for the discussion with other teams.

We’re looking forward on your thoughts on moving WordPress icons forward. Pleas feel free to comment on these notes, or share your ideas in the make/design post dedicated to this topic (which will appear soon on this page for you to discover. You can also subscribe to the design blog in the sidebar on make/design to get instant notifications once the post is there for you to read).


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