Main Entry: un•con•scious
Pronunciation: n- kän(t)-sh s
1 a: not knowing or perceiving : not aware b : free from self-awareness
2 a: not possessing mind or consciousness <unconscious matter> b (1) : not marked by conscious thought, sensation, or feeling <unconscious motivation> (2) : of or relating to the unconscious c : having lost consciousness <was unconscious for three days>
3 : not consciously held or deliberately planned or carried out <unconscious bias>
What is unconscious design?
The action of designing and the outcome of such an action that fulfils functional requirements and simultaneously is unaware of any in-context or temporal implications of its properties.
Distilling, design is a verb as well as a noun, and both can be unconscious. Unconscious design (as a verb) almost always produces unconscious designs (as a noun). Interestingly enough, unconscious designs (noun) not necessarily come from unconscious design (verb). That is, professional designers (conscious designers) often produce unconscious designs but with temporal properties attached to them, temporal unconscious designs. In other words, they realize that there is no such thing as ‘perfect designs’, just ‘perfectible designs’; so in a given point in time of a particular design life there are suitable strategic or tactical decisions for that time but not for all the design life. They (professional designers) also realize that software designs that are actually used tend to rot quickly, very quickly —as soon as the first requirement or context changes— so they make sure that the evolution of such temporal unconscious designs count on executable assertions in functional contracts avoiding those designs remain unconscious out of their proper time, making them conscious again when the proper context has come.
That also explains why design decisions that just make the software functionally complete are partial design decisions because they lack executable assertions that prevent a continuous state of unconsciousness. That kind of incomplete design decisions are usually linked with an unreflective practice of the design activity; one where there is no “conversation with the situation” as described by Donald A. Schon in “Reflective Practitioner: How Professionals Think in Action” as happens in all other design professions. Sadly, it is not uncommon to find partial design decisions in software taken by some so-called architects (whatever that term really means) that left an incomplete design work behind to blue-collar workers without proper executable assertions that make them realize the important design work yet to do. Because of the very nature of unconscious design both groups of professionals are completely unaware of the situation, just feeling the pain all around not knowing why.
The reason why a software system can be a success and a failure at the same time on different situations or contexts is because unconscious design (as a verb).
How professional designers think in action?
How practitioners facing tough problems get to optimal in-context solutions?
How practitioners start the life of complex software systems and how they successfully evolve those complex systems beyond version 1.0?
That is to say, how practitioners behave when they actually face the consequences of their design decisions overtime?
An ingredient of the answer is conscious design as a verb, mainly.