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.) Approve SAR documents more quickly
- 2.) Locate SAR documents in the approval process
- 3.) Help stakeholders communicate about the status of SARs
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.
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
Approve SAR documents more quickly
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.
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.
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
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.
In my first sketches, I planned to give the location of the SAR its own module on a single page.
Help stakeholders communicate about the status of SARs
This post was written by admin