UX Teams: Stop it with the wireframes. Please.

[Editor's note] Blogging has sadly fallen off my priority list and, for that, I apologize. Hopefully I (*cough* and the rest of this blog's team *cough*) will pick up the pace soon!

Over the past several years I've either been working in, or working directly with larger UX teams in a corporate setting. I've noticed that wireframes appear to be the primary product being produced these days. On a certain level, it makes some sense. It's a document (large organizations love documentation). It's something business stakeholders (at least claim) to understand. It's something that dev teams (usually in non-agile settings) often request. It's a paper trail (which fits in with the CYA school of business).

But wireframes don't work. They don't work because of all the things a wireframe is not. It's not a technical requirements document. It's not a user research document. It's not an interaction design document. It's not a content specification. It's not a testing document. It's not a visual design specification. It's not a component library.

In otherwords, it's NOT the product that the user experience is being crafted for.

What a wireframe is useful for is as an internal sketch for the UX team to help shape all of the aforementioned requirements that all the different parts of the corporate web/software development machine requires.

So to be clear--and perhaps a bit less provocative--I'm not against wireframes as a tool. Quite the contrary. They are an invaluable tool. What I am against is them being used as a document of record outside of the UX team. A wireframe simply can't communicate the full complexities of the solution to every individual team. Nor should it. But when it becomes the document of record, all of the sudden it's expected to live up to expectations it just can not meet. On top of that, the poor UX team now has to maintain this beast of a document, version it, distribute it, keep it in sync and basically become a slave to it.

Oh...the icons changed for the menu, can UX update the wireframe? That particular web service has a new API so the data retrieved is in an entirely different format. Please update the wireframes. Marketing came back to us and want to change the entire messaging on this section. We need new wireframes this afternoon! Dev just called and are confused. It looks like they have 7 versions of the wireframes. Which is the latest? The ID team pointed out that the flow we designed for the wizard is technically incorrect and can not be implemented as is. We need wireframe updates. Senior Management has some ideas to rearrange everything. They sent some sketches for you to update all the wireframes.

This is a reality of large software development projects. It's hell, but it's a reality. All that effort that should be put into crafting a better user experience is instead being pumped into pointless documentation that will never be up to date with the actual project.

I propose that all that effort, instead of going into Viso and Axure, go into actual working code. Yes, yes, that's Agile. I know. Of course, when Agile is implemented in the context of slow moving behemoth organizations, for some reason that key point is forgotten.

In summary, I encourage--nay, beg--corporate entrenched UX teams to get away from being wireframe maintainers and instead do what you do best: faciliate the process of finding the best UX possible and help craft the actual implementation of it. Do wireframes. LOTS Of them. But keep them on paper and the white boards. Don't commit them to electronic files as once you do, your role has shifted from being a UX designer into being the person in charge of the documentation that everyone else hates.

Focus on the product. Not the wireframes. After all, our users will never be using the wireframes.