Settlement Authorization Release System

March 22, 2018 3:45 am Published by Comments Off on Settlement Authorization Release System
In September 2015, I started my new job at the University of California, Office of the President. My second day on the job, I jumped into the deep end on a project redesigning a web application called SARS. I had to learn both about this new project and also about how to navigate the stakeholders in this new organization. SARS helps people across the statewide UC system process liability claims efficiently.

My Role

I am the only designer involved in this project. I am responsible for all user research, interaction design, and visual design in this project. I work with a team of developers, business analysts, and QA testers on this project.

Understanding the Problem

The first thing I did in taking on this project was meet with stakeholders to understand the business needs of our clients and get them thinking about what success for this project looks like. I had meetings with the clients to understand SARS’s user population and the tasks they rely on SARS to complete. These meetings helped me craft the research plan I would use to uncover the issues users were having with the application.

What is SARS?

SARS is a web application that processes UC settlement releases by allowing stakeholders to authorize them and making the authorization process more transparent.

SARS = Settlement Authorization Release System

When someone has a legal dispute with the UC (e.g. they are injured on a UC campus), the university can come to a settlement agreement with them. The amount of money in the settlement must be approved by the proper channels within the university before it can be released to the plaintiff. SARS facilitates the approval process between campuses all across California and the Office of the President in Oakland, CA.

SAR documents must be authorized by several stakeholders both at the location of the dispute and the UC Office of the President in Oakland, CA. Authorizing stakeholders can range from risk managers to UC lawyers, to chancellors of the campuses.

SARS makes the approval process visible to the list of stakeholders who must authorize it grows and changes. It helps people understand who else needs to authorize a SAR so it can be approved.

I redesigned SARS to help employees across the entire UC system:

  1. 1.) Approve SAR documents more quickly
  2. 2.) Locate SAR documents in the approval process
  3. 3.) Help stakeholders communicate about the status of SARs

Research Process

Because I needed more information on the types of problems users were having with the current version of the application, I interviewed 7 SARS users and was able to complete contextual inquiries with the majority of them. From my interview notes, I created several work models and an affinity diagram.

img_2066

Insights and Opportunities

Building the affinity diagram helped me to uncover several research insights:

  • Many SARS users use it infrequently; they create more process to deal with the cognitive load of remembering and relearning the system
  • Users rely on quickly checking SAR information personally to feel confident about authorizing it
  • There are rules based on a SAR’s information that govern the list of people that need to authorize it
  • SARS can be confusing to people when it doesn’t match how they think about their work
  • Within a location, users often revert back to using a paper-based process
  • There is an information hierarchy in users’ minds that SARS does not reflect visually
  • Current SAR location and status is the most sought after information, but it is not always easy to find in the UI

img_1497 A sample from the research findings report I delivered to the customers.

Design Process

Approve SAR documents more quickly

sign_1

Originally, SARS had 2 different ways for users to sign the documents: acknowledging and authorizing. It also required 2 steps for the user to sign, or authorize, the SAR.

sign_2

In this iteration, I designed the signing action to be on the same page as the rest of the information about the SAR. I also made the signing action (“reviewing” it in this iteration) into a button to draw more attention to it. Finally, I included an informative note in this module to help users, especially those who use SARS infrequently, understand what happens when they sign it.

sign_3

In the current iteration of this feature, we have simplified the concept of acknowledging or authorizing to only signing the SAR. Ultimately, the users did not need to worry about what kind of signer they are. I also combined this module with another module that had a list of people who need to sign the SAR at that location so the process is more transparent.

Deep Dive: Locate SAR documents in the approval process

loc_1

Originally, the user had to work pretty hard to understand the SAR’s current location and who has signed it. The information is one of the most important things users look for, yet it was spread across multiple pages and was not visually distinguished.

loc_2

In my first sketches, I planned to give the location of the SAR its own module on a single page.

loc_3

loc_4

loc_5

Help stakeholders communicate about the status of SARs

comm_1

comm_2comm_3

Takeaways

Categorised in:

This post was written by admin

Leave a Reply

Your email address will not be published. Required fields are marked *