A city website is an <infrastructure> problem
phoenix.gov serves 1.6 million residents across dozens of departments, each publishing independently. I built the design language that lets them all ship without colliding — dark-first, WCAG-audited, and built to survive handoff into Adobe Experience Manager.
Every department was its own design team.
Aviation, Fire, Parks, Water — each publishing to the same domain with its own take on what a button looks like. The site didn't read as one city.
For a resident trying to pay a bill or report a pothole, that inconsistency isn't cosmetic. It's a trust signal. When the "Report an Issue" button looks different on every page, people start wondering which one is real.
Six CTAs, six radii, six weights. Color chosen by whoever built the page — no rule connecting hue to meaning.
One radius, one weight, one scale. Color is no longer decorative — it now maps to a fixed content category, and blue always means primary action.
Three calls that shaped everything else.
A palette grid proves you can name colors. These are the decisions the rest of the system had to obey.
Dark-first, on a government site.
Municipal sites are almost universally light. Phoenix went the other way — #0D1B2E navy as the base, with white and cyan on top.
Dark-first forces contrast discipline early. On a light background you can get away with mid-grey text; on navy, anything under-weighted disappears immediately, so every pairing has to be audited before it ships. Designing dark first and deriving light from it produces a stronger system than the reverse.
Cyan never clicks. Blue always does.
The system runs two accents. Cyan #3DD5D5 appears on hero headings and section labels. Blue #1B7FE0 appears on buttons, links, and focus rings.
The rule is absolute in one direction: cyan is never applied to something interactive. That means the palette itself answers "can I click this?" before a user has hovered anything — which matters most for the people least likely to experiment, and on a city site that's a lot of them.
Six category colors, allowed in exactly one place.
Magenta for parks and arts. Coral for trails. Teal for events. Amber for tourism. Each maps to a content type and appears only on Explore card CTAs — nowhere else in the system.
This is the constraint that keeps the palette from collapsing. A six-color set used freely becomes noise within a release; the same set restricted to one component becomes a wayfinding language. Residents learn that coral means trails without being told.
Components in isolation always look fine.
The real test is whether they compose into a page a resident can actually use. Everything below is kit — nothing bespoke.
Pay your City Services Bill or other fee.
Request services using myPHX311.
Find your collection day or bulk pickup.
Pools, trails, community centers, and more.
Share your input on how federal funds should be used to support community programs across Phoenix.
Learn More & Take Survey →Three goals, none of them cosmetic.
Before the kit came the sitemap. Three objectives shaped it, grounded in real user stories rather than department preference.
Objective
To ensure essential City services are highlighted and easily accessible, we leveraged analytics and search intent data to inform the new sitemap and information architecture.
Elevate Essential City ServicesObjective
By breaking down departmental silos, we aim to provide a less siloed user experience, while still retaining important resources and information for City departments.
Integrated Services and DepartmentsObjective
The new sitemap is designed to equally serve both residents and visitors, providing a unified experience across transportation, parks, recreation, events, arts, and culture.
Residents and VisitorsTop Level Categories
Category
A centralized hub for essential services — utility payments, reporting local issues, finding housing options, and accessing community resources such as police, fire, and emergency preparedness.
ResidentsCategory
Dedicated exclusively to City services and resources related to business operations — permits, licensing, and services designed specifically to support Phoenix's business community.
BusinessesCategory
Maps transit options, highlights street closures, lists public transportation choices, and provides pedestrian and cyclist resources — persona-agnostic, for visitors and residents alike.
TransportationUser story discovery
By anchoring our design in real user stories, Reingold embraces a user-centric approach that ensures every feature is crafted around genuine needs and narratives.
What We Did
Three activities to ground the work in user reality
Engaged with stakeholders through a workshop in Phoenix, capturing valuable user stories firsthand.
Conducted a thorough analysis of the current website and user search intents, extracting and organizing user stories by department.
Compiled all user stories into Airtable, synthesized them into broader categories called epics, and prioritized them based on user value.
Tree testing results
A granular review of participant behaviors across core informational routes — direct paths, circular logic, and structural drop-offs — to pinpoint exactly where architecture failed expectations. Tree test conducted with 92 participants on Phoenix.gov.
Imagine you've just moved into a new home and need to set up your water service. Where on the site would you find that?
You're an entrepreneur planning to open a new storefront and need to check the commercial zoning laws. Where on the site would you find this information?
As a person with a disability, you require an accessible ride service within the City. Where on the site would you find information about the service?
You're interested in playing golf this weekend. Where on the site would you find that to book a tee time?
If you're looking to learn about the initiatives led by the mayor, where would you search on the City's website?
-
The new top-level categories are performing well overall.
-
Lower success and directness scores on several tasks indicate a need to adjust the sitemap to enhance clarity of some subcategory and page labels.
-
Users sometimes navigated to logical but incorrect sections, suggesting the benefit of incorporating cross-linking or a "Did You Mean?" feature on certain pages to guide users more effectively.
Task analysis & navigation paths
A granular review of participant behaviors — direct paths, circular logic, and structural drop-offs — to pinpoint exactly where the architecture failed expectations.
Scenario
Imagine you've just moved into a new home and need to set up your water service. Where would you find information to get this started?
Correct Destinations
Recommendations
No change needed for this page.
Scenario
You've noticed your garbage bin is cracked and needs replacing. Where would you go to request a new one?
Correct Destinations
Recommendations
No change needed for this page.
Scenario
Your grandmother is coming to live with you, and you want to look into local support services for her. Where would you look?
Correct Destinations
Recommendations
Consider relabeling Benefits & Support to something more understandable. This new section is intended to provide a collection of resources for human services or underserved Phoenicians.
A system nobody uses is a mood board.
The work wasn't done when the Figma file was. It was done when a Fire Department page and a Parks page stopped looking like different websites.
Governance mattered more than I expected. Departments needed a path to request new components, so intake asks three questions: what user problem, which existing component fails, and how many pages would use it. Most requests resolve to an existing component with different content — which is exactly the outcome you want.
Explore the library.
Every foundation and component, live. This is the reference layer — the argument is above.
| Category | Color | Token |
|---|---|---|
| City Parks | #C01E6E | --magenta-500 |
| Golf | #1B7FE0 | --blue-500 |
| Hiking and Trails | #E06848 | --coral-500 |
| Major Events | #10B8C8 | --teal-500 |
| Arts, Culture & Nature | #C01E6E | --magenta-500 |
| Visit Phoenix | #C99A10 | --amber-500 |
| Token | Value | Usage |
|---|---|---|
| --dur-fast | 150ms | Hover color changes, icon states |
| --dur-base | 250ms | Button hover, nav highlights |
| --dur-slow | 400ms | Accordion expand, panel slide |
| --dur-entrance | 600–800ms | Page-load fade-in animations |
| --ease-out | cubic-bezier(0.16, 1, 0.3, 1) | Elements entering the screen |
| --ease-in | cubic-bezier(0.4, 0, 1, 1) | Elements leaving the screen |
| stagger-delay | +100ms per child | List / card entrance animations |
| bounce | 1.8s ease infinite | Scroll-hint arrow pulse |