Loading ...
Sorry, an error occurred while loading the content.

RE: [agile-usability] designers and pairing

Expand Messages
  • Andrea L Spray
    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
    Message 1 of 7 , Jun 24, 2006
    • 0 Attachment
      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
      with!

      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.

      Andrea

      --- 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
      > Engineering
      > University of Madeira, Funchal, Portugal
      > Chief Scientist, Constantine & Lockwood Ltd
      >
      >
      >
    • Adrian Howard
      On 23 Jun 2006, at 22:46, Jeff Patton wrote: [snip] ... [snip] Not quite sure what the definition of design is here :-) but I regularly pair with graphic
      Message 2 of 7 , Jun 25, 2006
      • 0 Attachment
        On 23 Jun 2006, at 22:46, Jeff Patton wrote:
        [snip]
        > 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?
        [snip]

        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
        (<http://listserver.dreamhost.com/pipermail/discuss-
        interactiondesigners.com/2006-June/010333.html>) that you might find
        interesting.

        Cheers,

        Adrian
      • Miinalainen, Petteri
        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
        Message 3 of 7 , Jun 26, 2006
        • 0 Attachment
          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: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Myhill, Carl S (GE Infra, Energy)
          Sent: 24. kesäkuuta 2006 3:17
          To: agile-usability@yahoogroups.com
          Subject: RE: [agile-usability] designers and pairing

          This 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 TWa
          Module 2    IDa TWb
          Module 3    IDa TWc
           
          When 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!

          Carl
           
          -----Original Message-----
          From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Jeff Patton
          Sent: 23 June 2006 14:46
          To: agile-usability@yahoogroups.com
          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
          it.

          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?

          thanks,

          -Jeff

          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.

        • hilary coolidge
          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
          Message 4 of 7 , Jun 27, 2006
          • 0 Attachment
            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.

            Hilary Coolidge
            Consultant to Molecular

            __________________________________________________
            Do You Yahoo!?
            Tired of spam? Yahoo! Mail has the best spam protection around
            http://mail.yahoo.com
          Your message has been successfully submitted and would be delivered to recipients shortly.