Posts Tagged ‘Featuritis’

Keep it simple, smarty!

Saturday, September 3rd, 2011

People often ask me what I think, are the most important factors that contribute to the success of a product. My answer varies depending on the nature of the product, the person asking the question and my mood in that moment, to name a few. But interestingly, if we draw up a list of the responses to this question, the two items that top my list are simplicity and consistency. Yes, there is no doubt that these two aspects of user experience help to a largest extent in making any product, a huge hit. In this post,  I will cover the first one, ‘simplicity’ and how we can leverage this powerful yet ‘simple’ usability mantra to turn your products and applications into a success.

Simplicity sells

Yes, simplicity does sell and sells, all by itself. Its perhaps the biggest value proposition in your product. In any industry and any geographic market whatsoever, you have hundreds and thousands of products and variants. There is a huge margin of difference between the leading few and the following majority. Often this boils down to one super differentiating factor and that is simplicity. It works wonders not just before sales, but also after the sale is done during the usage by end-users. This positive experience during the product usage prompts more usage, referrals and increased sales, overall.

A case in point is the search industry in the 1990s. Most of the web sites and applications at that time, including the then search leaders like Altavista and MSN had their web pages all cluttered with too much content. Google then understood that the only way to make users happy was by uncluttering and uncomplicating their search experience. They did this by keeping it really simple, with the entire page being occupied by a text box and a button. Need I say more about the success of Google search and how this powerful execution of minimalist design made Google the giant that it is today, not just in search but in software, mobile and many more product areas.

Less is More

In the words of the great architect, Ludwig Van Der Rohe, “Less is More”  has been a watchword for the architects, designers and stylists. A pithy motto which says it all and stands by its meaning, simplicity is just that . While some designers also refer to this school of simplicity  as ‘Minimalist Design’, other professionals and users might prefer to call it ‘working easy’. Making things simple is often a complicated process in itself and does ask for a methodical/systematic approach in the product development space. In this post, I wish to mention a few tips and techniques that I follow as part of my product engineering practice. You might see that these are just a few in the hundreds of ways, and for simplicity’s sake, I will focus on a few things because, less is more. :)

Let us ‘uncomplicate’

There is no dearth of complexity in our lives and professions. We are inundated with huge number of problems, challenges, and pain areas to give enough exercise to our body, mind and soul. Obviously we don’t want the products that we use to add up to this already complicated and stressful situation.  The only way we can try and help ourselves is by looking at the problems and looking for the solutions that make it really easy.

  

There are various ways to attempt this uncomplication. However, the underlying concept is that you first need to identify the complexities involved and then find ways to remove or minimize them. To be able to do this, I suggest you try and get answers to the following questions.

  • Whose problem is it?
  • What problem(s) do you need to solve?
  • Why were the problems there in the first place?
  • How does solving this problem help the person(s)?
  • Where can we go from here?

Reduce the cognitive load

The gateway to simplifying the product lies in the extent of cognitive load on users. I would say that this is the first and foremost step in the way to deliver a great user experience. This cognitive load could be in the form of visual or textual elements, for example when we refer to the presentation layer. It could take the shape of deep levels of navigation or the manner in which the elements are laid out by the information architecture. This is so important an aspect of the product engineering model, that I planned to write a separate blog post on this in the near future.

Cure Featuritis with simplicity

Most of the product managers are pretty well aware that they have a potential evil that they constantly need to fight off and that is Featuritis.  However much they try, they invariably fall into the trap of adding more features and functionality, without validating how beneficial or what value they add to the product and its users. In a never-ending chase to build a better mouse-trap, the product takes the shape of a mammoth white elephant. Or just to exaggerate, the product could turn up into a ‘Frankenstein monster’ whose course cannot be controlled any longer by the product management team.

In the context of  electronics, computers and software products &  applications too, there has been an increase in the complexity scale corresponding to the rapid increase in the number of products. For instance, just jog your memory, thinking about the size of the device and the number of buttons on your  Television remote control as you changed your Telly sets over the years. These are a great proof that with time and number of products in the eco-system, the complexity only increases and the converse may not be true all the time.

 

The only cure for this disease is Simplicity. Ask yourself the following questions when you want to add any new feature or make changes to an existing functionality.

  • Who is this feature meant for?
  • What problem is it trying to solve? or how does it help the person?
  • Which users’ task is this feature relate to?
  • How better can we make the product/process?
  • How different is this feature from similar ones in previous versions or competitors’ products?

Push them under the carpet

You don’t have to give everything upfront and right on the first level. Understand the goals of your users from their own perspectives. Identify the tasks mapping to these goals or needs. For each task, you need to identify its importance and urgency.  Then decide where in the order of things, you need to place the task and corresponding feature. It might happen that the feature needs to placed not at the top level, but somewhere deep down in the 2nd or 3rd levels of the hierarchy. That should be perfectly fine because you based your decision on the sound logic and understanding of the users’ needs and their key tasks.

A perfect example for this is the all too popular Swiss army knife. Give all the options to users, but let them decide how they wish to use a specific option, depending on the circumstances and context of usage.

Not just ‘ease of use’

Some people would equate simplicity to ‘ease of use’. But I think that simplicity goes way beyond ease of use and it is the effect of an all encompassing experience not just related to usage of the product.  During the analysis, design and development of products, teams must take note of simplicity as a mandatory requirement for the product. In fact, the biggest measure for their effort and productivity is directly proportional to the success of the product in that how simpler the product got when compared to its previous version or that of the competitors’.

My five tips for simplicity

