How I increased user value by rethinking the jobs that needed to be done

Katie Locke
Aug 28, 2017 · 5 min read

Recently, I decided try an experiment. I wanted to realign my thinking about what value is for a user. I wanted to embody their tasks and understand exactly, what their goals are. I wanted to rethink what exact steps they were taking when interacting with our product.

My goal was to stop defaulting to data as the only answer source for when it came to feature definition. I wanted for the team to stop retrospectively build features as a band-aid to enhance the UX and start to proactively know our user’s goals better. My hope was to know what our users wanted before they did.

I start this by framing my thinking with with 2 key questions in the design process:

- “What is the problem the user actually faces here?”
- “Does this focus on what the job is that needs to get done?”

Start by questioning what you know

First, I decided to apply this logic to a side project that I was working on at the time. This was an online calculator for building developers, policy makers and housing advocates. It’s purpose is so these users can calculate affordable housing in a particular area. They would use the calculations as artifactual evidence that could help build a case.

After we had implemented a complete redesign of the interface, our users seemed happy. We weren’t actually receiving any negative feedback. Our data was telling a positive story, the users were s accomplishing the tasks we wanted them too. Sure, we found it odd that no one was complaining but as one team member said: “no news is good news — right?”. Users were using the calculator so what was the problem?

It didn’t sound like there were any problems. But does that mean that your product is still creating value to the user? Does that mean that you shouldn’t question if it could be doing more to enhance value? On a whim, I initiated another round of unmoderated user testing. This was to see how people interact with the calculator. I didn’t know what I was trying to prove — that didn’t matter. I wanted to sense check that we knew what our user’s were trying to achieve.

What resulted from the observations was surprising. We observed an consistent, deviated task that our users were doing, that we had not noticed before. We started to understand a different goals and tasks of what our users were trying to achieve. We now had an opportunity to focus on a solution to a problem.

Define the real problem

There were two key discoveries. The first being that we weren’t making it easy for users to request feedback from their community. The other being users would loose track of their thoughts and next tasks. Users needed to be able to sync thoughts to a task management portal for later keepsake.

These uncovered discoveries surfaced when we were observing how users were annotating. They were switching between two screens to communicate and externalise their thoughts. This was putting immense pressure on their working memory. One user actually said “phew” at the end of looking at the interface. A sigh of relief that now their brain could take a break.

Focus on the real job that needs to get done

The user needed relief from trying to share and remember. They needed to have the ability to externalise without having to open a new tab. We knew that It was important that they could do this within the calculator experience.

Once we knew what our problem was, solving it was easier. We were now focused, we understood their current tasks and we knew how to pave a better path.

The new path. Allowing user to permit large amounts of information into small, personalised note. Within the same screen. As known as — in-app annotation.

Annotationing within an product experience is awesome. It decreases cognitive load by shifting the burden away. It allows user to externalise, instead of having to recall previous thoughts. We took inspiration from other annotative document sharing systems like Google docs. Google docs uses annotation tracking to occur collaboratively. Something, that we discovered, would be beneficial for our product.

Change what success looks like

The line had been drawn and we changed what success looked like. Users should no longer require many screens to decipher previous ideas. This would empowered returning users in a few key ways. It allowed them to read and respond to previous comments from their community. It also allowed them to assign tasks to others as well as take their own personal notes. The extra layer of value, was syncing up these notes to their Google account.

Conclusion

We questioned what we knew and discovered that a focused problem solve a focused outcome. As known as — the real job that needed to get done. We we’re trying to prove a point or seek justification to reinforce a perspective. The aim to was uncover what people really wanted. Sometimes, it’s healthy to step back and rethink what you think you know.

Eventually, the knowledge about your users expires. This is the evolution of building products. Data is going to tell you stories of the past. It can’t always predict what tasks, goals and what optimal interaction for the future are.

You don’t need to be a rocket scientist to understand what value isn’t. Value is not about building features that aren’t solving real problems. Want profitable, predictable innovation? Want to increase value for your users? Start by questioning what you think you know about your users struggles.

)
Katie Locke

Written by

Product designer at Pushpay. https://www.uxkatie.com/

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade