Project Request Form

Role Played

UX Designer

Problem

Currently, this application allows users to create requests for funding for their projects. Each request requires specific levels of approval based on the amount requested for projects. However, the application is older and has become harder to navigate its core functional components. Instead of continuing to enhance this version of the application, the decision has been made to leverage the resources and funding to reconfigure the application to achieve the project objectives.

Activities Performed

Research: Surveys, Interviews, Field Studies
Design: Lo-Fi Wireframes, Hi-Fi Designs, Interactive Prototype
Usability Testing

The Solution

Our main objectives were to improve the front-end user experience by increasing ease of use and redesigning the functionality into logical components and to address the back end code to improve the scalability between databases thereby improving user response time.

Please note that this is an internal facing project. To respect my non-disclosure agreement, I may not share screens or specific details.

RESEARCH

Survey

For this project, I created 2 surveys’, one for user’s who create and submit request forms and another one for user’s who approve the request forms. The first survey consisted of 19 questions and the second survey had 9 questions. We had 78 respondents for the first survey and 33 respondents for the second survey.

First Survey Results (Users who create & submit):

50% of respondents say that it takes them 30 minutes or less to create and submit their request form
23% of respondents expressed that the top reason their request form gets rejected is because they filled out the form incorrectly
31% of respondents stated that they log back into the system to find out the status of their request form

Second Survey Results (Users who approve):

56% of respondents stated that the only way they know when a request has come into their queue to approve is via e-mail
49% of respondents explained how the “overall cost” of the request form is what they look at most in order to approve the request
48% of respondents say that they normally reject a request because there is wrong information or there needs to be an update made

Based on these results, we wanted to dive deeper with our end users to uncover more findings when it came to creating/submitting and approving request forms. The project team did have an assumption that it took users a long time to create/submit a request form, but as we discovered through our initial findings that was not the case. We also discovered that many requests get rejected because of information being entered incorrectly and the creator the form must go through the whole submitting process if their request gets rejected. This process was something we wanted to understand more of.

Interviews

Since this process was complex, we scheduled interviews with 16 end users. There were a lot of follow up questions that we wanted to dive deeper based on our results from our surveys. Some of our key findings include:

A lot of prep work goes on before a user goes into the system to create the form
Many attachments are added to the form because approvers need supplement information to approve
There is a lot of input fields that certain groups do not need to see, it would be helpful to only show items that pertain to certain groups and to autofill information where possible

Field Studies

After we finished our interviews, we decided to observe 5 people creating and submitting their request form. We were able to focus on their main pain points and asking follow up questions to further uncover issues that they were facing while filling out the form.

DESIGN

Lo-Fidelity Wireframes

Off to the drawing board we went. I worked with our stakeholders to come together on how we wanted to re-design this application. We first focused on combining certain pages to make a dashboard where a user can come in and see all their pertinent information at once. We went back and forth and had a lot of different ideas, but once we settled on what we all thought was the best approach, we moved on to create those hi-fidelity designs.

Hi-Fidelity Designs & Interactive Prototype

We spent countless hours creating all the different pages within this application. Originally, the designs were created in Axure, but then we shifted and started creating our designs in Sketch, since this was the new preferred method at UPS. We ended up with our first pass of our designs based on our lo-fidelity wireframes and started to create an interactive prototype so that we could show the development team how the new pages would interact and to start setting up usability tests with our end users.

Usability Testing

We created a set of tasks for the different users that we planned to test with. We ended up testing with 7 users: 4 submitters and 3 approvers. Since our users were very familiar with the existing application, we wanted to make sure that our new re-design still met their needs while also addressing and fixing pain points. After concluding with our sessions, there were minor refinements but overall, each end user passed their tasks and commented on all the improvements we made to the application.