Their rotation speed depends on how many designers they have in house at the time. Everyone there is a subcontractor so they sometimes get into crunches where each designer will be working on 2 different projects each day, and may hit 3 or 4 projects in a week. They use an agile project management methodology, so each subtask (e.g. design a screen, create a process flow, create use cases) is written on a card which gets a time estimate. Basically, the designers are assigned to a project for a day or half a day and work on however many cards they can get done during that time. They will usually try to finish a card before rotating out, but if a card is taking longer than anticipated it’s possible that a new designer will rotate on and finish a card that was started by someone else. There is some inefficiency introduced because the new person has to be brought up to speed on the particular card, and sometimes the project as a whole, before work on the card can proceed. But usually it works out ok.

The High-Tech Anthropology (HTA) is a part marketing voodoo but mostly refers to their contextual inquiry/observation process they do before working on the design, and the contextual prototype testing they do.

This sounds like an interesting methodology… I can definitely imagine that results vary depending on who you’re paired with. Do we know how often the designers rotate projects? Is their assignment time based (eg. you work on this for six weeks) or outcomes based (Eg. you design this process then you rotate). I guess it would have to be time based.

It’s interesting that they call it High Tech Anthropology. Why anthropology I wonder? It doesn’t sound like anthropology as I understand it!

So the protoype becomes the specification, eh? I know that works great with clients who need to see it working before they can sign off, but I also know that next to the prototype that specifies *some* of the interactions, you always need a set of descriptions for the other/edge cases. So there’s also a Visio document next to the prototype. (And then you need to update two parts when a specification changes, ugh!) But I agree that for the more-and-more highly interactive (yes: AJAX-y) systems we’re working on, a prototype which shows some of the interactions in real life, is the way to go.

As for creating early prototypes straight from Visio, can I point you to Swipr (http://www.swipr.com)? It has some nifty macro’s in the shapesheet that allow you to automate the steps you describe (export, import, add hotspots, create prototype in HTML). Have a look at the sample files, convince yourself of the advantages, and say “hi!” to Jacco when you register to download the templates

As for pair-documenting, when you say “I think it can be, but it depends on how much time you have” you make it sound like you think it takes more time to pair-document, is that true? Because I am sure others will have said the same about pair-designing, and still you, or at least the Agile people, are convinced that it’s faster to pair-design…

I think a less-Agile approach, where documenting is an instantaneous part of the design process (and not an end-of-iteration, or worse: end-of-phase activity), would work better for pair-designers. And I am still not sure if it beats the more traditional design-review approach, where a (senior) designer reviews the work of the main designer every now and then, after having agreed on the activities and deliverables.

One last question: what does your documentation look like? You mentioned annotations in (a separate layer of) the Visio file. Is there more?

(FYI: I am considering submitting a proposal for a panel about IA processes to the IA Summit, and am interested in hearing about people’s experience with documented IA processes and deliverables)

I was skeptical about Agile methodologies for this reason for a while, but I’ve come to realise that, in my case at least, the prototype becomes the new document. But, there is still documentation.

The way I’ve been working lately is to do initial design on paper (flip chart with extensive use of post it notes) which is then transferred to Visio wireframes (of reasonably fidelity), that are then outputted as GIF and imported into Dreamweaver where hotspots are applied and a prototype is quickly developed. Then we can do lots of testing/research and rapid iteration until we get to a design that’s actually doing it’s job.

There’s lots of scope (and reason) for capturing specifications etc in the Visio document, just make sure it’s on a seperate layer so you can switch it off to output the gifs for the prototype, and switch it on for printing.

For the project I’ve described here, documentation will be really important because we have three development teams working on this - each of which are more or less remote from each other. We need to document as much as possible to reduce miscommunication and misunderstanding between the teams.

Now, is this actually a pair design activity? I think it can be, but it depends on how much time you have. I think it would be ideal, but in reality I’ve found that you tend to split the project up into sections and each designer does most of the documentation on that particular part of the project, then someone pulls it all back in together.

I’ve found this is where the ‘weak spots’ in the interaction tend to creep in. In my ideal design environment. you’d do all of the documentation in a pair environment as well.

(yeah, i know. sounds bizarre. I never thought I’d be saying this either!)

I have been called a process freak more than once, and have an interest in agile designing as such.
Here’s my question: I know Agile methodologies are usually document-averse. How would you see pair-designers deal with documenting the design? Is that a co-operative effort as well (or is it one of the distractions you sepak about ;-))?