User Experience Architects tend to spend a lot of time puttering about doing some pretty mundane things - wireframes and behavioral specifications aren't terribly glamorous. Architects do a lot of drafting, online or off.

But time doesn't always allow for endless revisions, and launch dates rarely - if ever - have any relationship to the amount of work which needs to be done. Between developing a strategy for a site - what it should offer and who to target it towards - and designing the information architecture and content plan, there often isn't much time left for architecture. Wireframes need to get drafted, sitemaps outlined, revisions made, approvals received... and then the whole kit and kaboodle needs to be handed over to the developers. (Whole books have been, or should be, written on how differently UXAs and developers think.) There's a lot of communication, translation, reviewing, double-checking, and testing, among these groups.

And then there's the pesky problem of getting the darn thing built.

Now, there are schools of thought which say that the way around this problem is to spend less time planning, architecting, documeting - and more time building. And there's some sense to that, in certain circumstances. When all you've got is a couple of months, a pair of programmers and a mandate to get something - anything - online and working, digging in and throwing some code up against the wall is more likely to work than trying to plan out each. and. every. last. detail.

Bear in mind that this kind of situation works better when those programmers are already on your staff, and you're choosing whether to pay them to write code or write specs. In my work life, the situation is a bit different - we get hired to build software (be it an application, or a website) that meets a need. And the goal isn't a certain amount of finished code, or a certain number of hours billed. The end point is a working piece of software that solves a problem. If the problem isn't solved, we don't get paid. (OK, we do, but only for the work we've done, and the client isn't happy, and they don't ask us to do any more work for them. That's bad.)

Another, similar, approach is to pair a UXA with a developer, and have them work hand in hand to create a rough, black-and-white, wireframe-like prototype. Elements of interaction design would be implemented, rather than documented and annotated. The developer can collaborate with the UXA on feasibility right when the interaction design ideas first take root - instead of weeks or months later after reading a behavioral spec and guessing what they mean.

A lot of UXAs will recoil from this concept. "But I need time to flesh my ideas out on paper, and test them with users." Sure you do. But you're not going to get to do that most of the time, and more often than not the developers are just going to get started building the application off an incomplete spec anyway. "We'll fix it in QA," they say. (The smarter ones don't even say it, they just think it.)

Today, a developer came over and said, "I'm working on this prototype, can you help me something." Yes! A chance to collaborate!

He continued, at his desk: "I've got this page, and it's really long, and so I want to break it up into multiple pages. But the descriptions for each page are too long. Can you think of some shorter labels?"

Bonus points for anyone who knows what's wrong with this question.

Let's look at why the page is so long: Aha! He's put four textarea entry fields for each section. There are twelve sections so, yeah, this page is going to be kinda long.

"You know," I offered, "this page would be a lot shorter if you just used one textarea, plus a submit button, and then just added whatever text the user types into the textarea to the page body on submit."

"Oh, sure, but that's just client-side trickery. We'll do that when we get to the build. Right now I just want to get the general concept done in code."

That's. Just. Client. Side. Trickery. His exact words.

No. It. Isn't. It's interaction design, and the point of a prototype is to demonstrate the functionality of the client-side interface. Otherwise I could just writeup a wireframe, and document what it's supposed to do.

What happened here? Well, what happened is that we took a too-typical working relationship - UXA and developer speaking different languages, working with different expectations - and we bolted on a new and different deliverable. Big whoop. What does this do? Cost more money and take more time. But at least everyone is keeping busy.

Collaboration has two immutable requirements: physical proximity, and a shared working language. Teams which lack the former are reliant on written artifacts to communicate their ideas. Artifacts are always going to be lower fidelity that face-to-face communication (wth the exception of Tufte-ian visuals, which take an exceedingly long time and a great deal of talent to execute well.) Teams which lack the latter - well, they can be sitting on top of each other and still manage not to communicate.

(I'm willing to accept the possibility that physical proximity can be simulated, albeit very rarely and expensively these days.)

Collaboration has to come first, and it has to be fine tuned before you can expect to reap the benefits of a multidisciplinary team.