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

31 Mar 2009 - 9:50am
5 years ago
12 replies
1762 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: http://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
http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
UIE Web App Summit, 4/19-4/22: http://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: http://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
> http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
> UIE Web App Summit, 4/19-4/22: http://webappsummit.com
>
>
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://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:

> 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: http://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
> http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
> UIE Web App Summit, 4/19-4/22: http://webappsummit.com
>
>
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help

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:
>> http://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
>> http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
>> UIE Web App Summit, 4/19-4/22: http://webappsummit.com
>>
>>
>>
>>
>> ________________________________________________________________
>> Welcome to the Interaction Design Association (IxDA)!
>> To post to this list ....... discuss at ixda.org
>> Unsubscribe ................ http://www.ixda.org/unsubscribe
>> List Guidelines ............ http://www.ixda.org/guidelines
>> List Help .................. http://www.ixda.org/help
>>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

31 Mar 2009 - 1:57pm
Angel Marquez
2008

oh yea, my summation/conclusion based on my analysis/findings is
that:users/people/humans
need to know what they are looking for before they can find it which makes
it very necessary for something that wants to be found have an accurate name
and description.

I think...

On Tue, Mar 31, 2009 at 11:42 AM, Angel Marquez <angel.marquez at gmail.com>wrote:

> 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:
>>> http://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
>>> http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
>>> UIE Web App Summit, 4/19-4/22: http://webappsummit.com
>>>
>>>
>>>
>>>
>>> ________________________________________________________________
>>> Welcome to the Interaction Design Association (IxDA)!
>>> To post to this list ....... discuss at ixda.org
>>> Unsubscribe ................ http://www.ixda.org/unsubscribe
>>> List Guidelines ............ http://www.ixda.org/guidelines
>>> List Help .................. http://www.ixda.org/help
>>>
>> ________________________________________________________________
>> Welcome to the Interaction Design Association (IxDA)!
>> To post to this list ....... discuss at ixda.org
>> Unsubscribe ................ http://www.ixda.org/unsubscribe
>> List Guidelines ............ http://www.ixda.org/guidelines
>> List Help .................. http://www.ixda.org/help
>>
>
>

31 Mar 2009 - 2:26pm
Andy Polaine
2008

You mean I should drop my PhD? ;-)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=40833

31 Mar 2009 - 2:55pm
Alan James Salmoni
2008

Andy: "You mean I should drop my PhD? ;-) "

It (sometimes) doesn't help much!
See the post by Rich Rogan http://www.ixda.org/discuss.php?post=30388

Back to the initial point: the important thing is that if you are
having a medical emergency, then you want someone with at least a
base medical training to be there - a set of common skills and
understandings about how the body functions and how it can be put
right when it goes wrong.

I guess there are two problems: 1) which skills and knowledge
comprise this field; and 2) how can we get people outside of us to
agree on what skills and knowledge are required so that they don't
start making the main criteria as "must have 5 years C GUI
experience"

I get the impression that the community is quite happy to deal with
skills rather than roles but this often falls over when recruiters
are being dealt with. Quite often, they need a nice single title to
summarise everything because they deal with so many different roles.
Stepping outside of the norm can cause serious problems in getting
jobs if you're not perceived as a guru (just talking from my own
experience here - I sincerely hope other people's is better)

Well, we're supposed to be experts in people's experiences - why
don't we find out how we really are perceived in the wider world so
we can address any discrepancies?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=40833

31 Mar 2009 - 9:00pm
Marcus Frank
2009

The idea of a UX team made up of deep generalists is a wonderful fantasy. I think the idea of staff having depth beyond a particular specialty is a necessity in a digital world where boundaries are blurring between information and entertainment channels and the ways people engage with them. But, I can count on one hand the number of individuals I have worked with during my career that can truly function well as an IA, IxD, visual designer, programmer, marketing strategist and copy writer let alone the litany of other skills Jared suggests. An achievable and sensible reality lies between Jared's ideal and a micro-focused specialist.

I also agree with Nancy Broden's comment above that what is driving the current "trend" toward generalists in position postings is the economy. We've been here before with the dreaded Web Master job descriptions of the past and here we go again.

Let's agree that we all need to continue to diversify our knowledge base and skills, but let's stop short of becoming a jack of all trades and master of none. Focus in our field as in business is a key to success.

31 Mar 2009 - 10:18pm
Dave Malouf
2005

regarding the difficulty of hiring the right team:

What I've noticed about great design studios is that they are
uncompromising. Being great can't be done quickly and well it isn't
easy.

I think this is part of the underlying message to what Jared is
suggesting. You need great people.

-- dave

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=40833

1 Apr 2009 - 12:27pm
Jared M. Spool
2003

On Mar 31, 2009, at 10:54 AM, Nancy Broden wrote:

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

