CitySite — Government CMS

Beyond website templates

CitySite is a no-code CMS that helps local governments create and maintain public websites. Built on a third-party framework, the product primarily supported website creation through customizable templates, layouts, and visual styles.

The business wanted to expand beyond smaller government organizations and offer a broader range of website templates for mid-sized government teams. My initial brief was to design more templates in different styles and structures.

Before designing more templates, I needed to understand how these organizations actually managed their websites.

The problem wasn't inside the editor. It was between people.

I wasn't familiar enough with government publishing practices to assume that larger organizations simply needed more website templates. I proposed speaking with potential users first, then independently recruited participants from the company's existing sales contacts. Through approximately five interviews, I learned how government teams requested, created, reviewed, and published web content.

Across the interviews, a similar process emerged. Department representatives initiated content changes, while designers and QA specialists supported production and approval. The steps themselves were familiar, but coordination often happened through emails, meetings, and informal conversations rather than a shared system.

VISIBILITY

Requesters lost visibility after handoff

Once a request left their hands, Requesters had no shared view of whether work had started, moved to QA, or was waiting on someone. Status updates often required another email or meeting.

COLLABORATION

Feedback lived outside the work

Requester and QA feedback came back through emails, calls, and meetings. Designers had to piece it together before they could act on it.

OWNERSHIP

Access wasn't tied to ownership

Designers had broad CMS permissions rather than access scoped to the requests they owned. The system did not clearly connect editing access with responsibility for a particular piece of work.

Make the work move between people—not make people chase the work

The research revealed an important pattern: the work began with a request, not with a designer or a webpage. Department representatives initiated content changes, while designers and QA specialists served different responsibilities throughout the publishing process. Each role contributed to the same piece of work, but no shared system connected their actions.

That became the foundation of the product model. Rather than organizing the experience around a particular role or the webpage editor, I introduced the request as the shared unit of work. Each request would carry its own status, ownership, feedback, and approvals as it moved between people—turning an informal process into a structured workflow without changing the underlying responsibilities.

One request. One shared workflow. Different responsibilities.

REFINING THE WORKFLOW

I tested the mid-fidelity prototype with three participants—one Requester, one Designer, and one QA Specialist—each working within their own role-specific portal. One issue stood out: QA could publish a page without reviewing it first.

Instead of relying on a confirmation dialog or disabling the Publish button, I moved approval into the page preview itself, making review part of the publishing flow. In a follow-up session, the QA participant found the revised flow intuitive.

BEFORE

AFTER

One workflow. Three responsibilities.

The North Star translated the request-centered model into three role-specific experiences. Each portal supported a different responsibility while keeping the work connected through the same request.

A tested North Star for multi-role publishing

In six weeks, I moved from an initial template design brief to a research-informed product direction, defining and prototyping how Requesters, Designers, and QA Specialists could coordinate website publishing through a shared workflow.

The North Star gave the team a concrete concept for a potential expansion into mid-sized government organizations. It was intended to support future fundraising discussions, but the initiative did not reach investor presentations or production development after changes in the government market and funding environment led the business to reconsider its plans.

The concept received initial usability feedback across all three roles, but its operational and business impact remains unmeasured.