Tuesday, August 22, 2006

Concluding...(Design- Part 1)

My last articles (Moving from Needs to Problems & Design: Simultaneous Processing) had some interesting comments from friends. Most of the time I have been told to break the design to disciplines and processes. But that’s totally contradicts to what I’m saying. These disciplines have been existing for sometime now and most of you “might” agree that though they have been able to make a ‘workable’ solution any ‘innovation’ hasn’t happened from it. Innovations don’t happen by Process or Methodology or by distributing design; it happens by understanding problems and convergence.

These Processes have been there for sometime now I’m also aware of it (to make myself clear). For implementation, Process or Methodology 'is' needed; even I’m a firm believer in that (In Praise of Methodology). What I have been recently writing is about ‘approach’ or ‘attitude’ to design. Most of us at the first instance want to break the ‘Design’ into processes. The whole point is not to break the ‘Design’ but break the ‘Problem’ (why is the design needed? What is the problem it is going to solve?). Any big enterprise/complicated UI Design can be broken into smaller but ‘related’ problems. What we design should take into account all the parameters that influences or shapes up the design. The more knowledge we have about them the better design we can make. The best approach is to think of ALL the parameters that affect a design and if it becomes unmanageable then start Priorities them and then remove. Removing it consciously is a better approach than skipping it altogether.

Afert the understanding is developed on the problem, break the design solving into ‘Processes’. Processed don’t give solutions they just keeps you on track. Breaking the design in Disciplines comes at the ‘implementation level’ - once you know 'what to solve'. It’s the last leg of DESIGN.

What I have been advocating is to THINK and ANALYSE before starting to ‘sketch’/ ‘draw’ / ‘solve’ (I won’t say Design because its the analysis phase that shapes up the end product; its as much design as the rest of it). What I’m saying is not fundamentally different from what other Design Gurus have said. My approach to solving design is to understand the very core of WHY? WHAT? and then to HOW? And to look at the Problem ‘holistically’ first than fragmenting design into steps and disciplines. I hope this ‘CAN’ help me innovate or look at designs a little differently (hopefully rightly).

I do accept the fact that I may be wrong...but what the harm in trying. Failing is another form of learning...

Saturday, August 19, 2006

Moving from finding NEEDS to PROBLEMS

I recently went to see a presentation. The presentation was about an overview of a Research Group of a company. The presenter stated an interesting point “…look for NEEDS and design for it”.

This is quite interesting. I’ll just take a philosophical route (if you want to say its philosophy) and talk about NEEDS and PROBLEMS. We designers are “generally” trained to design for “needs” and researcher are trained t solve “problems”. How these words change the approach is interesting.

There will be people who will argue that NEED may not be existing and an introduction of a new gadget might create it – say like – iPOD or SMS in mobiles or Miss Calls or Mobile phones itself so on and so forth. When we look for need we bias our self to a solution; when you look for ‘need’ you have an idea about the solution. Let’s say to argue – “There is a need for a gadget that could allow people to listen to music while they are mobile”. We already have defined the need; so at psychological term we jump to finding solutions.

What PROBLEM does it; it opens up the issue for investigation. Lets say “People get bored while they are mobile for a long time”. The problem may have multiple solutions. The statement asks to investigate deeper into the problem. This means that the designer would have more scope to understand the problem thus may come up with a more appropriate design solution (or even multiple solutions) to the problem. To be better designers the approach should be…to look for PROBLEMS than NEEDS.

Though one may argue and say that both are just a play of words. It may be a play of word but they definitely change the approach and attitude towards design. The “problem statement” defines the route you would take to solve it…

The design doesn’t start at the drawing board but it ends at the drawing board. It had started with the time the designer was (actually) born. Because what he understands about people, their needs, his observation of the behavior or environment, his experience of handling the previous projects etc is all that basic data that he will use to design it. The more rich it is the better design can one make.

So if you are observant and can see the problems from you day to day life (or related to your) the better designer you can be. So pick out problems and keep your database building – you never know what may come handy in your next project. If you are a designer – you works 24x7; this world if your Labs (the best you can ever have).

Saturday, August 12, 2006

