Allan Buntoengsuk

Automattic

Nobody had built nested blocks this deep in Gutenberg. I designed the architecture that did it.

Year
2021
Role
Lead Product Designer
Tags
EdTechWordPressDesign SystemsInformation ArchitectureB2B

Overview

Sensei LMS was a course creation platform that Automattic had recently acquired. As it was a new addition into the ecosystem, it sat on top of WordPress as its own separate thing—disconnected from the Gutenberg editor that WordPress users already lived in. The bet was that we could make course creation native. Same editor, same blocks, no context switch.

I joined Automattic for three months as a lead product designer embedded with their team. This meant close collaboration with product, engineering, and design systems. The job was figuring out what a native course creation experience would actually look like inside Gutenberg—and whether it was even possible.

Strategic Frame

We weren't just adding a feature to Gutenberg. We were asking it to do something it had never done.

Standard Gutenberg blocks are one thing: a paragraph, an image, a button. but to create a block that could house an entire course—structurally involving modules, lessons, pages, nested inside each other—that’s another thing entirely. That kind of capability just didn't exist yet. Design and engineering had to figure it out together, because neither could move without the other.

Problem 1 — Sensei's IA didn't match how educators think about courses

First-time creators were lost before they'd built a single lesson.

I audited Sensei's existing IA and mapped out how competing course creation tools handled the same flow. A pattern emerged within Sensei: the experience and structure reflected how the database was organized—not how an educator thinks about course building. We had the three primary flows of creating a course, adding modules and linking lessons as separate tasks with no connection between them.

The audit led to a redesigned IA proposal that set the stage for everything that followed: that a Course is comprised of three things—an overarching Course, Modules to section content, and individual Lessons.

Problem 2 — Course creation existed outside the WordPress editor

The problem wasn't as much the interface as it was the interruption.

WordPress creators are familiar with Gutenberg. Leaving the Gutenberg editor to set up a course—then coming back to populate—then leaving it again to link content ends up becoming a painful experience. The redesign had to make course creation feel like part of the editing experience, not a separate tool that feels hastiliy bolted on.

Eventually I realized the solution was to build the whole thing in blocks. Course structure and content droppable directly on any WordPress page, using the same sidebar controls and styling UI creators already know.

Problem 3 — The block’s states were confusing

Before any architecture work, me and my PM Donna ran 5 usability sessions with real course creators to understand where the experience was breaking down. A few things became immediately clear:

  • Creators don't build courses linearly—they create the structure first, then come back to fill in content. The block needs to support that pattern, not fight it.
  • Users hovered on modules and lessons expecting to see an inline add action—not a toolbar item they had to discover.
  • The empty, preview, and edit states were being conflated. Users couldn't tell what mode they were in or what actions were available.
  • Clicking a lesson link, users expected to go somewhere immediately—not to enter an edit mode.

We synthesized findings and published a P2 with the team. These sessions reframed the core design problem: this was an interaction model clarity problem more than a visual design problem. Which actions are available, from where, and what happens when you take them.

The Architecture

Three nested levels, all inside a single WordPress page.

The architecture was designed around three distinct block states, directly responding to what testing revealed:

  • Empty state: first-time setup, clear prompt to add a first module or lesson
  • Preview state: lessons rendered as navigable links, a read-only overview of course structure
  • Edit state: inline editing with clear affordances for modifying lessons and modules in place

Making these states explicit was the core interaction model decision that made the block usable.

The Course Outline Block is the parent, drop it onto any WordPress page and you’ve got yourself a course. Layout, styling, everything contained inside it.

The Module Block lives inside the Outline Block. Title, description, and its own set of lessons. Great for grouping similar lessons together, but also able to be bypassed if a creator does not feel the need to group lessons. Collapsible and manageable from the Gutenberg sidebar

The Lesson Block is the smallest block unit, containing the title, completion status, and a link to the lesson content page. Lessons can live inside a Module or within the Outline and connect out to the full lesson experience.

Action to edit the lesson lives in the sidebar, editing the URL/going to the lesson lives in the block

One specific interaction required extra care: editing a lesson vs. navigating to it. In early iterations these actions were conflated—tapping a lesson could mean either entering edit mode or following the link to the lesson page. Usability testing confirmed this was a real source of confusion. The solution was to have the edit lesson action live in the sidebar, while the URL/lesson nav lives in the lesson action bar.

Since the lesson/module/course outline blocks did not yet exist in Gutenberg, I also defined the full styling system for each: typography, layout, color, sidebar controls—all consistent with how native Gutenberg blocks behave.

Impact

Shipped February 2021. After launch, the block architecture expanded to cover quizzes, flashcards, and certificates.

The interaction model it established was new for WordPress: course creation that lived inside the editor, matched how educators think, and had room to grow. The block was designed in a way so that it would be able to accommodate the future additions mentioned above.

Reflection

The actual constraint was Gutenberg itself—that it was not a blank canvas but rather, an existing architecture with its own component model, structure and user expectations. Every decision I made needed to fit inside that. The block structure being able to absorb quizzes and certificates further on down the line was the proof it had worked.