How ‘Critical User Journeys’ can help a product take off
medium.com
medium.com
Yes, yes, 1,000x when it comes to the importance of simplicity. It's far too easy to unknowingly distract yourself and your users from what is important in your product.
My criticism is that this pays very little attention to how important it is to get to know who the people are you are attracting at the top of your funnel. It's tempting to reduce your acquisition funnel down to the level of "here's how many people we dumped in the top, and here is the % rate at which they activated." The truth is a lot more complicated. Too many people overlook this and optimize for what is working, which puts you at risk of unknowingly niching down into a small portion of your addressable market.
This is the point of methodologies and techniques like Customer Development, Ideal Customer Profiles, and good ol’ fashioned business modeling.
That's something I wonder about with Show HN. Aren't many of us on HN inherently the 'wrong' customer for any product or service that aspires to be mainstream?
Famously, for example, 10 years back, some of the comments when @dhouston submitted "My YC app: Dropbox - Throw away your USB drive" [1] pretty strongly indicated 'wrong' customer.
I won't pull out the comments, because: 1. I don't want to make it personal & 2. It's with the benefit of hindsight.
1) They are ok with using worse/harder solutions because they know how to use them.
2) They don't like to pay for things.
3) They are much more technically adept than the general population.
4) There aren't that many of them compared to the general population.
5) They skew towards 20-35 years old, white/asian men with good income.
For example, this startup: https://unlockd.com/ pays you (via phone bill discounts) to watch ads on your phone after you unlock it. It had raised $17m as of May. I first thought it was the dumbest idea ever, but then I realized that this was because I would never use it. In fact, I couldn't even see my friends using it. That doesn't mean others might not.
Power users of a product who get deep recurring value from your product are get to analyze. they may be mostly earlier adopters at first but hopefully will grow to be your core customer.
When thinking about your products critical user journey you need to think about ideal cases: who is the User, what is their Goal and in what Context they are using your product. Lots of work goes into understanding each of these to hone in on specifics for each product and definitely much more detail than this first article.
I can also recommend the HBR article mentioned above.
More on the research methodology here: https://medium.com/envato/a-step-by-step-guide-to-using-outc.... I realize this seems a bit OT from the original comment, but Jobs to be Done and ODI are the same authors and they are intimately tied together philosophically
I get the sentiment, but specialization exists for a reason, and this sort of thinking could work just as well for a retail experience as it can for a software product.
Some of the best ‘UX’ solutions I’ve ever heard in meetings came from the software architect, usually along the lines of “Ohhhh, THAT is what the customer is trying to do? We can repurpose the flux modules pretty easily and ship that in a week or two!”.
Without good software architects on the UX team, designers will often punt on some of their more creative ideas because they assume it won’t be possible. A great architect tends to battle boredom, so the push/pull with designers can often keep them engaged and challenged. Win-win!
this article was meant to be an introduction to show how any product, startup, or company can use User Journeys as a framework for product development (not just product design) and how if executed in a systematic way can unblock growth.
The people who design and build it understand the entire picture and can see the value (hopefully).
It can be very hard from the position of totally understanding a system, to put yourself in the shoes of someone encountering it for the first time, and it can be hard to see what they see when they first use it, and it can be hard to empathise with their journey through learning the software application that you have built.
This is an incredibly valuable article because it helps people who have built systems to put themselves in the shoes of their users - that is not an intuitive skill.
you summed it up quite well. it is very easy to lose sight of what your users go through for the first time every day when you are the one adding to the system to extend or expand it.
As an example, we are somewhat known as an “online therapy” company, while we do offer that capability, that’s just a tiny part of the value we provide customers (behavioral health private practice professionals.)
And as a previous commenter said, you have to be careful listening to feedback that might inadvertently “over-niche” your product thus losing out on a larger market. As a result we’ve been careful to onboard users in such a way that “online therapy” isn’t the headliner feature being presented while still being responsive to those that find us because of online therapy-related organic traffic.
Marketing and “framing the solution in a meaningful way” is the toughest challenge there is. For us, the tech is the easy part, it’s the damned psychology of the users that keep me up at night – which is funny to me because our customers are psychologists/therapists/behavioral health pros.
We haven't solved this problem, but our current thinking is focused towards splitting up the application into separate offerings solving one thing at a time - ultimately a worse solution for the customer, but one with a lower cognitive load.
A few years ago, Google leadership initiated a "Product Excellence" initiative, the cornerstone of which was identifying and measuring CUJs, with the specific goal of improving UI/UX execution. This was because the UX of a lot of Google products was, well, not great. Implementation quality was low, in many cases because engineers were building what they wanted and not what was specified or designed. After all, it's an engineering company and this is ingrained in the culture. CUJs were a tool to rally people around building the right things at a high (enough) quality.
I'm not sure why they created new terminology. Either way, it was mostly effective. I wouldn't call most Google UIs "excellent" but they are at least passing usability benchmarks now.
An added side effect is that this methodology, like design sprints, created a new thing for evangelists to evangelize at Google and beyond. Hence the article.
Source: Grouchy Googler.
Zarget’s Session Replay is one such feature that captures and plays the user path without any flaw in the user usage patterns. Importantly, having the hold of real-time user interaction data will help us conceive when and why the losses are happening. And with such strong insights it gets easier to fix any conversion funnel (regardless the type business you’re in).
Perhaps, employing a session replay tool to map out the critical customer journeys is the only possible step we could take to fix this issue.
Whether we dogfooded? Yes, we ran recordings within our product. It busted many myths on users’ behavior and needs, as we were able to track our own journey as a customer. And we were able to make changes to customer’s onboarding process and do tweaks based on the findings. Now our product managers know how users interact inside our app and don’t make any guesswork on how users will adopt a feature. Also, our product folks can’t live without Session Replay anymore.
I'm just wondering how any technology like this would work in a PCI compliant environment.