Two Things Design Experts Do That Novices Don’t at Noise Between Stations

Two Things Design Experts Do That Novices Don’t

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.

Trackbacks & Pings

links for 2008-08-04 [delicious.com] « Brent Sordyl’s Blog on 04 Aug 2008 at 8:01 am

[...] Two Things Design Experts Do That Novices Don’t at Noise Between Stations 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. (tags: design creativity) [...]
Problem Analysis is Not the Key to Successful Design Process | Konigi on 06 Aug 2008 at 11:47 am

[...] excellent article on this topic and the comments generated in Victor’s blog entry. URL noisebetweenstations.com/perso… [...]
kirabug’s idea files » Blog Archive » Two Things Design Experts Do That Novices Don’t on 08 Aug 2008 at 1:18 pm

[...] Two Things Design Experts Do That Novices Don’t are two things I need to learn to do. [...]
Expert v Novice « I’m Just A Guy on 13 Aug 2008 at 10:13 am

[...] here to see Victor’s [...]
Everything is design » Blog Archive » Effective design problem solving: Chicago, user experience, interaction design, information architecture, information design, usability, graphic design, product design, strategy. Mostly. on 17 Aug 2008 at 8:50 am

[...] way of Noise Between Stations, there’s a line in this work, my emphasis added, by Nigel Cross’s Expertise in Design: [...]
Content Fairy - Guy Redwood’s Blog » Blog Archive » The difference between experts and novices on 07 Sep 2008 at 4:58 am

[...] from ‘noise between stations‘ – an interesting blog just added to my rss feeds. So, maybe the stars of tomorrow are easy [...]
The power of a project plan « Pig Lipstick on 16 Sep 2008 at 8:46 pm

[...] So here I am, messing with project phases and dependencies. And as a result, raising the level of discussion from tactics to strategy. Hopefully, we can make our problems solvable; rather than finding ourselves stuck. (More on this idea from Victor Lombardi’s recent post on Two Things Design Experts Do That Novices Don’t) [...]
[root@EGA]# » Blog Archive » links - 20081010 on 10 Oct 2008 at 10:36 pm

[...] the bank’s headquarters Google Employees Watch In Horror As 60 Percent Of Their Stock Options Drown Two Things Design Experts Do That Novices Donât Success with OpenSolaris ZFS MySQL in production Sins of Commissions McCain Style Mentality [PIC] [...]
Design Blog « idp08 orange on 12 Oct 2008 at 10:19 am

[...] Link [...]
ClearCove » Blog Archive » Experts design breadth first on 19 Oct 2008 at 12:33 am

[...] this article reminded me of a concept that applies to software design, user interface design, hardware [...]
The Navarra Group » Blog Archive » Experts are pragmatists on 24 Oct 2008 at 12:49 pm

[...] 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.– some guy [...]
October 2008’s most-clicked posts to the link list: Data scraping, design experts, copy editors, killing the article, local. - Joe Think on 09 Nov 2008 at 4:52 pm

[...] Two Things Design Experts Do That Novices Don’t [...]
ClearCove Software Inc. – Experts design breadth first on 27 Nov 2012 at 7:23 pm

[...] this article reminded me of a concept that applies to software design, user interface design, hardware [...]

Comments

Jay Morgan wrote:

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.

Posted 23 Jul 2008 at 8:49 am ¶

Matthew Milan wrote:

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.

Posted 23 Jul 2008 at 9:01 am ¶

Michael Anton Dila wrote:

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?

Posted 23 Jul 2008 at 9:08 am ¶

Andrew Hinton wrote:

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.

Posted 23 Jul 2008 at 9:15 am ¶

Victor wrote:

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 :)

Posted 23 Jul 2008 at 9:31 am ¶

Whitney Hess wrote:

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.

Posted 23 Jul 2008 at 11:22 am ¶

Victor wrote:

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,

Students of design often devote too much of their time to unimportant parts of the problem. It is easy for the inexperienced to generate almost impossible practical problems by slavishly following ill-conceived formal ideas which remain unquestioned but could quite easily be modified. One of the major roles of design tutors is to move their students around from one part of the problem to another and the job of the design student is to learn to do it for himself.

I suspect you’re more experienced than you give yourself credit for. :-)

Posted 23 Jul 2008 at 11:41 am ¶

Nate Archer wrote:

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.

Posted 23 Jul 2008 at 11:51 am ¶

Mario Vellandi wrote:

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

Posted 23 Jul 2008 at 3:53 pm ¶

Matthew Milan wrote:

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!

Posted 23 Jul 2008 at 10:35 pm ¶

Victor Lombardi wrote:

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.

Posted 25 Jul 2008 at 8:14 am ¶

Adam wrote:

So, how does one reframe the problem to make it solvable?

Posted 02 Aug 2008 at 4:36 pm ¶

Victor Lombardi wrote:

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.’

Posted 02 Aug 2008 at 4:41 pm ¶

Adam wrote:

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?

Posted 03 Aug 2008 at 8:10 am ¶

Victor Lombardi wrote:

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

Posted 03 Aug 2008 at 10:39 am ¶

jz wrote:

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.

Posted 04 Aug 2008 at 1:23 pm ¶

William Pietri wrote:

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.

Posted 16 Nov 2008 at 2:45 pm ¶

Noise Between Stations