In my research on concept design processes, I’ve come across two ideas that jumped out as vital behavior that differentiates expert designers from novices.
The first comes from Nigel Cross of Open University, UK, who seems to have studied designers and their processes more than anyone I’ve come across. In his Expertise in Design (pdf) he says (emphasis mine)…
Novice behaviour is usually associated with a ‘depth-first’ approach to problem solving, i.e. sequentially identifying and exploring sub-solutions in depth, whereas the strategies of experts are usually regarded as being predominantly top-down and breadth-first approaches.
While the protocol studies he cites contradict this, when it comes to digital design I find this explains why I see so little concept design these days. Both product developers and designers have a tendency to jump on the first great idea they generate and head down one path, instead of patiently exploring the space of possible solutions. The pain is only felt far down the line when development makes it obvious what doesn’t work and what could have been.
The other big idea comes from How Designers Work, Henrik Gedenryd’s Ph.D dissertation. In the third section (pdf), he observes how designers go about defining the problem to be solved, the most difficult part of the project. How the problem is defined can determine the success of the succeeding design task…
…the two contrasting attitudes make the whole difference between frustration and progress: Quist literally makes his problem solvable, whereas Petra finds herself stuck. The bottom line is that Quist who is the “expert” is acting as a pragmatist, whereas Petra, the “novice”, acts as a realist. And as we have seen, this accounts for a great deal of his superior performance. The choice of either position is not merely a matter of ideology, but has important consequences.
In short, experts are pragmatists, they re-set or re-frame the problem to make it solvable. Novices are realists, they take the problem as a given and get stuck.
I see this problem compounded as whole organizations are novice-level at interactive. For example, we know from problem-solving studies that you’d get better results evaluating a few competing concepts and keeping the best parts of each. But, the fact that so many organizations are so unsophisticated at design that they won’t tolerate that approach. They think it’s wasteful and unnecessary. Instead, they plow down one path wielding the machete of authority. The novice designers’ woes are amplified by the novice managers’.
Excellent post. And, thanks for sharing the sources.
Hey, thanks for posting this. I’ve been doing a lot of time thinking about your second point recently – and how generating insight that exposes the nature of the problem can help with re-framing.
Increasingly, I’m convinced that early-stage prototyping is one of the best ways to drive insight. Sadly, it’s something that we generally don’t do enough.
I’ve been doing some research into concept design processes right now as well. I’d love to share notes at some point if you’re interested.
Victor, This is an interesting post. I am not clear, however, whether you consider designers to be pragmatists or not. Or does that turn on your novice/expert distinction?
And if experts always frame problems so that they can be solved and novices never do (and therefore get stuck), how do we describe people who do not behave in either of these ways?
Crystallizes things that felt, um, less crystal before … thanks.
In my head this was bumping around as: why is it that newer designers tend to complain about constraints so much, or get stuck in one point of view on a solution? And should I feel guilty for ‘compromising’? But seeing it as ‘reframing’ feels a lot better! :-)
Really, though, I want to read this stuff — thanks for the links — it adds some helpful detail to CoP understanding, and how practitioner identity evolves.
RE>And if experts always frame problems so that they can be solved and novices never do (and therefore get stuck), how do we describe people who do not behave in either of these ways?
Lucky. Or clever. Or procedural. Maybe because they have a practice that attracts well-defined problems and no re-framing is necessary. I might also call that boring :)
Victor, this is a really interesting distinction. It reminds me of Bill Buxton’s talk at Interaction 08 in which he discussed “enumerative design” — creating a bunch of plausible solutions and then narrowing down to the best one and fleshing out the details. Leah Buley from Adaptive Path talked about a similar approach at IA Summit.
I’ve thought a lot about designers as problem definers more than problem solvers. Some of my comments are on Paul Isakson’s blog here (http://paulisakson.typepad.com/planning/2008/06/back-to-basics.html).
It seems to me that understanding the entire problem space allows a designer to create single solutions that mitigate multiple pain points — “killing two birds with one stone” if you will. When we concentrate on one small piece at a time, we’re likely to create redundant functionality and inconsistent interactions.
I have to wonder though if this is really an expert/novice issue. I am far from being an expert in the field, but I find that I often approach problems much differently than some of my more seasoned counterparts. In my experience, some people (any age or level) have “signature” design elements/models/flourishes that they’re determined to apply to every situation just to make their mark. Let’s face it, sometimes the best solution to a problem is no solution (look at the iPod), but designers who have their own motives lose sight of this.
I’m not sure what the distinction should be, but I’m not sure experience level is the right one.
RE>I have to wonder though if this is really an expert/novice issue.
Of course these are generalizations and there’s going to be exceptions. Reading this research, it’s clear they found many cases where a designer with either experience or formal training is more likely to know how to frame a problem. I see this a lot at the design school where I teach, and agree with Gedenryd when he cites Lawson who says,
I suspect you’re more experienced than you give yourself credit for. :-)
I would have to agree with Whitney’s point that everyone confronts problems in a unique and individual way. Furthermore, I would argue that any design thinker, no matter how experienced, posses a degree of the pragmatism Henrik Gedenryd identifies. Based on the quantity and quality of the pragmatism, the successfulness of the problem solving adjusts accordingly. Could any designer be a realist in Gedenryd’s definition? I think the pragmatist category is where the multiple variants Whitney mentioned exists.
Victor,
Brian Ling of DesignSojourn.com asked some designers and I to contribute to a series of conceptualization models, each post from a different contributor.
It’s an ongoing project and available at:
http://www.thinkdrawmake.com
If you or someone else might be interested, have them contact Brian.
Vielen Dank und Adieu
Whitney, your point about designers as problem definers vs problem solvers brings to light a really interesting situation that has evolved where I work, where the definition of the problem and the solution of the problem are broken out not only by role, but by department. My department is specifically charged with problem definition; the Creative department deals with solving the problem we define.
We recognize that this is purely an artificial split. What’s challenging is that over the last two years, we’ve seen real gaps emerge between the groups. Those who are tasked with “reframe or die” also tend to do very well with solution creation. Those who aren’t involved in the reframing process and only doing downstream solution creation struggle to solve problems that they haven’t run across before.
I have a sense that regardless of whether the designer is experienced or a neophyte, has an artificially constrained role, or has their perspective limited in some other way, design success is based as much around the design environment itself as the people who populate it. I think environments (tools, processes, frameworks and rules/lack of rules) drive great design as much as people. Sadly, our understanding of what is needed to build great design environments is very limited and most of the knowledge is trapped in the heads of a small number of people. We need more conversations around this topic!
RE>the definition of the problem and the solution of the problem are broken out not only by role, but by department.
That’s a key insight, because how we’re organized often determines how problems get solved. This split may be strategy/design (or engineering) or sales/execution. In small firms the practitioners may define the problem and design a solution, but otherwise there is likely to be a split, probably because stretching from strategic to tactical is difficult or undesirable, or because sales and design come from different skill sets and/or personalities.
So, how does one reframe the problem to make it solvable?
Hi Adam,
That’s a great question we need more answers to. At the moment there’s a variety of ways, but none that are well-known.
As a primer, I recommend starting with the book ‘Don’t Think of an Elephant.’
Thank you, Victor, I’ll look for that. Could you tell me if there were particular chapters or parts of the book that you felt applied to graphic design?
Hi Adam,
None it applies to graphic design directly. Framing is a way of helping to define the problem before we solve it. For example, whether if you frame the Estate Tax as the “Estate Tax” or the “Death Tax” can influence what kind of solution you design.
V
Matthew,
Re> My department is specifically charged with problem definition; the Creative department deals with solving the problem we define.
If you’re not familiar with it, you might want to investigate the historical conversation around “problem seeking”. In the 70s, some design firms, mostly architects, developed methods for a two-part design process — “problem seeking” (sometimes called architectural programming), or looking to identify and understand the design problem, and “problem solving”. William Pena from HOK wrote the best overview of these methods.
This practice proved to be controversial, as many architects grew to feel that, as you seem to be finding, separating these aspects of design was not only artificial, but reinforced practical and psychological splits between the people and groups working on one aspect vs. the other.
In my own view and experience, conceptual distinctions between “phases” of confronting design challenges tend to obfuscate the important underlying elements of productive creative thinking.
Design problems, whether they have as their object a new building, new policy, or a new web service, are always problems of agreement. The challenge is in getting stakeholders to reference the same details and aspects of the situation in considering how to treat them, so that you can sort what is really being agreed on and what is the source of disagreement. That can only be done through suggestion — by analogy, description, simulation, prototype.
Proceeding through the process then is a matter of reckoning with increasingly fine-grained distinctions and disagreements, which necessitates increasing fidelity in the suggestion or prototype. Those fidelity distinctions — not any underlying process difference — are the only things that distinguish the beginning of the project from the
end.
Very interesting! I coach agile teams, and one of the risks of weekly iterations is that you get caught up in the flow and don’t take time to step back and look at the big picture. Engineers have this problem with the software architecture, designers with interfaces and interactions, and product managers with solutions.
Something I remind clients of over and over is that they should never come to a problem with just one solution in mind. Three is great, as you are forced to dig deeper to what the tradeoffs are that make one design better than another. Zero is also not bad, as you are forced to remain open to the details. But only evaluating one solution means you’re terribly prone to confirmation bias.
The upside of weekly iterations is that your notions are frequently put to the test when you still haven’t invested much. That makes people more willing to try other approaches. And I think getting frequent reminders that even one’s most beloved ideas don’t always work out helps keep people thinking broadly.