The Problem: The City of Dearborn relaunched dearborn.gov in August 2024 and wanted to know whether it was actually meeting residents' needs before investing further in it.
What We Did: Ran six triangulated research methods — interaction mapping, resident interviews, survey design, competitive analysis, heuristic evaluation, and usability testing — over roughly two and a half months.
Headline Outcome: Four evidence-backed findings, each tied to a concrete recommendation, delivered as a final report to an actual municipal client.
01. The Scene // "A relaunch is not the same as a win"
In August 2024, the City of Dearborn launched a redesigned website — a real step forward from what residents had before. But shipping a new site and knowing it actually works for people are two different things, and by 2026 the city wanted an honest answer, not just a redesign retrospective.
The brief was direct: test the efficacy of the website and the overall user experience, and deliver recommendations for improving its quality for the people who actually use it — residents trying to pay a bill, apply for a permit, or find emergency information, not stakeholders admiring a homepage.
"What needs do Dearborn residents have regarding dearborn.gov, and how does the current website compare to their expectations?" — our guiding research question
02. What We Actually Did // "Six methods, so no single blind spot could hide"
Rather than lean on one method, we triangulated across six, run in this sequence over about two and a half months:
2/8 — Interaction Mapping
Explored and documented the website's existing layout and structure before forming any opinions about it.
3/8 — User Interviews
Preliminary interviews to learn the actual needs of the Dearborn community, in their own words.
3/15 — Survey Design
Built an instrument to gather broader data on Dearborn residents and their use of the website.
3/29 — Competitive Analysis
Looked at websites in adjacent fields to find concrete points of comparison and improvement.
4/5 — Heuristic Evaluation
Analyzed the website against established usability industry standards.
4/22 — Usability Testing
Watched real people attempt common tasks on the site and documented exactly where they struggled.
To ground the findings in real people rather than abstractions, we built three personas from the interview and survey data:
Michael Adams — Retiree, 68
Involved with the local community; has online/remote needs due to a physical disability; prioritizes clarity over looks; dislikes confusing errors and tasks with no alternatives.
Amanda Kim — U-M Dearborn Student, 21
Relies heavily on her smartphone; wants all her information in one place; uses government sites mainly for service info, emergency updates, and paying occasional tickets.
Amira Masour — Business Owner, 35
Calendar is often full with appointments and deadlines; wants mobile access for on-the-go needs; wishes taxes and permit requirements could integrate into her existing flow.
03. The Messy Middle // "One session, and it wasn't a small finding"
Our foreign-language finding came from exactly one Arabic-language usability session — a sample size that would normally make us cautious about how much weight to put on it. Dearborn has a significant Arabic-speaking population, and this wasn't a minor annoyance we found: the language toggle wasn't consistently available across pages, and navigating back silently reset the site to English with no way to switch back to Arabic.
04. The Findings & Recommendations // "Every finding, traceable back to a method"
Finding 1: A Web of External Links
Finding: Navigation links out to external sites rather than staying within a centralized structure, so users struggle to reorient themselves or return home — especially frustrating with external forms and documents. Supported by: Interaction Map, Competitor Analysis, Usability Testing.
Recommendation: Open fillable forms/documents in new tabs, with clear signifiers when doing so — standard links can stay in-tab, but a new tab should open when the back button would destroy entered info, or when a user needs the main site's information while filling out a form.
Finding 2: Mobile Experience Falls Short
Finding: The mobile version mirrors the desktop layout rather than being purpose-built for mobile use. One user described it as "kinda clunky" and "slimmed down" — excessive scrolling was required even for simple tasks, with key info buried. Supported by: Interviews, Competitor Analysis, Usability Testing.
Recommendation: Redesign the mobile experience based on user feedback — prioritize a mobile-first layout for the highest-traffic page, reduce scrolling by moving key actions higher and adding in-page navigation to jump to sections, and consider a dedicated City of Dearborn app for the most common resident tasks.
Finding 3: Confusing Language Around Key Functions
Finding: Section labels and link text didn't clearly signal what content was inside. Users felt they had to "decode the language" of the site to find what they needed, and some labels were duplicated or misleading. Supported by: Interviews, Heuristic Evaluation, Usability Testing.
Recommendation: Rewrite navigation labels and page headings in language that matches how residents actually think — consolidate duplicate labels, revise ambiguous ones, test any new label structure with real residents before implementing, and prioritize plain language for frequent tasks like paying bills, applying for permits, and finding emergency information.
Finding 4: Critical Gaps with Foreign Language Support
Finding: The language toggle wasn't consistently available across all pages, and navigating back reset the site into English with no option to switch back to Arabic. Supported by: Usability Testing.
Recommendation: Persist the language preference and make the toggle universally accessible — a user's language choice should follow them through their entire session, never resetting on "back," and the toggle should be visible on every page, not select ones.
05. Did It Work? // "The honest scoreboard"
This report went to an actual city government, not a hypothetical stakeholder — that's worth sitting with. At the same time, we were upfront in our own limitations about what the research could and couldn't support: both interviews and usability tests involved a limited number of participants, and Arabic-language testing was underrepresented, with only one session completed — even though that session surfaced some of the most actionable findings in the whole study. The recommended next step is distributing a broader survey (physically, at government buildings, libraries, and the U-M Dearborn campus, and digitally via city social media) to validate these findings at scale before further site investment.
06. Behind the Scenes // "Director's Commentary"
07. Souvenirs // "Take one home with you"
Want to inspect the raw materials? Links to be added:
Working across six methods with a five-person team taught me more about research discipline than any single method could have — every finding in our final report had to name exactly which methods supported it, which meant we couldn't quietly lean on a compelling interview quote if the heuristic evaluation and usability testing didn't back it up too. That habit — citing "supported by" under every claim — is one I want to carry into every research deliverable going forward, portfolio case studies included. Presenting deliverables to the client every week was its own skill separate from the research itself — it meant translating in-progress, sometimes messy findings into something a non-designer stakeholder could follow and trust, on a weekly cadence, not just once at the end.