Justice By Design
2014 · Federal Judiciary · Criminal Sentencing · CSRA / U.S. Courts
Zero-Error Sentencing Calculator for Federal Presentencing and Courtrooms
Mobile mode preferred by federal judgesRedesigning the federal sentencing calculator used across all 94 U.S. districts — where every calculation carries constitutional weight and failure means an unjust sentence.
↪ Impact
✓ Adopted across all 94 federal court districts by 30,000+ court staff
✓ Replaced an unreliable legacy calculator in zero-error courtroom environments
✓ Designed and coded the full front-end — UI, interaction logic, and responsive layout — using AngularJS
✓ Grounded in ethnographic research inside federal courthouses, including direct observation of sentencing hearings
↪ The Problem
Inaccurate. Unavailable.
In every federal criminal case, a pre-sentence officer calculates a recommended offense level that directly informs the judge's sentencing decision. The calculation is complex — driven by the U.S. Sentencing Commission's guidelines manual, the specifics of the offense, and the officer's professional judgment. Multiple alternative scenarios are typically calculated and compared before a final recommendation is made. The resulting number is cross-referenced with the offender's criminal history to produce a sentencing range — say, 30 to 36 months — that shapes plea negotiations and, ultimately, the judge's ruling.
The existing calculator was built on a legacy Java-based UI framework approaching end-of-life. It produced unreliable results. And it couldn't function on the tablets that federal judges were increasingly bringing into courtrooms.
The opportunity wasn't just a technology migration. It was a chance to rethink how officers navigate one of the most consequential calculation processes in the federal justice system.
Three years of vision work. None of it shippable within platform constraints.↪ My Approach
♠︎ Diagnosed
Mapped six non-compliant patterns across hundreds of instances to understand exactly where the real friction was.
♣︎ Rebuilt
Restored cross-functional trust by demonstrating compliance and adopting the platform team’s own established process.
♦︎ Negotiated
Identified ten innovations scoped for platform adoption. Showing the vision with real constraints was more persuasive than pure aspiration.
♥︎ Delivered
Shipped the core touchless flow first. Delivery earned far more credibility than any vision decks of mocks.
Example blocker — expense receipt attachment↪ The Design
1. Phone screen density
The core interaction surface is the expense card — the thing users see most and tap most. It needed to carry merchant name, amount, date, category, receipt status, and policy flags without feeling like a data table shrunk onto a 375px screen.
I used a clear visual hierarchy: merchant and amount dominate (they're what the user cares about first), status sits in a chip component that changes color and label based on state, and policy information stays hidden until it's relevant.
The goal was a card you could glance at and know "this one needs attention" or "this one's fine" without reading anything.
2. Making enterprise feel mobile-native
One of the hardest tensions in this product was that it ran on Oracle's Redwood design system, which was built primarily for desktop and had minimal mobile pattern support. We had to use Redwood's components as-is — for launch. But I laid out a roadmap of key enhancements that would get us closer to the experience people expected from their phones, while acknowledging the limits of an enterprise PWA.
The card idea itself was contentious. Stakeholders were firm in the belief that this pattern was the best way to achieve a consumer-grade experience. However, Redwood had no such component. To get across the finish line, I devised a short-term workaround — one with usability tradeoffs. Monitoring usage demonstrated my concerns and resulted in product committing to a real solution for this and other sacrifices.
3. What "touchless" actually means in practice
The product's name — Touchless Expenses — makes a promise: minimal manual effort. But the reality of expense management is messy. Receipts come in different formats, OCR isn't perfect, and policy rules vary by expense type, currency, and geography. The design challenge was making the system feel effortless when automation succeeds while providing clear, non-punitive paths when it doesn't.
When a receipt is automatically matched to a credit card transaction, the user sees a clean, resolved card — no action needed. When there's a mismatch or a missing receipt, the card surfaces a gentle prompt with a clear action. I was careful to avoid the trap of making error states feel like the user did something wrong — in most cases, the system failed, not the person. The tone of every status message reflects that.
4. Telling users they might be in trouble — without making the app feel punitive
Expense policy is the third rail of this product. Employees need to know when their spending might not be approved, but nobody wants to use an app that feels like a compliance officer looking over their shoulder.
I partnered closely with our own policy team to understand where we had room to smooth the process and where we were limited by regulation. We also surveyed customers to understand their policy considerations.
I used progressive disclosure to layer policy information: the card shows a simple status indicator, and only if the user needs to take action does the interface present an edit or justification flow, revealing related policy info. This keeps the happy path clean — most expenses are fine, and users shouldn't have to wade through policy language for every coffee receipt. But when something does need attention, the information is there, clearly written, and the required action is obvious.
Exception handling had to be as touchless as possible, while remaining fully compliant with corporate policy and government regulations↪ The Outcome
From Stuck to Flagship
What started as damage control became a model for how Redwood-compliant work could get done on this and all mobile projects. The team with a reputation for ignoring process ended up establishing a process others followed.
The pilot launched in April 2023 with 26 users, growing to 450 in six moths and over 1,200 by the two-year mark. Redwood adopted new mobile patterns and other teams leaned on our work for their own mobile initiatives.
↪ The Takeaway
Leadership had legitimately competing priorities. Both were reasonable, but neither fully compatible. My job was to find the overlap where something real could ship and each side could see their work reflected in it.
One vision for what comes next↪ Coda
No one likes doing expenses — especially when outside the office
Years of resources were allocated to creating a consumer-grade mobile expenses app. Stakeholders were convinced that this was the best route to achieve the “touchless” vision.
When real usage data showed a consistent decline in mobile usage — the first users were stakeholders, so they were all-in on the mobile approach — it was assumed the usability sacrifices were the culprit. If we could just fix the design issues, people would use the mobile app.
Wrong.
Extensive user feedback, interviews, and guerrilla contextual inquiries made clear this was not a design problem. People simply had no interest in doing their expenses when away from their desk. Travelers were rightfully focused on their primary job, their customers, and their getting to their next destination. Others just saw expenses as work, a banal task to be done at the office.
In retrospect, it would have been valuable to have explored the mobile hypothesis more thoroughly from the git go. Next time.