Finally, you can check how effective and simple your product has been designed and developed. I suggest you popup the following questions putting yourself in the shoes of the users and with their conceptual model in your mind. When you are satisfied with the answers that you give yourself, well you have got a product that flies!

  • What can I do with this product or app?… (Functionality)
  • Where am I now and where can I go from here?… (Navigation)
  • What should I do now to make <something> happen?… (Interaction)
  • Is it pleasing to the eyes? …(Presentation)
  • Is there help, ready and when I need it?…(Help)

With this I end this post, and hope you enjoyed reading it and find it useful. Please do drop a line if you have any suggestions or questions. Until next post, ciao!

Necessary but not sufficient

Wednesday, February 10th, 2010

With great effort, you have got access to the key stakeholders of the product organisation. You also identified the specific persons, their roles and responsibilities in the organisation. What are you going to ask them? You would obviously focus on the software product’s features and functionality, because well, that is what you need to know before designing and developing any software application. How about a few questions on the Technology? Well, yes of course, because after all, you are developing the software product using a specific Technology. Let us discuss if these are good enough to get you a head start in the product development or do you need to focus on any other areas during your stakeholder interactions.

Technology or ‘Trick’nology

While nobody can deny the significant role played by Technology in our lives today, one needs to be wary in focusing only on Technology and ignoring the rest. Technology is verily what IT and Software development organisations like us thrive on and I am in no way suggesting to drift away from it. However, I support the view that Technology should be seen as an ‘enabler’ and a means but not the end. All products that have been invented or innovated so far, did not succeed merely based on the technologies used to build them. The underlying technologies in each of these products, if I may call so, helped achieve some business objectives to their users-from the Potter’s Wheel to Radio, from Mainframes to Laptops, from ERPs to Web Applications and from Java to the Multi-Touch Interface. The moment one focuses only on technology ignoring other aspects, that product is bound to fail.

Like ‘Marketing Myopia’, product companies might get into what I call ‘Technology Trap’ leading to the failure of their products. This happened with Borland when they focused on Delphi as only a technology platform and could not pursue advancements and evolve their platform like other competitors. Same was the case with Konica and Kodak were focusing on making better film roll technology, while others such as Canon, Nikon, Olympus moved on to the Digital image technology.

It takes a lot of courage for product companies to come out of this trap. We had seen a real life instance of this ‘technology trap’ in one of the projects to reengineer a university administration suite. This suite was originally developed in LISP, about 15 years back and the product owners thought it was high time they made it modern. So, we were entrusted with the responsibility of reengineering it to Microsoft.Net platform. In one of the screens of the proposed modern platform, we noticed that the development team gave a solution which used Acrobat PDF to preview the schedules and reports. Obviously, we were puzzled why this was done, because PDF is not a suitable solution to be used for WYSIWYG (What You See Is What You Get) interface. When we probed the team, we understood that they did not think of alternatives and tried to imitate the solution applicable to the previous technology. Similarly in another project involving an automated information system, when user logs in he/she had to land in a blank page with very few options. The older technology solution did not use database and used flat files instead. Due to this, they could not maintain the user details.  However, even in the newer version of the product on modern technology platform, after user logs in, personalised welcome message and user-specific tasks could not be provided by the team. But, what stopped us from including personalisation in the modern technology solution?

Prevent ‘Featuritis’

On the other hand, a few people specifically those in the product management and business analysis areas tend to focus more on the features and functionality to the software product. They focus all their energies in adding new functionality and improving existing features. If this is backed by sound logic, business vision and user research, they are surely on the right track. However, this is done more as a pressure from the competitors and to keep up in the race. Focus on features is futile, because if you have created a product with 100 features, your next competitors will create another product with 200 features the very next day. Google, known for its innovation and user-focused products had been successful all along since Google Search, Gmail, and Android O.S. But even Google could not create the right ‘Buzz’ because I think they followed the lead of Facebook, and even Yahoo on this specific offering and could not pursue their core user-focused innovation. Just a day before Google announced the launch of Google Buzz, Yahoo had already implemented similar functionality, and Facebook did it two years back.

First, get on the BUS

So, you might ask what is to be done during the stakeholder interviews. While understanding the Technology and Functionality perspectives is necessary, it is not sufficient. We also need to understand the other perspectives, what I refer to as BUS, i.e., Business, User and System. I give below an indicative list of areas that could be part of each of these perspectives.

  • Business – Organisation’s vision, Business Strategy, Target markets, competitors
  • User – Customers, consumers, primary user groups, usage behaviours, and context of usage
  • System – Product roadmap, scope of features, Technology constraints

Why do we need to do BUS Analysis

As they say, for the success of any product, we need three aspects:

  • Business viability
  • Technical feasibility
  • Continual reliability

To this list, I add two other dimensions – ‘sound usability’ and ‘optimal quality’. To get sufficient responses to the above perspective, one needs to ask relevant questions to the respective stakeholders. This would help get a handle on the objectives, expectations and grounded logic, based on which we can provide solutions  that are practical, feasible and well within the budget, time and other resources of the product owners.

What are the challenges involved in interviewing stakeholders?

Stakeholder interviewing is a scientific technique that involves expertise, experience, maturity and a bit of domain knowledge in the area of the product. It includes asking the correct questions to the correct persons (based on their role and background) to get the correct responses. Even more important than the interviews is the analysis of the data collected from the interviews. It typically takes about twice the time for analysing the interview data and creating a report. The key challenge is to define this very clearly in the plan and let the project stakeholders know about this activity, deliverables and the value created thereby.

After the stakeholder interviews and analysis, we are now poised to define the user profiles and related usage information. Let us discuss this in the next post with some examples from my real life product engineering cases. Until then, ciao!