25th November 2015

Decision fatigue

Early this year I was part of a discussion around 'how many design options to present' and the topic of decision fatigue came up. Decision fatigue is defined as:

Decision fatigue refers to the deteriorating quality of decisions made by an individual, after a long session of decision making. It is now understood as one of the causes of irrational trade-offs in decision making.

Wikipedia

It got me thinking about the role of decision fatigue in design and further, eCommerce. The popularity and continuing emergence of 'curated' product offerings is a clear indication that consumers are faced with too many decisions - and they are now happy to allow a company or service to help them make these decisions. Companies are continuing to invest in building 'intelligent' systems that leverage the data they have on our behavior to automatically curate our experience - thus reducing the number of options we are presented with and ultimately the number of decisions we need to make. As a result eCommerce has transformed from being a - come and look at everything we have process to rather a let me recommend the right products to the right customer at the right time process.

I would suggest that as designers and product managers we need to start including a decision fatigue audit as part of our design process - and not just looking at the final product page - but rather the entire decision making process and see how we can better understand the products we are selling, the differences between them - and look at ways to better recommend these products to the customer - either by using data tools available to you - or by being bold and simplifying the options and pre-empting their decisions. Rather let you customer say yes or no -  instead of I don't know.

Research suggests that our short-term memory capacity allows us to simultaneously consider 6-9 choices - maximum - without starting to suffer from decision fatigue. I recommend walking through your product as a user to see how well your design accommodates this research. It's also important to understand that choice doesn’t only relate to content - the more complex your navigation and interface is the more time it takes a user to understand how it works, and what to do next.

29th July 2015

Engineering Happiness

As part of joining Automattic - you are required to spend your first three weeks in product support. I was recently part of the first group of the WooThemes team to do the 3 week Support Rotation and it gave me some key insights into customer behaviour - as well as my own behaviour  - and the way one markets/presents a product:

Engineer customer happiness and reduce open tickets.

As a happiness engineer - you are given all the tools at your disposal to help a customer with a query - as such your job it to engineer happiness for that customer using the tools at your disposal. But having said that you have to also weigh up customer happiness vs business interests - i.e. you would not just be able to refund every customer who asked for a refund with the line 'but it will make them happy!" and realistically feel you are doing a good job. When I thought about this as a product manager I felt I could apply this same thinking to bring clarity to an often 'grey' job title: engineer customer happiness in a product while reducing the number of feature requests either through inclusion or exclusion.

Just because there is information online – don’t assume the customer will actually try find it first, and if they have found it, don’t expect them to have read it. And if they have read it don't expect them to have understood it.

As a Happiness Engineer it's your job to find the answers to the questions a customer has - often this means referencing articles that they could have as easily found as you. But, you can never expect your customer to have found these articles, let alone read it, and how about understanding them? So if you start finding that you replying to the same questions over and over again - maybe you should have a look at how and where you are addressing these issues in your products design and or messaging.

Don’t assume you have the answer to a customers question until you fully understand the problem they are facing.

We can often start telling a customer what we think they want to hear, or even more so what we want them to hear - rather than actually first trying to understand what it is a customer is asking, or why are they asking this question. I heard this line during my support rotation and it really struck me: You can put a bandaid on the problem - or you can try address the cause now.

Customers come with an expectation of what they think your product can do – and often will actually buy or use the product still fully expectant that it will do what they wanted it to do – even if it can’t.

I had a support query where a customer had a very valid idea for a website he was trying to create - but the catch was that although it was a really good idea - the way he wanted to use some of our products was just not relevant to 99% of our customers. Maintaining your products focus amongst a sea of good ideas is key, you need stay focused on your product goals and keep working towards them.