Cognitive is fine, but…

What do users really feel about cognitive?

This is the era of Cognitive.

Intelligent systems, coming up everyday that not only can solve your problems, but can understand your problems in your terms, and also at times, can predict the problem you may face and solve it for you even before you actually run into it. Cognitive systems recognize you, know you, and they know you so well that they even know what you might want and they can give you just that without you having to ask for it.

We’re working on a few cognitive applications ourselves, but that’s not what I’m going to talk about here. I’m going to talk about some generalized user research insights that I was able to collect when I interviewed some of the users around how cognitive would or could fit into their lives.

  1. Cognitive is fine, but… I’m not sure I will like it – This is the classic resistance to change. A newer system, even worse – a newer and more intelligent system will intimidate me and I’m probably not going to like that.
  2. Cognitive is fine, but… if it is counter-intuitive, I won’t trust it – Users go by intuition when they make decisions towards solving a problem. This intuition comes with experience. So the issue here, really, is two fold. First, it is hard for the users to understand the concept of a “self-learning system” solving your problems from day 1 without being out in the field enough. Second, if the solution being proposed is different or disruptive or deviates from what they would normally do in that situation, then they wouldn’t trust it, but go with their gut feeling anyways.
  3. Cognitive is fine, but… I didn’t ask for it – Users like to feel in control. They like the sense of accomplishment they feel when they solve the problem. Most would turn to cognitive capabilities and ‘ask for help if I need it’ rather than having the system throw a bunch of recommendations at them as soon as they start using it.
  4. Cognitive is fine, but… tell me why – Most users will trust the solutions better if the solutions and recommendations are also accompanied by some reasoning. Why should I do what the system is telling me to do? How do I know that it is telling me the right thing to do?
  5. Cognitive is fine, but… let me test it – Users want to be able to test out the solutions and recommendations with sample scenarios before actually going ahead with the proposed solution. That way, they can validate the outcome of these solutions first.

FUNNY!!

I thought the users would be really excited when we talked cognitive to them. I thought the ideas would be welcomed with a thunderous applause, with open arms!

Why the resistance? Why the skepticism?

Well, the bigger problem here is that most users are unable to visualize these systems. They have no mental model of the cognitive system. The closest mental model they have is that of the existing system that they’re currently working with.. a system which probably is cumbersome to use already and difficult to figure out and make things work. This whole Cognitive thing only adds more confusion to the mix and makes them more skeptical.

The above list is intended to help empathize with the end users of your cognitive system and their concerns. However, Cognitive systems are really good candidates for “Users don’t really know what they’ve been missing out on all this while, until you’ve shown it to them.”

My personal learning from this: rather than having them imagine this hypothetical system and asking them what would you like this cognitive system to do for you, come up with a prototype first and take that first cut to them.. show them what you have in mind, show them how it will change the way they work, and then ask for feedback!!

Collaboration vs Teamwork

Are they the same? What’s the difference? Why should I care? Find out…

For the longest time, I used to think collaboration is same as teamwork and they could both be used inter-changeably. For starters, both stand for “working together”. Also, both involve a bunch of people working together with the intention of getting something done. So, what’s the difference then? Is there really a difference?

Apparently, there is…

Teamwork is an organized division of tasks at hand. It’s when people are structured to work together in a particular manner to accomplish a common goal. This common goal is more important than individual opinions and in most situations, majority counts. The process is a formal one.

Collaboration on the other hand, is a more casual setup. There is no ONE leader. Everyone works in conjunction with another to accomplish a common goal. The process fosters creativity because the goal still needs to be achieved but the onus is on the individual players to share knowledge, understand working patterns and get things to work, while still holding on to individual values and opinions.

Collaboration can sometimes get you better results than a structured team.

So how do you decide which one works for you? Make a call. Assess the risks, look at your end goal, your time-lines and then decide.

Teamwork most likely utilizes proven methods and concepts to fetch results. Structure and discipline will make sure the job gets done on time. But there will most likely be no innovation. If you are trying to come up with something new, go for collaboration. Creative individuals will bring new ideas to the table. The lack of structure may initially account for some additional time to get things moving smoothly, but once the team dynamics are in place, the job will get done, probably much better than what teamwork could have achieved in a similar scenario.

