"Help! Is there a Cardiothoracic Surgeon in the room?"

31 Mar 2009 - 9:50am

Last reply: 6 years ago

12 replies

2211 reads

Jared M. Spool

2003

In an emergency, you fetch a doctor.

Interestingly, there are no doctors. Or, more accurately, there are
many doctors that you don't want to help you in a medical emergency.
(My good friend, with the Ph.D. in 15th Century English Literature, is
not the person you want to deliver the baby, even if he was the only
Doctor on the island.)

Many qualified medical professionals don't have an official "doctor"
title. Rehabilitation specialists, nurse practitioners, and myriad
other professionals deliver trained, quality healthcare despite
missing that quintessential label.

In an emergency, a layman looks for a doctor. It's a useful term and
it works great.

If you're having a heart attack, you might want a Cardiothoracic
Surgeon. Certainly, if the result you want is to have your chest cut
open, your ribs spread, and your heart massaged. On the operating
table, this is a great result. In the foyer of the Opera House, an EMT
might in fact be better qualified to help you. (Cardiothoracic
surgeons are doctors, while EMTs are not, usually.)

Some of you may know that over the past eight years, we've been
researching what makes the ideal UX team. One of our early results is
that ROLES DON'T MATTER, SKILLS DO. It doesn't matter if a team has an
interaction designer or information architect. It does matter that
interaction design and information architecture skills are present
amongst the team.

Teams with the right skills are more likely to produce great user
experiences. Teams missing the right skills are very unlikely to
produce anything exciting or delightful. (Of course, we can't say
'never'. Even a blind squirrel finds an acorn every so often. But, if
I'm staffing a team, I want to do so in a way that will have the best
odds, no?)

Our research showed there are core skills: interaction design,
information architecture, user research, visual design, information
design, fast iteration management, copywriting, and editing. There are
also what we call enterprise skills, some of which are: analytics,
development methods, design-to-development documentation, ethnography,
social networks, marketing, technology, business knowledge, and domain
knowledge. (If you're interested, I wrote about these in more depth
and gave teams a tool to assess their strengths here: www.uie.com/articles/assessing_ux_teams/
)

On the best teams, every team member has a solid foundation in all of
these skills. That's important because it gives the team flexibility.
No matter who is available, no matter what needs to get done, a
competent and informed job is possible.

When teams are made up of specialists -- teams that have only one
person who can do a thorough job with a particular skill -- those
individuals run into the "binary workload problem" -- either they are
overworked or unnecessary. There is either too much work for them,
thus creating a backlog, or they don't have anything to do, thus
wasting a valuable resource.

The best teams still have individuals who are top-of-their-game in one
skill area or another. People who are up to date on the latest
thinking and techniques. But, because the entire team is fully
competent in the skill area, they can leverage their exceptional
skills in those areas on the rare project that demands it, plus act as
an advisor and mentor to the rest of the team, thereby continuing to
raise the entire team's skills further.

In my opinion, we'll see less emphasis on individual specialist job
titles going forward. We're already seeing that in the job postings
that have come out in the last year. They tend to be looking for more
generalist individuals with a well-rounded, rich set of skills. Many
teams can't afford to have members who are missing the core skills,
even if the skills they have are rich unto themselves.

(This goes beyond the "T-shaped person" concept that's been floating
around, or its more recent cousin, the "broken comb shaped person."
We're talking a full hair brush here. I promise to never use that
metaphor again.)

UX is not something unto itself. UX is a synergy of all the skills of
the team. The more skills and the richer each team member is, the
better the UX that will result.

And you probably wouldn't want to check into a hospital filled only
with extremely talented cardiothoracic surgeons, unless chest surgery
is the solution to every problem you have.

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
uie.com Blog: uie.com/brainsparks Twitter: jmspool
UIE Web App Summit, 4/19-4/22: webappsummit.com

Comments

31 Mar 2009 - 12:41pm

Andrei Herasimchuk

