The wireframe has long been the staple of user experience design. For the uninitiated, a wireframe is in its most basic form a sketch of what goes where in a website.
Wireframes can vary dramatically from hand sketched ideas on a whiteboard, used to explain to teammates what’s going on, all the way to a very specific technical design document saying what goes where, what it looks like, and what it does.
Traditionally, wireframes work a little bit like blueprints. They provide a clear and detailed plan for what the development team is going to create. While they might lack the technical specs of the ‘how’, they provide the development team with a picture of what a website or app should look like at the end.
This form of documentation though may be on the out, under dual threats from agile workflows and prototyping.
The Rise of Agile
Agile design is a development workflow that emphasizes working together and iteration
It's easiest to understand when contrasted with traditional development, called waterfall.
In waterfall style development, each stage is finished to completion before the next stage. So the UX team will conduct user research, write a complete wireframe document for the entire project, and then hand off to the development team. There's always some overlap during handoffs, but the idea is very much completed in discrete stages.
Agile design is the idea that teams work collectively in ‘sprints’ to quickly complete one particular deliverable or section of a bigger project. It's based on rapid iteration and adaptation and the idea that final result of a cross-discipline team is better than if they work in isolated silos.
In that sort of context, one weighty wireframe tome just doesn't really have a space. They don’t lend themselves to iterations because they tend to be completed in full, or cross-discipline work, since a big responsibility of the wireframe is to provide a blueprint for the development team.
If you're working together, it's just not necessary to create that deliverable.
The second major threat to the wireframe is prototyping.
Prototyping is writing actual code to create a shell of a final product. So instead of a piece of paper explaining how an app will work, you get a very rough draft of the actual app.
The problem with prototyping for years has been the expense. It’s wonderful to build a prototype, or even a prototype with almost complete functionality. But writing the code is time consuming and costly, and for a long time it couldn't really be reused for the actual product. It wold be like writing a draft and throwing it out, only to write the same thing again.
But with a variety of apps and prototyping sites dedicated to creating ‘usable code’ (like Twitter Bootstrap) emerging in the past few years, hi-fidelity prototypes are cheaper and faster to produce and more useful in the long run.
So is the wireframe dead?
While prototyping is great for showing to stakeholders, seeing and iterating on design, and getting a MVP in front of real users to test, they are not so good at offering a bird's eye view of a website. For designing and visualizing information architecture, and explaining to a team ‘this goes here’, wireframing is still a valuable tool.
That said, the wireframe format is very likely to continue to evolve. Instead of moving towards clickable wireframes, the move should really be towards fast iterative sketches that change and evolve based on team input and feedback.
The wireframe will continue to change but should, for the foreseeable future, remain a part of the design and development conversation. It might not be used on every project by every team, but it's a good tool to have at the bottom of the toolbox.