Thanks Google

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

 

Lipstick on a Pig

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

The Seven Thens

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”?

“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

Don’t ignore the User’s environment

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

The broken world of end-user training

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.

Yours visually

Wireframing a product or enhancements is a great way of validating customer propositions. Given the choice, customers and prospects will any day choose an html prototype over powerpoint hyperbole. Thus it is sad that html prototyping remains suboptimally utilized in the product development cycle – overused at the begining and consigned to the trash bin before it has yielded all it could.

I am no genius figuring out why a touch-and-feel prototype is more effective than paperware. The commercial/sales guys figured it out much earlier. The zeal to sell (or to just awe the audience) leads down the slippery slope of over-jazzed visual prototypes getting in front of customers. Overpromise. When the rubber hits the asphalt things start falling away. Engineering cannot deliver to the wireframe in the committed time or without overhauling the architecture. Underdeliver. A tool to elicit, refine and enhance requirements has been relegated to a cheap selling trick.

Html wireframes are much derided within the engineering fraternity as mickey-mouse. The prototype quickly dies off and after a while no one even as much remembers where the code is. What a waste. With some thought, practice and process, it is possible to extend the wireframe into the development stage as a bona fide artifact. Preserving the spirit, content and visual signature of a wireframe right throughout the development cycle is more guaranteed with this extension. Product Managers and Usability folks should retain some oversight into the engineering process to ensure minimum deviation from original state.

On the side try this. Ask Usability or engineering to give you a flash version of the wireframe. Put that on the thumbdrives of every salesperson in your organization. Trust me, leaving a “live” version of the product with a prospect is times better than leaving dead-tree version collaterals. The sales folks will love you. The flash and html versions will come in very handy when you are running subsequent marketing campaigns and want your prospects to see and play with the product over the web before they sign up for a trial.

Wireframes are not use and throw. Rather used as flow and grow they can return a staggering return on investment for the product in question.

Update: Seth Godin has a brilliant post on measuring ROI on design. No, he doesn’t give you the spreadsheet you are looking for. On the other hand, he leaves you with enough food for your gray cells. Quintessentially Seth.

Start from the Finish

A fair amount of software products – I would dare say about 70% – have front ends (or User Interface, UI, if you will). Narrow that list to application products and the proportion possibly goes up to about one hundred percent. The final output of the product development process is also a great artifact to start off the initiative. Here is how it moves

The above diagram should be self-explanatory. If your product relies on a visual impact and superior usability as core differentiators then please do not leave that job to your developers. Visual Engineers and Usability teams usually create two important artifacts – a visual representation (from 2) and a fully or quasi-clickable html mock-up (from 4). Do not throw these away. Use the HTML mock up to create an early adapter program (pre-alpha) for your product and create a feedback loop back into the Usability team. Show the clickable model to senior sales folks to excite them about what is coming up as a salable product down the road. Plug the Photoshop based static output into presentation and other non-interactive product collaterals.

Start with the finished product. It is a fantastic place to begin.

The Redesign Conundrum

Microsoft is launching a new product called Web Office. It liberates the user from being slaved to his desktop for using MS’ blockbuster productivity suite – the one and only MS Office. Microsoft hasn’t yet designed the user interface for the web version and is inviting suggestions for it. How wouold you go about designing for this challenge (you perhaps know that MS is not planning any such thing, but just stay with me on this hypothesis for a while)?

Option A

Design the interface exactly replicating the rich client (the one you install in your PC/Mac and fire up whenever you need to use). Look, the dude using the web version of Excel will be really pissed off if it required him to learn new tricks to do the same stuff that he does in the desktop version, right? Right. So if you are looking to extend the accessibility of a rich client product by developing a web equivalent, stick with the same design. Phew, that was easy.

Option B

Take the opportunity and create a different interface. Does this option even hold water after everyone voted aye for Option A? It actually does, but perhaps not in the example I thought up. The opportunity to redesign an existing application for its web existence may be taken when the customer segments for the web and rich client application are different. Take for example an accounting software that caters to large enterprises (very close to being an ERP system). Its complexity, need for scale, security et al precludes the possibility of putting it up on the web. However, the same vendor may choose to offer a scaled down version of the product for the small-and-medium-enterprise sub-segment (perhaps on a SaaS model) and hence develop a thin equivalent. Non overlapping segments – freedom to redesign.

What do you think?

Technorati Tags: web products, designing products, web product design

Workflow. Optimization v Cannibalization

Workflow based products strive their best to help users complete the workflow. Embedded in this rather simplistic statement is the basic premise of selecting the user interaction, functionality and features of the workflow product, which can be as much a device as an application. For example,

Microsoft Word features the functionality to complete the workflow of sending out the document as e-mail without having to exit the application and fire up the e-mail client.

Take a closer look at business handheld-telephone devices. Almost all (I am chained – literally – to the Blackberry) provide functionality of saving received-call numbers, making notes during a call, checking e-mail archives and such other workflow completion features within the device. For a product manager to design the application with the intention to close the workflow loop, she must understand what the workflow is. And more importantly, what part of the upstream and downstream workflow does the application (or device) support.

This is where I cannot understand digital cameras – more specifically why mobile telephones are trying to become cameras, thereby tying users down to telecom service providers. It is possible today to take a picture using a mobile telephone and e-mail/MMS that using pipes provided by the telecom company. The charges for doing this is exorbitant because the pipes are optimize for voice, not so much for data. Also, it stumps me why users would repeatedly perform such battery gulping acts on their phones, leaving them vulnerable to a situation where a drained battery stares down when an SOS call must be made.

Digital cameras, on the other hand, suffer from the stark absence of workflow completion. We all take pictures and then transfer them to our PC/Mac using a cable and then e-mail them to friend and family or upload them to online albums. This begs the question – why does the phone attempt to complete a resource draining operation that I am not even sure is the workflow while the camera doesn’t. Building Wi-Fi capabilities in the camera would not only allow as-it-happens photo sharing at a cheaper price but will also pave the way for better photo journalism. No – I am not asking digital cameras to become PDAs.

Workflow optimization and workflow cannibalization is very thin line and it is important for Product Managers to understand both.

Technorati Tags: Workflow, Close Loop, Workflow Optimization, Digital Camera, Mobile Phone, Wi-Fi