Case Study

Editorial Control Without a Developer

Indivisible Project

Senior Manager, Digital Products

Organizers were printing web pages and filing them in binders because they could not find resources online. I led a homepage and resource library overhaul that made resources easier to find and let staff change content priority without waiting on an outside development firm.

15%
User engagement increase, reported post-launch
Minutes
to reprioritize content instead of waiting on an outside development queue
0
Development requests needed to shift content priority

Note: this screenshot is a later state of indivisible.org, not the launch build.

Indivisible homepage. A campaign hero with an email and ZIP code signup, and below it two content blocks side by side.

The Product Decision

The answer was not to make staff learn Drupal. Routine editorial decisions should not require technical expertise.

There were two connected problems to solve.

Organizers needed to find resources based on what they were trying to do, not when something had been published.

Staff needed to change what surfaced on the homepage without filing a development request and waiting for an outside Drupal team.

The publishing workflow had to work for the people managing the content just as much as the site had to work for the people trying to find it.

Key Facts

On this project
Lead product designer
Scope
Homepage + resource library IA
Stakeholders
Content ops + engineering
Craft
Modular prioritization system

The Problem

Inflexible content posting

Changing what led the homepage meant filing a request with the outside development firm and waiting for availability.

In a campaign environment, that could mean the priority had changed again before the site caught up.

Priority moved at the speed of a release, not a campaign.

No structure in the resource library

Finding a specific resource depended on already knowing it existed.

Organizers were printing pages and filing them in binders because the website was not a reliable way to find them again.

Content overload

The homepage and the library presented everything at once.

The reader did the sorting.

Inefficient search

Search underperformed. A resource nobody could browse to was effectively not there.

What the Redesign Had to Achieve

  • Increase resource library engagement by 10% or more by making resources easier to find.
  • Let content managers reprioritize the homepage in under 5 minutes without developer support.
  • Reduce bounce rate by 8% through clearer organization.
  • Build a system that could respond to campaign priorities as they changed.

Architecture & Interaction

The homepage used a five-module priority system. Any block could be promoted to primary without changing the page structure.

Primary
Featured module. CMS-controlled promotion.
Secondary A
Active campaign or announcement.
Secondary B
Time-bounded update.
Secondary C
Evergreen resource or reference.
Secondary D
Action or signup prompt.

Interaction Model

Editorial priority could shift through CMS slot reassignment instead of a structural rewrite. Staff could respond to campaign urgency in minutes without filing a development request. The module proportions stayed fixed regardless of which content was promoted, so the visual hierarchy remained intact while staff controlled what appeared first.

Process

3 phases

1. Research & Interviews

Interviews with content managers and organizers surfaced two related problems.

Organizers could not reliably find resources because the library had no structure beyond chronology.

Staff could not respond quickly to campaign priorities because promoting content required a request to the outside development firm, with turnaround determined by that firm’s availability.

The problems affected different people, but they were part of the same system. Fixing the public experience also meant fixing the workflow behind it.

2. Prototyping

I prototyped modular homepage structures to test whether content could be promoted and deprioritized without rebuilding the layout.

For the resource library, I reorganized the categorization around topics rather than publish date and tested that model against the organizer journeys mapped during research.

The resource center image shows the topic-based filtering system that replaced the chronological listing structure.

The five-module priority system in two states. Secondary C is promoted into the Primary slot through CMS slot reassignment, and the module proportions are identical before and after.
How a block is promoted to primary through CMS slot reassignment. A diagram of the mechanism, not a screenshot of the shipped page.
Indivisible resource center showing topic-based categorization
Resource center with topic-based filtering replacing chronological listings.

3. Validation

Usability testing confirmed that topic-based categorization made resources easier to find across organizer groups.

I validated the modular CMS slot system with content and communications staff. They confirmed they could change content priority in minutes without filing a development request or touching Drupal. We had each thought a preview would matter. The conversation confirmed it, and it was built in.

The two changes solved different parts of the same problem: organizers could find what they needed, and staff could change what mattered as campaign priorities shifted.

Impact

After launch, the client reported a 15% increase in user engagement. I treat it as a reported result rather than a metric I independently verified.

Organizers who had been printing web pages and filing them in binders to compensate for poor online discoverability could find what they needed through the site. Bounce rate improved after the redesign shipped, and organizers were able to find resources without staff intervention.

The redesign also removed the outside development dependency from routine homepage reprioritization. Staff could change what led the page in minutes instead of submitting a request and waiting for the development firm's availability.

That mattered because the content could now move at the speed of the campaign instead of the speed of the development queue.

Reflection

At first, the resource library and the publishing workflow looked like separate problems.

They were not.

Staff could not surface what mattered quickly, and organizers could not reliably find what mattered. Fixing one without the other would have left half the problem in place.

The biggest lesson for me was that the workflow behind a site is part of the user experience when its limitations determine what people can see, find, or do.

Next Project

DMV Arts Guide

Get in touch