4 ms·

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 a

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?

mhluongo 9y ago
Usually this sort of work falls under U/X or "product design"- software design often means architecture. 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.
- kitotik 9y ago
  Agreed on specialization being valuable, but the issue that arises is when this type of UX/Product process isn’t in place the specialists tend to spin out of control and lose sight of the users. And likewise, the UX team really, really needs those architects on their team to both help ship the experiments/improvements and make sure they aren’t proposing features that aren’t technically feasible with a given budget/timeline/tech stack. 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!
  - briandear 9y ago
    So much this! Too often UX and SWE are black boxes to each other and thus there is a loss of, pardon the buzzword, “synergy” that could be driving progress towards making customers love your product.
- austinchang 9y ago
  completely agree. most "Critical User Journey" articles are written by UX or product designers. 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.
  - mhluongo 9y ago
    Glad to see you in the comments Austin. Would love to hear your thoughts on cranking up growth on a project of ours!
    - austinchang 9y ago
      sure. happy to chat. ping me at austin [@] initialized [.] com
vinceguidry 9y ago
Sure, but the management of software design needs some serious work. We know how to manage the actual engineering process, but the design work still feels like black magic half of the time.
- luckydata 9y ago
  I feel the same way, but the other way around: design is MUCH more predictable than the engineering side in my experience.
andrewstuart 9y ago
Because often a software application is many things, with alot of features and power. 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.
- austinchang 9y ago
  thanks andrew. glad that you thought it was valuable. 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.
- briandear 9y ago
  Another problem that we faced at my little startup is the public perception of our product is different that what the product really can do. 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.
  - danieltillett 9y ago
    We face the same problem in an even more niche market. It seems to be very hard for customers to understand that a product can have more than one use and that the first use they think of is not the only use. 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.
AndrewKemendo 9y ago
If you use the mantra that you are the user, and you build something for yourself with a small following, then you might miss a much larger market if you don't look for or seek out these hidden "journeys."
anon_googz 9y ago
It is just rebranded UX Design, and a pretty oversimplified version of it. 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.

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?

mhluongo 9y ago

Usually this sort of work falls under U/X or "product design"- software design often means architecture. 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.

kitotik 9y ago
Agreed on specialization being valuable, but the issue that arises is when this type of UX/Product process isn’t in place the specialists tend to spin out of control and lose sight of the users. And likewise, the UX team really, really needs those architects on their team to both help ship the experiments/improvements and make sure they aren’t proposing features that aren’t technically feasible with a given budget/timeline/tech stack. 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!
- briandear 9y ago
  So much this! Too often UX and SWE are black boxes to each other and thus there is a loss of, pardon the buzzword, “synergy” that could be driving progress towards making customers love your product.
austinchang 9y ago
completely agree. most "Critical User Journey" articles are written by UX or product designers. 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.
- mhluongo 9y ago
  Glad to see you in the comments Austin. Would love to hear your thoughts on cranking up growth on a project of ours!
  - austinchang 9y ago
    sure. happy to chat. ping me at austin [@] initialized [.] com

vinceguidry 9y ago

Sure, but the management of software design needs some serious work. We know how to manage the actual engineering process, but the design work still feels like black magic half of the time.

luckydata 9y ago
I feel the same way, but the other way around: design is MUCH more predictable than the engineering side in my experience.

andrewstuart 9y ago

Because often a software application is many things, with alot of features and power. 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.

austinchang 9y ago
thanks andrew. glad that you thought it was valuable. 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.
briandear 9y ago
Another problem that we faced at my little startup is the public perception of our product is different that what the product really can do. 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.
- danieltillett 9y ago
  We face the same problem in an even more niche market. It seems to be very hard for customers to understand that a product can have more than one use and that the first use they think of is not the only use. 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.

AndrewKemendo 9y ago

If you use the mantra that you are the user, and you build something for yourself with a small following, then you might miss a much larger market if you don't look for or seek out these hidden "journeys."

anon_googz 9y ago

It is just rebranded UX Design, and a pretty oversimplified version of it. 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.