Through Collective UX, I pitched in on a massive site reorganization for the New York Stock Exchange. Diving into their diverse financial product offerings was quite an education!
Deliverables included sitemaps and wireframes.
Through Collective UX, I pitched in on a massive site reorganization for the New York Stock Exchange. Diving into their diverse financial product offerings was quite an education!
Deliverables included sitemaps and wireframes.
I’ve been doing a lot more wireframing lately and it has me thinking about the usefulness of both the form and the term. What is a wireframe? To paraphrase Wikipedia, a wireframe is a basic visual guide used in interface design to suggest the structure of a website or webpage. “Structure” in that definition could be anything from a user’s path across the site to the hierarchy of information on a single page (see more on this at w3avenue).
In many of the web projects I’ve been involved with over the years, there has not been a user-interface lead dedicated to the process of creating wireframes. The task has generally fallen onto a designer or developer. The former tend to wireframe in a graphics editor like Photoshop, and the latter tend to wireframe in HTML. Once in a while the wireframer will use “diagramming” software like OmniGraffle, however I find those generally get used as graphics editors in the end.
The wireframing I’ve been doing lately tends to focus on page hierarchy rather than user flows, but in the past I have been involved in projects that favored user flow over page hierarchy. Either way, I don’t think wireframes are doing what they could be doing for communicating to all the involved stakeholders what the ultimate structure of the site or application will be. When the process is too design-focused, the wireframes become merely a black-and-white Round Zero of design. When the process is too user flow focused, wireframes can become unintelligible to less technical stakeholders. (For a more detailed discussion of these tensions, see Dan Brown’s “Where the Wireframes Are”.)
I’ve begun to consider advocating for more of a storyboard approach to structural planning. Frequently the term “storyboard” is reserved for experiences with a single, linear narrative such as movies and would thus seem to conflict with the web’s choose-your-own-adventure vibe. However, while web producers (in this case I mean literally anyone producing the internet) have to juggle multiple perspectives and motives when creating a website, users come to a website with an objective in my mind and their perspective on the site always remains narratively their own.
Thus, I’ve found it increasingly useful to think of the sites I build in terms of use cases, works flows, and user narratives. So why not also adopt the terminology of narrative? In addition to being truer to the task at hand, the idea of “storyboarding” has the added reputation of being fun, even spontaneous. Indeed, some are even advocating for the sketch as a legitimate structural tool.
All in all, better planning means better websites and I think good web planning is more apt to happen when people are engaged, understand the process, and when the user always remains at the focus of it.