The Wireframe Audiences

Infor­ma­tion Archi­tec­ture is a dif­fi­cult field. Not only do we con­tin­u­ally have to sell the impor­tance of our field, but we also serve a role that most IT peo­ple do not. We walk the thin line between busi­ness ana­lysts and design­ers; we also have the dif­fi­cult job of trans­lat­ing func­tional busi­ness require­ments into some­thing our devel­op­ers can under­stand and our cus­tomers can buy off on.

Because we often don’t fit well into a nice cat­e­gory we are respon­si­ble for a much larger part of design­ing infor­ma­tion sys­tems. Noth­ing makes this more evi­dent than the process of cre­at­ing wire­frames, and I’m going to address the debate on inter­ac­tive vs. sta­tic wire­frames in the con­text of our role in the devel­op­ment process from the per­spec­tive of design­ers, cus­tomers, and man­agers. The time has come to more clearly define who we are, the role we play in the devel­op­ment process, and be sure that we sat­isfy all inter­ested par­ties in the process.

The fol­low­ing quote from Rosen­feld and Morville in their IA mag­num opus will be expounded upon:

Wire­frames rep­re­sent a degree of look and feel, and strad­dle the realms of visual design and inter­ac­tion design. Wire­frames (and page design in gen­eral) rep­re­sent a fron­tier area where many web design-related dis­ci­plines come together and fre­quently clash. The fact that wire­frames are pro­duced by an infor­ma­tion archi­tect (i.e., a non-designer) and that they make state­ments about visual design (despite being quite ugly) often makes graphic design­ers and other visu­ally ori­ented peo­ple very uncom­fort­able. For this rea­son, we sug­gest that wire­frames come with a promi­nent dis­claimer that they are not replace­ments for “real visual design.” The fonts, col­ors (or lack thereof), use of white­space, and other visual char­ac­ter­is­tics of your wire­frames are there only to illus­trate how the site’s infor­ma­tion archi­tec­ture will impact and inter­act with a par­tic­u­lar page. Make it clear that you expect to col­lab­o­rate with a graphic designer to improve the aes­thetic nature of the over­all site, or with an inter­ac­tion designer to improve the func­tion­al­ity of the page’s wid­gets. (pgs. 308–9)

Are We Inter­ac­tion Designers?

The answer is yes and no. We cer­tainly have a role in the over­all user expe­ri­ence process, but we are not respon­si­ble for how a user actu­ally inter­acts with an infor­ma­tion sys­tem. Let’s face it our anno­ta­tions don’t replace the role of a qual­i­fied inter­ac­tion designer. I will be focus­ing on the fact that our value-added propo­si­tion is that we can effec­tively lubri­cate the evo­lu­tion from a stiff busi­ness require­ments doc­u­ment into some­thing rem­i­nis­cent of a usable sys­tem that is then passed onto the pro­gram­mers, design­ers, and usabil­ity gurus.

Please under­stand that I under­stand that the field of IA, UX, and all other aspects of archi­tect­ing inter­faces often hap­pens with just a sin­gle per­son. I don’t want to min­i­mize that as I myself served all these hats. I’m sim­ply point­ing the role of a wire­frame in the over­all inter­face design life cycle.

There are an abun­dance of tools that pur­port to aid archi­tects in cre­at­ing inter­ac­tive wire­frames, but then what does that dis­play to our team mem­bers? Does a designer want to be handed a gar­bled, poorly-coded, auto-generated lay­out with cookie-cutter inter­ac­tions? I know when I was a designer I wanted at least some lib­erty in what the inter­ac­tion and user expe­ri­ence ended up look­ing like. It’s true that in most design shops that the designer serves an IA role, but when we have ded­i­cated infor­ma­tion archi­tects shouldn’t we stick to doing what we do best? Don’t we deliver more value in design­ing tax­onomies, labels, nav­i­ga­tion, and con­cep­tual layouts?

The Customer’s Perspective

The cus­tomer will always pre­fer some­thing interactive—that isn’t a ques­tion. Look­ing at a bland Visio doc­u­ment doesn’t exactly inspire some­one, but what is the pur­pose of the wire­frame? Are we not try­ing to get the cus­tomer to focus on the lay­out, labels, etc and not how the inter­ac­tion will take place? When we design inter­ac­tive wire­frames doesn’t it also pigeon-hole the design­ers to design around the inter­ac­tions from the IA’s wireframe?

Here is what usu­ally hap­pens when you give any­thing inter­ac­tive to a cus­tomer when you’re try­ing to do IA and not inter­ac­tion design/user expe­ri­ence. They will spend more time click­ing around com­plain­ing about the pop-up win­dows and the way it looks and not what we actu­ally want them to be look­ing at? The value in sta­tic, seem­ingly dry wire­frames is that they have no choice but to focus on what we bring to the table in terms of IA and not user experience.

The Designer’s Perspective

Design­ers are artists in their trade. They make money, because they know typog­ra­phy, col­ors, inter­ac­tions, and all the other unique chal­lenges to being a designer. I can’t tell you how many times I’ve asked for wire­frames when what I was given was a poor mockup. Let us answer once-for-all that a mockup and wire­frame are not the same thing. The designer does not want to be given a mockup—that is the very thing they are experts in. The prob­lem only esca­lates when an infor­ma­tion archi­tect tries to tread too much on what the design­ers are sup­posed to do.

When an infor­ma­tion archi­tect goes out and con­verses with the cus­tomer, inter­acts with the func­tional busi­ness require­ments, and cre­ates and receives buy off on a wire­frame that it is almost invalu­able to a designer and the other pro­gram­mers. A pro­gram­mer can then focus on data­base schemas, object ori­en­ta­tion, while the designer can worry about the aes­thet­ics of the inter­face. You will become a programmer/designer’s best friend if you can abstract the job of cre­at­ing labels while not dic­tat­ing how the inter­ac­tion and how it will actu­ally look.

The Project Manager’s Perspective

Project Manager’s are often the hard­est to sell on the value of IA. They look at IA as some­thing the designer does, and that only con­tributes to the dif­fi­culty of sell­ing the impor­tance of our field. They are likely to look at the designer and say: give me a mockup to send to the cus­tomer, and when money becomes an issue in the project they’ll cut IA’s always before design­ers. I have never heard of a designer being cut in place of an IA. It has never happened.

We need to carve out what we do best. Design­ing infor­ma­tion sys­tems amongst dif­fer­ent skill sets is not rem­i­nis­cent of some mea­sure of unre­lated diversification—everything we do as IA’s is related to every­thing else. We just need to be sure that what we do we do as well as we pos­si­bly can while enabling our fel­low design­ers and pro­gram­mers while appeas­ing our customer.

Con­clu­sion

The the­sis of this essay was to define what our role is in the wider scope of the devel­op­ment process, and address just one small part of our value added propo­si­tion in the devel­op­ment of wire­frames. We have so much to offer, but we must be care­ful on where we tread because we fill such a polit­i­cal posi­tion in the devel­op­ment process.