Category: Product Design

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 »

So whats the Problem ?

April 13th, 2009 · Rahul Dighe · Product Design No comments - Tags: ,
Whats the Problem

What's the Problem

I don’t seem to get enough of  “so what’s the problem?”

I was in a discussion with a web designer recently who was showing me the designs for one of the products he was working on. Apparently, the users were not aware that there was a section in the product in which they could download ready made reports. The sales group thought that the current product design wasn’t helping the users to get to the reports that they sought.

Fair enough, I thought -  “Users can’t get to the reports they are looking for”….and waited… er…. is there a discussion on how the users look up a report, any use cases, any preferred mode by which user accesses the reports. No not really – is the answer I get.. Thats all that the brief said.. and the sales like the new design. I can’t stop myself for asking so how and what did you design for if you didn’t actually know about the users and the challenges they face in retrieving the reports. Furthermore, how would anyone test the efficacy of the solution if there is really no measurable test that can be defined for it.

If the problem perhaps, was such that 5 times out of 10 when users search for a report they get a message “report not found” and hence cannot get to the reports they are looking for. At the very least, we could test it with the same set of search inputs and verify if the number is any different or the results “better” or design the products to give helpful hints on searching if no reports are found. In the absence of such crisply defined problem there was really no objective way to evaluate a solution.

In all fairness, the solution did look “better” than what they currently had but that was just my personal opinion. A proposed product design needs an objective way of proving that it  meets the needs of the user. However, to do so one needs to have a deeper understanding of the problem. I see the statement “Users cannot find the reports” as the conclusion, the often difficult bit is – Why is it that they cannot find the Report?  – The answer’s to this question will help define the problem ! .. So there we go again – Whats the Problem?

Continue reading »

Tell me the Problem not the Solution

April 13th, 2009 · Rahul Dighe · Product Design No comments - Tags: ,

To loose sight of the problem your trying to solve is the single worst thing you could do during the Product Development process. It’s not hard to see the reason why it ends up being so. As the Product Strategy crafted during strategy meetings starts the morphosis into a tangible product pressures from the market, technology limitations and not to forget “internal preferences” start to emerge – all shaping the products at its various stages of development.

It’s not unusual to sit in the meeting with a discussion of the solution and identifying the pros and cons of it. However, what is often missed in this meeting is the scant understanding of the Problem for which the solution is being sought. It’s not to say that the solution under discussion might not be a good solution to the problem but not enough emphasis on the problem often results in dumbing down of the solution to just one alternative.

I was in a meeting recently with individuals from the sales staff who requested that perhaps we should just disable functionality on some options within the product to support the pricing changes that they had in mind. No harm intended, its a perfectly normal request. If they had asked this to a developer he would have perhaps left the meeting and started implementing it already !   However, disabling functionality is just one of the possible solution to the problem. Sales could certainly have an opinion on how the problem could be solved. However,  to discuss it as if it is the only solution resorts to dumbing down of the solution finding process. Furthermore, it stops exploration of other possible solutions from the participants as they do not get a deeper appreciation of the problem for which the solution is being discussed.

So, next time when your in a meeting when a new functionality is being proposed and all everyone is doing is talking about the solution, request everyone to take a step back and let the business do most of the talking about the problem that “they need a solution for” and leave the discussion about the “solution” to people whose job it is to find the solution – product designer, business analysts and technologists.

Continue reading »