The Reflection on Advanced Programming and Prototyping
Shalini Mookerjee
Should Designers Code?
As a designer we are meant to be problem solvers. We make things that arise from the needs of people and we try to make it as seamless as it can get. We try to reach a point that is beyond the most obvious solutions. However, these solutions are not complete if one cannot express it. What code does is it becomes just another tool like illustrator or photo-shop that helps us achieve completion to a particular solution. For me mostly it helps me to gain control over my iterations. When I know how the working of the actual developing works I have more control over what I can achieve with it. This is because no two brains think the same let alone two brains that have come from two completely different backgrounds. Inevitably there will be a perspective difference between my perception of a project as a designer and a person’s perspective as a developer. Hence speaking the language of a coder helps to create a bridge between the perspective gaps and hence giving more control. It also enables me to understand the prospects of a design. There is always a scope of understanding which increases as when one works on it. While one prototypes a certain design on code it makes it easier to prospect those further advancements. Hence you also develop control over your iteration’s future. It is actually an act of creating scope as just knowing the basic iterative applications used by designers can be quite restricting.
How Can One Achieve the Technical Aspect being a Designer?
So now that we have established the fact that a designer should know how to code. At this point the question is how. I feel the best way for a designer to learn how to code is when they have ideated upon a certain solution. This solution could be based upon the user research and ideation phase that is apt design wise to follow at that time. After the designer has devised a solution which is according to him or her the apt solution and fits in the social and experiential ecosystem, the designer could prototype their solution in code. This prototype might just be the second version. Meaning if I was to make an iron that detects the cloth and prompts settings. I could make the prototype of the iron on fusion 360 and I could prototype the UI of the feedback screen on Adobe XD and use After Effects to show the exact transitions. However, after this if a designer has to prototype how the functioning happens then they will have to use code. At this point when one is prototyping it makes sense to start a software that does that. At this point the tool is not acting as a constricting factor but a exploring factor. In this level of low fidelity code prototype, the learning curve of the device is projected upwards. Meaning when you are trying to make something that is already in your mind and you are using a new software to do that. Every mistake you make on the path to the desired result is another learning. This is how a designer should pick up a tool and learn it. It effectively also makes the designer confident of picking up a skill during working on a project which makes one viable in the market. Which means that if tomorrow there is a newer better software it would not be out the way for the designer to pick it up if he or she requires it.
Reflection on David Kelly and Bradley Hartfield’s Interview
The interview talks on a very relevant topic of the difference between engineers and designers. This discussion spreads into the aspect of what kind of environment favours good design and design thinking practices.
I usually have a problem collating to myself what is the difference between a software designer and someone else as a software engineer. In this interview David Kelly puts it up beautifully as to where the difference actually lies. He says that engineering deals with solving a problem at a given situation conditions be fixed. However, design on the other had deems to finish a problem way beyond the obviously stated. It takes into consideration the socio-cultural and socio-economic context. Not just the apparent problem but also the ones that may arise depending on the forecasted use. It also tries to judge the experience of the people using it and their perception towards its various aspects. It is somewhat a try to achieve everything and yet giving the important aspects priority. Unlike engineering it is not an equation based solution. Hence, with the absence of an equation a designer must learn how to live with uncertainty. This uncertainty leads to something ‘uncomfortable’ and ‘messy’ as David Kelly puts it. He says that a designer will not always know what the solution may be however, they will have to learn how to deal with that. Designers will eventually learn how to trust their gut and listen to their intuition. At this point one might as that this can be applied by engineers as well. In reply, David Kelly says, design thinking is everyone’s art. One can be trained in it. This creative thinking comes after an individual from whichever background takes the uncomfortable leap. This leap has been explained by David Kelly in his book ‘Creative Confidence’. ‘‘So what do designers actually do?’’ when asked to David Kelly he answers that they make ‘it’. Basically, what he means to say is that if one was to make an iron, what colour of the iron will be most attractive towards the audience is the job of the designers, how to place the handle to make it most user friendly and things like this. It is usually confusing because the word design is used for various fields and in various intentions.
