Re: What's Interaction Design?
- Thanks all for the comments back.
Nuno, thanks for the reference to UIDesign.net. I'd read the Cooper
interview, but not the Raskin comments afterwards. Basically if
these well-respected people don't have a common definition of
Interaction Design, I don't expect I'll find one.
The stuff I'm trying to label are the decisions made before we know
what might be on the user interface - or if there should be a user-
interface at all. I'm seeing Interaction Design addressing questions
like: "Who are the users?", "What do they want?", "How should they
interact with some system to get it?", "Who else cares and what do
they want?". Once we've decided what the users should do with the
system, and basically what interaction contexts might contain, we can
go about designing user interface and measuring its effectiveness.
But no amount of good user-interface will compensate for
misunderstanding the goal of a user - or leaving an important user
Paul Hodgets wrote:
>Are these papers available somewhere? I'd like to take a lookif I could.<
They're simple experience reports and still a work in progress.
XP/Agile Universe and OOPSLA have accepted drafts. They'll be
presented at each of those conferences. It's feedback from those
groups that prompted my post. I'd asserted that some form of
Interaction Design should be used - but then only gave information
about U-CD. Which prompted the fair question "What is interaction
design exactly? And, what other forms are there?" - Which maybe
should have been my real posted question to this group.
Nuno Nunez wrote:
>Assuming the broad definition, it seams obvious that interactiondesign
starts at early project inception when task cases (or task flows) are
identified and the structure of use is captured and worked. This is
especially true when work or process re-engineering are a concern
should always be in my opinion). The key issue here is that, assuming
interaction design starts early in the project lifecycle, then it
influences the system architecture... And perhaps that is the major
breakthrough in the last couple of years (together with what is known
OOUID). Unfortunately it seams that those important aspects are not
interesting in a world of x-something or agile-something!!!<
Good comments. I'll focus on the comment on interaction design
influencing system architecture. We've had good luck bringing
developers, business people, end-users and UI people together in
collaborative U-CD sessions. We find that developers and UI people
come away with a better understanding of why things are the way they
are. And, business people and end-users understand how doing things
a little differently can be more cost effective and faster. U-CD
gives us a framework to make sure we ask and answer all those right
questions. We end up calling this agile because it's highly
collaborative, we throw around lots of 3x5 cards, we churn out lots
of poster-sized post-its then roll them up and call them design
documents. We may be guilty of calling it agile because it doesn't
look like anything we used to do.
Nuno Nunez also wrote:
>I'm sorry but I can't figure out how you can practice interactiondesign as
an activity in XP without creating something which is not XP at
the other hand I can't see how UsageCD can be classified as an agile-
when Larry and Lucy are strong proponents of upfront-modeling and
agile development can cope with upfront specification of dozens of
cases without iterative or evolutionary development!!! I hope that
doesn't think about using the excellent modeling techniques of
while doing XP, and them call it X-UsageCD...<
This is a fun one to respond to. I've never seen an XP project that
could be called XP including the one I spent a year on that was set
up by Kent Beck himself. We're definitely not doing pure XP. We do
XP style planning, regular iterations, unit-testing, refactoring,
pair programming.. yada yada yada. But, we front-end this entire
process with a collaborative U-CD session. We "re-brand" our
resulting task-cases as user-stories then use them to plan releases
and iterations. Things get "agile" when we realize we made a mistake
and need to change our minds about what to develop. We go back to
the user roles and task cases and make our decisions with what we
hope are interaction designer's sensibilities.
On iterative development and upfront specification of lots of task
cases, I find that when XP people bristle at big upfront design,
they're generally talking about the architecture & objects under the
interactions. In practice we don't decide any of that stuff up
front. We still have lots of room to make mistakes and change that
design without affecting the interactions we agreed on together.
There's still plenty of room to really evolve the architecture over
the course of many iterations. We may let interaction requirements
push some major architectural issues like "the performance of
interactions required for this user may be better served by a Java
Swing UI rather than an HTML/Servlet based approach."
I hope we don't see an X-UsageCD either. I'll make it a career goal
right now to never invent a software development methodology. I
couldn't take the resulting abuse ;-) - Makes me think of the joke
you've likely all heard: "What's the difference between a
methodologist and a terrorist? You can negotiate with a terrorist."
Larry Constantine wrote:
>There is also a political issue, which is that interaction design ismore trendy than UI design.<
I'm adopting the more trendy interaction design label. The political
issue I keep fighting in the XP/Agile community is: "UI designers are
the people you bring in to make things pretty just before you ship."
The emphasis in XP and agile processes to involve the "customer" or
user in the process is a good one. Now if we can just get someone in
there to ask the customer the right questions, we may just get
somewhere. So, coming full circle, that skill of knowing what
questions to ask and how to respond to that with an appropriate piece
of software - can I get away with calling that "Interaction Design?"
Someone also forwarded me this link:
thanks Peter. I haven't digested this article yet, but it may have
some useful ideas as well.
Thanks again for everyone's comments. Lots of good information and
lots of good ideas to consider.
Development Team Lead
(801) 924 - 6924
"We can't solve problems by using the same kind of thinking we used
when we created them."