This post is a possibly ranty reaction to the recent Wireframes are dead, long live rapid prototyping post on UX for the masses. If you've not read it, it's definitely worth a click. And also worth working your way through the comments it generated. As the title makes clear the post argues that wireframes, a traditional tool of the 'UX professional', no longer add value. I'd agree with this and probably go further and say they never have. And probably go further still and say none of the accepted 'UX Deliverables' (sitemaps, user journeys, card sorts (you're not building a library; this is the web; things don't have places) etc) add value either. And don't even get me started on 'Personas'...
But I disagree with the post on two counts. First off the 'Why ditch wireframes?' section lists six reasons why wireframes don't help you actually make stuff. I'd agree with all six but think they're not the most important reasons why wireframes suck. And secondly:
the alternative is to bypass wireframes altogether and either go straight from sketch / outline designs to developing working code (in an Agile fashion), or as is more use common use [sic] a rapid prototyping tool to create a prototype
which loses me at the comma. Because rapid protyping tools suck too. And, being harder to use than Omingraffle / fag packets + pencil, suck worse than wireframes.
If wireframes aren't dead I'd be more than happy to take them outside and put a bullet through their head
It's probably best to consider this list a personal addendum to the six reasons to ditch wireframes list in the original post.
On a more basic level if I want to resize my browser I will do. And if your wireframes say the search form is top right what happens? Is your layout absolute so the search form disappears somewhere out of view or is your layout liquid making the search form always visible? CSS makes this behaviour explicit, wireframes don't.
The point is user experience on the web is up to the user. It's not something you as a designer / publisher can define and control. Wireframes are just one way to fool yourself and / or your 'client'.
Wireframes conflate: the data / content / assets you need to build a resource with one specific representation of that resource with the visual layout of that representation with the document order of that representation. Breaking that apart:
Imagine you want to list some things. Imagine that list is time based with new items being added as some state somewhere changes. Do you want to make RSS of that list available? Or imagine it's a list of events. Do you want to make that list available as an ical / ics feed? From a less data centric point of view do you want to make a mobile friendly version of your page? A smart phone version? An iPad version? Then what is your wireframe supposed to represent? And are you going to make a different wireframe for every possible device that might at some point want to access your content?
The point is to document the data / services you need to build all representations of your resource, not just some simplified / idealised desktop HTML version. How best to do that? My advice would be over a coffee / beer with a developer on a fag packet. If god had intended us to specify data queries in plain Engish / French / whatever (s)he wouldn't have invented SQL or SPARQL. The best way to document code is in code. The rest is paperwork and process.
The second problem is more general and more common. Very roughly speaking (and for accessibility and SEO reasons) an HTML document should be: h1, content, navigation. For some 'stickiness' reason or some misguided belief that most visitors arrive through your homepage and have the patience to navigate your navigation, page layouts tend to stick 'global navigation' (for some definition of global) at the top of the page. Which is fine from a page presentation point of view. But a bit rubbish from a document design / SEO / accessibility point of view. Again, title, content, navigation. And use CSS to 'move' your navigation to the top of the 'page'. If god had intended us to specify page layout in pictures (s)he wouldn't have invented CSS.
Document design has nothing to do with visual layout (except by default with CSS off). Design your document first, then use CSS to add layout. For what it's worth I divide my CSS into two bits: layout.css handles the floats and the positions and the margins and the padding; decor.css handles the decorative stuff (colours, typefaces etc). Like it or loathe it, CSS is the design language of the web. If you want to wireframe stuff edit layout.css. Any other means of codifying layout is a lie and will catch up with you.
If wireframes are dead, rapid prototyping tools should die in their arms
So I don't really like wireframes. But I really dislike rapid prototyping tools. If you've not already read the comments on the original post it's probably worth doing so. They break down roughly into:
- wireframes are still useful as a deliverable / conversation tool with clients
- suggestions for other rapid prototyping tools to use. From a quick scan through, suggestions are: Axure, Balsamiq, EasyPrototype, iPoltz, InDesign, SketchFlow, Flowella, Justinmind Prototyper, LucidChart, Tiggr, Protoshare, Naview and Cacoo
How in god's name did so many people make so many tools that pretend to make websites when making websites isn't that hard? The problem is all these tools output wireframes with links. Sometimes they do that by outputting HTML and CSS and a few annotations. But even then they do it badly. Which is almost forgiveable: even people employed to make HTML and CSS often do it badly; the machines never stood a chance. But they have all the problems of wireframes (conflation of resource and representation, document and layout) without the benefit of being easy to ammend and update. Really, stick to pencils and fag packets and working code.
One final rant: Designing how code interacts with idealised data is easy. But you're never going to know how your application works until you combine real code with real data with real users. You can wrap your process in as many "user centric" buzzwords as you like but until you're testing real code with real data with real users the picture will be, at best, fuzzy. Or ship, test, change. And realise UX deliverables are fine as project checkpoints and fine as signifiers to client X that this might be a good point to donate to your bank account but they're really only of benefit to your agency / bank manager / random important person incapable of abstract thought, and they really won't lead to the things you're making being any better / the making of better things.