How The Big Boys Do It: The Danger of Wireframes In Website DesignBy Burkey Belser
March 12, 2012
We don't begin the design process with wireframes. For most, that's a shocker. We begin with design. Recently, a client's developer opined "The big boys begin with wireframes." I nearly hit the roof, but quickly realized we need to explain our philosophy more clearly.
Wireframes were invented around 12 years ago when web developers called themselves web "designers." It was a left brain moment in the history of site design. Wireframes define functionality and let the coder know where to pull the data from and how the results should display…in excruciating detail. That is, return results for professionals last name first, first name last, etc.
This is a way to get an effectively structured site, but is it the best way to get a brilliant site design? I say no. The Internet is so new that in order to understand it, we use metaphors like "web pages." Does a website have "pages"? If you're philosophical, you could say that templates on which "pages" or views are built are ideal Platonic "pages." But, in fact, the book metaphor is worn out, having died after rapid advances in bandwidth and compressed coding technologies turned pages into stages where visitors can view any type of information unit (words, video, charts, diagrams, etc).
The Internet is still a teenager. Can there possibly be one best way the Big Boys should do it? Let's offer another metaphor commonly used to explain website design. Building a website is like building a house. If you want a brilliant house, do you go to a design/build company? Of course not. You go to an architect. And after you both talk about your vision, the architect returns with sketches. Designs. Where's the blueprint? A long way off. And what's the purpose of a blueprint? To realize the architect's vision…and to get the plumbing and electrical where you want it. What's the purpose of a wireframe? To realize the designer's vision—and to get the relationships and functionality in order
Why does Greenfield/Belser invert the Big Boy strategy? Because wireframes as commonly conceived are designed to be limiting, not expansive. How can design soar if you wear shackles from the start? Now. To be clear, of course we use wireframes. Our wireframes, like all wireframes, define functionality and relationships. They include developer notes, client notes and even best practices. In fact, we begin with a "standard" wireframe to ensure clients get all the basic functionality typical to a professional service site. But our wireframes are not laid out like "web pages." We have rejected the modular layout of wireframes as less, rather than more helpful, UX (User Experience) and UI (User Interface), nothwithstanding. No drawings, no boxes, no layout. Just lots and lots of notes. The developer gets what she needs and the designer what he needs. The user experience is unshackled. The developer notes satisfy the software demands.
This post began because of a recent article in The Washington Post. On the eve of the Academy Awards, the Post interviewed three visionary film directors, including Woody Allen. Sixteen academy awards for his actors. Three for himself. The Post reports, "a veteran cinematographer once told me the only directors he knew who got exactly what they wanted acted like fascists on the set and ran over anybody who got in their way… For a guy who "barely talks to the actors," Allen seems to repeatedly bring out their best." (Wireframes are deliberately fascist.) But the real insight and relation to web design occurs later in the article: "If you're the writer of the story, you know what you want the audience to see because you've written it" (Forbes). It's just common sense.
If you're the designer of the site, you know what you want the audience to see because you've designed it. It's just common sense.
If I haven't exhausted you with this post, then you might wish to explore more in this well-written and well-imagined approach to wireframes. Not quite the same as ours…but that's the point!