If only my interaction with a machine could be Collaborative…?

I realised that most Error Messages frustrate me, some even scare me and only a very few actually guide me through the error scenario…

error scares me

Just last week, I was exploring a new software service – and incredible as it sounds – despite being a native user (and developer) of software, and having survived generations of software applications, I still panicked at the sight of a ‘big red X’ (a typical ‘ERROR’ alert) – so much so – that before I knew, I had instinctively killed the application!

That got me thinking. A simple response by a system to one of my ‘natural’ actions managed to induce a feeling of helplessness and despair, even a degree of frustration and anger – enough for me to give up. And, if I am honest then I know that I have no intention of retrying anytime soon.

I am sure that I am not an exception – many of you will have a similar experience to share – at least at some point in your interaction, with one or another system or application.

I looked further – I found research that said that there is a tendency in all of us to blame ourselves for our failure with everyday objects and systems. Surprised? Well I certainly was. Isn’t it a contradiction to our natural inclination to blame everything that goes wrong in our lives on others or our environment?

But, the underlying question that continued to bother me is simple – if I reflect on my ‘natural’ action, it was nothing but a typical ‘user behaviour’. How can user behaviours be ‘Errors’? So what are we missing?

I guess, it comes down to the product design and user experience. I know, that when I design a product, no matter how I expect users to use the product, it is a reality that, there will always be a few users who will find different and unexpected ways to use it. And a good design can neither ignore that (and hence needs to handle the unexpected), nor be restrictive to force all users to comply with a single flow (which would inherently conflict with their natural behaviour).

I started to look at the error messages that we issue under different error scenarios in our own mobile video application. We had invested a lot of time in humanising all our application messages and notifications, and were even inspired by NLP (Neuro-Linguistic Programming) – so while most had a human touch (and hence were not as scary as the big X), I realised that they still were fairly limited in guiding the user through to the next stage.

I started to look at error messages from different applications under different scenarios. I noticed that even when actual errors encountered were similar, my experience (and hence response) as a user was very different – and the difference was in the small details of how the message was communicated.

And then I remembered an old reference from the book ‘Design of Everyday Objects’, where Don Norman interestingly uses a standard interaction between two people as an example to demonstrate that effective interactions are mostly built on collaboration – where a person tries to understand and respond to the other party, and when something is not understood or is inappropriate, then it is seamlessly questioned, clarified and the collaboration continues naturally.

I guess, as a user, I am tuned to expect my interactions to be collaborative – and hence struggle when my interactions are with a machine (and not another person)… of-course they inevitably fall short! Any expectation that the user behaviour will/should change when interacting with a machine is suspect – we all know how un-adaptable we all are as a species! There is no doubt that the goal for us – as product designers – should be to build in intelligence into the machine interaction and aspire to develop a collaborative interaction between the user and the machine – i.e. when the user does something wrong, the machine should respond by providing clarification, helping the user to understand, guiding the user to continue through to the next stage – ensuring that the communication illustrates how to rectify the inappropriate action and recommend the next actions.

I know it sounds onerous. But it is not. Technology is a powerful tool and we have enough capability and building blocks now to easily build us simple collaborations and design good feedback and interaction models.

I am fascinated with this new challenge. Our goal will now be to eliminate all error messages and instead replace them with messages that aid and continually guide the user…

This article was first published on LinkedIn on January 23, 2016.

When I paid the price for forgetting that the first 5 minutes of user journey is more important than all the cool features…

user journey

I love technology and of-course I thrive on building cool features – nothing compares to the excitement of implementing highly complex algorithms or finding new ways of using the technology to solve a problem.

But many hard experiences have taught me that technology (alone) does not sell and I have over-the-years learnt to first focus on user experience and always keep the technology hidden.

So, when I started to write down the product specifications for my new startup idea, I did everything right – there was not a single word on technology and I captured the product definition through 5 stages of user journey.

[5 Minutes] captured the 1st Experience: AWARENESS

[5 Hours] focused on the 1st Use: ORIENTATION

[5 Days] looked at making it work for the user and lead to Participation: PERSONALISATION

[5 Weeks] looked at making it work for the larger group and added elements of Induction: INFLUENCE

[Ongoing] introduced capabilities to sustain the momentum: CULTURE

It was the right way to do it. We ran the user journeys with many clients and fed the inputs and preferences back. After 4 months of market validation we decided we were ready to start development.

And that’s when the problem inadvertently occurred (of-course, I never realised it at that time). As we drew out the release plan we ran through the normal cycle of chopping features and prioritised to define the feature-set for the first beta version. I believe that is when my latent love for technology overtook my experience and I selected the base feature set to include functions that demonstrated the algorithms (justifying it all by saying that these complex contextualization algorithms were our differentiator and critical for illustrating the value to the user). Nothing comes for free – to balance time and resources we decided to take a shortcut for our initial sign-up and login process. At that stage it seemed the perfect thing to do – after all its something a user does only once or at best a few times – and even if its a few extra steps or a little painful – it will still work!

Of-course it worked. But only for those true early-adopters who had the motivation to take that extra initiative and accept a few painful interactions. As our user base grew, a lot many users attempted to sign-up but never managed to get onboard. Its amazing how often it happened – and believe me that the interaction wasn’t anything demanding – it simply required them to copy an access code (sent separately) and input it as part of the sign-up. In those days, we lost a few users and for many others our client engagement teams had to invest time and run after them (and often hand-hold) to complete the process. If only we had stuck to our original definition of keeping the 1st 5 minutes interaction simple and seamless, we would not just have got a lot more people on-boarded, but also ensured that their first touch point was fail-safe.

In hindsight, it seems a blunder – how could we have ignored the fact that users had to onboard first before they could experience the cool contextual and personalisation features? There was no technical complexity to the desired sign-up process and I do not even know if we really saved that many development hours and resources. It’s more like we were avoiding working on a task that had virtually no challenges for us to fix…

What hurts me even more is that its something that I, as a Product Manager, always knew and even apportioned the right value to it at the time of conceptualisation. And yet, somewhere I still lost control on the road from concept to delivery.

This article was first published on Medium on October 27, 2015 and LinkedIn on November 21, 2015.