Digging for the problem

Living for a bit in the problem space rather than jumping to a solution can yield a superior user experience.

Katie was an exemplary team member, One of the operations team of our fintech company who came in early each morning and spent the entire day in our internal admin portal, she was responsible for evaluating the pipeline of daily client requests for funding and deciding who would get their money that day.

She had often humored me when I asked to sit and just watch her work for an hour or so occasionally, so I could find pain points in our internal workflows. She had patiently explained to me the purpose of each Post-it on her monitor, which I dutifully transcribed as pain points, adding solutions to the product backlog.

At FastPay we had a policy that anyone could approach any member of the product team with requests or suggestions, and that included UX. The product team would share these requests with each other and prioritize them, so anyone could feel comfortable approaching any of the product people.

So one morning Katie came to me with a request; “Can we add the date and time of the last document upload to the portal?”

For some time we had studiously avoided the enterprise table trap, where every view is a table and product requests involve adding ever more columns. We had carefully designed the internal admin portal to be formatted with list items that did not have columns, and we tried not to add more information on that view.

But Katie had to have a reason for her request. What was the problem that showing the date and time would solve? If I could understand the problem, I could maybe find another solution. Or maybe Katie’s solution was right.

“Tell me why you want the date and time of the last upload on the list,” I asked her.

“Because we need to know if they uploaded their documents in time.”

“So tell me when clients need to have their documents uploaded by,” I said.

“By 9 a.m.,” Katie replied.

“Okay,” I said. “So what happens if they don’t get their documents uploaded by 9 a.m.?

“They won’t get funded that day,” she said.

“What if the system checked for the time of last upload and didn’t show those who were after 9 a.m., would that solve your problem?” I was concerned that scanning a list of possibly hundreds of list items looking for those whose time began with a 9 or more was a fairly large investment of cognitive effort.

The user should never have to review a long list of data to pick out actionable items. That’s what software should do.

“No, not really,” Katie replied. “We still want to be able to see the line item, because if we have time we go back later and prepare the funding for the next day.”

“I see. So you want to know which clients to skip in the morning but maybe you can come back and get them ready later in the day for funding the next day?”

“Yes! We want to have that option, so hiding those who uploaded after 9 a.m. wouldn’t work for us.”

I thought a bit. “So tell me, Katie, what if we were to dim the items where an upload occurred after 9 a.m. That way you could quickly see to skip them in the morning but you could still process them if you had time in the afternoon. Would that work for you?”

Katie was surprised. “Absolutely. Then we wouldn’t have to check the date and time of every request!”

And that, folks, is what it means to live a bit in the problem space before jumping to a solution.

Image: Unsplash, Janusz Maniak