Creating intuitive products that users just get
Creating intuitive products that users just get
Creating intuitive products that users just get
▾
▾
▾
Creating products is hard.
I used to think this was due to the technical challenge involved. That’s still true but several products later, I believe there’s two other aspects that are even harder: 1. Creating something users want and 2. Creating something that users intuitively get.
There’s some great material on the first part (Rahul Vohra on building Superhuman & Hiten Shah on identifying Product-Market fit are fantastic) but little on the second.
In this post, I'd like to share an approach that helps with the second part.
Making products user just get
Most products are designed based on their underlying implementation model. This means that the user interface exposes functionality similar to how its modelled in the underlying implementation.
But to create a truly intuitive product, one must first understand its intended users, their behaviours and their motivations. This in turn shifts the solution from thinking in terms of the implementation model to what users need and when.
A simple example to illustrate this
In a music player app, from an implementation standpoint the actions for Play, Next and Shuffle have the same importance — they’re all verbs associated with the Player object. Hence when designed in terms of the implementation model, the actions have the same prominence on the UI.
However, from a user’s standpoint these actions are very different in importance. Users use Play more often than Next, and that in turn much more often than Shuffle. A design that respects the user reflects this difference in the UI.
How to uncover user needs & behaviour
The best process I've found to uncover these is to talk to customers and capture their behaviours & motivations through job stories. (The folks at Intercom have a great writeup on this. Alan Klement's writing is insightful too.)
The table below shows the format I use to capture job stories. Picturing the user along with the situation helps visualise the situation like a movie and understand the job better.
The last column captures possible solutions for the user's needs. Decoupling solutions from problems in this manner allows for better solutions to emerge later (and by others too since everybody can now understand the underlying problem being solved.)
Eventually as you capture more stories, the features required in the product and their relative importance in various flows become clear. This lets you prioritise features which are frequently required over those which are not.
The right design then emerges from this.
Creating products is hard.
I used to think this was due to the technical challenge involved. That’s still true but several products later, I believe there’s two other aspects that are even harder: 1. Creating something users want and 2. Creating something that users intuitively get.
There’s some great material on the first part (Rahul Vohra on building Superhuman & Hiten Shah on identifying Product-Market fit are fantastic) but little on the second.
In this post, I'd like to share an approach that helps with the second part.
Making products user just get
Most products are designed based on their underlying implementation model. This means that the user interface exposes functionality similar to how its modelled in the underlying implementation.
But to create a truly intuitive product, one must first understand its intended users, their behaviours and their motivations. This in turn shifts the solution from thinking in terms of the implementation model to what users need and when.
A simple example to illustrate this
In a music player app, from an implementation standpoint the actions for Play, Next and Shuffle have the same importance — they’re all verbs associated with the Player object. Hence when designed in terms of the implementation model, the actions have the same prominence on the UI.
However, from a user’s standpoint these actions are very different in importance. Users use Play more often than Next, and that in turn much more often than Shuffle. A design that respects the user reflects this difference in the UI.
How to uncover user needs & behaviour
The best process I've found to uncover these is to talk to customers and capture their behaviours & motivations through job stories. (The folks at Intercom have a great writeup on this. Alan Klement's writing is insightful too.)
The table below shows the format I use to capture job stories. Picturing the user along with the situation helps visualise the situation like a movie and understand the job better.
The last column captures possible solutions for the user's needs. Decoupling solutions from problems in this manner allows for better solutions to emerge later (and by others too since everybody can now understand the underlying problem being solved.)
Eventually as you capture more stories, the features required in the product and their relative importance in various flows become clear. This lets you prioritise features which are frequently required over those which are not.
The right design then emerges from this.
Creating products is hard.
I used to think this was due to the technical challenge involved. That’s still true but several products later, I believe there’s two other aspects that are even harder: 1. Creating something users want and 2. Creating something that users intuitively get.
There’s some great material on the first part (Rahul Vohra on building Superhuman & Hiten Shah on identifying Product-Market fit are fantastic) but little on the second.
In this post, I'd like to share an approach that helps with the second part.
Making products user just get
Most products are designed based on their underlying implementation model. This means that the user interface exposes functionality similar to how its modelled in the underlying implementation.
But to create a truly intuitive product, one must first understand its intended users, their behaviours and their motivations. This in turn shifts the solution from thinking in terms of the implementation model to what users need and when.
A simple example to illustrate this
In a music player app, from an implementation standpoint the actions for Play, Next and Shuffle have the same importance — they’re all verbs associated with the Player object. Hence when designed in terms of the implementation model, the actions have the same prominence on the UI.
However, from a user’s standpoint these actions are very different in importance. Users use Play more often than Next, and that in turn much more often than Shuffle. A design that respects the user reflects this difference in the UI.
How to uncover user needs & behaviour
The best process I've found to uncover these is to talk to customers and capture their behaviours & motivations through job stories. (The folks at Intercom have a great writeup on this. Alan Klement's writing is insightful too.)
The table below shows the format I use to capture job stories. Picturing the user along with the situation helps visualise the situation like a movie and understand the job better.
The last column captures possible solutions for the user's needs. Decoupling solutions from problems in this manner allows for better solutions to emerge later (and by others too since everybody can now understand the underlying problem being solved.)
Eventually as you capture more stories, the features required in the product and their relative importance in various flows become clear. This lets you prioritise features which are frequently required over those which are not.
The right design then emerges from this.
–
Notes:
Talking to customers is the best way of understanding what they're trying to accomplish using your product. However, I also find job stories useful to capture insights gleaned from secondary research – the format helps weed out jobs that sound implausible.
When critiquing a product's flow or static design, you often find functionality that isn't supported by any job story (or a rare one.) Thus job stories are also a powerful tool to reduce complexity in products.
Job stories are usually written in present tense. However, I find describing situations in the past tense helps visualise them better. This is similar to how books written in third-person, past-tense are easier to picture in the mind's eye than those in first-person, present-tense.
Jobs can also be used as a lens to understand when disruption might happen (the classic Clayton Christensen Theory of Disruptive Innovation is descriptive but not predictive.) Alex Danco's series on Emergent Layers is an extremely enlightening read on this.
–
Notes:
Talking to customers is the best way of understanding what they're trying to accomplish using your product. However, I also find job stories useful to capture insights gleaned from secondary research – the format helps weed out jobs that sound implausible.
When critiquing a product's flow or static design, you often find functionality that isn't supported by any job story (or a rare one.) Thus job stories are also a powerful tool to reduce complexity in products.
Job stories are usually written in present tense. However, I find describing situations in the past tense helps visualise them better. This is similar to how books written in third-person, past-tense are easier to picture in the mind's eye than those in first-person, present-tense.
Jobs can also be used as a lens to understand when disruption might happen (the classic Clayton Christensen Theory of Disruptive Innovation is descriptive but not predictive.) Alex Danco's series on Emergent Layers is an extremely enlightening read on this.
–
Notes:
Talking to customers is the best way of understanding what they're trying to accomplish using your product. However, I also find job stories useful to capture insights gleaned from secondary research – the format helps weed out jobs that sound implausible.
When critiquing a product's flow or static design, you often find functionality that isn't supported by any job story (or a rare one.) Thus job stories are also a powerful tool to reduce complexity in products.
Job stories are usually written in present tense. However, I find describing situations in the past tense helps visualise them better. This is similar to how books written in third-person, past-tense are easier to picture in the mind's eye than those in first-person, present-tense.
Jobs can also be used as a lens to understand when disruption might happen (the classic Clayton Christensen Theory of Disruptive Innovation is descriptive but not predictive.) Alex Danco's series on Emergent Layers is an extremely enlightening read on this.