Briefs
Redesigning the building-profile tool university emergency dispatchers rely on mid-call.
This work involves an active public-safety environment. Everything here stays at the workflow level — screens are recreations, and no operational data appears.
Role
UX Research · Product Design · Information Architecture · AI-Assisted Product Development
Timeline
Summer 2026
Organization
University of Michigan Division of Public Safety & Security
The short version
Dispatchers coordinating emergency response used a building-lookup workflow so broken they worked around it entirely.
I ran contextual inquiry inside the dispatch center, documented how information moves across a 7-screen workstation and 10+ simultaneous tools, and redesigned BRIEFS around a tabbed information architecture with a sticky critical-information strip — so the details that matter mid-call never scroll away. The redesign now exists as an interactive prototype with a PRD the department is building against.
7
Screens per dispatcher workstation
10+
Simultaneous tools in live workflows
5
Fixed profile tabs in the redesign
Quick facts
Role: UX Research, Product Design, Information Architecture, Rapid Prototyping, AI-Assisted Development
Methods: Stakeholder interviews, workflow mapping, requirements synthesis, IA, iterative prototyping, usability feedback
Deliverables: Operational workflow, case management platform, request intake, command center, linked entities, design system, responsive UI
The challenge
It looked like a software problem.
When I first joined the project, the request sounded straightforward: “We need a better way to manage intelligence requests.” My initial instinct was to improve the request form and create a cleaner case management experience. But after spending time with analysts, I realized the software wasn’t the biggest obstacle. The workflow was.
The challenge wasn’t redesigning a screen. It was redesigning how intelligence work moved through an organization.
Current-state workflow
This visual earns its place by showing the real problem: intelligence work was distributed across tools that were never designed to operate as one system.
The cost of a buried answer.
When someone calls campus dispatch about a building — an alarm, a threat, a medical emergency — the dispatcher needs that building's critical details in seconds: access points, hazards, contacts. BRIEFS is the tool that holds them. When the lookup fails or buries the answer, the cost isn't a bad session metric; it's a slower response to a real emergency. That's the bar every design decision had to clear.
Understanding the work
I ran contextual inquiry inside the dispatch center, watching dispatchers handle live workflows across a 7-screen workstation running 10+ simultaneous tools. Three findings drove everything after.
Rather than jumping directly into interface design, I documented how information moved from the moment a request was submitted until findings were delivered. One insight changed the project: analysts spent only a few minutes receiving a request—but days managing the investigation that followed.
Before: “How can we make requests easier to submit?”
After: “How can we make investigations easier to manage?”
Workflow map / research synthesis
The research artifact matters because it explains why the case study pivots from intake UI to the operational model behind the work.
01
The lookup had been abandoned
Dispatchers had built personal workarounds because getting to a building's critical information through BRIEFS took too long under pressure. The tool designed for the emergency was being routed around during the emergency.
02
Critical information scrolled away
The profile was one long scrolling card layout. Access, hazards, and contacts lived at unpredictable depths depending on how much data a building had. Data-rich buildings buried the important parts; sparse ones looked broken.
03
Everything looked like an alarm, so nothing did
Warning iconography appeared on nearly every card whether or not anything was wrong. In an environment saturated with real alerts, decorative hazard icons trained dispatchers to ignore exactly the visual language that should mean "act now."
The pivotal decision
The request wasn’t the real unit of work.
My earliest concepts organized everything around incoming requests. It seemed logical—every investigation began with one. But requests were temporary. Investigations were not. A single investigation could include multiple requests, multiple analysts, people of interest, source checks, evidence, findings, documents, and follow-up work over days or weeks.
Click to compare
Request
Make the request the primary object
This mirrors the moment work enters the team and makes intake easy to organize, but it treats investigations as one-time transactions. Reopening, combining work, and preserving findings across time become harder.
Switch to the case-centered model
Before: request-centered
Queue → request → notes → delivery
After: persistent investigation
Intake → investigation → people → source checks → findings → completion or reopening
This before/after matters because every later feature—linked people, findings, notifications, case history, and collaboration—became a consequence of persistent investigations.
Design principles
Every feature solved a workflow problem.
Rather than adding functionality because it was expected in case management software, every feature responded to a specific operational challenge uncovered during research.
01
Centralized Case Workspace
Analysts needed one place to manage investigations instead of switching between emails, folders, spreadsheets, and notes.
02
Linked People of Interest
Individuals often appeared across multiple investigations. Reusable records preserved historical context and reduced duplicated work.
03
Investigation Lifecycle
Real investigations do not move from Open directly to Closed. The platform supports assignment, review, findings, completion, and reopening.
04
Role-Based Experiences
Requesters, analysts, and administrators each interact with different parts of the workflow while sharing one consistent system.
05
Responsibility-Based Notifications
Instead of notifying everyone, notifications are tied to responsibility—keeping requesters informed while helping analysts focus.
Annotated feature walkthrough
The screenshot should show how the product direction turns a fragmented workflow into a persistent workspace, not just a prettier case-management screen.
Designing with AI
AI accelerated iteration—not judgment.
Requirements changed continuously throughout the project. I used AI-assisted development to rapidly prototype and refine working interfaces based on analyst feedback, moving from research insights to functional prototypes that stakeholders could critique. AI helped accelerate implementation. It did not make design decisions.
Research
Prototype
Feedback
Iterate
This section is intentionally precise: it shows AI as a prototyping accelerator and product-assistance exploration, while keeping investigative judgment with human analysts.
Designing for complexity
Enterprise UX is really workflow design.
Intelligence work rarely follows a predictable path. Cases can be reassigned. Investigations can reopen months later. People appear across multiple investigations. Information evolves over time. Designing for these realities meant designing relationships between people, cases, notes, findings, permissions, and organizational processes.
This diagram should help a skimming reviewer understand that the product value is in connected records and responsibilities, not a single polished screen.
Impact
More than a new interface.
This project established a shared operational model for managing intelligence work within DPSS. Rather than introducing another disconnected tool, the platform creates a centralized workspace where requests become investigations, information remains connected, and analysts can manage work throughout its lifecycle. Because the product is still evolving, I intentionally avoid claiming unverified performance improvements.
Evaluation focus
Future evaluation would focus on time required to triage requests, investigation completion time, duplicate administrative work, analyst adoption, visibility into workload, and ease of retrieving historical intelligence.
What I am not claiming
This project changed how I think about UX.
Before this experience, I often thought of UX as designing interfaces. Working alongside intelligence analysts taught me that the most impactful design decisions happen much earlier: understanding how people, information, and decisions move through an organization—and designing a system that supports them without adding unnecessary complexity.
Today, I approach every project by asking not only “What should this interface look like?” but also “How should this work?”