RE: [agile-usability] designers and pairing
- I was recently tasked with the job of creating a
*team* around 4 designers (myself included) who had
each been working independently at my company anywhere
from 0 to 3 years. I knew that the biggest hurdle
would be to get these guys to work collabortively and
to see that we could do better work together than any
one of us could do working in a silo.
To that end, the first thing I did was establish
bi-weekly (by which I mean twice a week) 'think aloud'
meetings to critique each other's work and set the
expectation that no design would leave our team
without at least an informal review by another member
of the team. These sessions often become group design
whiteboarding sessions where each designer has a copy
of the design and will sketch their recommendations,
each building on the ideas of the others. Its really
amazing what 4 people working on a problem can come up
While not paired designing, its gone a long way to
building trust amonst the team members, has created a
safe environment for designers to critique and be
critiqued, and has supported everyone's development.
Not to mention the improvement to the quality of our
work. Because we've already hashed through so many
issues (both design and usability), applications
designed in this way have been very successful when
tested in labs.
--- Larry Constantine <lconstantine@...> wrote:
> Do I do pair designing? As I have been saying for
> years, the best practice
> in interaction design is multi-disciplinary
> teamwork. Just as in pair
> programming, design teams are for more efficient and
> creative, producing
> higher quality work in less time, for all the same
> reasons as with pair
> programming. My preferred group is 3-5, with a
> variety of skill sets, but
> two is good, too. I also do a fair amount of design
> work on my own, but it
> is rarely my first choice. My sympathy goes out to
> those who have to work
> alone all the time.
> That said, I have my own preferred "style" of work
> that fits my personality
> and cognitive patterns best, which oscillates
> between intense team sessions
> followed by break-up to do solo problem-solving,
> then return to the group. I
> think every designer needs to find the rhythm and
> work style that works best
> for them.
> --Larry Constantine, IDSA
> Director, Lab-USE - The Laboratory for
> Usage-centered Software Engineering
> Professor, Department of Mathematics and
> University of Madeira, Funchal, Portugal
> Chief Scientist, Constantine & Lockwood Ltd
On 23 Jun 2006, at 22:46, Jeff Patton wrote:
> My question to people doing design for a living is: do you pair when
> doing design? If so, is pairing best practice? Are there approaches
> to pairing you'd recommend? How does it normally go for you?
Not quite sure what the definition of "design" is here :-) but I
regularly pair with graphic design / usability folk both when wearing
my programmer hat and when wearing my usability hat. I nearly always
find working with other people more productive than sitting by myself
when helping develop software - no matter what the task at hand may be.
There was a recent thread on the IxDA list on pair programming
interactiondesigners.com/2006-June/010333.html>) that you might find
- This is really interesting thread.About five years ago, me and couple of my ex-collagues tried to convince that working on multi-disciplinary teams is a way to go. Even the clients were very happy with the results, but our work was considered as too expensive and ineffective. ( As in, why there are three people doing the same task?)In my opinion, it makes all the difference in quality of work (pairing or even teaming), but it is very hard to sell it in corporate world where each consultant should be able to bill at least 80% of time at certain rate. Having two of them working on "same task" is often considered prohibitively expensive by sales, project management and also by client!!But, by pairing designer with programmers or technical writer in doing design, you could justify the other person. I see real benefits in that approach as the handover effect would be much smaller if designer would work hand in hand with programmer or with a person who is writing the documentation for the system / product. Have to try to bake this in to my next project!!Petteri
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Myhill, Carl S (GE Infra, Energy)
Sent: 24. kesäkuuta 2006 3:17
Subject: RE: [agile-usability] designers and pairingThis is interesting. We pair up to design. We started doing it because we had a lot of technical writers on hand who were keen to get involved earlier in development. Years of pent up frustration about having to write about software that wasnt designed very well played well for us.We paired a tech writer with an interaction designer and it worked very well. We even had a model like the chief programmer team model, one ID with several TWs, but paired for different modules. That sounds complicated, I mean:Module 1 IDa TWaModule 2 IDa TWbModule 3 IDa TWcWhen we went over to Cooper for some training we were pretty thrilled to see they do the same. They have pair teams of a Design Communicator (former tech writer) and Interaction Designer. The reason Cooper did this, as I understand it, was that IDs would spend ages having good ideas on the white board and would then go for lunch or roller skating or something and not write it down. So they conceived the Design Communicator who was primarily responsible for writing it down. Their role grew however and they are pretty much designers in their own right now (which is what we found too) but they do still have the responsibility for writing it down and presenting the design to the rest of the team.I tried pitching the concept of 'pair designers' internally, hoping to latch on to a parallel with pair programming. Management didnt make the connection but on the ground, it is the way we work.Oops, I stopped lurking - hi!
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Jeff Patton
Sent: 23 June 2006 14:46
Subject: [agile-usability] designers and pairing
A problem with people who do interactiond design and user interface
design work on projects - agile or otherwise - is that they often
work alone. OK, I often work alone. By alone I mean alone doing the
design work - not alone on the project.
I'm teased at my company as being "post-dev" meaning it's been over a
year since I wrote code on a project. But, I miss pair-programming.
I miss active discussion and collaboration. So, on projects when I
do design work, I usually grab someone in a business analysis or
developer role to pair with me while I/we design. They often feel
twitchy - uncomfortable doing that - like we're wasting time. This
is much the same feeling developers feel when they first pair
program. But, once they get past that, spend a few hours developing
this way and see the quality of their work improve, they understand
I had the chance recently to work with rockstar class interaction
designers. [Think of the top name-brand interaction design companies
you know - they're from one of those.] But, basically they pair on
design work. I watched these guys work and noticed they work in ways
very similar to pair programmers. One designer stands at the
whiteboard and "drives." The driver talks out loud - says what he's
doing. He may write a scenario - talk about the user and what
they're doing. The driver may then switch to drawing user interface
on the whiteboard walking through the scencario to test the UI
design. The other pair observes, asks questions, flips through notes
about users, workflow etc.. works to poke holes in the driver's
design. This looks and feel a lot like pair programming - without
the code, IDE, or computer.
I haven't experienced exactly the same thing doing design. For the
programmers reading, it's sort of like pairing with someone who
doesn't normally code. They're present, they listen and can give
feedback - it's just not quite the same.
My question to people doing design for a living is: do you pair when
doing design? If so, is pairing best practice? Are there approaches
to pairing you'd recommend? How does it normally go for you?
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
- I've used pairs while doing rapid paper prototype
testing. We get two people in to do the test and ask
them to talk aloud and note the conversation - the
sticky points where they ask eachother questions etc.
You can also have one person go through an exercise
and then bring a person in who has yet to see the
prototype and ask the first person to explain the
site/tasks to get an idea of how well they understand
the concepts and what might be missing.
Consultant to Molecular
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around