Beyond Observation...

In my earlier blog “ BIG IDEAS come from small thing around us…” I had written about need and importance of observation. Continuing on that I want to add few more aspects to it. No doubt that the eye for observation is needed; but there is a need to go beyond and understand the reasons for that behaviors/situation. Observation is just the introduction of a problem; its analysis is the thing that leads to solution…

I saw a demo of an experiment by taking the Table Desktop as an example BumpTop 3D Desktop Prototype . They observed how people manage their Desktop and tried to come up with a software that replicates it. Now the question here are 2 – why replicate the real life into another medium (Learnings from History of Architecture ) and secondly it does not try to understand why do people manage their work like that.

This to my understanding its just an observation. We need to understand why people do that. This is not the problem; it’s an outcome of some need/problem. If we know what is it that people want we might be able to solve it for the ‘Screen Interface’ (a different medium) and hopefully the solution would be very different from the one tried here.

(Say) People generally don’t go shopping alone. This is an observation; but the reason why people this way may be that they want someone to assure or help them in decision making…or it may be a psychological need…If we know the reason the solution we try to achieve would me more appropriate…

I’m not sure if I’m able to express clearly here…hope you understood :)

Saturday, August 05, 2006

Design: Simultaneous Processing

Though the title might look technical the subject I want to talk is not. Though what I write may be a bizarrely philosophical; that it means may not be so absurd. They are all a reflections of my thinking both about UIs and Design in general. Design - I’m sure you will agree - is a continuous learning. Every project/product thrown up different challenges; so every new project is built on the experience and learning of the previous one. So one should keep their ears, eyes and more important the mindopen to learning. Writing is my way of learning.

Let’s come to the point. Why do I say ‘Design as Simultaneous Process’?? any thoughts?

Taking UI Design as an example; lets try to see what builds it – there are two primary aspects Communication and Experience. The main aim of UI is to help human operator to communicate with the machine; but at the same time this communication should be interesting and engaging for the human operator. This helps him in doing his work efficiently and effectively. Now the big challenge is both communication and experience should be in sync. What do I mean? What I mean is if either of the two are lacking in their role; the over all communication and experience is not achieved. Which means a FAILURE OF DESIGN. So as a designer one needs to do parallel or simultaneous processing – taking care that 'both' not only individually are efficient but when they combine together also create a greater impact. Communication is supported by experience and vice versa. Which one will dominate or if they be equal will depend on the ‘Context of usage’ of the application. If design is good in experience but bad in communication it fails and vice versa

Its here that my earlier thought about Research and Design fits in; communication is one which is driven more by research while experience is what is more driven by creativity. Now you would ask where will I place Interaction design or Visual design or even elements like navigation etc; what category are they – Communication or Experience? Well; they lie in both; every element has both communication value and experience value.

Isn’t it complex? Yes it is. That’s where the knowledge of a designer comes into picture. The more and more parameters a designer can process the better and more complete design he can make. If I can think of 1000 parameters at one time; means that I am taking all those 1000 criteria for designing and that I’m designing for those 1000 parameters. This should ensure that the design has taken care of those 1000 criteria. These criteras are nothing by parameters; mentions in my earlier post.

Pheew. That’s why I call it Simultaneous Processing.

Looking at in a very detailed level – the UIs is a set of elements. Not only do the individual elements have to be good but when they combine with other elements in the UI - the whole UI also should look good. Same is the case with products – if the packaging is not good; even if the item inside is good; people wont like to buy it; is the packaging is good but the item is not good them; they might buy it once; but they wont buy it later.

Thus design is complete system; to work effectively it has to take care of each and every element – Simultaneous Processing.

There are Processes which break all this into disciplines - Interaction, Visual etc. But what I talk is not UCD Process but an 'Approach' to design. Approach should be to design for all the parameters available rather that dividing it into sub part. No doubt with division we can make the design process simpler; but it compromises the completeness. Individual design disciplines can care for their own part but even in UCD Process there could be people who should think about the connections - the over all design.

Thursday, August 03, 2006

Design Portfolio

My old NID portfolio now goes online. You can see it by clicking on this link PORTFOLIO.