Rethinking how government teams review and publish
Rethinking how government teams review and publish
Isomer is a website builder that lets government agencies create, manage and publish informational websites.
Team
2 Product Designers, 4 Engineers, 1 Product Manager, 1 Product Ops
Year
2022
Contribution
Design strategy, Product design, Research, Prototyping
One part of the experience still lived in GitHub
In 2022, while most website management happened within Isomer, publishing changes still required editors and reviewers to leave the platform and complete the approval process through GitHub.
For users unfamiliar with GitHub, this was a key friction point in the publishing journey and a recurring source of support requests for the Isomer ops team.
Bringing approvals into Isomer was a chance to close that gap and cut the support load it created.
Discovery
There wasn't one approval flow to bring over
We initially thought we could map GitHub’s approval flow directly into Isomer. But through user research with editors and reviewers, it was revealed to us that GitHub was only the final part of a much larger process.
Reviews started elsewhere, moved through rounds of feedback, and looked different at every agency.
What we learnt
Isomer rarely came first
Most collaboration and review happened outside the platform, communication was largely manual.
Every agency worked differently
Some teams gave editors more autonomy, while others required multiple layers of approval. No single workflow would fit them all.
Reviewers wanted in and out, fast
Most only opened Isomer to approve changes. They needed to understand what changed and act on it quickly.
So we stopped treating GitHub as the blueprint
Instead of asking how to recreate GitHub's approval flow, we began exploring how Isomer could support different ways of reviewing and publishing.
As reviews were often iterative, we explored how a request could evolve as it moved between editors and reviewers.
Concept testing
Testing the workflow, not just the screens
We tested two models: one where each resubmission created a new request, and another where related changes were kept together in a single thread.
Users thought about their edits as one continuous piece of work, even when individual changes needed further review. Keeping them together matched that mental model and made it easier to track progress.
Pivot
Then the scale of the problem changed
Midway through, we learned that Isomer would be taking on 300+ government sites by the end of 2022, roughly three times our existing volume.
This meant hundreds of new users would soon need to manage and publish their sites and GitHub-reliant approvals were about to become a friction point at a much bigger scale.
We no longer had time to solve the entire workflow at once. We narrowed scope to an MVP that replaced GitHub for the essential approval tasks, while carrying forward what we'd learned to shape the more flexible model as our longer-term direction.
Solution
Designing for the shortest path to approval
With the scope narrowed, we focused on making the core actions clear for both sides of the workflow: help editors request changes fast, and help reviewers understand exactly what needs their attention.
01 – Put what's actionable first
Our first dashboard gave site settings, collaborators and reviews equal weight. Testing showed users cared about pending reviews above everything else.
We brought them forward, so editors and reviewers could see what needed action at a glance.
02 – Don't make editors review what they already know
The initial flow asked editors to review their own changes before submitting, a step that added little value since they already knew what they'd changed.
We made it optional, removing friction without removing access to the information.
03 – Help reviewers understand what changed
Reviewers needed to quickly see what changed, where, and what decision it required.
We designed the review around that single task: request details, edited pages, and approval actions, all in one place.
04 – Keep conversations with the work
Feedback used to happen across email and messaging apps. Users had to piece together context from different threads.
We brought comments into each request, giving editors and reviewers a shared place to discuss changes as they iterated.
Next steps
Making room for what comes next
The MVP solved the immediate problem: bringing essential approvals into Isomer. But the broader workflow uncovered through research pointed toward something bigger.
One open question was how granular an approval could get.
For the MVP, we worked with engineering to support approvals at a page level. Longer term, we were exploring item-level approvals where a single change, like an updated link or image, could be reviewed and published independently of everything else in the request.
Reflections
What I Learnt
Sometimes the problem is bigger than the feature
As we spoke to users and mapped how publishing actually happened, approvals turned out to be only one part of a much larger workflow. That reframed the problem for me — from fixing a feature to rethinking how Isomer supports the way government teams collaborate.