2004

--
Andrei Herasimchuk
Chief Design Officer, Involution Studios
e. andrei at involutionstudios.com
c. 408.306.6422

On Mar 31, 2009, at 7:50 AM, Jared Spool <jspool at uie.com> wrote:

> In an emergency, you fetch a doctor.
>
> Interestingly, there are no doctors. Or, more accurately, there are
> many doctors that you don't want to help you in a medical emergency.
> (My good friend, with the Ph.D. in 15th Century English Literature,
> is not the person you want to deliver the baby, even if he was the
> only Doctor on the island.)
>
> Many qualified medical professionals don't have an official "doctor"
> title. Rehabilitation specialists, nurse practitioners, and myriad
> other professionals deliver trained, quality healthcare despite
> missing that quintessential label.
>
> In an emergency, a layman looks for a doctor. It's a useful term and
> it works great.
>
> If you're having a heart attack, you might want a Cardiothoracic
> Surgeon. Certainly, if the result you want is to have your chest cut
> open, your ribs spread, and your heart massaged. On the operating
> table, this is a great result. In the foyer of the Opera House, an
> EMT might in fact be better qualified to help you. (Cardiothoracic
> surgeons are doctors, while EMTs are not, usually.)
>
> Some of you may know that over the past eight years, we've been
> researching what makes the ideal UX team. One of our early results
> is that ROLES DON'T MATTER, SKILLS DO. It doesn't matter if a team
> has an interaction designer or information architect. It does matter
> that interaction design and information architecture skills are
> present amongst the team.
>
> Teams with the right skills are more likely to produce great user
> experiences. Teams missing the right skills are very unlikely to
> produce anything exciting or delightful. (Of course, we can't say
> 'never'. Even a blind squirrel finds an acorn every so often. But,
> if I'm staffing a team, I want to do so in a way that will have the
> best odds, no?)
>
> Our research showed there are core skills: interaction design,
> information architecture, user research, visual design, information
> design, fast iteration management, copywriting, and editing. There
> are also what we call enterprise skills, some of which are:
> analytics, development methods, design-to-development documentation,
> ethnography, social networks, marketing, technology, business
> knowledge, and domain knowledge. (If you're interested, I wrote
> about these in more depth and gave teams a tool to assess their
> strengths here: www.uie.com/articles/assessing_ux_teams/ )
>
> On the best teams, every team member has a solid foundation in all
> of these skills. That's important because it gives the team
> flexibility. No matter who is available, no matter what needs to get
> done, a competent and informed job is possible.
>
> When teams are made up of specialists -- teams that have only one
> person who can do a thorough job with a particular skill -- those
> individuals run into the "binary workload problem" -- either they
> are overworked or unnecessary. There is either too much work for
> them, thus creating a backlog, or they don't have anything to do,
> thus wasting a valuable resource.
>
> The best teams still have individuals who are top-of-their-game in
> one skill area or another. People who are up to date on the latest
> thinking and techniques. But, because the entire team is fully
> competent in the skill area, they can leverage their exceptional
> skills in those areas on the rare project that demands it, plus act
> as an advisor and mentor to the rest of the team, thereby continuing
> to raise the entire team's skills further.
>
> In my opinion, we'll see less emphasis on individual specialist job
> titles going forward. We're already seeing that in the job postings
> that have come out in the last year. They tend to be looking for
> more generalist individuals with a well-rounded, rich set of skills.
> Many teams can't afford to have members who are missing the core
> skills, even if the skills they have are rich unto themselves.
>
> (This goes beyond the "T-shaped person" concept that's been floating
> around, or its more recent cousin, the "broken comb shaped person."
> We're talking a full hair brush here. I promise to never use that
> metaphor again.)
>
> UX is not something unto itself. UX is a synergy of all the skills
> of the team. The more skills and the richer each team member is, the
> better the UX that will result.
>
> And you probably wouldn't want to check into a hospital filled only
> with extremely talented cardiothoracic surgeons, unless chest
> surgery is the solution to every problem you have.
>
> Jared
>
> Jared M. Spool
> User Interface Engineering
> 510 Turnpike St., Suite 102, North Andover, MA 01845
> e: jspool at uie.com p: +1 978 327 5561
> uie.com Blog: uie.com/brainsparks Twitter: jmspool
> UIE Web App Summit, 4/19-4/22: webappsummit.com
>
>
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ www.ixda.org/unsubscribe
> List Guidelines ............ www.ixda.org/guidelines
> List Help .................. www.ixda.org/help

