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.
Note: this screenshot is a later state of indivisible.org, not the launch build.
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.
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 phases1. 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.

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.
