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
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.
Be nimble, start small, get traction, generate revenues, (then profits), IPO, face analyst stares, get sold to Banker’s non-organic growth pitch, acquire companies, bloat, lose nimbleness. There are only a handful – if not a fingerful – of companies that can force themselves out of this vicious circle of life for start-up companies. Acquisitions happen.
And once they do, the pressure to integrate acquired product assets with the core offering becomes of paramount importance (after all, synergy was why the acquisition was made, right?). There are two approaches to integration that I have seen corporation take. First option – integrate the front ends of the two system. That is, figure out the common platform and slap screens (all or select) of the other into it. The back-end infrastructure and databases that feed the two systems can stay different or perhaps just loosely coupled. Second option – create a cleaner integration of the back-end systems and infrastructure that ensures cleaner plumbing. The front-ends can stay separate and will come together when their feeding systems have gotten sorted out.
Both these options are acceptable but if someone stuck a gun to my head I’ll choose the first option. Here’s why
- Customers want to see benefit from the acquisition, and they should see it in the front end of the product. Customers want to experience the acquisition, touch it, feel it. They deserve it too.
- Back-end plumbing is a relatively easier problem to solve. One can throw people at the problem – perhaps at low-cost-centers or outsource to maintenance vendors. And once the front ends have been integrated, the pressure from business to clean up the rear (no puns, please) will ensure quicker compliance (especially if data center problems are breaking the front ends)
- The front ends coming together opens up possibilities for users to leverage the combined offering and in doing that they will figure out interesting ways of extracting synergies that the Bankers who came to make the acquisition pitch never figured out. That’s what every product manager lives for.
There is one large, hairy matter that can definitely break this choice. Usability. At no cost should user experience be compromised when screens are mashed together at the front end. It is undeniable that there will be changes in navigation, but that should never compromise on ease of use or continuity of functionality. Gopal Shenoy, who writes a popular blog on Product Management, has an interesting example to cite.
Technorati Tags: Product Integration, Front end components, back end databases, Usability, Product Acquisition