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.

Timeframe
February 2016 – July 2018

Role
Research
Prototyping
Presenting designs
Information architecture
Usability testing

 
Case View.jpg
 

Problem

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.

 

Research

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:

The four job roles at Orin & Schuster. Avatars courtesy of SAP’s   Scenes  Kit .

The four job roles at Orin & Schuster. Avatars courtesy of SAP’s Scenes Kit.

 

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:

 
Orin & Schuster’s lawsuit workflow.

Orin & Schuster’s lawsuit workflow.

 

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

 

Solution

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.

 
Case Page Sketches.png
 

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.

 
Intake Tab - Wireframe.png
 

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.

 
Editables - Version B1.jpg

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 - Version B.png

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.

 
Attorney Review - Annotated - Version B.png
 

 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.

 
Sharepoint Settlement Modal.png

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

 
New Settlement Modals - Version B.jpg
 

Retrospective

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.

 

 
Max impressed me as our full-stack designer. He led client relations, focused the engineering team, and consistently produced strong designs in a complex application domain.
— Ben Yee
 

Want to see more of my work?