How Understanding Task Flows Increases Usability

My Role:  My role was primarily research and strategy.   I interviewed the client and conducted, conducted analysis, testing, and identified what features were missing to accomplish scrap metal recycling through a mobile device.  I worked with two UI designers, Mads DiNardo and Ishwin Sagguu to communicate the strategy and design decisions.  .   
Methods:   Client interviews, second hand research, user testing, scenarios, user stories, task flows, heuristic evaluation, cold calling, competitive analysis, comparative analysis, proto persona creation, wireframes, prototyping, second hand user testing

The Brief

The Covid-19 Pandemic created quite a challenge for recent college graduates trying to enter the workforce. Doubly so for those that dreamed of being social entrepreneurs. And this was the challenge ReMatter faced. 3 Stanford graduates learned that scrap metal recycling can have a powerful effect on the environment. They earned a grant from Stanford and started a business making an ERP for scrap metal recycling facilities. The pandemic shut down traditional methods of research and still they persisted determined to make a user friendly application for the facilities. So, they contacted my team about turning part of their desktop app into a mobile sub app to allow operators to do their work in the yard. But what differences need to be considered when switching to the mobile setting?

The Problem

Short Cuts Taking Twice As Long

Busy operators were short cutting writing scale tickets. Third parties were designing to optimize for short cuts, rather than efficiency and effectiveness. This was resulting in work needing to be repeated at later times to make accurate records. This meant always being busy or having erroneous inventories.

The Solution:

Optimize for Efficiency Instead of Short Cuts

Investigate what is the minimum amount of information needed to create accurate records quickly and allow for entries just using this information. Discover the different situations where a person would recycle scrape metal and build enough flexibility for these routes. Design a proof of concept to discuss optimizing mobile needs.

A Simple Task

How it began.

It seemed easy at first. Design 9 features.

1. Create a ticket for a public supplier
2. Create a ticket for a commercial
3. Select 1 or more materials
4. Enter Gross Weight
5. Enter Tare Weight
6. Send Supplier Receipt
7. Close Ticket
8. Navigate between open tickets
9. Allow user with permission to include manual price

The client gave us a task flow they had built to explain the process in a high level.

This works in the office settings when other tools are present, but on mobile, one doesn’t have they advantage of being in the office. We needed to know if we could place all the tools of the office into the phone. So we needed to conduct more research. What do each of these features actually mean? How are the features being used? How are weights being measured? And so many other questions.

It’s Not Uber Eats For Metals

After the client meeting we had thought it could make something like UberEats. Have a menu of metals and the operator could just select the metals the supplier has and build that order. We could use the cool interface of Uber eats, which has elements slide, tons of pictures, and lots of interactions. This model would fail.

UberEats	ReMatter
Used in home or open area	Used surrounded by metal
Leisurely activity	Tool to do a job
Used with clean hands	used with dirt fingers
Can be by self while using	will be around another person
Is requesting service	Is delivering service
Might not be familiar with all the options for selection	Is incredibly familiar with all the selections

The two models are different. UberEats should deliver delight in offering confidence in the selection. ReMatter should deliver delight through efficiency of use. Therefore we needed to conduct more research to understand the ReMatter’s model.

Busy Multitaskers

We needed to understand the context better. If it were not for the pandemic, we would have conducted contextual inquires. So we settled for YouTube product demonstrations from competitors. Much better than nothing. We learned a lot.

• Operators handle many suppliers simultaneously
• Tickets won’t be completed in one go
• A need for speed has led to competitors creating band-aid short cut features.

We use a software. Yes it has problems, but all software does.

Operator In Maryland

After watching the videos we were hoping we could more context so we tried cold calling operators.

“Software crashes” or “Connection is too slow” are engineering issues. It just has problems is a usability issue. The software does not match the users expectations. The mental model behind designing the software does not match the operators. And this mismatch slows down the operator.

Busy Operator

Between this context and the client meetings we had we could produce a prototype persona. This would give us a sense of the user we were designing for with many assumptions would have liked to challenge if we had the opportunity.

Lost In Sandbox Exploration

So, to help us get a greater sense of the context, the client gave us a sandbox version of the desktop app. Through getting the desktop app to work, we learned how interconnected the system is.

In this interconnected system the limitations and features of the other apps will effect what can happen in the scale ticket sub app.

“Facilities don’t use common names to refer to the materials. One uses the term honey. They aren’t recycling honey. And we need the flexibility to call the names whatever they want”

Drake Huogo COO of ReMatter

While there are only about 36 materials that are recycled, the scale ticket app must take into consideration that anything can be written into the materials sub app and that will populate choices in the scale ticket app.