31 Mar 2009 - 12:54pm

Nancy Broden

2005

Let me first say that I agree with Jared's POV on the value of being a
generalist.

As for this:
> In my opinion, we'll see less emphasis on individual specialist job
> titles going forward. We're already seeing that in the job postings
> that have come out in the last year. They tend to be looking for
> more generalist individuals with a well-rounded, rich set of skills.
> Many teams can't afford to have members who are missing the core
> skills, even if the skills they have are rich unto themselves.

I think the rise in interest in people with broad skills has a lot to
do with the economy. Every time it goes down the toilet, employers
want people who can fill more than one role. When the economy improves
and more bodies are needed, that pressure is alleviated and employers
become less picky and demanding. It happened in 2001 and again in 2008.

Nancy

--------------------------------
Nancy Broden
nancy.broden at gmail.com

31 Mar 2009 - 12:58pm

Andrei Herasimchuk

2004

Damn iPhone buttons.

That last message was supposed to say:

"I think I love you, Jared. "

And yes, watching this bickering is a little too much for me on the
enjoyment scale. Pots and kettles and all.

Once the fighting is over, someone will remember to bring in the
visual people to the table and then things can continue where they
left off in 1996 before people thought that splitting up all of the
skills was a good idea.

--
Andrei Herasimchuk
Chief Design Officer, Involution Studios
e. andrei at involutionstudios.com
c. 408.306.6422

On Mar 31, 2009, at 7:50 AM, Jared Spool <jspool at uie.com> wrote:

31 Mar 2009 - 1:42pm

Angel Marquez

2008

I totally wrote the doctor, mechanic, musician, specialist post and then
deleted it before sending. I wanted a cello player not a stand up bass, yea
they are both stringed instruments, I only do transmissions I can refer you
to a brake specialist, I know a great plastic surgeon my ex wife uses etc...
I've decided even though these arguments are ridiculous based on the fact
that every time it comes to an end, that's just what happens. It ends;
although, the name is very important for findability and a good example of
best practice. The entire use of self documenting is what you all should
strive for.

Just recently I've been looking for more custom type leads for front end
'functions' with google and coming up short. Perfect example was posted last
night. The skills you employ are similar to a function or a collection of
functions that would fall under the design class, right?

If everyone agreed on what was named what your search time would have to
branch off in so many directions when under the gun. I'm all for branching
off into tangents; but, when you need to actually deliver and your
'researching' a clean channel is nice, ideal, desirable. If someone wants to
steer with there teeth and use their hands for the gas and clutch, let em,
just get out of the car.

Changing the name on a whim would be the same as changing the names in the
names of functions in code which in turn would be easier with a CLI and the
system built with this frequent urge in mind.

#designer

interaction (idea) {
return deliverable
}
visual (wireframe) {
return deliverable
}
database (functional-spec) {
return deliverable
}

On Tue, Mar 31, 2009 at 10:58 AM, Andrei Herasimchuk <
andrei at involutionstudios.com> wrote:

