In order to do any project, one of the things that an expert designer tries to do is to look into their set of repertoires to find for solutions, based on past experiences. Over the times, I think that this leads to the development of ones own design philosophy. This is also something that Donald Schon mentions in his writings about a designer being able to identity a problem and look at the experiences gathered from the reflection-on-actions and reflection-in-actions over projects.
The design philosophy can be developed over time, or over multiple projects. One of the things that a professor mentioned in one of the classes I took was that there is a difference in being an experienced designer and a expert designer. One can be doing design for many years, but that does not guarantee that the person is an expert in the matter. This I think is a good analogy to look at the job market, where by default the person with more years of experience are wrongly thought of as being experts. If that was the case and was always true, then people would be CEOs at the end of their job life. However that is not the case and we have people becoming CEOs at 45 also.
So finally, what is my Design Philosophy? I think I am still in a nascent stage to have one that is very stringent and that it is truly applicable to all projects. But I do hope that with the years to come, I do have one. The way I see it, my design philosophy is based on strong design rationale, the ability to enhance user experience and a solid return of investment for the stakeholders.
Thus this becomes the three prime areas of focus as a designer for me. One is the user’s experience, the other is the stakeholder’s value and then my own personal design thinking.
I loved this ….
‘The way I see it, my design philosophy is based on strong design rationale, the ability to enhance user experience and a solid return of investment for the stakeholders.’
Right on the money. I would like to add some more points to the design philosophy
– understanding a problem before jumping to solve it
– building a criteria or set of rules to evaluate design solutions for eg. I have 20 solutions to a problem , then I prioritize and give weights
For e.g.
solution 1
– good for user
– but takes time to engineer
– good for business value
– must have as our competitor has it
– as a designer be open to criticism and play the role of a facilitator, not the owner of a design
– have no sacred rules that can’t be broken… a design rule that is good in a particular context may fail in another…
so have no rules but use frameworks and learn from others