With the ability to complete tickets and see the sub app in full use, we could conduct a Norman Heuristic Evaluation. My approach is to note what is working well(green) and what has room for improvement(orange).

System Doesn’t Match Reality

After we conducted the heuristic evaluation, we met again with the client. He showed us what a scale ticket looked liked.

The ticket showed many details

• Operators who were already busy needed to do the process of writing a ticket twice
• Operators noted weights through percentages
• System only accepted inputs in pounds
• Translating percentages to pounds required outside technology
• Mirroring the desktop features to mobile would not reduce the double work

Trust Through Testing Ticketing

We identified a serious gap, but we needed to get the COO’s buy-in to adding these features. I conducted two rounds of usability testing. I wanted to learn to learn two things

• Would an average person feel comfortable guesstimating the weight?
• Are there other elements app that give people pause

One Size Fits All Doesn’t Fit

When reported these results to the COO. He understood the importance and reasoning, but nonferrous doesn’t work that way.

After realizing that there needs to be multiple task flows, I created scenarios to make sure that all varieties of scenarios were addressed. I wanted to drill down on the details to make sure the application was flexible enough to handle any situation.

Scenario 1. New public supplier recycling nonferrous materials

Features Requirements

• Ability to create a new public customer
• Ability to record tare once
• Ability to record the gross weight of first metal in subsequent trips
• Ability to add a second material to the ticket
• Default public tickets to 3 day waiting period
• Ability to record tare before gross

Scenario 2 New commercial supplier

Feature Requirements

• Operator should not have a way to create commercial supplier

Scenario 3. Two suppliers at once. One commercial one public. public supplier has both ferrous and nonferrous materials

Feature Requirements

• Ability to record gross before tare
• Ability to be ticket on hold
• Ability to create multiple tickets for the same person
• Ability to easily switch between two tickets
• Ability to record approximate percentages of each type of metal
• Ability to find an existing public supplier
• Ability to record tare after gross weight for ferrous tickets
• Ability to retrieve contract information regarding supplier payment
• Ability find existing commercial supplier

Scenario 4. Recycler is the operator returning from being dispatched

Feature Requirements

• Ability to find jobs driver was dispatched to do
• Ability to process the tickets for dispatch driver in succession
• Ability to find other drivers who were dispatched

After I wrote these scenarios, I checked with Drake the COO to see any details I might have missed

“Yes! These are all realistic and captures the complexity of the industry. But the operator at a nonferrous station will have two scales for easily switching between two suppliers”

Drake Huogo

Past The Smog, We Could Design

After presenting the scenarios to the client, and verifying its accuracy I met with my partners to explain the findings. I sketched my ideas to give a visual feature list. My goal was handoff not visual suggestions.

After the handoff, my partners conducted comparative analysis to see modern ways to display the features.

Then we began to wireframe

The forms have a logic relevant to material type being recycled. This includes whether it would be realistic to recycle in tons.

But Does It Work?

Context Through Usability

Through having the client run the usability testing we learned:

• Ferrous and NonFerrous can be on the same ticket, although weighed on different scales
• Percentages would be useful in updating inventory
• Tickets should include whether there was a price override
• Operators would adjust price based on the normal price, not just make up price
• Lack of automation in forms leads to forms not being completed.
• While users can use bins for nonferrous tickets, they won’t always

Designing With Context

With a greater sense of context, we amended the task flows and the prototype

Results

Client accepted more pathways
The client planned new features in the desktop version. This includes mix loads and scrapping cars.

Proved the task flows were more complicated.
Client gained a talking point to talk with their clients about the more particular questions about the industry

Decreased time burden on operator suggested.
Client of client identified points were cashier could do more work and free time from operator.

Next Steps

In 3 weeks of working a new industry to us, we had just begun to design cutting edge usability.

With more time we would do the following

• Recruit scrappers to interview. Contextual inquires are still not available during the pandemic and operators are too busy to interview. So scrappers those who receive the scrap tickets can offer contextual information
• Create the design to handle not initially knowing tare in nonferrous materials
• Research ways of reducing information to the bare minimum of what is required.

Lesson Learned

Usability tests are a context. Contextual inquires and user testing are great tools for generative research. But, circumstances might prevent them from being options. Usability tests on fledgling concepts of how processes work can create an environment to discuss context. Missing the mark is only really bad when the product is live.

Small details have large impact The scale ticket came up in a meeting as a side note. We dove deep into what that meant and were able to flesh out ideas from it. Any visual or artifact can have great significance to another person

Make many task flows even of the same process The task flow the client gave us was good for quickly onboarding. The task flows we created are good for communicating what the system needs. They both have their needs and they both needed to be written.