PROTECT: case management for Wisconsin prosecutors
PROTECT (Prosecutor Technology for Case Tracking) is the system District Attorney offices across Wisconsin's 72 counties use to manage cases. For 18 months I was its only designer. I created the brand, redesigned how case details appear in the desktop app, and rebuilt a 2005-era inter-county search tool. The web design system started from IBM's Carbon Figma kit, with light and dark modes.
A statewide legal system with no brand, no design system, a 2005 search tool and a desktop app that made people switch tabs for every case.
As the only designer for 18 months: the brand, a web design system built from IBM Carbon with light and dark modes, three web tools, desktop changes in Fluent UI, and 300+ screens made consistent.
Live: three web interfaces (XCQ, eFiling and Administration) built on the new web design system, and the desktop app with the new changes. All tested in QA with the BAs. Plus the new logo and brand files.
One platform, four very different design problems
PROTECT is built by the state's DA IT program (DAIT). It isn't one app. It's a Windows desktop application, a set of web tools, and the documents and training material around them. Each piece had its own users and its own technical limits.
The desktop app follows Microsoft Fluent UI, and I designed with the Telerik and ComponentOne components the developers were building with. Across desktop and web, I moved more than 300 older Windows-based screens into one consistent experience.
I worked directly with business analysts, who knew the legal workflows deeply, and with the developers who would build each piece. There was no other designer, so I owned everything from discovery notes to final specs.
Without a design team, I also led the work around the design: I ran workshops and the bi-weekly design reviews with the BAs and stakeholders, reviewed builds with developers and helped with HTML, CSS and Angular, and mentored teammates on UX and Figma.
Logo & identity
A mark that works from a 16px taskbar icon to a training manual cover.
02 · DesktopDetails pane
Shows synced case data under the grid so people stop hopping between tabs.
03 · WebXCQ inter-county query
A search tool from 2005, rebuilt with sorting, paging and a real component library.
04 · WebeFiling site search
A people and case lookup built from the same components as XCQ.
Search like DA staff do
A small working version of the XCQ search, built from the same components as the case study. Type a last name, sort the columns, change the page size, or turn on a failed county sync to see how the screen warns you. All names are fictional.
| Sex | Aliases |
|---|
Learning a legal domain with limited access to users
Prosecutors and their staff are busy, and government projects don't always grant designers direct sessions with them. I combined what I could get: BA-led requirement sessions, walkthroughs of the live tools, feedback already logged by users, and stakeholder reviews of every prototype. When I couldn't test with end users, I ran proxy sessions where analysts who support DA offices worked through the prototype while I watched and took notes.
What I gave up, and why it was the right call
Modern patterns vs. the Windows desktop framework
Engineering confirmed the desktop renderer couldn't support animation or reliable hover. I checked every proposed element with a developer before it went into a frame, so nothing had to be cut later.
Show every result vs. paginate
Large surname searches were slow in the old tool. Letting people set the page size kept their habit of scanning long lists without the slow load.
Fresh visual style vs. continuity
Staff move between desktop and web all day. Shared colors and components make the web tools feel like the same product.
Wait for user access vs. test with proxies
Waiting would have stalled the schedule. Proxies caught most usability issues, and the decision log recorded what still needed confirming with real users.
Each piece of PROTECT, in depth
Each case study has its own research, trade-offs and interactive Figma file.
Logo & identity
A mark that reads as Wisconsin, legal and software, and survives 16 pixels.
Details pane
Ending tab-hopping: case details follow the selected row, inside strict desktop limits.
XCQ inter-county query
A 2005 search tool rebuilt on a new design system, with sorting, paging and accessibility.
eFiling site
Cross-county search in the browser, designed around data freshness and clear error states.
Built from IBM Carbon, extended for PROTECT
I didn't draw the web design system from scratch. I started from IBM's Carbon Figma kit, kept what already worked for dense, data-heavy tools, and changed what PROTECT needed. Carbon is made for enterprise software, which suited staff who read tables all day.
Carbon's roles, PROTECT's colors
Kept Carbon's token roles (background, layer, field, text, border, support) and pointed them at PROTECT navy and gold. Two modes: Light and Dark.
From the kit, restyled
Buttons, inputs, notifications and tags from the kit, restyled with PROTECT tokens. Each state is a variant: default, hover, focus, disabled, error and read-only.
Carbon's table, extended
Carbon's data table as the base. I added surname-first sorting, inline aliases, a page size of 10, 25 or 50, and a last-synced footer.
One layout system
Carbon's grid, spacing scale and type scale, so XCQ, eFiling and Administration line up and feel like one product.
Below is a recreation of the Figma file with sample data: the variables in both modes, components in light and dark, and the same XCQ and eFiling screens with the Dark mode turned on. Names are fictional and color values are simplified for this site.
| Name | Light | Dark |
|---|---|---|
| Background | ||
| background | #f6f7fa | #0f1726 |
| layer-01 | #ffffff | #18233a |
| layer-02 | #f3f5f9 | #213052 |
| field-01 | #ffffff | #0f1726 |
| Text | ||
| text-primary | #111827 | #eef2f9 |
| text-secondary | #4b5563 | #a9b6cf |
| Border | ||
| border-subtle-01 | #e5e7eb | #2c3b5c |
| border-strong-01 | #9ca3af | #5a6a8c |
| Interactive | ||
| brand-header | #233b63 | #0b1220 |
| button-primary | #e1c25c | #e1c25c |
| link-primary | #2563eb | #8ab4ff |
| focus | #2563eb | #8ab4ff |
| Support | ||
| support-success | #16a34a | #6fdc8c |
| support-warning | #e1c25c | #f1d27a |
| support-error | #dc2626 | #ff8389 |
Results from those counties may be missing. Try again after 6 AM, or contact DA IT if it continues.
Check the spelling, or search by last name only.
Variable collection❖
Mode check❖
Variables applied⬡
Variables applied⬡
Frame❖
Frame❖
Data table❖
Data table❖
Banner❖
Banner❖
Frame❖
Notification❖
Search bar❖
- Components use semantic tokens only, never raw colors, so switching a frame to Dark changes the whole screen.
- Properties and variants cover the states designers need, so nobody has to detach an instance.
- New patterns from product work go back into the library, like the data-freshness banner from eFiling.
- The decision log records what was approved, by whom and when.
- One shared Figma library; developers see the same token names in Dev Mode.
One library, four products
There was no design system when I joined. I started from IBM's Carbon Figma kit and built it out in stages: brand tokens first, then the XCQ component library, then patterns the desktop and eFiling work could share.
The eFiling site search was the test. Its people and case lookup was assembled almost entirely from existing XCQ components. The one new pattern it needed, a banner for data freshness, went back into the library for everyone.
To keep it governed as a solo designer, I kept a decision log in the file. Every approved and pending choice was written down with the date and who approved it, which kept settled decisions from being reopened in reviews.
| Database Search | → | XCQ Query |
| Scheduled Events | → | Hearings |
| Pending Review | → | Awaiting DA action |
| ERR_422 validation failed | → | Charge date can't be before the arrest date. |
Labels follow the words DA offices already use, and errors say how to fix the problem.
Annotated frames with redlines, every component state, keyboard order and screen-reader notes for tables, delivered alongside InVision walkthroughs for reviewers outside Figma.
What went live, and what I'd do differently
I delivered a new logo, a design system for the web, three web interfaces (XCQ, eFiling and Administration) and changes to the desktop app. Engineering built from my Figma specs, everything went through QA testing with the BAs, and all of it is now live.
“What stood out most was Shivani's ability to adapt across a wide range of challenges, from UI/UX for multiple platforms to logos and icons.”Lisa FangmannBusiness Analyst, Wisconsin
Build the library earlier
The full component library came together months in. Starting with it would have made the later workstreams faster.
Start the decision log on day one
It started as a fix for repeated debates. From the first week, it would have prevented them.
Push for direct user sessions sooner
Proxy testing worked, but a few early sessions with DA staff would have confirmed the desktop and web split weeks earlier.