Everlaw Database Fields

Improving administrative workflows for large organizations by offering ways to customize data tracking and display

My role

Product Designer

Team

  • 1 Product Manager
  • 1 Product Designer (me)
  • 1 Developer

Completed

2023

Background

Everlaw is a software that supports different workflows throughout the life-cycle of a legal case.

Legal cases are represented as databases, which live under one organization in Everlaw.

Summary

Problem

There was no way for organization admins to track custom details about their databases, which was a pain point in workflows and security practices.

Process

  • Stakeholder interviews and feedback sessions
  • Benchmarking
  • Concept exploration via wireframes
  • User testing

Solution

  • New feature allows users to create custom fields for database details.
  • Users can “pin” fields to display important info at a high level.

Outcomes

We met a large client’s contract “must- have” while uncovering and addressing reporting needs for our broader user base.

Qualitative data captured through user testing. Unfortunately, I do not have access to quantitative metrics.

Keep reading for the details

Problem

There was no way for organization admins to enter custom details about the databases in their organization.

Why was this a problem?

Admins were tracking details in spreadsheets, which added another step to their workflows.

Admins wanted to track these details in Everlaw to minimize the need for outside tools, and make the details readily available within the platform.

Admins needed to indicate if a database was sensitive.

When users interact with a database in Everlaw, they may not know that the database contains sensitive materials. Allowing admins to enter this detail could help minimize security risks.
This was a deal-breaker for a large client.

How might we...

Allow org admins to track custom details about their databases?
Allow org admins to call attention to important details (e.g. sensitive database)?

Process

Understanding the feature request and learning more about use cases

Initial feature request: Database labels

This project started as a request for functionality to add “labels” to databases. The rationale was that labels could be used in a variety of ways, such as labeling that a database is sensitive, or capturing other details like the project type.

Gathering open questions, assumptions, and potential dependencies to drive discovery

I typically gather my thoughts via some form of digital whiteboard through any combination of diagrams, sticky notes, and images.

Interviewing stakeholders to learn more about use cases

  • We learned that users wanted to track different types of details, including different categories (project type, practice area), unique ID #s (such as a billing ID), and dates (such as deadlines).
  • We concluded that a simple labeling system was not sufficient. We pivoted to exploring custom fields, which is a common functionality in other admin workflow software.

Benchmarking other products to drive exploration

While robust fields best served our broader user base, we still needed a way for users to call attention to pertinent details (such as a database being sensitive). We looked at other products for inspiration related to this theme.

Wireframing ideas to obtain stakeholder feedback

We came up with 2 directions and reviewed the concepts with stakeholders, discussing the pros and cons of each.

Using Whimsical allowed me to create quick wireframes to communicate the overall concepts before spending time on nuanced design decisions.

Outcome: pursue concept 2

Users can create custom fields of different types (text, numeric, multiple choice, etc). Users can "pin" fields to make important information appear near database names.

  • ✅ Offered flexibility to users
  • ✅ Simplified functionality (no “labels” vs “fields”)
  • ✅ Approved by client with contract requirement

Prototyping our design and conducting user testing

Using our design system, I created a high fidelity prototype in Figma to user test the various flows.

Research goals

  • Gain a deeper understanding of reporting use cases
  • Assess user understanding and perceived value of pinned fields
  • Usability test parts of the experience

Method

  • Individual sessions with 7 different org admin users (conducted by me)
  • Part usability test, part feedback and discussion

Process improvement: user recruitment

  • Our team historically had trouble findings users to participate in research.
  • In partnership with cross-functional team members, I helped create a new process for recruiting participants through the Everlaw user community.
The post I created in the user community to find participants

Synthesizing key insights to inform design

1/3

Insight

After populating database fields, users expected to see all of the details available in one view on the “projects” page.

Outcome

Creating a new view on this page was out of scope for the feature, so we documented the feedback to address with future initiatives. In the meantime, we provided an export of the data.

2/3

Insight

A primary reason that users want to track database details is to better understand data usage reports. Our current report page showed an individual breakdown by databases, but users needed a higher level view.

Outcome

We added an option to change the table view so that admins could see higher-level, aggregate usage data based on the fields they had created for their organization.

3/3

Insight

Admins created work-arounds of including details in the database name. While this resulted in really long names, some of these details were helpful when browsing long lists of databases.

Outcome

Users were excited that pinned fields functionality would allow them to track all of these details separately for reporting, while picking and choosing which details maintain high visibility.

Final design solution

Field creation

As an org admin, I need a way to create custom fields so that I can track database information that is helpful and relevant to my organization.

Field population

As an org admin, I need a way to populate database fields so that I can track important information that helps me identify and report on databases.

Populating fields when creating a database
Bulk populating / updating fields through CSV import

Pinning fields

As an org admin, I need a way to promote important fields, so that the data is visible at a higher level.

Leveraging field data for reporting

As an org admin, I need to know how much data is being used across various categories so that I can perform budget reports.

Note: The amount of data stored on Everlaw is directly related to an org's monthly bill (Everlaw charges a monthly rate per GB).

Outcomes

Project impact

  • Large client who listed this feature as a “must have” was pleased when we presented the solution to them.
  • We uncovered and addressed a reporting pain point around billing, and prioritized additional features to address more reporting needs.
  • We created a new process for sourcing research participants.

Personal reflections

  • This project was good practice in balancing scope with user needs and stakeholder feedback. If I could redo the project, I would advocate for a review of the scope changes (before diving into design) to get ahead of misalignments.
  • If I could redo this project, I would want to learn more specifics around why users were tracking database details earlier in the process. It might have changed the way I approached the project and the options I explored.
allielozdesign@gmail.com
© Allie Lozinak 2023