RE: [agile-usability] designers and pairing
- 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: email@example.com [mailto:firstname.lastname@example.org] 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: email@example.com [mailto:firstname.lastname@example.org] 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