Author Archive

The Art of Customer Interviews

December 23rd, 2009 · Rahul Dighe · Customer Research No comments

The best part about my job is I get to talk to  lots and lots of people all across the world in different industries and with a variety of different job functions. In every interview, the goal is the same,  to find that one bit of insight that when applied within the product would deliver maximum value for our customers.

Having done this many times over , I know I am good at it and that if given the opportunity to talk to users/customers I can in most instances overtime identify key “insights” that can differentiate and improve the value of our products. I am not a trained psychologist and I don’t think I am better than those who interview for a living. However, I do feel what I do have is “empathy” – a quality that helps me connect with individuals and get them to talk about our products about their jobs in a way that helps me in the end get the answers that I want.

I recently came across a very good talk by “Marc Pachter” – The Art of the Interview. Although the context is slightly different, this particular talk resonated with me. Although, I cannot claim to have achieved the level of empathy that he describes in his talk, it is something that I feel I can always strive for. In concluding the talk he says – The key point (to interviewing) is “empathy” – because everybody in their lives is really waiting for people to ask them questions so that they can be truthful about who they are and how they became what they are.

The art of customer interview for me is the ability to ask that one key question to the customer, which opens him/her up and reveals the true nature of their actions and behaviour. It’s not a question that can be scripted or pre thought but is something that reveals itself if one is truly curious , empathetic and can see the world through the eyes of their customer.

Continue reading »

Product Features – Does your product really need more of them?

December 23rd, 2009 · Rahul Dighe · Product Features No comments

Product Features

Over the last few months, I have been involved in “relaunching” existing online products with the aim towards making them usable and intuitive to our customers. Not too long ago, I was interviewing a user who had been using our product for about 3+ years. As I was showing him the wireframes, at one point he pointed at a feature and said “It’s great that your introducing this features, I can see myself using it”.

Such a positive reaction normally brings smile to my face, but in this instance it did not! – reason being that the feature in question had been in the product for atleast last 5 years. As I interviewed more customers it became apparent that this was not an isolated incident and that mere act of “repositioning” and “highlighting” certain aspects of the product had a profound impact on what customers perceived they could do with the product.

The lesson to be learnt is that it is important from time to time take stock of “features” that are not being used by our customers. Some of it could be down to the fact that it is not relevant to certain groups of users. However, it won’t be unusual to find features which although relevant and useful are not being used either because they have not been properly designed or emphasized within the product. Identifying and developing such features first will ensure that we don’t continue to add more features without first deriving maximum value from those already in the product.

Continue reading »

Design Process

December 22nd, 2009 · Rahul Dighe · Product Design No comments

Design Process

Do you have designs that are visually brilliant but poor in interaction? Do you struggle with stakeholders who send you back to make “expensive” design changes? If so, have you followed the below basic design process?

I  have always viewed “Design” as a 3-step process comprised of  – wireframes, interaction design & visual design. I would define them as follows -

Wireframes - The process of creating low fidelity “sketches” that define the structure of the website, it’s pages and how they relate to one another. Wireframes done at the “right” level of detail can help stakeholders “visualise” the solution being proposed.

Interaction Design – The process of creating “storyboards” that helps stakeholders visualise the “flow” through the website. One could define a storyboard for e.g. for a “wizard on the website” or for a “checkout process” on an online shop. The “storyboards” need not be different than “wireframes” but build upon them adding details wherever necessary

Visual Design – The process of visually (through shapes, fonts, colours) expressing the product to deliver the intended effect and reaffirm brand values. The “intended effect” is critical – as for an online shop it could mean motivating user to click the “buy” button whereas for a news website it could mean getting users to read “related news”.

Ideally you would have staff who is an “expert” on each step of this process. However, in practice, it isn’t unusual to have just one person that is responsible for all three aspects. The key point to note is that whether its a team of 3 or a team of 1 – each step of the process needs due diligence and care. Focus/Skip one or the other and one gets designs that are visually brilliant but poor in interaction or great in interaction but lacking a visual appeal.

Continue reading »

Speak the language of the user

June 5th, 2009 · Rahul Dighe · Customer Research, Product Design, Product Training, Product Usability No comments - Tags: , ,
Language of the user

Language of the user

As an organization grows it tends to build and develop its own vocabulary. A new individual joining an organization almost always has to confront the challenges of being able to learn and appreciate this vocabulary filled up with company jargon, marketing buzzwords and abbreviations. But why should we expect our customers who use our products and services to learn this “internal” vocabulary.

More often than not such words creep into the product and given that everyone in the company is so familiar with it no one realizes its a impediment to customers more readily adopting the product. A few suggestions on how it could be easily remidied.

1. As you talk with customers, pay attention to “Keywords” they use. The customers themselves could have developed their own vocabulary around your product and at times its probably more readily describes the features and functions.

2. Some buzzwords are industry specific and are widely acknowledged and understood. However, learn to appreciate your user base, at times it might be easier to use a plain speake alternative unless the words are so entrenched that not having them would actually has the effect of users getting confused.

3. An easy way is to grab new employees as they join the company and ask them to trial the product and note down words for which they seek more information.

The operational aspects of these at times could be difficult because these words are part of the identity and culture of the organization. However, it could start with the front line staff who train or service the users. Using plain-speak doesn’t mean eliminating branding within your collateral or your in your marketing efforts. But , as with all these efforts its important to get your message across and for that there is no alternative but to – speak the language of the user.

Continue reading »

Justifying Design.

May 25th, 2009 · Rahul Dighe · Uncategorized No comments
Justifying Design
Justifying Design

During the product design process choices need to be often made with regards to navigation methods, color schemes and interactions amongst others. Sticking to established best practices is a good thing. For some designers such best practice is something that they studied in university, for others it could be something that the corporate style guide has clearly laid out.

As new trends get established on the web there is an aspiration on the part of the designer and also sometimes the wider stakeholders to see if or how they could be adapted within their product. It isn’t too uncommon to hear from stakeholders – I really like how you can filter and search for products on Amazon, Ebay why can’t we do the same for our website ?

What is more worrying is the attempt by Web Designers to explain away/justify design solely based on its apparent use by top brand named or trafficked websites.  “Amazon/BBC/CNN/Ebay are using it , they probably have spent thousands of dollars doing market research and usability studies, so I think its perfectly fair for us to use it as well”.

I don’t completely dismiss this argument. The pace of technological change means that there are now new and different ways in which one can interact with a website. Looking at a top branded website for leadership/inspiration seems like a completely sensible thing to do. However, I would like to point out to a few pitfalls in following this strategy

  1. Know your audience -What matters most is not where your source your design ideas from, but whether your design works for your audience. It is great to introduce social features such as “sharing” within your product but lets not do it because everyone else is doing it. Lets do so because our customer on seeing the design tell us that,  “Yes !  this is a great feature and I can see myself using it”
  2. Experient! – but be Agile - Designer often get back to me and say , but it will take 1/2 a day to implement, can’t we just implement it and see if it works. I think experimenting with new design concepts is a great idea! However, understand the risks to your customers and have a well defined exit criteria to roll back design ideas if they seem like they are not having the desired effect. If there is no clear exit criteria, you run the risk of overtime being left with a bloated product.
  3. Your inspirations could change – Unless you have an inside view or verifiable information on why a certain design has reaped rewards for a company don’t assume that such is the case and not subject to change. A end result rarely provides information about the problem it was supposed to have solved.

Continue reading »