Business Challenge & Scope

PubPub Platform enabled academic publishing communities to create structured content models, submission workflows, and publishing experiences without custom development.

I joined during a major transition from the original PubPub—a well-loved but comparatively limited publishing tool—to PubPub Platform, a more configurable product designed to support the complex data structures and workflows required by larger publishing organizations.

This case study focuses on Form Builder, the primary interface communities used to structure and collect content. Designing it meant turning an inherently technical concept—configurable data schemas—into an experience that publishing teams could understand and manage without developer support.

Research & Discovery

When I began work on Form Builder, the concept was still loosely defined. Knowledge Futures' Head of Product had established the initial vision and a rudimentary developer prototype existed, but there wasn't yet a shared understanding of what a "Form" represented or how it should behave within PubPub Platform.

I interviewed team members and key users to understand the problems Forms needed to solve and how they related to the smaller JSON schemas users were already creating. I then studied products with comparable functionality—including Google Forms and Contentful—to explore familiar interaction models we could build upon.

Primary Challenges

Translating System Architecture into User Experience

The challenge wasn't removing the platform's underlying complexity, but deciding when and how to expose it to users. I established four principles to guide those decisions:

• Reuse familiar interaction patterns whenever possible

• Expose complexity progressively

• Align terminology across stakeholders and users

• Validate concepts with developers and customers early

Mapping the Content Model

Before designing the Form Builder, I needed to understand how Forms fit into the platform's broader content model.

• A Pub represented a single piece of content.

• Each Pub was assigned a Type, which defined its available fields.

• Types were reusable collections of fields.

• Forms allowed communities to create and manage variations of those Types.

The resulting hierarchy was: Fields → Types → Forms → Pubs

I mapped the hierarchy and reviewed it with my lead developer to validate my understanding before translating it into the Form Builder experience.

PubPub Platform Data Hierarchy Notes

Designing the Form Builder

With the underlying content model established, I built on interaction patterns already familiar to PubPub users rather than introducing entirely new interface paradigms. This allowed the experience to focus on helping users understand the Form model while also reducing unnecessary implementation complexity.

The following flow shows how those principles shaped the Form Builder experience from initial setup through configuration and use.

Forms Landing Page

The Forms landing page appears after users create a Type and introduces Forms within the broader platform context. The primary challenge was clearly distinguishing between internal Forms—used by community members to create and edit existing Pubs—and external Forms—used by contributors to submit new Pubs.

Testing showed that the explanation was still too generic to clearly communicate the distinction between internal and external Forms, highlighting the need for more contextual guidance in future iterations.

Create a Form

Create a Form

Design challenge: Users needed to understand how a Form related to existing content structures before creating one.

I reused an established modal pattern to keep the interaction familiar while collecting the minimum configuration needed to create a Form. Contextual guidance explained how each choice affected the resulting Form, helping users navigate concepts that might otherwise require technical knowledge.

Build a Form

Build a Form

Design challenge: Users needed flexibility without breaking the integrity of the underlying Type system.

Forms inherited the fields defined by their selected Type, giving users a structured starting point rather than an empty canvas. From there, users could reorder fields or add additional fields to tailor the Form to a specific workflow.

This preserved the relationship between Forms and the platform's underlying content model while giving communities the flexibility to adapt how content was collected.

Add a Field

Add a Field

Design challenge: Users needed access to a large field library without feeling overwhelmed.

When adding content, users could browse their community's existing field library without leaving the Form Builder. I organized available elements into two categories: Fields for collecting structured data, and Structure elements such as headings, body copy, and horizontal rules for organizing and explaining the Form.

Search and field-type indicators made large libraries easier to scan, while the side panel kept the Form visible throughout the process so users could add content without losing context.

Configure Fields

Configure Fields

Design challenge: Users struggled to understand how schema configuration translated into real user experiences.

When configuring a field, users could choose how the underlying data would appear in the final Form—for example, displaying a text field as a short input or a larger text area.

Rather than exposing the schema configuration directly, I presented these choices as familiar UI elements with contextual guidance. Users could then define the label and help text that contributors would see, connecting the underlying data structure to its real-world presentation.

Preview the Experience

Preview the Experience

Design challenge: Users lacked confidence that their configurations would produce the intended experience.

I advocated for a preview mode that would let users see how their configuration translated into the final Form before publishing. Although it wasn't prioritized for the MVP, I designed the experience so we could validate the concept alongside the core builder.

Preview became the most-requested feature during external user testing, validating the need we had anticipated. Because the interaction had already been designed, the team was able to incorporate it into the second iteration with minimal additional design effort.

Results & Impact

Product Impact

• Introduced Form Builder as a core platform capability for structured content and submission workflows

• Translated abstract publishing architecture into workflows nontechnical users could understand and manage

• Established reusable interaction patterns that could scale across the broader platform

• Used customer feedback to shape subsequent iterations, including the addition of Form Preview

Team Impact

• Established Knowledge Futures' first dedicated product design practice and foundational processes

• Created shared terminology and collaboration patterns across product, design, and engineering

• Introduced a lightweight research and validation process that supported rapid iteration

• Established reusable UX patterns and design conventions that supported future product development

Form Builder established a foundational capability for PubPub Platform, enabling publishing communities to manage complex content structures and submission workflows without custom development. Beyond the feature itself, the project helped establish the design patterns and cross-functional practices that supported the platform's continued evolution.

Lessons Learned

Designing for Complex Systems

One of my biggest lessons was that simplifying a complex system for users first required understanding that complexity myself. Working closely with engineering, I developed a deeper understanding of PubPub's Entity Component System architecture and how its technical constraints shaped what the product could support.

My Figma Notes on ECS and how the concept translated to PubPub Platform

Artifacts like the one above helped me validate my mental model with engineering before translating those concepts into user-facing interactions. That technical fluency became essential for designing abstractions that felt simple without misrepresenting how the underlying system actually worked.

Discoverability vs Configuration

User feedback revealed that customizable submission buttons were too easy to overlook or leave unconfigured. In giving users flexibility over their Forms, I had inadvertently made a critical part of the submission experience feel optional.

If I revisited the feature, I would make the primary submission action persistent within the Form while still allowing users to customize its presentation. I would also surface submission controls through the Add Element menu as a secondary path.

The experience reinforced an important distinction: flexibility is valuable, but essential workflow actions need stronger defaults and greater visibility than optional configuration.