About the Project
From 2018–2022, I was lead product designer for Mobile Gutenberg, the mobile equivalent of the block editor for the official WordPress native apps.
Gutenberg is WordPress’ next-generation block editor, a new page and post editing experience that makes writing rich posts effortless and removes barriers to things that typically would require a developer or pre-existing knowledge of the product.
The overarching goal of the mobile editor project was to create a native version of Gutenberg that is simple and intuitive for mobile — not just build a replica of the web editor but one that is designed to meet the needs and expectations of mobile users. More specifically, we aimed to:
Dramatically improve the overall editor experience vs. the “classic” editor.
Support as many of the core blocks as possible, especially ones that are used the most on mobile.
Increase engagement with the editor (e.g. avg. posts-published, session count/duration, etc.).
For the apps as a whole, our goals were to improve retention, MAU’s, and app store ratings.
Research
One of the biggest challenges we faced at the outset was deciding what the “ideal” mobile version of Gutenberg would look like for users of the WordPress mobile apps. I spent time doing research (user interviews, moderated usability tests, competitive analysis, data analysis) to gain a better understanding of what types of things mobile users value most in the context of content creation. Here are some of the key takeaways from that research:
Users primarily use their phones for quick tasks such as messaging, checking a status, or making a quick edit to a doc — especially In the context of content-creation.
Many users have anxieties around blogging from mobile devices because of experiences with data-loss, cellular connection issues, or a preference for a larger screen.
The most common terms folks used to describe their favorite mobile tools were intuitive, quick, and available on multiple platforms.
A very small number of content-types account for the vast majority of content. This was especially pronounced on mobile.
Early Explorations
After the initial round of research, I explored various aspects of the editor experience by sketching and prototyping key components, interactions, and flows — from granular interactions like editing and navigating blocks to high-level flows like the end-to-end publishing flow.
Along the way, I shared concepts with the team and tested prototypes to gather feedback, then iterated until we felt confident that each concept was structurally sound and achievable for v1.
As I progressed through these explorations, I used our research and the existing web editor as inspiration, establishing patterns and systems that were better-suited to mobile — familiar patterns and components like bottom sheets, menus, and action sheets and native gesture-based interactions like drag & drop, long-press, and more.
Design
Our core design principles were established early in the process and mapped closely to mobile user expectations.
Principles
Native
The editor feels “native” on each platform, adhering to established standards and patterns.
Contextual
Controls are relevant to the context and task at hand, and don’t get in the way.
Reachable
Primary actions are placed in locations that makes it easy to perform key tasks.
Discoverable
It is clear to the user what actions are available and what they do.
Blocks
In Gutenberg, blocks are the star of the show. Each piece of content in the editor (e.g. paragraph, heading, image) is a block, which has a toolbar and a set of controls that are relevant to that type of content, as well as a variety of settings that allow you to fine-tune how the block looks and behaves on the page.
Over time, we iterated on just about every part of the block structure — from how the tools in the block toolbar and settings bottom sheet were grouped to adding new types of settings and UI components.
Block Inserter
The primary goal of the block inserter was to make finding and adding blocks super easy. We shipped v1 with a small set of block types, so the inserter sheet was pretty minimal.
Over time, we added more blocks and as a result, shifted our sights to improving findability and discoverability. We added dynamic search to make it easier to find blocks. In the future, we planned on adding block patterns to the mix, which are essentially pre-made sections comprised of a variety blocks (e.g. hero, headers, footers, etc.).
We also iterated on placement and styling of the entry point, the way we used labeling, and more to make it more discoverable and easy to find the blocks you wanted to use.
Slash Inserter
In addition to the primary block inserter method, we implemented a secondary method called the “slash inserter”, which has become a common pattern in various editors and messaging apps.
Drag & Drop
One of the common themes from usability tests and feedback was the expectation of drag & drop, especially related to moving blocks around on the canvas. After some technical investigation and prototypes, we landed on a simple and flexible solution that was intuitive and allowed us to iterate quickly.
Color Picker
The color picker UI was probably the most fun of all of the sub-projects because it was both challenging and rewarding because it was easy to see visual progress while we worked on it.
It required us to re-think the way we were using bottom sheets — from a fairly static surface to a dynamic, nested interaction model that required special care to get the transitions and animations just right across platforms.
Nested Blocks
Getting the interaction model for nested blocks was a real challenge but a critical one to solve.
Nested Block Hierarchy
The first challenge was determining which extreme of the hierarchy should be selected when a user first taps on a nested area — the parent/container block or innermost child block?
After a series of tests and a prototype, we landed on the former (parent is selected first, then subsequent taps “drill down” into the hierarchy.
Toolbar
The next challenge was figuring out the design and placement of the navigation helper UI.
In terms of placement, we tried a few variations and found that floating the UI directly on the block was ideal. But we ran into a technical roadblock and ended up pivoting to a fixed placement at the top or bottom edge of the view (Android and iOS respectively as part of an experiment).
For the design of the toolbar itself, we explored a number of designs, eventually landing on the a toolbar that shows the selected block, hint of the immediate parent, and a button to jump up a level.
Edit/View Modes
Something I noticed during early usability tests was that some users seemed unsure about whether or not the editor was in an “active” mode. My proposal was to re-structure UI around two “modes” — edit and view — in order to provide a clearer visual distinction between the two types of tasks and provide more appropriate actions based on the context.
Design System
Over the course of the early stages of the project, I established a set of styles and components, which grew organically to serve the needs of the project and our users. The system was comprised primarily of a Figma library and documentation site.
Having a system documented — however rudimentary — made communicating design decisions and having discussions much easier because it gave us a shared language. It also improved consistency across the board.
We also experimented with ways to connect design and code using tokens and other shared assets. This was especially a challenge because of the cross-platform nature of the project, which utilizes React Native, iOS, and Android.
Summary
Looking back on the project, I’m incredibly proud of the work we did as a team. Building a completely new editor from scratch came with a unique set of challenges, but we were able to build an experience that is lean, stable, and in some cases, easier to use than the web editor.
36
Blocks Built
4.6+
App Rating
~20%
Posts Published
We were able to effectively analyze a variety of inputs and execute in a measured way, utilizing data and continuous discovery to understand how folks use the editor. This informed our strategy for iterations to existing features and adding new blocks, capabilities, and features along the way. It also enabled us to quickly adapt to challenges and pivot when necessary.
Key Learnings
I learned a lot in a short time working on this project — how to collaborate effectively (even when the engineer-to-designer ratio is ~25:1 😬), when and how to systemize and document things (as early and often as possible 🤓), how to navigate a cross-org/community project at scale, and above all, I learned the hard way that I should trust my gut and be more vocal.
Other Examples