Hi Nancy,

We've researched this quite a bit. You're correct that it has to do
with economic factors, but it's not related to the global or national
economies. Instead it's related to the organization's internal economy.

It has to do with internal demand for the skill sets. If there's
enough work to justify someone who is specialized in an area (such as
IA), then the organization will seek to hire a person like that.

But for most organizations, it's rare they can keep someone
specialized busy full time. In those cases, they seek more
generalists. (Sometimes their postings are poorly written and they say
they are hiring someone with a specialty, but then, in the job
description and requirements, they list more generalized skills and
experience. This is fairly common.)

Also, keep in mind that among the UX disciplines, real specialists are
actually rare. A specialist is someone who has significant general
training, but in-depth knowledge in one or more specialties.

For example, in medicine, doctors train in general medicine first for
many years, then they pick their specialty. As residents, they rotate
through specialties, gaining knowledge and skills for each one, before
they pick the one they'll focus their career on. That way, an
orthopedic surgeon is trained to deliver babies, though after a few
years, they are probably not as up-to-date on the latest advancements
as a practicing obstetrician.

In design, it's rare that someone who has chosen IA as a career path
is skilled in visual design, user research techniques, and
copywriting. In our training institutions, we don't have an equivalent
notion to resident rotation, where those new to the field get to
experience the entire thing, then choose their specialty. So, there
are few specialists.

Instead, there are what we at UIE call compartmentalists: people who
have trained completely in a single area with little-to-no applicable
skills in other areas. (They could be excellent IAs, but have no
better skills at visual design than a layman.) These people will be
less valuable to organizations that don't have economies to keep that
person busy every working hour.

If you're interested, I've written more about our research here:
http://www.uie.com/articles/ideal_UX_team/

I think what you see in the ebbs and flows of the global economy (2001
& 2008) is that companies are paying more attention to what they can
and can't afford. They are realizing they were wasting resources on
individuals who didn't have the skills necessary to do the entire job,
therefore they are more careful in their hiring practices (and a
little more ruthless when it comes to restructuring).

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
http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
UIE Web App Summit, 4/19-4/22: http://webappsummit.com

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
http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
UIE Web App Summit, 4/19-4/22: http://webappsummit.com

2 Apr 2009 - 12:28pm
Jared M. Spool
2003

On Apr 2, 2009, at 8:52 AM, Sarah Kampman wrote:

> "In our training institutions, we don't have an equivalent notion to
> resident rotation, where those new to the field get to experience the
> entire thing, then choose their specialty."
>
> That may be true; I didn't go to school for UX. But I'd argue that
> start-ups provide this type of skills rotation. I've worked at more
> than
> one small company where I've been, as needed: UI designer, usability
> specialist, webmaster, tech writer, trainer, graphic designer, project
> manager, front-end coder, QA, marketing copywriter, and sales
> engineer.
> I'd never have gotten all that experience in a large company or as a
> solo contractor. So maybe a stint in a start-up how to move from
> compartmentalist to specialist. ;-)

Sarah,

You make an excellent point. What you describe is working as a
generalist. Spending time working as a generalist will certainly
rotate you through the specialties.

However, what you find in a true resident rotation program is a
specialist mentor in each field. So, as the residents rotate through
each specialty (usually for a period of six to eight weeks), they are
being taught, critiqued, and guided by someone with experience.

The generalist environment, especially in a startup, doesn't typically
lend itself to that type of mentorship. So, while a startup-based
generalist is getting an opportunity to be a jack of all trades, they
aren't getting a structured educational aspect. It's likely that many
of the habits, tricks, and techniques they develop are not the most
effective (and certainly not the best-of-breed) for that speciality.

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
http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
UIE Web App Summit, 4/19-4/22: http://webappsummit.com

3 Apr 2009 - 7:51pm
Lisa Trager
2009

As someone who is currently looking for full time employment in this
field, what I hear Jared say is music to my ears! I started out as
an Information Architect/Content Strategist and then over the last
ten years have inverted that to being more of a Content
Strategist/Information Architect. My background by the way is
Director in television production.

Bottom line - when I worked in a shop where lines were strictly drawn
between IA and CS, there definitely was a problem with one or both of
us being over inundated with work. Although I could have helped on
the IA side, there was a sense of turf wars. In the end I was the
one that was laid off when work slowed down due to the client pulling
back the amount of work.

I find that most people in our world have interesting, eclectic
backgrounds that would make sharing of roles very practical. Not
only that, having the opportunity to take on different roles on
different projects would help with burn-out and help to keep things
more challenging and interesting.

I suspect that one of the benefits of working in a small shop is that
generalists are often more in demand to carry the weight. From a
political point of view, that may also be a good thing as everyone
can then work more as equals vs stars and plebeians.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=40833

Syndicate content Get the feed