Submit a hubNashville request
Route potholes, missed trash, code concerns, and non-emergency service issues into one receipt-first path.
Prototype service desk
Start with the resident's verb.
Current homepage signals include search, hubNashville requests, popular services, recovery resources, news, events, maps, district lookup, and Metro video. The improvement is not more content. It is a clearer first decision.
Pay property taxes or fees
Give users requirements, due dates, accepted payment types, and office ownership before payment.
Find trash or recycling info
Combine pickup schedules, drop-off locations, accepted materials, and service alerts in one branch.
Look up council district and maps
Keep address lookup, council member, district boundaries, and public maps in one predictable path.
Recovery resources
Promote restore and recovery resources only when urgent, with service status and office contacts.
Meetings, news, events, and MNN
Move civic awareness below the service desk unless the visitor chooses attend, watch, or learn.
No matching service brief. Try a broader civic verb like request, pay, find, trash, property, map, or meeting.
Breakout page
A hubNashville-style request path without the link maze.
This is the proposed breakout behavior: select the service intent, collect only the required fields, show a receipt, and keep the official handoff obvious.
Flow analysis
Improve the homepage by changing the order of decisions.
Ask the verb
Pay, request, find, learn, attend, or watch. The page should sort the job before the department.
Separate urgent paths
Emergency and recovery resources need priority lanes, not the same visual weight as general news.
Show needed info
Before a handoff, tell the user what address, ID, fee, photo, or contact detail is required.
Confirm next step
Every request or service path should make ownership, status, and follow-up obvious.
Move content below
News, events, maps, MNN, and feedback remain available after the service desk is solved.
What gets better
A quieter page with faster civic decisions.
The resident picks a verb before scanning departments.
Requests end with reference language, not uncertainty.
Controls stay large enough for real phone use.
The prototype does not transmit user-entered data.
Usability and OWASP checks
Demo checks before deploy.
Keyboard and screen-reader structure
Skip link, semantic headings, labelled form controls, button elements for commands, and an aria-live receipt panel.
Mobile scan path
Responsive single-column fallback, no horizontal overflow, stable tap targets, and service cards that do not resize unpredictably.
Client-side input handling
Search and receipt output use textContent, no eval, no inline event handlers, and no dynamic HTML injection.
Submission boundary
The form has no network action. A production Metro form would still need server-side validation, rate limiting, CSRF protections, and abuse monitoring.
Dependency surface
No external fonts, frameworks, trackers, or third-party scripts. The local SVG asset is served from the same static origin.
Header posture
The deployment configuration keeps nosniff and referrer policy, and can add CSP, permissions policy, and frame protections without changing the demo flow.
Demo boundary
This is not an official Nashville.gov page.
Ten Thirty Two is using the public homepage as a design-flow exercise. The page avoids official outbound links, does not collect real reports, and does not represent Metro Nashville. It demonstrates how a civic homepage could split search, service requests, recovery resources, news, events, maps, and video into a calmer resident-first path.