in Agile, Process

Pair Design – Less Wireframes, More Collaboration

In my previous post, I talked about how applying grid focus to a sketching activity can allow for improved integration between the work of UX, Visual Design, and front-end developer disciplines. One natural follow-on activity to having explicitly defined or sketched out a page grid during sketching is to then work on more detailed designs in pairs, i.e. to Pair Design.

What is Pair Design?

The idea of Pair Design is, of course, based on the concept of Pair Programming.  But it is more a hybrid rather than a wholesale translation of the model.  Here, instead of having two people with the same skill sets collaborate side-by-side, we are pairing people with different skill sets and perspectives.  In other words, the front-end developer might pair with the graphic designer and build the grid created during the sketching session, the graphic designer ‘debugging’ it from a visual design perspective, while also being made aware by the front-end developer of the range of dynamic potential of the grid by way of iterating between building and seeing it evolve in a browser.  Or the front-end developer might pair with an information architect or interaction designer, instead focusing on issues such as content structure and flow.  Who pairs with whom will be specific to the project and team.

Pair design might be a bit weird for some team members at first, as they may be  uncomfortable about having someone else watch them work.  One way to mitigate this is to start by pairing in front of the application used by the person least experienced with this method (or with Agile methods in general), e.g. OmniGraffle or Visio for an Information Architect, which is their home turf and comfort zone.  Then, once some detailed design work has been completed, or whenever makes sense, move to the developer’s screen and begin the work of translating the work completed so far into code, and go from there.

This activity can be a powerful team-builder, allowing for forming stronger bonds across disciplines, and reduce the quantity of unnecessary and redundant artifacts.  One great example of an artifact you might be able to skip is wireframes.

Pair Design offers an opportunity to skip wireframes altogether

One of the biggest problems with wireframes is that they inherently communicate a design idea in the form of a page layout.  Often, the layout is created by the person creating the wireframes without having explicitly discussed it with other team members, particularly the visual designer, which can lead to one of two equally bad scenarios.

Bad Scenario 1: The visual designer takes the lazy route and simply replicates the layout created by the information architect in the wireframes, which very possibly may have been produced with no formal understanding of page grids, meaning that the entire visual layer of the application will be hampered by a sub-standard layout.

Bad Scenario 2: The visual designer completely disregards the layout in the wireframes and produces a comp with elements organized in a completely new way.  This is almost certain to aggravate and confuse clients or non-technical stakeholders,  who understandably have been evaluating the preceding wireframes not purely as representations of an information architecture, but holistically.

I’m never quite sure whether to laugh or cry when I hear IA’s ask clients to disregard the layout in their wireframes, since it not only places an incredible cognitive burden on the client, but also really makes no sense.  How information is represented visually has meaning in itself (e.g.  in terms of proximity, size, visual hierarchy, etc.) So we really are asking of our clients a near impossible task and instead only admitting to a fundamental flaw in the concept of a wireframe, in that it purports to somehow separate information architecture from visual design, when it in fact does nothing of the kind.

Better to instead present a layout that in fact is one developed by the team as a whole.  And a great way to do that is to skip the wireframe (or use it strictly as an internal artifact) and instead present either early versions of a design comp or skeleton page builds.

Pair Design can help to dissolve the Us/Them divide between Tech and Creative

Too often, Tech and Creative see themselves as separate camps within a design team.  One common reason for this is that a waterfall method effectively creates this separation by virtue of the two roles being separated in the project plan (design first, production  second), and separated by one party handing artifacts off to the other.  By physically pairing these roles, you are able to bring roles in closer contact, and have them looking and talking about the design together.

Another great benefit of Pair Design is the potentially powerful psychological bond that emerges between two people working in isolation from the larger team.  There is just something about two people sitting in close physical proximity and looking at and conversing about the same problem that seems to transcend their respective disciplines.  Compare the dynamic of having a visual designer email a Photoshop comp to a front-end developer to that same person instead sitting next to the developer and talking about the ideas underlying their comp and the two then working together to evolve the design solution.  For example, a design may look great to the visual designer when viewed inside their graphics application, but when the design is rendered in a browser, it may look significantly different. A great example of this is how fonts are rendered in a browser.  I.e. fonts may look nicely anti-aliased on PhotoShop, but when the browser displays them, not so much.

A possibly even more powerful example is that of rapid prototyping using frameworks such as Jquery.  Rather than have the interaction designer toil away at some time-consuming illustration of a dynamic feature, the interaction designer can instead pair with the front-end developer and actually prototype a variety of dynamic options on the fly.   In fact, I regularly talk to interaction designers who have no clue that there are a lot of dynamic features, particularly those available in standard UI libraries, such as, that a front-end developer probably can prototype faster than the interaction designer can spec it.

So is this to say that the entire solution should be created in pairs or that there is no need for any wireframes?  Absolutely not.  The ideal is likely to be an even balance of team members working separately and in pairs.  More importantly, it is about an underlying mindset of not defaulting to creating artifacts in isolation but rather defaulting to creating artifacts by way of conversation.

  1. “… standard UI libraries, such as, that a front-end developer probably can prototype faster than the interaction designer can spec it.”

    I rather think that’s the exception that proves the rule. 99% of the time, a UI designer will be able to design far faster than anyone can create a functional prototype – even using rubbish like Visio.

    This leads to a rather glaring obstacle in the way of pair design: the fact that at anyone one time, the developer will usually be working hard on the stuff that the designer produced a couple of weeks ago. As one of my team once said to me as I approached him with paper and sharpies in hand: “Dude. Not again. When, exactly, I am supposed to ship deployable code?”

    Just sayin’ :-)

  2. Really interesting thoughts, thanks for sharing.
    Esp. the idea of designer/front-end developer working simultaneously, entices me a lot.

    I’ll definitely have to pitch this idea to my team.

  3. Yes, I do think that pair design is a good idea. I’m an interaction designer and have tried out pair design both with developers and with other designers. However we do create quite a few PowerPoint sketches and find this a valuable way to communicate design toughts and get clarifications from the product owners.

Comments are closed.


  • Reflections on four years of integrating design and development | Atomic Spin June 8, 2009

    […] Anders Ramsay, a friend of Atomic’s from the Agile UX community, identifies advantages of pairing across design specialities. We achieve some of these with our poly-skilled team approach. Leisa Reichelt concluded that pair […]

  • Agile UX and The One Change That Changes Everything - Anders June 8, 2009

    […] designs something and then has to meet with another person to review it and so forth.  This is why pairing is so powerful, because you are in a continaul state of both exchanging and vetting one another’s […]

  • Why Agile UX is Meaningless without an Agile Attitude - Anders June 8, 2009

    […] start designing together?  Two inter-related patterns are Cross-Functional Pairing, which I’ve talked about before (and others have as well), and Active […]