Lately, I've been thinking a bit about product design. Despite all of the lengthy Twitter threads on the subject, it's not super often that I come across a product experience that delights me. This isn't a knock on all the 'product people' out there doing their thing. Building great product is really, really hard.
This passage from Erik Bernhardsson regarding his wishlist for the next generation of software explains the feeling well:
You know how crappy software is crappy in ways that are so blatantly obvious to the user that you wonder why it was released? A touchscreen interface that's super laggy, or an appointment booking app that forces you to go in and out of possible dates and fill in all information before it tells you if it's available. We've all seen janky stuff like that, and they are generally janky in the same way: it feels like no one actually used the product after it was built, and said like, hey, this is kind of annoying, maybe we should make it more intuitive?
"Don't build a janky product" seems like fairly straightforward advice. Yet I would wager that most products you use on a regular basis have some degree of 'jank' coming along with it. At least that's definitely the case for my software suite.
Debugging the Jank
So why does this happen? Back to the same post:
In 99% of the cases, I imagine they ended up in this situation because someone spelled out a long checklist of requirements, but there was nothing on the checklist to make sure the experience is delightful. Like, someone started with a wall full of post-it notes going “as a user, I want to …" Which I think logically makes sense — you can define a requirement that users should be able to do x, y, z, but you can't define that the experience shouldn't suck.
Embedded in this passage are two reasons why products end up with a less than delightful experience.
First, the "feature request → not removing anything → bloated product" pipeline is very real. We have all seen companies fall victim to this. It's quite easy to get caught up in improving and adding everything until you end up with a Microsoft-esque offering that can do everything well but nothing easily.
Second, we prefer to work towards requirements that can be defined. As Erik stated above, it's not easy to define a requirement that the product shouldn't suck. On the other hand, it's quite easy to define requirements for features. As humans, we tend to optimize for whatever is easiest, and ill-defined problems aren't easy.
Building for Delight
There are lots of different things that make a product delightful and as mentioned before, it can be hard to define. However, I thought I would put together a short list of some attributes that I see in delightful products:
- Speed: Load times and general pace
- Control: Ability to do things as you want them done
- Goals: Working towards some point or variable rewards
- Mastery: Motivation to level up in skill or status
- Surprises: Moments of unexpected joy
Attempting to put all of these together: Delightful products enable you to quickly do things as you want them done while leveling up in skill to work towards a goal. Reaching this point is easier said than done, but keeping a few principles in mind as you build is certainly a start.
Lastly, some quick advice for the road:
- Gut-check: Is this product experience intuitive? Does it make sense?
- Avoid bloat: Every time you add a new feature, remove or simplify one
- Goals: Be mindful of prioritizing well-defined goals over the experience
Thanks for reading! If you enjoyed this post, you can subscribe in the form below to get future ones like this one straight to your inbox. If Twitter is more your speed, you can follow me there as well. 🔥