Skill sets for an interaction designer

27 May 2005 - 12:58pm
9 years ago
3 replies
1097 reads
Jeff Isom
2005

My organization is currently debating the role of an interaction designer on Web
application development projects. Luckily, we have strong support for the
position, but we are having trouble defining what they should do. There are two
camps:

1) The interaction designer is a generalist. She/he takes on the role of a
business analyst, defines user requirements, creates prototypes, does the
graphic design, builds the final HTML that will be used by the programmers, and
conducts usability testing. This person would report to the software engineering
group. The feeling from this camp is that this is a much more efficient model
that can produce results much more quickly. It requires a highly skilled person,
but if you are willing to pay, you can find people with those skills.

2) The interaction designer is more specialized. She/he works with a business
analyst and product manager to define requirements, creates wireframes and
low-fidelity prototypes. A graphic designer does the visual look and feel, a
front-end developer creates the HTML, and a usability specialist conducts
usability testing. This person would report to a separate UX group servicing all
engineering products as well as other products designed by the organization. The
feeling of this camp is that specialization allows people to become more skilled
in their area resulting in better designs. They also feel that collaboration
between specialist results in better designs than any one person could create.
They are also concerned that the "one man show" approach is not a sustainable
model because it is too dependant on the ability to find people with all the
skills listed above.

I've been following the thread about "Why hire and ID instead of a software
developer" and there has been some interesting information there.

I'm curious to hear how other organizations define the role of interaction
designer. Who does the role report to? What are the key skills of the
individual? How are the project teams organized? What are the strengths and
weaknesses of the model you are using?

Thanks in advance.

Jeff

------------------------------------------------------------------------------
This message may contain confidential information, and is
intended only for the use of the individual(s) to whom it
is addressed.
------------------------------------------------------------------------------

Comments

27 May 2005 - 4:22pm
Anonymous

Greetings All,

Following the debate on "Why hire and ID instead of a software developer"
and Jeff's inquiry as to the role of ID designer, I would like hazard some
observations based on my experiences while working as a "generalist" as well
as a specialist designer.

While working as a generalist I agree to the results come by quickly but to
a great extent this depends on the scale of the project, project duration,
"ratio" of importance and/or priority attached to various tasks of the ID
designer (business analysis, user study, prototyping, UI design, writing
specs and stylesheets, usability testing etc) in the organization. A
designer being a creative person and over a period of time (after the
euphoria is over) some of these tasks become a more of a drudgery and fail
to excite or motivate the designer to give his best leading to indifferent
or patch-work design or designer quitting the job. For example: if a
communication designer evolves (over a period of time) to become a
generalist s/he would probably not be thrilled to write specs or stylesheet
day in and day out but do it to keep his/her job in most cases. So, this
approach might not work on large projects with long timelines. There are
other subtle/cognitive reasons for this but I guess you get the idea.

Some of my best work has come while working as a jack of all trade and
master of one (may be two) in a group of similar generalist specializing in
their own niche areas. Being generalist each one of us understood the
nitty-gritty of the others works and complemented/supported/augmented others
work. Such teams are best suited for large projects.

Your mileages may vary.

On 5/27/05, Jeff Isom <IsomJD at ldschurch.org> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> My organization is currently debating the role of an interaction designer
> on Web
> application development projects. Luckily, we have strong support for the
> position, but we are having trouble defining what they should do. There
> are two
> camps:
>
> 1) The interaction designer is a generalist. She/he takes on the role of a
> business analyst, defines user requirements, creates prototypes, does the
> graphic design, builds the final HTML that will be used by the
> programmers, and
> conducts usability testing. This person would report to the software
> engineering
> group. The feeling from this camp is that this is a much more efficient
> model
> that can produce results much more quickly. It requires a highly skilled
> person,
> but if you are willing to pay, you can find people with those skills.
>
> 2) The interaction designer is more specialized. She/he works with a
> business
> analyst and product manager to define requirements, creates wireframes and
> low-fidelity prototypes. A graphic designer does the visual look and feel,
> a
> front-end developer creates the HTML, and a usability specialist conducts
> usability testing. This person would report to a separate UX group
> servicing all
> engineering products as well as other products designed by the
> organization. The
> feeling of this camp is that specialization allows people to become more
> skilled
> in their area resulting in better designs. They also feel that
> collaboration
> between specialist results in better designs than any one person could
> create.
> They are also concerned that the "one man show" approach is not a
> sustainable
> model because it is too dependant on the ability to find people with all
> the
> skills listed above.
>
> I've been following the thread about "Why hire and ID instead of a
> software
> developer" and there has been some interesting information there.
>
> I'm curious to hear how other organizations define the role of interaction
> designer. Who does the role report to? What are the key skills of the
> individual? How are the project teams organized? What are the strengths
> and
> weaknesses of the model you are using?
>
> Thanks in advance.
>
> Jeff
>
>
> ------------------------------------------------------------------------------
> This message may contain confidential information, and is
> intended only for the use of the individual(s) to whom it
> is addressed.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Welcome to the Interaction Design Group!
> To post to this list ....... discuss at ixdg.org
> (Un)Subscription Options ... http://discuss.ixdg.org/
> Announcements List ......... http://subscribe-announce.ixdg.org/
> Questions .................. lists at ixdg.org
> Home ....................... http://ixdg.org/
>

