On user experiences and needs

The Amadeus blog recently posted an interesting take on the fad "less is more" in a post entitled Why the ‘less is more’ concept in software design often falls short of its intentions. At first I agreed wholeheartedly as the title and intro had lead me into some nice confirmation bias ("grrr! gosh darn those gurus selling us different flavours of snake oil every year!"). Then I thought about it a bit more and the new feature being discussed was meeting a need; people wanted it and were pleased it was now present. That made me think that there was possibly some effective product management going on .. lo and behold the post was written by a product manager! This sentence was the most telling :

"how we define the worth of adding more features. For me, it is worth it if you are doing something for the human being who will be using the feature."
So a focus on user need is important, as if by magic later that day I read the brilliant post  How to Work with Designers that suggests the way to get the most out of working with designers is to focus on user need, for example:
"... the language here matters. Make it easier for users to sign up vs. Optimize the conversion rate on the sign-up flow. One approach speaks to the value for the end user. The other approach focuses on what the company needs to do to be successful. Designers generally think and operate in the mindset of the user."
I think this is actually useful advice for all the project team, let what the user will see and/or experience be the lens through which you see that fancy new feature.

Looking at the other side of the fence from a developer's point of view Sometimes less is more in language design probably explains some of the original intentions above. Simplicity should be the base and complexity layered on top as needed, you shouldn't start off complex otherwise things will get unwieldy.

An example from my real life, recently I've moved office building and the new kitchen has a "fancy" microwave. Most microwave ovens I've used have two dials - time and power - and at most two buttons - start, stop/open door. These covers pretty much anything I'd want to set on a basic oven. Unfortunately the makers of this microwave had decided it would be useful to let the user alter the time and power in combination according to the weight and type of food being heated up. This means it has various buttons and an LCD display. It took multiple attempts (including resetting the clock!) before the floor's receptionist rescued me and told me I had to press start for each 30 seconds I wanted to heat it up and then wait, after a short pause of no buttons being pressed it would heating. Here more is most definitely less, it doesn't meet any unmet need I had and is much harder to use the basic functionality.

Another more practical example of when less really is more in the world of IT products came in the Tnooz article Why we ditched mobile and hitched to tablet gives a good example of how when you know the market and have data on how it works you can make decisions to concentrate on features that are useful and meet a need. Although going mobile seems a no brainer and a good feature to have, that's if your product is in advanced booking it might not be the best option. Here is Anshuman Bapna describing how took the decision and viewed the experience they wanted to create:
"we always thought that travel planning should be a lean-back, sit-with-your-partner-on-the-sofa, browse-a-magazine kind of an experience. That screamed tablets, not mobile phones.

So to begin with, we decided to ignore mobile."

So, "less is more" seems to be a poor phrase to use as a guiding principle in product development; and can lead to frustration and miscommunication between different stakeholders. If you're going to use a single phrase I would prefer "build the right thing", the right thing can be a bit vague but I'd try and use these two principles to find out what's right for now:
  • focus on the user needs
  • use your experience in the market place to the maximum

Further reading

Prioritizing Joy By Drew Colthorp at Atomic Object (Posted August 20, 2013) a slightly different look at building the "right product, instead of merely the most feature-complete product." including brand and emotional response.

Sources

Why the ‘less is more’ concept in software design often falls short of its intentions Amadeus blog by Jean-Noel Lau Keng Lun Head of Product Management Corporate, Services and Security, Amadeus IT Group (posted August 1, 2013)


Why we ditched mobile and hitched to tablet Tnooz "Special Nodes" blog post by Anshuman Bapna, CEO and co-founder of mygola, a trip planning portal. (posted August 15, 2013 )

Sometimes less is more in language design "Haskell for all" blog post by Gabriel Gonzalez (posted August 2, 2013)

How to Work with Designers Medium post by Julie Zhou (posted August 15, 2013)

Confirmation bias entry on Wikipedia

Comments

Popular posts from this blog

CONFERENCE: TTI Summer Forum 2017 – Getting to Grips with GDPR

On performance and environment

On HBX and online education