You don’t need control

If you create an environment where people truly participate, you don’t need control

Respect people for who they are!

Respect people for who they are!

- Herb Kelleher, Co-founder & CEO, Southwest Airlines

They know what needs to be done and they do it. The more people devote themselves to your cause on a voluntary basis, the fewer hierarchies and control mechanisms you need.

Years ago, business gurus used to apply the business school conundrum to me: “Who comes first? Your shareholders, your employees, or your customers?” I said, “Well, that’s easy,” but my response was heresy at that time. I said employees come first and if employees are treated right, they treat the outside world right, the outside world uses the company’s product again, and that makes the shareholders happy. That really is the way that it works and it’s not a conundrum at all.

New homepage for Colleagues.io

Graphics Designing for a programmer is probably a toughest task. The lovely part of being a startup founder is you get to do everything.

 

The new face of Colleagues.io

The new face of Colleagues.io

There were many iterations before we reached the final version. The first one with which we made the product idea announcement had few basic flaws.

Old Colleagues.io Homepage

Old Colleagues.io Homepage

Pictures. Reading is still not a natural process for us – most of us; it is commonly unpleasant. We want a picture or two to which we can relate words to. But the hardest part that I personally find in a visual design is placing the right picture in it – finding that one perfect picture takes hours, in this case weeks. Dylan – the cute kid (Source: http://www.flickr.com/photos/way2go/3506463585) came to our help. I was looking for a picture that would nicely portray the thought “Your people will love the job, if you let them work at their core strengths”. It was extraordinarily hard.

We did another mistake of not including any snapshots from the actual application; leaving our readers to read a lot of text to understand what we were up to. Hopefully, that’s fixed now.

Focus. We had listed all our tools – one that’s in production (Interviews) and all the future upcoming tools (Expenses, Inductions, Pre-screening, Polls) – in a straight list. Worse, the platform add-ons (Employee DB and Beautiful Profiles) were mixed with it. Many seemed confused about what Colleagues exactly was with Interviews Process Management (productivity) and Beautiful Profiles (fun) together, and how they relate to work culture. Now, the total focus is on “Interviews” – the tool that’s up and running.

Sales. The primary or probably the only purpose of a product website homepage is to sell the idea – it is a marketing tool; face for your business. You need to show something on this page that people want to buy. They wouldn’t have time and interest to look through all the details about your product that you think are cool. Instead they would glance through for a quicker explanation of what exactly this is all about and how it can help their business save money and/or time. If they find any clue that indicates so, they would ponder a little more to find out details and compare their options before finally buying it.

Clear Messages. The words used on a homepage need to crisp, clear and precise. Punch line, hyperlink titles, image captions, section headers, bold text – they all need to deliver without creating any slightest confusion. I believe, we still need to improve on this part; and we’re open to changes.

The right Color Palette. Its difficult to come up with the right color combination for the site design and even more challenging to fit your content into those colors. Our old design had ‘shouting’ colors, we knew we had to make it smooth. And a lot depended on the hero picture that we were going to select. Since we are just starting up, freedom of choice and change is fortunate and enjoyable. We believe the current color selection gives a lot of opportunity to the content to shine and is also light on the audience eyes. Hopefully, we will stick with it for sometime.

Price tag. There is a lot of conflicting advice available on this aspect – whether to put it on the homepage or dedicate a separate page. It might actually depend on the kind of product or service and also the kind of potential customers your business has. Personally, I don’t like to intentionally hide the price – whatever the product be; it just need not be at a mean place. Although, a small problem with putting the pricing on homepage is linking to this section from other parts of the website or external pages. You do not want to add any distractions when a customer is about to press that ‘Subscribe’ button. So we took a mixed approach; the pricing plans are listed on the homepage and for the links we also have a dedicated page.

Pull in. Once the visitor likes the idea and is convinced about its usefulness, the next critical job for the homepage is to send them in – Pricing, More details about the product, Sign-up – these links should be able to grab them by hand and bring them in.

I think the new homepage would do a much better job than the old one. The figures will speak for themselves.

Introducing Collèagues.io

Following up with the last post ‘The culture matters as much as the product‘, today, we have completed basic working prototype for our product “Collèagues.io“. The public Beta will be out in next two to three weeks. Here is a sneak peek.

All the people

List of Everyone in the company with a Team filter. [Update: we've just added a "search by name" on this view]

Collèagues is a culture building platform for small companies offering a series of simple-to-use, no-nonsense productivity tools. The first problem small companies have is lack of a one-place robust employee database. Robust, in the sense, it should also be able to port to external systems easily. With Collèagues, you can import a CSV containing all the employee records or just enter employees one-by-one. The best part is, along with a conventional set of record fields, the account administrator can always configure the employee record according to the organizational needs. E-mail remains as the only required field. The second problem Collèagues tries to solve is at the heart of the culture of a company – knowing everyone closely in their own words – Beautiful Profiles.

Beautiful Profile

Beautiful Profile

For simplicity, all organizational groups are called ‘Teams’ on Collèagues. UI Team, Engineering, Human Resources, Management, Project X, Drama Group, Football Team – everything is a team. Obviously groups can be overlapping. A team may or may not have a manager.

Teams

Teams

Organize Teams

Organize Teams – Drag-Drop members

The tool provides a drag-and-drop interface to organize people into teams. When you are done organizing people into teams we create beautiful visualizations from that data.

Circular Org Chart

Circular Org Chart

Horizontal Org Chart

Horizontal Org Chart

With very few clicks and some data entry you can very quickly setup your employee database. We create a base set of template for profiles and allow you to get started quickly. But all of this is easily customizable. From the administration section you can change the default configurations and information about the organization like Name, Org Logo, Fields in the employee record, bulk upload employee records or add them one by one, teams and one-to-one reporting structure.

Fields in the Employee Record

Fields in the Employee Record

The focus is to allow as much customization as possible at the same time already providing a lot of standard conventions. This can get the companies started in no time.

Interviews

The very first productivity tool that we are providing on Collèagues is “Interviews” – the first cultural impression for company’s future employees. Many companies spend enormous amount of money and manpower on tracking candidates and storing resumes which is absolutely of no value. The primary aim of this tool is to bring transparency and efficiency to the interview process. This tool steps-in when the first round for a vacancy is about to get scheduled and disappears when the vacancy is closed. It brings both the candidate as well as the panel members to same page. It allows the candidate to know about the interview panel members, topics of discussion, possible duration – everything well before the interview, to avoid any surprises or typical delays. Not only that, it allows the company to share panel remarks with the candidate after a round and also let candidates share their feedback. Imagine the candidates taking away such an open culture experience with them.

Interviews - Everything important at one glance

Bring the panel and candidate closer to keep them well informed

The simplicity of this tool is beyond normal experience; everything that matters about your organization’s current openings is on one single page. Every addition and change to the round or panel is e-mailed to the candidate and panel members. It tries to cover that part of the recruitment process which has the highest pain for potential employees and exhibit a glimpse of internal culture. If you are a small company, Collèagues can help you convince those candidates that you really care about your people and you’re what you say you’re – transparent, efficient, and productive.

Add a roundEverything on one page

Future

Our upcoming modules are polls (Questions and Answers), expense filing, pre-screening and the most important one – induction programs (know your company). We are using these tools at Usable Bytes and believe, culture is everything that a small team can offer to its people. The tools and processes a company adopts is a major part of its culture. Instead of making people work for processes, enable processes to work for your people. Allow everyone to focus on their core responsibilities by keeping the processes optimal and employing the most productive tools that everyone would love.

Basically, this platform is for small companies, who care for nothing but just simplicity and wish to stay focused on their product development.

Good things cannot be sold; they can only be bought

A professional friend asked me to summarize my efforts in promoting UCD (User Centered Design) at my last work place, before I decided to stop convincing people and do it on my own.

UCD is pure common-sense. A solution built without understanding the user “needs” is scrap. The words ‘User and Needs’ are replaced with ‘Customers and Requirements’ without hesitation in almost all companies. This problem sits at the root of series of other issues that follow during a typical product development. Users and customers for many, if not all, enterprise applications are different. Similarly, needs and requirements. The second difference is even more disastrous if not understood properly by the development team, especially the seniors.

User needs

Users vs Customers

When both the terms are in-front of your eyes, any explanation would look unnecessary or rather stupid. But practically, customers overshadow users for many development teams – knowingly, unknowingly. In some cases, the team may not know the difference and would always focus on customers. The solution to this problem can begin with a simple presentation covering the very product case that the team is working on and go on highlighting the UCD approaches. But the second type of problem, where the ignorance is deliberate, is tough or rather impossible.

Being a ‘customer centric company’ is much easier than being a ‘user centric company’. And many parts of your organization would actually enjoy the focus on customers because it shows off immediately. Sales figures being the most prominent evidence. And then, the ignorance about users is taken for granted – forever. This is the ultimate threat to any UCD promoter.

Needs vs Requirements

This one is the trickiest. Most of the development instructions received are requirements – actually, almost all. The worse, they are covered under the mask ‘Need’. Need drag-and-drop facility for selecting line items, need iPad support, need an option to select multiple regions, need category filter, need pagination, need tree-view, need inline editing. If you ask the customers what they want – you will get a set of requirements. If you observe and truly understand their problems – you will get the needs. This is the key. By asking the customers you are actually multiplying the problems. First, asking results in requirements and then, getting it from customers give you no hint of real issues faced by the actual users.

If you have both pair of problems, let me kiss you on the forehead because you’re the blessed one! Not that these are the only spoilers, there is a long list – organizational hierarchies (the mother of all), graphics and interface designers putting trends and innovation over problem solving, product managers’ inadequate understanding of terms – usability and user experience, recruitment focus on academics and number of years instead of candidate’s able experience and thinking process, management’s hunger for more processes and tracking tools instead of pure productivity, business growth defined in terms of number of employees and turnover rather than customer-base and profitability, senior product engineers more concerned about release deadlines than the respect for development standards, sales people pressure on building competitor-like features rather than adding value to the product, looking at staff as liabilities than assets. All these issues can at least partially be converted into advantages with the right blend of balance in the approach; they all are not inherently bad, may be except the last one.

User Centered Design

During my final struggle, that vaguely went on for 8 to 10 months, as an employee, I tried to take on various initiatives to bring in UCD practices.

  • First, taking my founder and then immediate manager our for lunch – to sell the good things. The ROI on UCD. Industry examples. Highlighting the missing pieces and lack of direction at various places in the overall workflow. That would save me any raised eyebrows over my next steps.
  • Requesting management to (1) establish Customer-Developer Links and (2) provide access to active users for UX practitioners – so that these channels can mainly be utilized during the pre-development/design analysis stage.
  • Drafting a step-by-step approach of combining UCD with the current development life-cycle (Agile + UCD).
  • Listing the error evidences from past and the direct revenue impact. Also highlighting that the in-house support staff aren’t actually the end-users; they are just representatives. The design feedback during all development stages should be collected from the actual end-users.
  • Categorizing the application users into three primary categories – customers, end-users (customer staff) and in-house support staff. Explaining why there should be separate interface versions for each.
  • This liaison with management also included discussions with top technical leaders. How bringing in users and involving them first hand during the initial stages of product development will save us huge rework, frustration, loss of motivation and disbelief among people.
  • Getting friendly with the UX team.
  • Initiating knowledge sharing discussions among the key decision making stakeholders.
  • Creating activity groups to promote good UX practices and whenever possible, bringing in few.
  • Grabbing a pilot project to implement UCD.
  • Talking to engineering leads to give development standards higher priority over deadlines. I believe, a product is an output of efforts from various teams with conflicting interests. A refined product can only result when every team has pulled its interest string with full force. Balancing actSales and marketing will work on customer satisfaction. Innovation from Designers. Problem solving from architects. Engineers on product quality and durability. Product managers on solving real problems for end users. Managers on empowering the people with knowledge and authority (rather than perks and facilities). Organization visionaries pushing builds that won’t change over long period of time and demoting the rest. You can imagine what would happen when your architects buy the motto of your sales team.

When you talk to the audience coming out of a cinema hall, everyone’s takeaway is different. Why does that happen? The truth is, people hear what they want to hear and not what they are being told. The looks of a person, the brilliance of an actor, the talent of a director, the special effects, music, singing, story writing, action – almost everything has got an Oscar waiting. They are important. But what about the most important of it all – message from the story?

A company is driven by a vision. If the visionaries realize the importance of UCD and are all in for it, you’ve got some bright chances that your organization may eventually start studying end-users closely. Otherwise, no matter how hard you try, it’s not going to work. It is unfortunate for any organization to expect an employee to convince the visionaries of the right approach; it should be the other way round. Not that one should not try. The efforts are equivalent to giving a new vision to the company. The hardship involved in this brings out a real character and teaches you many good lessons. For that, the try is well worth.

The answer to the whole equation is hidden in a simple fact. If products originate out of the owner’s own pain, the whole business would focus on solving the customer’s problems. And users will automatically be sitting at the center of it. But when companies are setup for higher annual turnover and number of sales, that’s precisely what they will aim for, that’s how everybody’s achievements will be quantified against. And that’s also my advice to you – to all the UCD promoters – the first thing you should do is to check what your visionaries stand for.

Culture matters as much as the product

Every one of us love working with a team where we feel involved, we get to learn great things, our opinions matter, there is authority and freedom of execution, we have fair chance to choose, our passions are cared for, burdens of hierarchies and processes are avoided, we could see where and how our contributions are directly impacting, where all team members understand which exact problem are we trying to solve for the customer and the business decisions are openly shared. These practices lead to belonging, trust and ownership.

Most companies who claim to be flat, are not. There is always a CEO, VP, Sr Manager, Manager and Team Lead. Hierarchy isn’t a bad thing if people have authority to do the right thing for their teams. So, doesn’t it make sense to publish the org-chart rather than claiming to be flat? Let employees decide whether the organization is hierarchical, flat or somewhere between.

This world is full of irrationals. The larger-than-life approach devised and exploited by the advertising world has completely taken us blindfolded into an illusion where happiness is money, success is being bigger and larger, education is academics, sales is revenue, marketing is advertising, care is facility; and richness is a huge list of features. These illusions have knowingly or unknowingly, but smartly, paralyzed our thinking process and decision making, thereby. It becomes very hard to take a rational approach.

Fortunately, it is simple to understand that – no matter how great of a product your company is trying to make, if the people working on building the product doesn’t feel it, no worthy mission can be accomplished. Building a company culture to make this happen is about building a team of people who are committed to the same ideals, purpose and passion. An amazing company is nothing but the amazing people it has; product is merely an outcome.

How can this be done? Every team, small or big, it needs a way to function; a workflow framework that all members would follow; a process. If the company’s processes and tools use some rational foundations, focus on getting things done in the simplest manner, promote productivity and transparency, then definitely a great culture can take shape.

As a company, share your story with your people – the beginning, key idea, founders, struggle, first customers, growth, important people, core values, existing teams, office campus, employee benefits, facilities, tools and processes, products/services and vision. Let these stories be available to them all the time; whenever they want to check upon. Make your people understand the business domain thoroughly. Make them feel the problems your customers are facing. Show them how you believe in helping your customers, partnering with them rather than selling stuff to them. Promote participation from everyone in business decisions. Help them understand how their growth will lead to team’s growth. Demonstrate that you put authority where information is. Celebrate hard. Give and promote ownership. Make the workplace a platform of learning and growth opportunities. Setup processes and bring in tools that help them focus on their core area. Show them a genuine care and they will care for you, your product – because it would become their product.

Culture can go beyond employees. The word quickly spreads outside. People discuss on Twitter, Facebook, Quora. Potential candidates check Glassdoor reviews before accepting the offer or even worse to decide whether to attend the interview or not!

Exhibit a touch of your culture to these interview candidates; share interview feedback with them and also ask for theirs; be transparent; inform them about panel members beforehand and the topics for discussion. There are so many simple things that you can do to achieve highest possible productivity and offer a great place for your people to work at.

Culture is all, a great company offers to its people.

Why am I doing this?

There are two primary problems that pulled me towards entrepreneurship

  1. I worked with various organizations during last one and half decade in the Software Industry and got to learn a lot. But there was no company that I could truly wish to continue working for long.
  2. Software engineering, especially the User Interface Engineering for Enterprise Web Applications is my passion. And I see a lot of pain and lack of common-sense even with the most popular productivity tools.

Not that I wish to fix everything, but I believe in my own ideas to solve these problems in much simpler ways and I want that freedom of execution. It was hard to convince companies whom I worked for of these straight and effective approaches as I found their minds covered with a lot of fallacies that practically doesn’t make any sense at all.

I’m into this for my own freedom and would feel fortunate if could help others enjoy their work on my way.

Setup Postgresql 9.3 on Ubuntu 13.04

Running “apt-get install postgresql” installs 9.1. But we use json datatype which was introduced in 9.2. Instructions found at http://www.postgresql.org/download/linux/ubuntu/ seem incomplete. Specifically, we can’t have this line:

deb http://apt.postgresql.org/pub/repos/apt/ 13.04-pgdg main

on /etc/apt/sources.list.d/pgdg.list file. That fails saying it can’t find packages. Instead if you have this line on the same file:

deb http://apt.postgresql.org/pub/repos/apt/ wheezy-pgdg main 9.3

and then run the following commands:

wget –quiet -O – https://www.postgresql.org/media/keys/ACCC4CF8.asc | \
sudo apt-key add -
sudo apt-get update
apt-get install postgresql-9.3

it works just fine and installs 9.3 successfully.

Website or web application

When a user enters some domain name in browser, there are two things likely to happen. First, he may read and navigate to some content in the form of html pages and in second case, he may interact with the pages like comment or like some post, login to bank account and do some online transaction, etc. In modern terminology, former is called as website and later as web application.

There is a great difference between the two. Websites are there almost from the beginning of Internet. There were meant to consume content by people in the form static documents that are connected by hyperlinks. But, as technology evolved so are the ways of consuming content by people. Websites became more and more interactive leading to what we call today as web applications. In terms of technology, a typical website is nothing but a bunch of HTML, CSS and probably little bit of JavaScript coupled with content. No database is required as such. Generally, websites are static in the sense that they are not updated often.

However, web applications are a whole different beast. Initially, they used to behave like traditional websites but, with the evolution of Ajax, behavior and user experience of web applications changed forever and perhaps for better. Web applications are dynamic and ever changing. These applications expect heavy user intervention (interaction by user) for their functioning. They use programming language like PHP, Ruby, etc. at backend along with some sort of database for persistent storage.

In real world, typical company or organization’s main site which is relatively static and build for branding and marketing purpose can be considered as website. Whereas, applications like Gmail, SkyDrive are pure web applications. But then, there are sites like amazon.com or news portals like cnn.com which serve content similar to traditional website but also allow interactive features similar to that of web application. To make boundaries as distinct as possible, these sites fall under third category of hybrid apps (website + web app).

Users and audience

Websites and web apps have rather different motivations behind them. In context of web site, audience is more apt description for the guest visiting the website. Since, website is often seeking the attention of its guest. In an infinite network of Internet, there is always 100% probability that content for which the guest is looking for will be available on some other website too. In such scenario, if website cannot entertain its guest, guest is likely to move out somewhere else. This is similar to hoteling business where if the guest does not like the hotel, he is very much likely to seek another one. What marketing is to hotel business is what SEO (Search Engine Optimization) to website is. Along with that, to woo its audience, website needs better web design, simplified information architecture, better content, brand management, etc.

On the other hand, for web application, user is much better description for its so called consumers. This fundamental thought drives web application with very different requirements than that of websites. SEO, web design may not be the very high priority for web application. The user base will be limited and can be stereotyped to a better approximation. Web applications usually have very specific purpose. It involves business processes and workflows which are often very complex and streamlined. Unlike website, web application does not really scream for attention of the user. It is the user who needs to use the app to get his task done. (* This may not be the case always. If user does not like Gmail, for example, he can always go to another vendor. A good user experience is still a high priority). The user does not necessarily demand SEO or killer visuals but he will wish for high security, data integrity, regular updates, etc.

Of course, there are few requirements that are fundamental to web in general and not just any specific application range. Such requirements include good usability and user experience, high performance and ability to consume content on multiple devices.

Nature of web application and development methodology

This is where probably comes the real big difference between web sites and web applications. Rather than focusing on both websites and web applications in general, we will go in depth with web apps. Today’s complex web applications are often developed by team of people in some IT organization be it small startup or established player. It is simply not possible for a person or two to develop entire web app within a stipulated time especially when everything now a days have strict deadlines for obvious competitive reasons.

Further there are few realities about people, business and software development. People, almost for self-interested reasons, move out of organization. Vacant positions have to be substituted for by new resources. For business, requirements change almost on weekly basis and software has no other way but to cater to those ever changing requirements. For software development, there are few realities too.

If not properly managed, the application code can really get cluttered as time passes. After a while, making new requirement change adds to exponential increase in complexity (most dangerous hidden cost of unmanaged code). If not properly documented, new people often face difficulties in understanding the framework wasting precious time. If design patterns are not followed, the code can get become difficult to read. If code is made too generic to accommodate any future change, the code can get pretty messy and performance may suffer for huge flexibility. And, if not accommodated for any future change, the code may provide performance but at the cost of inflexible code and overall bloated solution leading to security issues.

Beside these, the code has to be reusable to adhere to DRY (Do not repeat yourself) to avoid time on reworks. The code also needs to follow centralized control or single source of truth principle (Meaning, change at one place should be propagated throughout the application source without any possible feedback).

If not least, then application lifecycle is probably another factor needs to be taken into consideration while developing web application. Code needs to be designed in such a way that it should work through complete lifecycle of application (be it five years or ten years; and typical web application usually have very long lifecycle) without much rework. Technology consideration should also be kept in mind. Along the lifecycle, new technology stacks often arise on the surface. For example, when Facebook had started in 2003-05, there was no HTML5 or mobile content consumption as such but today, Facebook needs to accommodate these new technologies or they will have to suffer the consequence of Darwinian survival of the fittest theory.

So next time before you kick start any project, go to level zero and ask yourself what you really need viz. website or web app. If you get it right, then you are less likely to make mistakes while selecting a framework or appropriate team.

Usability and Usefulness

While reading Rex Hartson in The UX Book, the two terms that always sounded and meant identical started taking separate shapes. Usability, although a bigger circle encompassing Usefulness, seemed incomplete without the later. But understanding the terms in depth made the difference clear.

To separate the two things, consider the example of farmer. For a farmer, something like a weather application is of vital importance. So he downloads the application on his mobile phone. But, when the farmer starts the application, he gets the weather report for a foreign country. There goes the usefulness of the application. Since he cannot get local weather report, the app is not useful at all for that farmer. This is usefulness or business value of the product to its user. In economics, this usefulness is also called as utility of a good.

Further, let’s assume that the weather app gives local report for that farmer and thus it is useful to him. But, the report is in English language which the farmer does not understand. And, there is no option to change the language either. Or let’s say he understands the English, but the report provided by app is too scientific to understand for a farmer. Though useful, he cannot use it. This is known as usability of a product. What is going to be the end result? If there is another alternative or app, the farmer is likely to switch to that one. And in real life, there are always alternatives.

Now, consider the same context for a technology professional. For him, the weather app may not be useful at all. No matter how easy the app is to use (usable), since there is little or no business value or usefulness for him, he is not going to download it at all.

This simple difference has lots of implications on business and consumers. Organization often fails to understand this distinction and ends up with wrong product team. The job of a UX Designer is to make usable products while the job of a product manager is to make useful products. But, organizations tend to assume two things are same and merge these separate roles into one. It is not that a UX Designer does not understand the market forces or that a Product Manager does not understand product usability, it is just that these two are roles with unique specialties.

In reality, sometimes, there are budget considerations. For a small application, it would be reasonable if these two roles are merged. But, in such case you need a more generalist talent that specialist one. By generalist it means that you hire a talent that is comfortable in doing their non-specialty activities. However, for big application, it should be strict no-no.

During our trainings’, we often get this question that if we are hiring a UX Designer for our product, then he should also be able to determine usability of our product. This is again where it goes wrong. To clarify we should understand usability as a scientific measurement. The well-known fundamental elements of usability are:

  1. Learnability
  2. Ease of use
  3. Efficiency
  4. Memorability
  5. Satisfaction.

To put it in layman words, Usability can be looked at as a measuring unit for how genuinely a product does what it claims. A UX Designer will try to build usable products but he may not be the best person to check if he has indeed built a usable product or not. If you ask a UX Designer to do the usability testing, too, that’s like a student rating himself for his own test. Or, it is like saying that if a company is building and selling scientific calculator, then everybody in that company is a mathematician. The analogy is clearly absurd, isn’t it?

Coming back to original question, who should measure the usability of a product? Well, the answer is Usability Engineer or Analyst who can actually measure the usability against the five fundamental tenets of usability and pinpoint exact area of problem if any. The rational theory behind this existed long back. The traces can be found in all time classic like “Design of Everyday Things” by Don Norman. But it is now catching up fast as full-fledged profession as organizations have realized its importance. Earlier, computer technology solutions were platform based. But now they are becoming more and more product based. Consumer driven economy has started. Consumer do not pay much attention to the OS or platform they have in their devices. They are concerned about the vast number of products and applications that are available on that platform. If consumers do not like certain option, they have alternatives that are accessible on a touch of finger. So, why would they not like a certain product? Is it because the product was not usable?

Having talked about usability, it is time to talk about usefulness or business need of the product. When you think of a product, there is one fundamental question. Why are you building that product? This answer leads to two paths. First path is where there is already a need in the market for the product. For example, consider net-banking needs by consumers where they can do banking transaction from internet without visiting a bank. Bank X launches net-banking facility for its customers, then it almost becomes necessary for bank Y to do the same if it does not want its customers to abandon them and join bank X. So, here the need exists and bank is simply addressing the need.

The second path is more interesting, challenging and probably little risky. There is no need in the market but you understand that such need will arise in future. Then it is job of that organization to create such need and complete ecosystem to support it.

When Henry Ford created first car without horses he said, “If I’d asked people what they wanted, they would have asked for a better horse”. There was no need by consumers for car without horses but Ford envisioned it and seized the moment. He had walked that extra mile with that. The product was no doubt usable but Ford also made sure to convince consumers for its need and usefulness. In modern times, consider that example of tablets. Everyone knows that first tablets were introduced by Apple. But history says otherwise. It was Microsoft ten years ago before first iPad that gave world its first working tablet. But, nobody noticed it to even remember it now. There were many reason for the failure like too early to market, lack of ecosystem, immature technology, poor marketing, etc. But these reasons are just reflection of one bigger inherent fundamental problem – “Failure to create a business need”. This is what happens when you do not pay attention to business need of the product.

In the end, if we try to plot usefulness and usability together, we get following product:

Usefulness Usability Probable outcome
High High The product is perfect. Users will not leave the product easily. The product allows users to do things most efficiently.
High Low As long as users do not have alternative, they will use the product. But just one competitor, the product is dead.
Low High Even if a product is diamond studded, nobody is likely to buy it.
Low Low Help me understand the difference between product and a garbage.

In the conclusion, the product is useful if user has need for it. The product is usable if the product fulfills that need in a most efficient manner.