As anyone who follows me on twitter likely knows, I spend a nontrivial amount of time making food. The past two weeks, I’ve been complaining off and on about not having a kitchen because there had been some renovations going on. Thankfully, as of a few hours ago, the most fundamental kitchen functions have been restored and life is returning to normal, once I move all my equipment and supplies back.
But during the long ordeal of having to cook and eat meals for the family in a spare bedroom and washing everything in the bathtub, I’ve started pondering on the nature of Critical User Journeys.
A brief explainer on user journeys
User journeys is a term that is most often used within product development circles, especially within the UX disciplines. Very often from a qualitative research standpoint, they’re the result of journey mapping exercises. From a quantitative research standpoint, which readers here are probably more familiar with, they’re more often expressions of patterns in user behavior.
The rough concept is that a user who is using your product is going on some kind of journey from beginning to end of their experience. It encompasses context like why would a user use the product, what’s their end goal, the steps taken to actually complete their job, and the end state the user leaves in.
For example, if I open my email to send a message to someone, my journey would involve me thinking of who I want to message, opening my email client/service, bring up the message composer, inputting the recipient, subject, body of the message, and finally hit send. Fairly simple stuff.
But imagine if the email app’s design was broken and I had to click 20 times to start composing, or there was no address book feature and I couldn’t recall my friend’s email address, or I can’t load the client because of internet connection issues. Having the ideal journey in mind also points to places where flaws can disrupt the user experience.
Also notice that there are lots of “squishy” qualitative details in there, there’s mention of needs and intention, there’s overarching goals that might not be part of your product (what if I chose to use SMS instead of email to send a message, why did I pick one over the other?). Note that much of this stuff is “in the user’s head” and normally can’t be measured with our quantitative methods.
While it’s often practical to break everything down into concrete objective steps in a flow within a product, it’s usually insufficient for building out a well-running system. Context is important.
Data folk and user journeys
With all the qualitative mental details often involved in documenting a user journey, you’d think this would be primarily the work of a qualitative researcher of some sort. But I’m sure that many of us data folk will find this line of questioning extremely familiar.
I think the vast number of us have been asked a variation of “we have all this user data, can you go find patterns in what users are doing?” A epic fishing quest that often results in months of struggle with disorganized log data trying to find useful linear patterns of user behavior, where users often behave non-linearly.
It’s a giant mess, so I won’t be getting into the details of the data aspect today. I hoghly doubt I’ve found a solution to this class of problems myself, so it’s worthy of it’s own post or two in the future.
So, what’s a critical user journey?
There are tons of possible user journeys for any product, even if you group most of the similar ones together, people often have multiple reasons to use your widget. Moreover, there’s a lot of leeway for defining the right altitude to define things.
But however you decide what constitutes a user journey, we can layer a critical flag we on top of user journeys to say that they’re extremely important to the success of your product.
Usually they’re journeys that are very fundamental — if you mess them up, most users will be unable to use your product and they’re going to leave and take their time and money elsewhere. Most people tend to agree that the most obvious CUJs are the ones that involve purchase, payment, or otherwise tied to the reason your product exists in the marketplace.
But once you wander away from the most core functionality and wander into more niche use cases, the notion of “Critical” can get hazy, really quickly. Now you’re looking at features used by maybe 10-20% of the userbase, but for those specific users, it’s a critical feature. Do you classify it as “critical”, or not?
So what’re the CUJs of a kitchen?
Taking things back to my kitchen experience this week. Ask yourself what are the most important user journeys for a kitchen?
Prior to the project, I had these priorities in mind:
I use it to make food for the family
I use it to store food for future use
I use it to store all my cooking and eating equipment, dishes, utensils, pots, etc.
I use it to wash stuff and clean up after
Since I wouldn’t have a kitchen for at least a week, I looked at these critical functions, and put together a plan. Ordering out for a week was unthinkable.
Bought a portable induction cooktop (surprisingly cheap and useful!) and set up a mini kitchen in the spare bedroom - thus I can make food, albeit slowly and awkwardly
Plug in the spare fridge in the basement left by the previous homeowners - so we don’t lose access to our fresh food stores. Without that we’d have to use a cooler and daily market trips.
Pack and move all my gear, and dried pantry foods, into bins and store them around the house - it sucks to dig through boxes, but it’s only for a week
There’s no good solution for cleaning, but there’s bathroom sinks, some basins, and even the bathtub for anything that won’t fit…
I figured I could bear with the pain of doing all this for the 3-4 days of work the project was planned for… Little did I know that thanks to a ~2-foot blizzard that hit NYC, plus other scheduling delays, it wound up being close to two weeks.
Things start getting awkward
The mini kitchen idea worked better than expected. Cooking was rather slow and you obviously can’t do things that vaporizes a ton of hot oil into the air, but it works. Making breakfast in a rush involved a ton of dashing around looking for ingredients in stacks of bins, but we managed.
Also, I learned that kitchen counters are higher than tables because it’s an absolute pain to stand and cut produce on a table bent over slightly. Using a sharp knife of any size while sitting down also felt all sorts of awkward. So I ultimately spent a lot of time counting the days until I could get a counter height space back.
But the thing that wound up breaking my soul was the lack of a sink. I had completely forgot how central cleaning was to how I use a kitchen. I clean constantly while I’m cooking, to the point of where I used to operate the sink to wash my hand while simultaneously stirring a dish in a pan.
Without the sink, I had to cart loads of dirtied dishes around the house into the bathtub. Then my knees and back definitely did not like the process of doing dishes at floor level. Plus, it’s really awkward to use strainers and such to make sure I’m not sending a chicken bone or something down my drain to clog everything up.
After a week of that, I was looking for any way I could cheaply put in a sink in the demolished kitchen area.
Back to CUJs
So what had happened was that in the act of destroying my entire kitchen, I wound up bringing to the front a fact that flew under my radar, the task of “cleaning stuff” is so secretly prominent in all my work that I should’ve come up with ways to deal with it. Given a couple of days time, I could’ve rigged up a basin on a stand with drain drilled in that I could use as a temporary mini-sink or something.
It also highlights something I didn’t really grok about user journeys. How extremely difficult it is to pin down what failure points are. I managed to predict a number of them, but it was far from ideal. The problems only became obvious once I had been left with no choice and was forced to adapt.
There’s user pain that is “undetectable”
If my kitchen situation had been a tech product, it presents a very interesting situation. It’s not immediately obvious that it would be noticed by any reporting system. The user flow had drastically changed, but the ultimate task of “make food, wash up after” was completed, so all success metrics along those black box lines would be fine.
It would be obvious that a new workflow had been put in place, a set of tasks that normally all happened quickly in the same location were now scattered across multiple points in the home while taking significantly more time. But since telemetry data can’t infer intent, it’s not clear why I suddenly started spending extra time in the bathroom, or running around the house a lot more. If anything, I would’ve looked like a very confused user that was puttering around the house oddly when it should’ve been dinnertime.
So in the end, while there’s a ton of interesting insight that can be pulled from a very careful telemetry-based study, it’s a very incomplete picture. The only way to really know what’s going on is to do some hard work and talk to people, or observe them.
Goods Micro-Update
I’ve gotten my hands on a pretty logo! And in my usual “run with the idea before it gets cold” pattern, an order of 3-inch stickers are on order. I still have to figure out a TON of things like getting shipping supplies to mail out stickers, setting up a storefront, etc.. Also a bunch of foolishness about sales tax collection regulations =\, details details details.
But whatever. Counting is hard!
Expect fun details in the near future while I figure out the best ways to set things up.
About this newsletter
I’m Randy Au, currently a quantitative UX researcher, former data analyst, and general-purpose data and tech nerd. The Counting Stuff newsletter is a weekly data/tech blog about the less-than-sexy aspects about data science, UX research and tech. With occasional excursions into other fun topics.
Comments and questions are always welcome, they often give me inspiration for new posts. Tweet me. Always feel free to share these free newsletter posts with others.
All photos/drawings used are taken/created by Randy unless otherwise noted.