Watching someone do something can make you experience it as if you are doing it yourself… hard to believe?

Sounds far-fetched! But, believe me it’s not a figment drawn from science fiction but grounded in neuroscience studies…

mirror neurons

I recently came across a reference to mirror neurons in neuroscience studies and the more I read about them the more I got intrigued…

A simple explanation suggests that there are specialised neurons (named the mirror neurons) that are seen to fire both when a person acts and when the person observes the same action performed by another – thus mirroring the behaviour of the actor, as though the observer was himself performing the action.

If this is true, then its almost as if the mirror neuron is performing a virtual reality simulation of the other person’s action… just think about the possibilities – it can start to explain simple behavioural and complex social responses… I have often wondered why most of us get so engaged and emotionally charged when we watch our favourite sports… it’s almost as if we are playing ourselves! Could it be the mirror neurons in play?

As with any new discovery it’s a subject of speculation and intense debate and while its premature for us to draw conclusions, I am personally biased by my passion for understanding how our brain adapts and using that to simplify every day activities.

The potential of the discovery in itself is enough motivation (for me) to delve deeper into the subject and the initial opinions that I have found have not yet disappointed me. (Ref. A good introduction to the subject is a TED talk  by neuroscientist Vilayanur Ramachandran where he describes his research on mirror neurons).

Most of the discussions talk about the potential role and importance of mirror neurons in two different areas – from understanding the actions of other people or empathy (where we could literally experience what others are experiencing and adopt the other’s point of view) to learning new skills by imitation (where the mirror systems simulate observed actions). The experiments show that while we can empathise and imitate other person’s action, we are still able to distinguish, eventually, that the action is not done by us since we do not get the same feedback from the sensory receptors in the skin (touch, pain etc.)

The importance of empathy and imitation is not hard to imagine in any context – from broad social and cultural contexts to dynamic business environments. As our environments become more global and we work in geographically distributed teams, our primary business interactions are centered on email, conference calls, social and collaboration tools, etc. As the opportunity to watch someone in action has notably gone down, it has inadvertently restricted the use of our natural ability of imitation and empathy in everyday interactions.

It is believed that video can fill this void – it provides an opportunity for people to observe and watch others as they speak and act… it is becoming increasingly apparent that embedding video in our interactions and work-flows in product design not just drives simplicity of action, but influences user behaviour through an increased ability to understand and empathise with others and to co-relate more effectively by imitating behaviour and skills.

I genuinely believe that by understanding what makes people act the way they do, we can design more intuitive and engaging products and interactions that match their natural way…

ps. Of-course I cannot deny that my excitement extends beyond every day social and behavioural application and I am equally fascinated by the possibility of a scientific explanation to the Indian philosophy (that I have grown up with,) that is based on the belief that there is no real independent self and we are all part of the same consciousness)… after all who knows we are all connected by neurons and we just need to dissolve the barrier of the physical self to communicate and interact – far more effectively than the current digital plane of the internet!

This article was first published @LinkedIn on May 07, 2016. 

 

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.

Great User Experiences start at the Back End

 

Successful consumer experiences are as much about behind-the-scenes business operations and processes as they are about easy-to-use products and cool designs. 

There is no doubt anymore that most companies recognize the true power of experience—thanks in large part to Apple, who has successfully emphasized user experience as an important element of success. And yet, it’s amazing to see that there is no simple definition of what “experience” really means or entails. Is it the overall interaction with a cool or smart design or is it confined to the graphic user interface (GUI)? I would say both. But I would also add that the complete user experience must also entail the service flows around various experience touch points.

The fact is, experience is the art of taking all those behind-the-scenes business processes and operating complexities (which we always tend to overlook), rationalizing them into streamlined functions, and then hiding them from the user by creating easy-to-use touch points and cool designs. So far, this is what has set Apple ahead of the competition, even as the competition floods the market with a surfeit of Apple look-alike products.

I’ve been associated with customers who go through an innovation cycle to replicate Apple’s success. Most of these initiatives ended with marginal success, and none created any industry-changing paradigms. What they all had in common was a single dimensional approach of hurrying the service functionality to the market. Existing operations and business processes were given short shrift and overlaid with ad-hoc upgrades in order to address service impact requirements. The result was that while the functionality excited technology innovators, it failed to generate any momentum because the experience wasn’t seamless enough.

These days, as the world becomes more connected than ever, dependency on the entire business eco-system has increased significantly. Touch points of customer experience now extend into multiple and diverse back end systems and processes (e.g. authentication and user identity/profile management, discovery and recommendations, download and upgrades, optimization for bandwidth and performance, campaigns and advertising, billing and revenue assurance, business analytics and service assurance, inventory and fulfillment, and third party eco-system management across CRM, billing, BI, OSS and SDP systems). Initially, it’s fairly common to overlook the complexity and impact of creating a comprehensive user experience, and when the challenge surfaces during the later phases of deployment cycles, the impending launch dates leave no room for innovation in that area.

In my experience, the most well-defined experiences get created when the impact on operations is envisioned at the same time as the product or service itself. This allows for all dependencies to be built in upfront into planning, while ensuring that a separate focus is created to commit to a seamless end-to-end operation. This may be possible through simple rationalization or through the evolution of existing systems, but in some cases it may require a full transformation. As the world becomes more connected and more people and products come online, the biggest challenge to service delivery models and business processes will be to sustain dynamic ever-changing real-time user and business parameters.

This is, in-fact, the difference. Apple designs for the end-to-end service—not just for a product. What this means is that companies must plan for service integration as part of an innovation strategy. At least, they do if they want Apple-like success.

This article first appeared on Aricent Connect on June 18, 2011 (http://blog.aricent.com/blog/great-user-experiences-start-back-end)