PROBLEM

Users were using some features from our mobile app to solve a complex issue. Their workaround was not intuitive so I took the initiative to design a new bean (data entry/function) that would give them a simple solution.

OPPORTUNITY

StringBean has a client, "Caldwell & Walsh" (CW), who regularly complete routines on facilities. Within their routines, the users have to register the deficiencies they observe as well as the quantity. With our existing functionalities, the users had to select one item from a list, and then separately input the quantity. This required the users to complete a task in two different beans. If they observed more than one item from the list, they would have to repeat the flow over in a loop until they covered all of the deficiencies they encountered. This could result in an endless loop as well as a million beans being created in the database. I saw this as an opportunity point to create a new bean in which it can allow the users to determine the deficiencies they observed as well as the quantities; all-in-one bean, without looping around.

To do so, I had to make sure that my designed solution satisfied the following KPIs:

See if the users were able to navigate the functions
Get a high task-success rate
Get a low user error rate
Get high user satisfaction for the solution.

MY ROLE AND PROCESS

I began this project alongside our customer experience director. As we were analyzing CW users' behavior, we came to notice the workaround trend that they use frequently. I took on the challenge to create a tool that would eliminate their hardship and make their workflow a lot easier and better. I expanded on the concept and figured out the executional aspects of the experiences, including user flows, wireframes, prototypes, and user testings.

USERS

CW currently faces a challenge where in order to log deficiencies with StringBean, they have to go through a large amount of work to complete something small. For them, they are currently intimidated by the amount of work and data that they have to collect so with this experience change, we can make the users feel more confident and have all of their data organized and in one place.

THE USER FLOW

To start off my design, I fleshed out what their current workaround user flow was.

After analyzing, I realized that there was a simple solution to eliminate their possible endless loop; a new bean, that would serve as a clicker and possibly a checklist. I designed a new user flow on how the new tool could give the users a better experience.

THE DESIGN

As I created the user flow and wireframes, it became clear that the interactions were going to be an essential aspect of conveying the direction. I started off with some sketches on how I thought the clicker would act to convey a general feeling of the experience. Once I got green-lighted, I pushed on the designs to a medium-fidelity prototype.

Rapid Sketches

Medium Fidelity

Solution A

Solution A.5

Solution B

Solution C

EARLY USABILITY TESTINGS

I ran some usability testings to see how the users would react to the tools. All of the users interacted with 4 prototypes and I had them determine how they would rank them based on its usability. At the same time, I also analyzed their behaviors to see how successfully they would be able to pull off each task. Here's what I gathered.

GRASPING THE SOLUTION

We were able to eliminate one of the prototypes (Solution A.5). From there, I started transitioning the wireframes into designed screens. This was a rewarding part of the process because I was able to streamline the process of how the bean would function as the experience took shape.

Solution A

Solution B

Solution C

LAST ROUND OF TESTINGS

Once the high fidelity prototypes were all created, I ran another round of testings and came to find similar KPI readings except this time, solution C didn't make the cut. Users did not feel comfortable with solution C because they believed the behavior was stretching out of the norms and there was no way for the users to manually input the quantity. Overall, the users preferred solutions A and B since the flow was a lot more traditional and within their normal behaviors.

Solution A

Solution B

REFLECTING AFTERWARDS

Due to time and scope limitations, I was unable to conduct one final round of testings between solution A and solution B. All of the users gave pretty similar responses to both prototypes but it would appear as though A had the higher satisfaction among the users. Ultimately, this design is in the pipelines for production and I would love to observe more of the users interacting with the live version to further tighten the flow.