How three departments ended up with one project page system, without losing what made their work different.
One Model for Every City Project
The problem
Transportation, Community Development, and Public Works each published project pages on cambridgema.gov. Between them, they used four or five layouts, maintained by more than 20 people in Sitecore.
Each department built its layout for a reason, and each could point to real differences in its work. None of them reported to me, so I couldn't mandate a template. And making the pages look alike wouldn't have fixed anything.
I wrote the project scope: the problem, the constraints, and how we'd measure success. The goal was one shared model that worked for all three departments without erasing the differences that mattered.
Looking at the experience from the resident side
Projects move between departments as the work progresses, and the information splits with them.
Inman Square started with Transportation's safety studies, planning, and traffic changes, then moved to Public Works for construction. Each department kept its own page for its part. That made sense inside the City. But a resident following one project had to find it in two places, and all they wanted to know was:
what's happening in Inman Square, and how will it affect me?
I audited projects across all three departments and studied how Boston, San Diego, Charlotte, and New York present project information. The same questions came up on every page:
What is the project?
Where is it?
What's its status?
What's happening now?
What's the timeline?
What's the impact?
What comes next?
How can I stay informed or weigh in?
The pages looked different, but they did the same job.
I brought that list to the departments, and the argument shifted. They stopped debating whose projects were more complex and started sorting what residents needed on every project from what only certain projects needed.
The real change: how projects move between departments
The layout wasn't the real problem. The workflow was.
When a project moved from one department to another, the receiving department started a new page from its own layout. The history, documents, and updates stayed behind on the first department's page. Every handoff broke the project in two, for residents and for staff.
The shared model changes what a handoff means. Every page names a lead department and any supporting departments. When Inman Square moves from Transportation to Public Works, Public Works takes over the same page. It becomes the lead, adds construction updates and impact details, and the planning history stays where residents already know to look.
That only works if the template flexes. The same page has to hold a traffic study in one phase and a construction schedule in the next. Community Development projects push it further: the Mass Ave Planning Study runs on working groups, repeated community meetings, and public feedback over years. A rigid template would have pushed departments back into separate pages.
I walked all three departments through a single project's lifecycle on one page, from planning through construction, and showed each team what its part of the handoff would look like. That's what got them to agree to a shared model. Consistency alone didn't.
Building the shared model
I built the system around a shared core instead of a fixed template. Every project page answers the core questions first. Teams then add the modules their project needs: engagement content, documents, public comments, photos, detailed updates, or extended timelines.
The departments didn't have to agree that their projects were the same. They only had to agree that residents arrived with the same questions. The differences stayed. The separate page systems didn't.
Where it stands
The City Manager's Office and Communications approved the design. I validated it with users and stakeholders.
It hasn't shipped because the CMS work isn't done. When it ships, I'll measure three things: department adoption, the time staff spend creating and updating pages, and resident usability scores.
What I took from it
I went in thinking simplification meant removing things. It doesn't. Some complexity has to stay.
The work is deciding which complexity belongs to the user, which belongs to the organization, and which shouldn't exist at all. Once I separated those, four or five layouts became one model, and no department had to pretend its projects were the same as everyone else's.
User Testing Quotes
-
The FAQ is a little bit extreme with the drop down having so much information. I think it'd be better as horizontal tabs but I like the information. Maybe incorporating both designs or having it take you to a different page. But I like the information and layout. I like at the top there's a map showing you where it is.
-
It's innovative, especially having the map at the top, so I know exactly where, the information is easy to read.
-
Very easy to navigate through and to understand.