> Damn iPhone buttons.
>
> That last message was supposed to say:
>
> "I think I love you, Jared. "
>
> And yes, watching this bickering is a little too much for me on the
> enjoyment scale. Pots and kettles and all.
>
> Once the fighting is over, someone will remember to bring in the visual
> people to the table and then things can continue where they left off in 1996
> before people thought that splitting up all of the skills was a good idea.
>
> --
> Andrei Herasimchuk
> Chief Design Officer, Involution Studios
> e. andrei at involutionstudios.com
> c. 408.306.6422
>
> On Mar 31, 2009, at 7:50 AM, Jared Spool <jspool at uie.com> wrote:
>
> In an emergency, you fetch a doctor.
>>
>> Interestingly, there are no doctors. Or, more accurately, there are many
>> doctors that you don't want to help you in a medical emergency. (My good
>> friend, with the Ph.D. in 15th Century English Literature, is not the person
>> you want to deliver the baby, even if he was the only Doctor on the island.)
>>
>> Many qualified medical professionals don't have an official "doctor"
>> title. Rehabilitation specialists, nurse practitioners, and myriad other
>> professionals deliver trained, quality healthcare despite missing that
>> quintessential label.
>>
>> In an emergency, a layman looks for a doctor. It's a useful term and it
>> works great.
>>
>> If you're having a heart attack, you might want a Cardiothoracic Surgeon.
>> Certainly, if the result you want is to have your chest cut open, your ribs
>> spread, and your heart massaged. On the operating table, this is a great
>> result. In the foyer of the Opera House, an EMT might in fact be better
>> qualified to help you. (Cardiothoracic surgeons are doctors, while EMTs are
>> not, usually.)
>>
>> Some of you may know that over the past eight years, we've been
>> researching what makes the ideal UX team. One of our early results is that
>> ROLES DON'T MATTER, SKILLS DO. It doesn't matter if a team has an
>> interaction designer or information architect. It does matter that
>> interaction design and information architecture skills are present amongst
>> the team.
>>
>> Teams with the right skills are more likely to produce great user
>> experiences. Teams missing the right skills are very unlikely to produce
>> anything exciting or delightful. (Of course, we can't say 'never'. Even a
>> blind squirrel finds an acorn every so often. But, if I'm staffing a team, I
>> want to do so in a way that will have the best odds, no?)
>>
>> Our research showed there are core skills: interaction design, information
>> architecture, user research, visual design, information design, fast
>> iteration management, copywriting, and editing. There are also what we call
>> enterprise skills, some of which are: analytics, development methods,
>> design-to-development documentation, ethnography, social networks,
>> marketing, technology, business knowledge, and domain knowledge. (If you're
>> interested, I wrote about these in more depth and gave teams a tool to
>> assess their strengths here:
>> www.uie.com/articles/assessing_ux_teams/ )
>>
>> On the best teams, every team member has a solid foundation in all of
>> these skills. That's important because it gives the team flexibility. No
>> matter who is available, no matter what needs to get done, a competent and
>> informed job is possible.
>>
>> When teams are made up of specialists -- teams that have only one person
>> who can do a thorough job with a particular skill -- those individuals run
>> into the "binary workload problem" -- either they are overworked or
>> unnecessary. There is either too much work for them, thus creating a
>> backlog, or they don't have anything to do, thus wasting a valuable
>> resource.
>>
>> The best teams still have individuals who are top-of-their-game in one
>> skill area or another. People who are up to date on the latest thinking and
>> techniques. But, because the entire team is fully competent in the skill
>> area, they can leverage their exceptional skills in those areas on the rare
>> project that demands it, plus act as an advisor and mentor to the rest of
>> the team, thereby continuing to raise the entire team's skills further.
>>
>> In my opinion, we'll see less emphasis on individual specialist job titles
>> going forward. We're already seeing that in the job postings that have come
>> out in the last year. They tend to be looking for more generalist
>> individuals with a well-rounded, rich set of skills. Many teams can't afford
>> to have members who are missing the core skills, even if the skills they
>> have are rich unto themselves.
>>
>> (This goes beyond the "T-shaped person" concept that's been floating
>> around, or its more recent cousin, the "broken comb shaped person." We're
>> talking a full hair brush here. I promise to never use that metaphor again.)
>>
>>