CaseBase: Reports View
Orin & Schuster is a San Francisco law firm that uses CaseBase, a custom-built CRM, to manage their client base.
For confidentiality, I've changed the names of the firm, their employees, and the app.
I worked as the team’s only designer, alongside two developers and the firm’s project owner. We saved each attorney 2 hours per week with a streamlined reporting workflow.
February 2016 – July 2018
Attorneys were frustrated with building lawsuit reports by hand. Though CaseBase had a Reports feature, its rudimentary filters forced attorneys to rely on other apps.
We were challenged to help attorneys build reports more quickly and with less manual work.
I ran user interviews and field studies with three Schuster attorneys to better understand why making reports was frustrating, and more importantly, why they had to make them.
This was Melanie’s experience:
Melanie built these reports to answer three questions about each client in any lawsuit:
- What are all the products this person has used?
- How long did they use each product?
- When did they start and finish using the product?
We set out to eliminate Microsoft Access and Excel from Melanie’s report-building workflow.
Filtering data without Access
Melanie could already use CaseBase to find clients who’d used a given product, but she couldn’t refine her search by timeframe or product combinations.
Our new iteration augmented the filters with date ranges and logic operators. By using progressive disclosure, we gave attorneys more power without distracting their teammates.
Getting insights without Excel
I explored new Reports table layouts to help Melanie answer her three key questions without pivot tables. This was challenging because clients had extensive medical histories which she needed to see in full.
Top: An early, rejected concept. Attorneys found comma-delimited dates too hard to scan.
Bottom: A near-final concept, using more subcolumns to organize data.
Our final design introduced subcolumns and subrows to keep data-packed cells easy to scan. We also sorted and grouped data to replicate the layout in Melanie’s spreadsheets.
Attorneys could now analyze hundreds of cases in a glance, without having to build the same reports over and over.
A prototype of the final Reports View.
Thanks to our awesome developers, we were able to deliver a Reports experience that was fluid and fast.
Non-blocking filters let people rapidly tweak their filters, even if a query was still running
Optimized database queries returned a thousand-case report in under two seconds
Learning by watching users
Watching user session recordings reminded me that I am not the user. One of my favorite “discoveries” was seeing attorneys scroll the Reports table by dragging its horizontal scroll bar; I was so used to trackpads that this was a joyful surprise.
My developer teammates eagerly helped with usability testing, too! As Steve Krug pointed out, it’s easy for anyone to spot the most serious problems.
Natural language vs. database language
Given the following database, who has used Advil and Tylenol?
There are two answers because we can interpret “and” in two ways: attorneys, thinking in database language, said “Dolores”; their teammates, thinking in natural language, said “everyone”.
I realized this problem in my filter design too late, having only asked attorneys for feedback. Given more time, I’d replace my verbally-oriented solution with a visual one for a more intuitive design.