Susan Locsin
Arch 587
Reflections on design style readings.
I was amazed at the many diverse ways that the different papers approached the
explanation of the design process. No two papers approached it in the same way, though
there were some similarities in descriptions. It is very interesting that something that is
so hard to decompose and define is the key ingredient for the architectural industry. Can
you name any other industry whose functional core is so ill defined, documented and
understood?
I propose that design is learned through the evaluation and understanding gained from
our cumulative lifetime experiences. Depending upon what environments and stimuli we
have been exposed to greatly affect the ideas that we can conceptualize. Questions: How
would a blind man describe the room he was in? How would he describe a room that he
has entered for the first time? How would a deaf person describe an orchestral concert vs.
a rock concert?
I can only describe a design process by comparison to things that I have knowledge and
experience about. Much of this knowledge / experience is from self discovery rather than
formal structured education. Only by framing my experiences in terms used and
documented by others can I gain a common understanding. Since we are all from such
diverse backgrounds, how can we understand that which cannot be conveyed in writing?
When talking about defining style, I must break down the items presented into smaller
pieces that I can compare to other things in my experience. I interpret things through my
own experiences and not someone else’s.
When designing from a software engineering perspective, I try to discover / document all
of the requirements about a project. They are written in a manner that leaves room for
interpretation by others but distills to the essence of the need. The requirements are also
rated as must have, nice to have, and if it’s not impossible.
Another common approach for software design is through the prototyping method. This
is used most often when a certain esthetic or functional ease is desired. This process
generates several examples of what a final product might look like without putting all of
the details that make it function in place. This method allows feedback to be gathered
quickly and early in the development process.
A third approach to software design is the iterative or waterfall approach. This process
combines both requirements and prototyping into a structured method. Some
requirements gathering occurs, some prototyping occurs and then both are evaluated
internally and externally by the stakeholders for the project. Areas of improvement as
well as success are documented and feed back into the process for the next iteration. By
the short and fast iterations, more understanding of the problem and its possible solutions
