You’re in a somewhat different situation, being in-house, so in that case, it is possibly something worth considering because you get real long-term value from the time you’re investing.

I’d love to hear how you go with this, and where you start (with developers or product people, for example?) and sing out if you want to knock some ideas around.

(btw: it was nice to be reminded of this post and the great experience I had that prompted me to write it!)

“Choosing the right co-designer is pretty important. I’d be loathe to pair design with someone who knew nothing about interaction design… it would be way too much mentoring and not enough designing, which isn’t practical or appropriate on a ‘project’ based design.”

Inside my company all I have are non-designers, but I think there has to be value in getting them involved, if only to help my thought process and come up with some new ideas.

However, I’m slightly worried about them being too worried about the ‘blank piece of paper’, and me riding over their ideas if they don’t make sense from an interaction point of view and ending up where I would’ve been in the first place.

Hmm, seems like something I’ll just have to try and see.

Because I work in a small company, the more I can spread the load, the more can get done, but I guess it’ll be a gradual process as people get up and running with it.

Just thinking out loud really, I’ll let you know how it goes. :¬)

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)