For the day job, needless to say I do a fair amount of wireframing and writing of use cases, and there’s a lot of “what does this link do?” when reviewing the work with the developers (we try not to just throw stuff over the fence). No matter how much we annotate and clarify, there’s always the usual…

“You know, I didn’t quite think about it. I’ll just remove it for now.”

Part of it is lack of sufficient time to gather requirements, part is sometimes crafting a good user experience where coming up with something really cool is something that you can’t put a time frame on. Sometimes it could take five minutes and hit you on the road, like how to handle comments within an MySpace Open Social application I am working on now. It could take weeks where after you design it, it’s implemented and you realize, “man, that’s just not effective.”

At work and at some of the clients, I push for having an Information Architect around during the development process — not necessarily full time, but just around for questions — because issues will always come up. That’s why I am convinced that waterfall-style requirements gathering works well for building the Space Shuttle, but doesn’t work well for developing web applications because of the nature of the technology (ultimately flexible, low barrier to entry, the approach of “let’s throw everything against the wall, see what sticks”).

With wireframes, there’s always this “lost in translation” moment where Scarlett Johannsen asks Bill Murray, what does this do, and we haven’t quite covered it. I’m convinced it not a tool issue (Axure, Visio, whatever) but just an understanding of what we do is part art, part science. Apple gets it. Some other companies get it.