Skill sets for an interaction designer

27 May 2005 - 12:58pm
11 years ago
3 replies
1579 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: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