What differentiates a 'big-league' chef is that they make really good food.
Some of those chefs will be analytic-style cooks able to provide introspective traces of fundamentally sub-conscious decision processes (to non-chefs), but some will NOT be. Some designer will be good at communicating introspective traces (to non-designers), and some will not be. Some programmers will be good at communicating introspective traces (to non-programmers), and some will not be.
I write this as both a Real Programmer(TM) and an interaction designer, usually hats that I wear on separate projects, and never the twain shall meet. I have experience on both sides of the fence, and disagree strongly that a designer who can not justify their decisions (particularly to non-designers) is necessarily a 'little-league designer'.
The author makes an easy case that will resonate with developers: "a good designer can tell you why they did something, a bad designer can not". This is satisfying, because it confirms the (general) biases of the developer audience; namely that other job roles inside an org better be able to justify themselves (the reverse, a developer required to justify technical decisions to those unable to understand technical concepts is often seen as an absurdity, and I think in many cases it is...). Is the 'big-league designer' iff 'can justify themselves' assertion true, or is it alluring because its what you, as a developer, would like to believe is true?
Yet I believe the author's own chef metaphor undermines the argument.
Do you really believe that what differentiates a 'big-league' chef is that they can explain (esp explain to non-chefs!) why they did a certain thing? Do you believe there is not a significant subset of talented chefs who walk-the-walk but introspection is not a built-in feature?
Introspection is closely related to 'ability to teach', and is NOT necessarily related to 'ability to do'. The author references cognitive architecture, and this is a frequent assertion from that direction. A learning pilot is 'consciously' aware of what they are doing, an experienced pilot is often no longer able to 'introspect' what they are doing anymore, a pilot-teacher has to relearn the 'conscious' (introspective) aspect, coupling it with the subconscious skills acquired while doing.
Introspection /is/ a nice feature in a designer, absolutely no doubt about it. It reduces team-friction, particularly when the designer is working with developers who (rightly or wrongly) like to have design concepts justified to them.
But "not being able to introspect" does NOT necessarily entail "not being able to design", just as "not being able to explain how to fly a plane" does NOT mean "not able to fly a plane".
Many developer-oriented design blogs imply that justification of design decisions to non-designers is a mandatory feature of a designer.
Is justifying key technical decisions to non-developers a mandatory feature of a developer? Yes and no. Its better if you can, absolutely, and being totally unable to explain decisions is a bad thing, but on the other hand, being constantly asked to justify decisions "outside the bounds of professional competence" (say, to a PHB) is counter-productive.
Design is roughly as subjective as programming. Take that for what you will. Both are first and foremost arts; neither is fully encapsulated as a 'methodology' (the whole UX methodology is as silly for encapsulating all possible talented forms of design as Agile is at capturing all possible ways to program).
Most day-to-day decisions in both design and programming are based on experience and intuition, with a mix of conscious reasoning on the top.
Talented communicators exist in both areas, and are more highly prized than poor communicators, yet skilled practitioners who are poor explainers are useful and 'big-league' in both programming and design. To believe otherwise is to unecessarily pass over talented and useful designers, designers that will score big wins for somebody else.
Some of those chefs will be analytic-style cooks able to provide introspective traces of fundamentally sub-conscious decision processes (to non-chefs), but some will NOT be. Some designer will be good at communicating introspective traces (to non-designers), and some will not be. Some programmers will be good at communicating introspective traces (to non-programmers), and some will not be.
I write this as both a Real Programmer(TM) and an interaction designer, usually hats that I wear on separate projects, and never the twain shall meet. I have experience on both sides of the fence, and disagree strongly that a designer who can not justify their decisions (particularly to non-designers) is necessarily a 'little-league designer'.
The author makes an easy case that will resonate with developers: "a good designer can tell you why they did something, a bad designer can not". This is satisfying, because it confirms the (general) biases of the developer audience; namely that other job roles inside an org better be able to justify themselves (the reverse, a developer required to justify technical decisions to those unable to understand technical concepts is often seen as an absurdity, and I think in many cases it is...). Is the 'big-league designer' iff 'can justify themselves' assertion true, or is it alluring because its what you, as a developer, would like to believe is true?
Yet I believe the author's own chef metaphor undermines the argument.
Do you really believe that what differentiates a 'big-league' chef is that they can explain (esp explain to non-chefs!) why they did a certain thing? Do you believe there is not a significant subset of talented chefs who walk-the-walk but introspection is not a built-in feature?
Introspection is closely related to 'ability to teach', and is NOT necessarily related to 'ability to do'. The author references cognitive architecture, and this is a frequent assertion from that direction. A learning pilot is 'consciously' aware of what they are doing, an experienced pilot is often no longer able to 'introspect' what they are doing anymore, a pilot-teacher has to relearn the 'conscious' (introspective) aspect, coupling it with the subconscious skills acquired while doing.
Introspection /is/ a nice feature in a designer, absolutely no doubt about it. It reduces team-friction, particularly when the designer is working with developers who (rightly or wrongly) like to have design concepts justified to them.
But "not being able to introspect" does NOT necessarily entail "not being able to design", just as "not being able to explain how to fly a plane" does NOT mean "not able to fly a plane".
Many developer-oriented design blogs imply that justification of design decisions to non-designers is a mandatory feature of a designer.
Is justifying key technical decisions to non-developers a mandatory feature of a developer? Yes and no. Its better if you can, absolutely, and being totally unable to explain decisions is a bad thing, but on the other hand, being constantly asked to justify decisions "outside the bounds of professional competence" (say, to a PHB) is counter-productive.
Design is roughly as subjective as programming. Take that for what you will. Both are first and foremost arts; neither is fully encapsulated as a 'methodology' (the whole UX methodology is as silly for encapsulating all possible talented forms of design as Agile is at capturing all possible ways to program).
Most day-to-day decisions in both design and programming are based on experience and intuition, with a mix of conscious reasoning on the top.
Talented communicators exist in both areas, and are more highly prized than poor communicators, yet skilled practitioners who are poor explainers are useful and 'big-league' in both programming and design. To believe otherwise is to unecessarily pass over talented and useful designers, designers that will score big wins for somebody else.
</rant>
I wrote a blog post on this subject that may or may not being less rambl-y than this comment: http://blogs.gnome.org/seth/2010/02/23/i-did-the-worst-desig...