Vikram
National Institute of Design, India

27 May 2005 - 4:41pm
Jack L. Moffett
2005

Jeff,

Your description of Camp #1 is a perfect description of my current position,
so I figured I ought to respond. I work for a small software development
firm that has a long history of including ID in its process (it's first hire
was a designer). We have a number of products, and we also develop custom
solutions.

We have another designer who's main responsibility is the marketing side
(printed materials, website, etc.), although he is sometimes tapped to help
with development. Additionally, we have a product manager that is a trained
interaction designer. His main contribution in terms of ID is defining
requirements for our products. I work closely with him on our products and
seek his input whenever I feel the need for a second opinion.

> Who does the role report to?

My supervisor is a software engineer, and our senior project manager.
However, I end up "reporting to" whoever is managing a project I'm working
on. As the only designer solely responsible for interaction design, I work
on most projects. I often directly support our sales people and CEO.

> What are the key skills of the individual?

I don't really do any business analysis, per se. I do user research and
define requirements. I create prototypes ranging from paper sketches to
interactive animations in Director. I do the graphic design, and I build the
final HTML used by the developers. I have done some informal usability
testing in the past, and would like to do more. However, our project
schedules have not been including it of late (see the weaknesses).

> How are the project teams organized?

Program managers are our point of contact with the customer, of which we
have a few, all fairly senior members of the company. Project managers are
software engineers who manage the rest of the developers and me. Typically,
SEs are assigned to a single project for the life of that project, and then
moved to another project. I, on the other hand, end up juggling most of the
projects going on at any point in time. Most of my time on a project is
spent up front, with support as needed during the implementation.

> What are the strengths and weaknesses of the model you are using?

The strengths are that I have a good working relationship with almost every
developer in the company. They know what to expect from me, and we
communicate well. I believe they consider me to be, at some level, one of
them, and they always come to me when they have questions about how
something should be implemented. This is a very good thing. The company
benefits due to the fact that I get everything done on time and with a high
level of quality, and they only have to pay for one of me. Finally, the fact
that I am responsible for all UI design lends tight consistency to our
products and solutions.

Weaknesses:
I'm often stretched thin, sometimes to the point that I can't provide all of
the artifacts I usually create for the developers. There are several ongoing
projects that I am not involved in due to the fact that I'm already fully
booked. Most of the time, my involvement with our products is spotty, as my
superiors prefer me to spend my time on billable work. Usability testing of
any kind is rarely done anymore, and I don't have the time to push for it.
Although, I must point out that for quite a few of our projects, we are not
the primary, and the testing is being handled by somebody else (the prime or
the customer). I do have other designers to bounce ideas off of, but its not
the same as having multiple designers working on a problem. Finally, if I'm
on vacation or otherwise unavailable, anyone who needs me just has to wait
(or proceed without my input).

It is my hope that as business continues to pick up, and the company
continues to grow, I will have the opportunity to form an interaction design
group more along the lines of your Camp #2.

I hope this has been useful.

Best,
Jack

Jack L. Moffett
Interaction Designer
inmedius
412.690.2360 x219
http://www.inmedius.com

Form follows function -
that has been misunderstood.
Form and function should be one,
joined in a spiritual union.

- Frank Lloyd Wright

***********************************************************************
Confidentiality Note: The information contained in this email and document(s) attached are for the exclusive use of the addressee and contains confidential, privileged and non-disclosable information. If the recipient of this email is not the addressee, such recipient is strictly prohibited from reading, photocopying, distributing or otherwise using this email or its contents in any way.
***********************************************************************

27 May 2005 - 11:02pm
Navneet Nair
2004

I've been in both camps really starting out as part of the Engineering team,
our UX group was part BA, part IxD, part HTML development and even MarCom
rolled into one. The challenge as Jeff mentioned was to find people who were
comfortable with all these aspects. At that time the team was generalist
heavy and it was really effective working this way. And really speaking this
works well if the team is small and as a development process this fits in
well with Agile or Scrum oriented processes. Also this might be more suited
to early stage products or exploratory design.

With changes in the team skill sets we oriented ourselves to a more
specialist functionality. The UX team is now re-aligned as part of the
Product Management group and the IxD team takes in inputs from BAs, produces
low fidelity prototypes which are already compliant with a well established
visual guideline, which are converted to high fidelity prototypes by HTML
developers.

Both the camps have their advantages and disadvantages and it really is up
to the team's skill sets on how well they (and the team, in turn) perform.
I've seen that specialist designers feel out of place in a camp 1 atmosphere
while generalists can be frustrated more easily in a camp 2 place.

So if you're working in a project oriented environment, it might be
worthwhile resourcing the project based on the project needs and team
alignment towards either of the camps. If it is a product development
environment, camp 2 might be the way to go for established products and camp
1 for newer products. I don't think either camp is right or wrong, it
ultimately the people who make the difference. Good designers will come up
with good designs no matter which camp you put them into...

My 2¢
Navneet

----------------------------------------------------
Navneet Nair
Interaction Architect
onClipEvent: form follows function();
----------------------------------------------------
Website: http://www.onclipevent.com
Blog: http://www.onclipevent.com/enterframe/

Syndicate content Get the feed