This site hasn’t been updated since 2012. You can still peruse who I was back then, but know that much of what I think, feel, write, and do has changed. I still occassionally take on interesting projects/clients, so feel free to reach out if that’s what brought you here. — Nishant
A year ago, I proposed the future of wireframes.
My proposal centered around relaxing the stranglehold wireframes have on layout decisions. Traditionally, the exact positioning of the different "boxes" of information has been in the information architect's domain. In other words, when a wireframe shows a featured article rotator above a sidebar of resource links, it is expected that the final site will have the featured article rotator above the sidebar of resource links. In fact, it is expected that all such boxes of information show up relative to each other as depicted in the wireframe.
There are several problems with this approach, but let's focus on the fundamental ones.
Despite how things turned out, nature intended the layout and the visual design of a site to go hand-in-hand. You pay a notable price when you decouple these two aspects of the design process: a price that generally manifests in the form of a design that's not very exciting.
In addition to the decoupling problem, there is the problem of lost opportunity cost. When members of a design team have cross-disciplinary skills—that is, when they are experienced generalists—you endure the opportunity cost of not maximizing the team potential if you decouple IA from the rest of the design process.
But finally, there's the question of responsive design: how does IA adapt to include responsive design?
I suspect that those who specialize in IA will argue for more wireframes: wireframes for every form factor. It may be a great way to inflate the project budget, but remember Biggie's infinite wisdom?
In all seriousness, creating wireframes for the full responsive matrix isn't sustainable. It's counterproductive, and as Trent points out, it's unnecessary. It also compounds the decoupling and opportunity cost problems I mentioned earlier.
So, where does that leave us?
It turns out that the key to solving our dilemmas lies in our ability to address the source of all these issues: the issue of control.
For the most part, today's approach to IA is similar to architecture in the physical world: create an exact blueprint for what is to be built, and then build it.
This approach worked well when IA was emerging as a discipline in a time where designing for the Web was unchartered territory. It was a practical way to solve problems up front, control scope, and manage stakeholders. But times have changed, and while it's still necessary to know what you want to build up front, it isn't necessary to have it fully locked down. It isn't necessary for the IA to exert full control over it.
In fact, it's better to ease up on the control.
As I proposed in The Future of Wireframes, information architects (or, whoever owns the wireframes for the project) can often improve the quality of a design drastically by relaxing their control on layout decisions. I introduced the concept of functional wireframes to illustrate this.
My proposal this year—something I'm calling "fluid information architecture" in the spirit of our times—is for wireframes to have less control over other aspects of information architecture, like responsive architecture for a site and functional copy decisions.
There are two major benefits to this approach. First, it allows responsive content choreography to happen downstream in a much better way. Secondly, due to the nature of the beast, it introduces a level of delightful unpredictability for our users. Remember, these are exactly the kinds of results we were hoping to gain.
However, the fluid IA approach brings an elephant into the room with it: if the information architect doesn't control the blueprint of the site, then why have the role?
This is worthwhile question, and I've found that the answer varies from project to project depending on scope and makeup of the design team. Sometimes, the answer is for the information architect to focus on other aspects of the process: identifying page-level information, determining relative priority of information (Allison House provides an excellent example), capturing page states, and so on.
But a perfectly reasonable answer is for the role of the IA to be combined with surrounding roles, like creative director, or front-end developer, as we did in the 10K project.
For those of you who haven't heard of the contest, the 10K challenges contestants to build the best application they can with no more than 10K (yes, kilobytes) of code. You can read about this year's contest here.
Among other things, I served as the information architect for 10K Apart. As you'll see, I drastically reduced the scope and influence of the IA role precisely due to the scope of the project, and who was on the design team.
I was fortunate enough to have the Paravel trio come on board to help design the site. This isn't a gratuitous plug. Paravel is on the top of their game in several areas of the design process—among other things, they create wonderfully laid out websites, and have cracked the responsive nut better than most. This helped me adapt the information architecture approach for the project, particularly in three areas:
To fully illustrate my point, I'm making the functional wireframe deck for the project available for your perusal.
As you can see, I mandated only one thing: page-level information. The rest was at Paravel's discretion.
Some things they chose to keep (like the entry form and the gallery layouts), while others they completely changed (the hero banner and layout of home page elements). The process was seamlessly fluid as becomes apparent in Reagan, Trent, and Dave's posts.
The resulting design—and I may be biased here—turned out to be functional and unpredictably delightful: http://10k.aneventapart.com.
It's widely accepted that the information architecture phase of a project can make or break the final experience. And this is true. But this belief rests on the assumption that control creates predictability. While this checks out in theory, we've seen how it quickly falls apart in practice.
Ironically, in practice it seems that creating predictably delightful designs isn't about exerting control. It's about judiciously giving it up. It's about identifying the right fluidity for the process and establishing the optimal flow.