The University of Michigan Division of Public Safety & Security Intelligence Group manages sensitive requests, investigations, and intelligence reporting that support campus safety. Rather than designing another case management tool, I worked with analysts to rethink how investigations were organized, tracked, and completed—creating a centralized operational platform for the full lifecycle of intelligence work.
Role
UX Research · Product Design · Information Architecture · AI-Assisted Product Development
Timeline
Summer 2026
Organization
University of Michigan Division of Public Safety & Security
Command Center
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
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.
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.
Understanding the work
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?”
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.
The pivotal decision
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
Rather than adding functionality because it was expected in case management software, every feature responded to a specific operational challenge uncovered during research.
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
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
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
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.