Any system/tool/platform/product that combines content with workflow has two components. Let’s call them the container and the payload. Each requires something from the other to be of any worth together. And either of the components can be worked on – though not entirely independently – for betterment. But sometimes strange things happen. Take for instance e-mail. The e-mail ecosystem has the client as container and the mail (the stuff we write) as payload. E-mail client developers assumed they had not much control on the payload so they went about making the container smarter. Search, labels, keyboard shortcuts, themes, threaded conversations and so on. Later providers like Mailbox (and I am told Inbox, though I am still waiting for an invite) attempted at taking the payload and infusing smartness into it. But in reality for e-mail ecosystems no matter how smart the containers became, the payload was slowly moving towards extinction. Conversations had started moving away to instant messaging platforms of various forms (IM clients) and delivery mechanisms (like WhatsApp). No matter how smart the container became, the payload was getting irrelevant by the day and those with their necks immersed in the containers (no pun) never saw that happening
This presents a rather interesting situation for those building content and workflow combos. The conundrum – which should be made smarter – containers or payloads? One way to examine this is to ask the question – what would reduce friction between the user and the
task outcome? (Just pause a minute to consider that strikethrough. Very often we focus on the task and become oblivious to why the task is performed). Workflow and content combos in enterprise software invariably play to productivity and efficiency. The question for a product manager finally boils down to how can those two be improved
Product managers have different levels of leverage on the container and payload (example, email client developers have less control on the payload. Imagine a mail client asking email senders of recipients to add tags to their text before they can be processed). Control over payload is usually less. And this is where effort should be directed to make the payload smarter over the condition in which it arrives even before we start looking at smart containers. For example
- Text mining to improve contextual understanding of unstructured content
- Interlinking of entities for multi-dimensional content
- Algorithmic understanding of relationships
- … and so on
As we work through the layers of containers and payload, it is useful to remember that it takes two to tango. And their could be work to do at either end
Deepa Bachu of Intuit has a fabulous post on designing awesome products. (no, don’t skip. Click the link, read the article and come back here. I’ll wait)
I think time has come for product managers (and designers) to stop using the term Know Your Customer. Before you reach for your cudgels to beat me up – my intent is not to stop people from knowing their customers but to get a couple of layers deeper in the engagement. Let’s look at some specific problems with this “know your customer”phrase
- The phrase has been bastardized. It happened the moment KYC as a TLA emerged from the fertile crescent of product management and got dragged – kicking and screaming – into the muddy waters of banking. In its most sophisticated form in that industry, KYC is a bunch of entity identifiers and descriptive text about the entity. To be updated at intervals and filed away only to be brandished if a regulator came calling
- The word “customer” – I have a problem with. It is very common in my industry of enterprise information and I am sure it happens elsewhere too – the customer is not the user. The customer is the one who disintermediates vendors from the user (example, IT departments strike deals with capital market data vendors and often chooses the most cost effective vendor. The market data users are dealing room staff who do not participate in the choosing process). If it is the user that we care about then we must not confuse her with the customer
- The word “know” – I have a problem with that too. I know too many people on Facebook – I care for only a fraction of them. I know many more people on LinkedIn than I could really care for. The word “know” has diluted the sense of affinity in relationships. In its pristine form, Know Your Customer is not really “know” – it is living with him, sharing his daily joys, pains and frustrations. A closeness much deeper than just that cursory “know”
So what should the new phrase be? How about User Affinity (UA). Besides addressing some of the problems I mentioned above, this is a smaller acronym and easily segues into what should be a logical next step – User Experience (UX). UX should build out what UA discovers – that is the relationship
I’ll leave this post here just so you can let me know your thoughts about this new paradigm of User Affinity. In the next post of this series I will look at ways to develop affinity and insights. Till then keep the comments coming
In my earlier post, I had ranted about the icons that go against feed identifiers in Google Reader (that wasn’t the only thing I ranted about but yes, they did look like 1990s). I was pleasantly surprised today morning that Google has started showing brand thumbnails against the feeds. That’s good.
Before: 1990s style icons
With Brand Icons
Google was the pioneer of simplicity in UI. The company that made billions had a rather strange website – a big text box to accept your search string. It later went on to doodles, which became an instant hit. Simplicity was key, which was fine so long as someone was zealously guarding that cornerstone of design philosophy
Google’s approach to product development has been a mixture of organic and inorganic development. Google unleashed its engineering expertise in the form of Labs onto assets, extending their capabilities. In that process it succumbed to the “UI is too important to be left to engineers” syndrome. The Gmail user interface looked very different from Google docs (which had inconsistent UIs amongst its own components as some of them came via acquisitions) and Google Reader had a different look, feel and navigation. So it was natural that Google stepped into an area not exactly its strength – designing UIs to make them consistent. It dealt itself either a weak hand or set for itself a low bar by defining the coverage of consistency to imply just the look
Google users were slowly pushed these UI updates with the login page to a Google service being the first. Then other services took over. Notice the first inconsistency in this consistency drive – the login page has a big blue button while other services have red. Users ignored such glitches up until Google brought out the new-look “Reader” – a service that allows RSS aggregation and sharing
My Twitter timeline was a first warning that things did not go as planned for Google. After a quick check, I can understand why. The first rule of UI refresh is not to apply lipstick on a pig. The user interaction on Google Reader was always dated – one reason why services like Flipboard and Zite pretty much took up the reading experience leave Google with just the menial task of fetching. And Google passed up an opportunity to redo the design to not just make the service consistent with its brothers but also more modern and egg the reader to stay on by making reading easier. Instead, other than changes in fonts (oversized ones in the main column – Jesus Chirst!) the only other thing I see is a shroud of white all around. Improving user experience to induce more reading (or more +1’ing if Google was after that) was surely not a design objective
(click to see larger, clearer image)
And Google, for reasons they know best, chose to retain a list of keyboard shortcuts on the right panel, leaving the rest of the real estate – copious one – totally blank (adding to the already dominating whiteness of the page)
Ability to aggregate content from publishers that expose them via a common protocol was a tough problem to solve several years ago. No longer so, unfortunately. As Google bets big on its social gambit it has to understand somewhere that it is effortless usability much rather than astute engineering that greases the wheels of social interaction
With a starting point in a situation, one can choose their turns. There is a way to go backwards in time, which is what quality assurers and detectives do – and call it root cause. They ask the question – “why?” (Toyota wanted that to be repeated five times. That many layers of reason hide the truth that each subsequent “why” pulls back). There is another turn however that leads to insights about the future. We will come to it but just a spot of background building
Organizations and decision makers have depended on analytics – or analysis – for making better, fact-based decisions. With an explosion of data, available both publicly and within organizational confines, coupled with sophistication of computational technology creating analytics is not as onerous as it once was. The great thing about analytics is that they are never dead-ends. They are not what I refer to as “terminal” (this is where a lot of data vendors have a problem because they have always seen – and called – their offerings as “terminals”). In order to glean true insights from analytics one must further the analysis. Furtherance happens either by extension (“this is fine, but how about a further analysis of all our lost businesses”) or collaboration (“hey Steve, I think there is something funny with our sales trend. Can we take a look at it together and try make sense of it?”). Thus, analytics almost always casts an eye to the future. When we stand at the cross roads of a situation and we want to take the turn towards understanding the future, what question do we ask?
“Then” sets us out on a path of inquiry that hurls us into the future. “Then, once I have the current price of a security, I look up what the price trend has been in the past”. “Then?”. “Then I try to figure out if there is a price level from where it has bounced back so I could buy at that price”. “Then?”. “Then I place an order with my broker to buy at that price”. Theoretically we can go on but you get the drift. If you are building a product or service that has to do with user workflows, the word “then” is the best friend you can hope to have. Leave the “Why?” to the policemen.
Post Script 1: Of particular interest will be for interaction designers is this “then?” concept. Anyone has examples in action will post in comments, no?
Post Script 2: Someday a management consultant or an Ops Research person will work out the optimum number of “Then?”s required to capture most of forward workflows – till then let’s call this “The Seven Thens”. It lils nicely on the tongue
Picture courtesy: Deposit Photos
Behavior is a function of the environment. It is also a function of participants in the environment and a complex psychographic intertwining of the participants. Social networking is a great example. Corporates intranets have matured to varying degrees from being a storehouse of company policies to platforms of information dissemination. Some intranets, especially those from multinational, multi-disciplinary firms, are warming up to the fact that the workplace is after all a social environment with its own needs making effective connections. At this point, the trapdoor of Facebook-meets-corporate-intranet opens up, little realizing that the environments and participant psychology in the two situations are vastly different. And hence the need to cater to different environment driven networking demands.
I have witnessed this while building capital markets related products. Given the democratization of these markets, it is very likely that a Product Manager, Engineer, Tester – all – have particpated in it in some form or fashion. The choices they make during product development is often clouded with their own behavior. The fact that retail participation in capital market follows an entirely different workflow compared to institutional investing is overlooked.
Managing overlapping environments is an interesting challenge because it is not axiomatic that what I have mentioned above must always hold good. Take for example the building a professional software developer Q&A community (must watch – Joel Spolsky talking at Google about Stackoverflow). It is best that software developers just meditate over their own professional trouble-shooting pain points and build a system that effectively addresses them. Sadly, such examples are fewer and far between. And the challenge remains to carefully understand the users along with the environment they would be working in. Investigating in isolation either of the two will most likely result in this
It has been a while that I promised to write about Product Training. I was interacting with the Client Training group in my company when I remembered the promise and also realized how the current model is broken.
The trouble exists both at the supply end of the chain and at the demand end. Let’s see. Like not too many poeple graduate wanting to become teachers, getting talented people to join client training is difficult. In most organizations Client Training is considered a cost center, which means it is pernnially under pressure to keep costs low. Consequently one trainer has to develop multi-product (or multi-module) skills. Now this thing works fine in primary school (geography teacher also teaches history) but in the professional world is a disaster. Training the trainers is mostly inadequate with the product teams’ unrelenting focus on shipping the product and then getting busy for either the next round or the sexy stuff like wine-and-cheese launch parties.
On the demand side – at least in India – user attrition is a big problem. Teams of users leave and a new set comes in. The new set has experience of using Product B so now the company that sells Product A needs to come in and retrain. The problem exacerbates if the industry has many products catering to roughly the same user group.
Some organizations outsource training arguing the not-our-core-skill theory. The decision is fine as a standalone but when you look at the intricate interconnections between Product Management, Product Marketing, Market Intel and Training a big chunk of the intercdependant relevance goes away with the outsourcing. Some companies do a smart thing by imposing switching costs for their products in the form of user certifications. Unfortunately the execution of this strategy also ends up suffering from the same supply side problems I mentioned earlier.
Consider keeping training departments of product centric firms close to Product Management. Over a period of time, all training that has to do with historical and existing functionality should be moved from physical contact to digital delivery. Once that happens, the training module can actually be placed within the product and perhaps at a cost (That F1-for-help thing is actually training too, in some form). Alternatively, there are many different ways to deliver digital content to the user fraternity (yes, an i-phone version is downright innovative and outright sexy). At the end of the day the idea is simple – improve the content of the training and move away from traditional physical contact method of delivery.
Got other ideas? Let’s hear them.