Collaboration today has become fairly straightforward in the workspace given  a) people’s familiarity with the concept of social networking and their ability to utilize their networks to do things or get things done; and   b)the availability of many social and collaboration tools for enterprises in the market.

Social computing gives us a way to tap into each other and bring the combined talent of the network to solve business challenges.

The catch, however, is that using social computing tools at the workplace requires you to change your mindset about how you do your everyday work:    to understand where exactly collaboration and open communication fits in as opposed to the closed avenues of sharing information like emails, memos fliers and files; to utilize the social computing tools to solicit feedback, opinions and inputs from a the larger pool of employees rather than depend on the traditional organizational hierarchy for gathering required data.

It all leads to accepting the fact that none of us is as smart as all of us.

(Ported from my other blog)

Down the memory lane…

A catalyst that helped change my thought process from get-it-done to get-it-done-right.

It was meant to be.

Back in the days when I was still actively developing User Interfaces, I chanced upon the “This is Broken” page from GoodExperience’s Mark Hurst and loved it so much that i subscribed to it. For 2 years or more, I remember waiting for the site’s newsletter every week to get a good laugh out of some of the gems like these:

Cuyama  Traffic_lights

110765351664  Livechildren

I did not realize when and how I graduated from having a hearty laugh to start looking for “broken things” on my own. I started noticing things better, I started to point out to myself: This message does not seem right, this logo does not seem to convey it’s intent, this signboard seems out of place, the elevator buttons are confusing…

I also started validating my observations with people around me. Did they find it confusing too?

I was slowly but surely converting… morphing from a quick fix, get-it-to-work developer to someone with a “Does this make sense?” “Will this look broken?” perspective.

That probably was my formal initiation into the design and user experience and user research world.

Eventually, Good Experience fell off my radar as I got assigned to solving real UX problems on my own. A little bit of searching revealed that it is now a blog, with last entries on there dating to 2013.

It did bring back fond memories, though… and a smile on my face! 🙂

Save

Myfavcorner bids adieu…

I’m porting my blog posts from my other blog to this one because I lost my wordpress userid for that one.

My older blog Smarter Thoughts will not be functional anymore because I cannot remember my WordPress userid and password for that one (yeah… stupid, irresponsible, how can i not?, etc, etc).

After spending a few hours trying to figure out a way to revive it, I’m finally giving up on it.

I’ll port some of the relevant blog posts from that one here and leave out the ones I don’t like much now.

I hope to keep this one up and running for a long time.

Time for a new beginning 🙂

Designing for bears

Well, what would you do if I asked you to create designs for bears? I mean, apart from telling me that I’m probably out of my mind!

Would you give it a try?

Take a look at this slide deck which I came across  in my twitter stream:

Designing for Bears

 

Lucy Spence makes it look so easy

… and so logical!

Logical it is. Most usability folks will agree that observation is the most important step in getting to know your users; even if they’re bears! Observe them and you’ll know what they need to get their work done; making it easier for you to give them what they actually want.. rather than second guessing.

I loved the uncomplicated and to-the-point sketches that get the point across very well.

The iceberg

The User Interface design is just the tip of the iceberg. The strategy, scope, structure and skeleton constitute the bulk of the work that needs to be done behind the scenes.

Everyone in the User Experience domain swears by Jesse James Garrett’s  Elements of User Centered Design.

If you’re from this field, the elements will  probably make sense to you the moment you look at the diagram above.

However, put yourself in your client’s or customer’s shoes and you’ll understand the need to translate the above into something that will make sense to them and at the same time emphasize the value these elements bring with them.

I came across this very smart representation of the Garrett’s model by Trevor Van Gorp, which he calls The UX Iceberg:

Like Trevor rightly puts it: “…  when the User Experience Iceberg is used to add context to the Elements, it illuminates the dark, unknown depths for project stakeholders who are new to UX. Because in the end, the unseen elements of user experience are the parts of the iceberg that will sink your project, while your stakeholders are busy focusing on the ‘tip’ “