Finished version of the Vision Scheduling form.

Modernizing Legal Tech

An enterprise application to convert client’s email requests into scheduled jobs.


Quick Summary


About Veritext

Veritext is the top national agency for legal services. Veritext connects law firms with providers to fulfill services for legal proceedings. The company has developed a suite of applications to meet their customers' demands.

The Problem

Veritext wanted a more efficient method of data entry because the current methods have a long turnaround time in scheduling services and is prone to duplicate data entry.

My Role

My primary role was to be the UX Designer but I also provided agile and product management coaching.

Solution

I worked with the product management, engineering, and QA teams to align on these priorities for the solution to be considered successful:

  • Form validation
  • Logical grouping of relational data
  • Visibility into data entry requirements or restrictions

Prototype

Click here to view the prototype in Figma.

The Full Story


More On the Problem

An undocumented business process was at the center of the problem. Schedulers did not know the “right” way to enter data and often found workarounds, which led to duplicate data and a lengthy manual data entry process.

My main takeaways after reviewing the research artifacts were the following:

  • Schedulers had to arduously sift through existng information before they could even enter their data.
  • Schedulers couldn’t determine the information they were entering was duplicate or invalid data.

My Onboarding

I joined the team a few months after the project’s initiation. When I joined, the initial user research and design concepts were already done.

To familiarize myself with the legacy application, I performed a UX audit and reviewed the previous user research. Doing so helped me conclude that these problems needed to be solved: consistent visual indication of required fields and form validation.

Various patterns to indicate required fields in the legacy application.
Required fields do not follow a consistent pattern: some text is red, some text is red and flashing.
Various patterns to indicate required fields in the legacy application.
Form errors are not indicated to the user through any validation method.

Identifying the Users

Collaboration sessions with the Product Owner (PO) confirmed that these problems were longstanding pain points for the Schedulers. At this point, the PO confirmed 2 archetypes of the Scheduler role:

  • The newly onboarded Scheduler
  • The seasoned veteran Scheduler

The next gen application needed to be intuitive for both new employees and those with a tenure. The content grouping on the new job creation form should be easy to navigate, as Schedulers are often inputting information while on the phone with a client.

Challenges

In the early stages, requirements were not defined and the roles were not established. A distributed team of third parties were involved with this application. There was often misalignment on the information architecture, business process, and how the application generally functioned. Designs underwent multiple feedback loops and there was a lot of requirements churn. I helped the team overcome these challenges by:

  • Collaborating closely with the PO to document requirements through user stories.
  • Regularly modeling out my understanding of the information architecture and presented it to validate with the PO and engineering team.
  • Converting the ambiguous requirements into user flows to capture anticipated use cases.
  • Creating mid-fidelity designs to confirm alignment and gain buy-in.
Data model used to validate the relationship of client and job information.
Data model used to validate the relationship of client and job information.
An instance of a user flow. This one is specific to the complex case information and its data entry.
An instance of a user flow. This one is specific to the complex case information and its data entry.
An instance of wireframes. This one is specific to the complex case information and its data entry.
Wireframes to validate the various use cases for case information entry.

"Final" Designs

Considering this is an ongoing project, below are the designs that were delivered for the first release.

Required Fields

The initial form design used a black asterisk to indicate required fields. The PO had concerns that this would be too subtle. I proposed the use of red asterisk to make required fields more apparent. This decision became a standardized pattern in Vision’s design system (to be detailed in another case study).

The initial iteration used black asterisks.
The initial iteration used black asterisks to mark required fields.
With the provided feedback, we iterated on the designs by using red asterisks.
With the provided feedback, we iterated on the designs by using red asterisks.

Form Validation

Various workshops with stakeholders resulted in the prioritization of consistent messaging and an expectation to deliver content guidelines as a part of the design system. Form validation patterns was the starting point for the content guidelines. The form validation was designed with Nielsen Norman’s guidelines on reporting errors in mind.

  • Inline validations
  • A green checkmark and red error icons to communicate validation status
  • Actionable error messages delivered via the respective field’s helper text

Error and success messaging in this form design was the foundation of the content guidelines that were delivered.

The initial iteration used black asterisks.
The initial iteration used black asterisks to mark required fields.

Next Steps

The roadmap’s next priorities is an in-context document validator. Currently users have to navigate to an external application. However, I handed off this work stream to another designer. With an established roadmap and agile methodologies implemented in the team, I moved on to support the ramp up of a client-facing work stream.

Reflection

I got to work with a well-rounded team that helped me grow exponentially. This was the first project that I worked closely with the QA team and supported them by writing test cases. Strange as it sounds, this paired well with my design process because of the focus on interaction design. I was able to naturally create an “interaction guide” that the QA team was able to use for their test cases.

There were a lot of database considerations in this project because of the complex architecture, which gave me the opportunity to work more closely with the back-end development team. To drive engagement across the team, I often created entity diagrams to present for feedback and validation.

I’ve always been able to collaborate closely with the product management and front-end development teams in previous projects. My storytelling skills greatly benefitted from my new experiences with the QA and back-end teams, as I quickly learned various ways to set the context and drive team alignment.