CaseBase: Case View
Orin & Schuster is a San Francisco law firm that uses CaseBase, an in-house CRM, to manage a large client base while staying small.
I worked as the team’s only designer, collaborating with two developers and the firm’s project owner.
For confidentiality, I've changed the names of the firm, their employees, and the app.
February 2016 – July 2018
The Schuster team’s lawsuit data was split across CaseBase, Microsoft Sharepoint, and Excel spreadsheets, making it hard to stay on the same page. The team often duplicated data to fill gaps between each system.
Our challenge was to help the team keep track of lawsuits more confidently and prevent duplicated efforts.
I ran user interviews and field studies to understand how each Schuster team worked together on a lawsuit.
Each person played one of four key roles:
Teams comprising of these four roles work together on a lawsuit; each lawsuit was split into key phases, and each team member had responsibilities in multiple phases:
While Intake Specialists relied on CaseBase in Phases 1 and 2, the rest of the team used Microsoft Sharepoint and Excel to track client information in Phases 3 through 5.
This made it made it harder for people to handoff case work. We often saw duplicated efforts across multiple roles:
Attorneys tracked verified medical history in Sharepoint, but had to open CaseBase to reference it against its unverified version
Paralegals stored court dates and filing deadlines in Excel. Attorneys emailed them for simple facts, since Sharepoint lacked fields to store these
The Finance Manager copied co-counsel information from CaseBase into Sharepoint to calculate Settlement payouts
We iterated CaseBase’s Case View to help Orin & Schuster see everything about a client in one compact view, letting teammates reference each others’ work more quickly.
Exploring a new layout
Since the original Case View was only designed for Intake Specialists, I sketched new layouts that could also accommodate the work of Attorneys, Paralegals, and Finance Managers.
A three-column layout seemed most promising, as...
Tabs gave each teammate a focused view on their work
Two columns could be used for role-independent data
There was room to add future, unknown features
I wireframed this layout, retrofitting the legacy Case View with real data to define column widths and a constrained set of font sizes.
Designing clear affordances
The new wireframe had potential but was overwhelmed by a sea of blue links. More important calls to action couldn’t stand out.
First, I rethought our editable data component. Since these always positioned labels above their data, we could combine layout and icons to indicate clickability.
Left to right: editable data in their default, hovered, and read-only states.
Then, I defined a set of buttons with a range of visual weights. This would help people to distinguish primary, secondary, and tertiary actions even in the most data-dense screens.
Buttons in default, hover, and disabled states.
An improved view for Intake Specialists
Building on our new Case View foundation, we retrofitted the old Case View into an Intake tab that felt familiar to Eric and his team of Intake Specialists.
Bringing Attorneys into Casebase
We designed an Attorney Review tab so Melanie could compare her client’s medical records with the Intake team’s initial findings, without having to leave CaseBase.
Bringing the Finance Manager into Casebase
Eleanor had worked exclusively in Sharepoint, using a kludgy Settlement modal to manage payments to clients and co-counsels.
The Settlement modal from Microsoft Sharepoint, with some data redacted for confidentiality.
We added a Settlements tab in CaseBase to replace this modal. Removing unused fields, grouping values sensibly, and putting key information at the top let Eleanor quickly scan a sea of data.
We also organized each section's form fields into modals, which...
Housed interactions for adding and deleting dynamic lists
Focused the Settlements tab on available data
Organized the remaining data with bold headings and subheadings
Staying effective as the only designer
Being our team’s only designer was at times stressful, but it taught me two valuable lessons in being productive and effective.
First, I learned how to say no with grace. Since our product-team-of-three could only design and build two features at a time, the best response to “urgent” feature requests was often, “where does this fit against our top 3 priorities?”.
Second, I learned to shorten design cycles by strategically sharing low-fidelity designs for feedback. The more complex the feature, the more we benefited from earlier feedback. Sketches helped me understand a problem, while mockups helped me refine solutions.
Documenting design decisions
I clarified my thinking by articulating assumptions and justifying decisions in writing. This gave us the confidence we could thoughtfully iterate on an imperfect solutions, especially when the “right” solution wasn’t obvious.