problem solving – designer and the developer

This is the second post where I ponder about design. Here I am thinking aloud my experiences with developers. You can read the first post here.

A good developer is a very good problem solver. You give him a problem and he will give you the most fast, or the most efficient, or the most cost effective solution. Now having said that who defines and words the problem? The right answer would be the designer. The designer would consider different aspects of the problem, among them marketing, usability, etc, and then give a very specific and unambiguous problem statement to the developer.

The problem comes at this point. It seems as if everyone knows what the problem is. From the developer to anyone who knows about the project thinks he knows exactly what the problem is. And this in fact is the main problem. This is the problem which I guess is the root reason of why Open source software is difficult to use and not widely accepted.

There are various facets of this. Lets take an example which I hope will demonstrate this clearly. Clearly when I say developer it could also mean engineer for other fields. So there’s a furniture company called Woodworks. It decides it needs to introduce a new chair for the season. If it has it’s workflow in order, the chair will be firstly be designed. The team which will handle it might comprise of both marketeers and designers. They will ask and discuss questions such as, “How should it be new/different?” , “What should be the focus of the particular chair – should it be executive, lounge, dining etc..” , “which country is it going to be marketed in? are their cultural norms for chairs there?” , “Is it for the general public or a specific age group? – teenagers or the elderly”. Among other such questions.

Then the designers give detailed specifications for everything to the developers. It should be noted that their might be a person or team in the middle which works as an intermediate. See this scenario:
designer: the chair legs should be very thin and made of rubber. also the material costs should not exceed this many bucks.
the intermediate: no to make it within this budget the chair legs have to be atleast this thick.
The difference between the developer and the intermediate is that the intermediate is comfortable with many variables. While also being able to suggest some new things to the designer. In short he has technical basics clear while also is able to “hear” and understand the designer.

So when the engineer gets the design, with no ambiguity, he can get his work done fast.

Now I don’t have any experience in the furniture industry, so these steps might be wrong, but take this example as a general product development case.

Now if the same thing is done by a company which does not have a big team or where the workflow is not good enough. And if the problem is not well defined the resulting chair might be a pain in the ass.

My personal experience is that, developers get too hung up on the “how to do it”, rather than “what exactly to do”. So if the problem is not well defined before the developer gets it, he might do plently of cool optimizations, make it very efficient, but in the end, “it” might not be what the people want.

Anyway I would love to hear your take on this issue. Both designers and developers are welcome :).

2 Comments on “problem solving – designer and the developer

  1. This seems to be the traditional procedural approach to development (like pipeline production) where the product goes from one hand to another and is worked upon sequentially.

    With the latest methods of working (for instance Agile methodologies), one can imagine the problem been solved to a great extent by a simple gathering of designers, developers, testers, customers at once…to work on and discuss the final product from conception to delivery. So while designers can convey the design and usability issues, the developer can discuss the implementation or technical limitations, and customer can say if they like the sound of it.

  2. @rasheena – agreed. you may argue between a pipeline production and agile methodology. and sure in some scenarios one would be better and in others the other would be.

    What I am saying here is at the very least there should be some method. That people should realize that designers do more than just prettying up there work. the design is more than just UI (if we consider software)…or looks would be a general word. And I am talking this with experience i have gained working with small teams, startups. this would also be true with open source software.

Leave a Reply

Your email address will not be published. Required fields are marked *

*