To me, it's sad that this isn't just called "software design". If you aren't building software to solve your users' problems, why are you building anything at all?
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.
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.
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.
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.
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.