The Information Architect: Cuckoo in the Nest?

Information Architects are newcomers to the web development scene and their precise role is often unclear. One thing appears to be agreed, however: web development was lacking something that the IA now provides. But given the overlap between IA and other roles established in software development, marketing services and other teams over the past few years, how should they best integrate so as not to screw everyting up (to use the technical term)? This essay puts the case for information architecture in a team context: challenging the assupmtion that responsibility for IA is something that should be invested in a single person.

Clear As Mud

Building web sites is a confusing business. Agendas conflict, technologies come and go, and quite often people can’t even concur on what makes a good one in the first place. Faced with this confusion, it’s natural to look for clarity. Who better to deliver that clarity than the Information Architect?

The IA is the new hero of the web development process. Five years years ago the role was all but unheard of, at least in new media agency circles. But quite what an IA is supposed to do is, just like most other roles in the new media development scrum, pretty unclear. Nevertheless, I’ll have to have a go for the sake of argument (and to add mine to pile): an IA ties together a diverse set of activities to arrive at a plan to create the best possible website for those all-important users. It’s a people-facing role, but underpinned by documentation because what the IA discovers needs to be communicated to the rest of the team. The use of user testing, content catalogues, site maps, schematics and wireframes are all IA territory. Perhaps more controversially, the IA can influence the client to change how they think about their website and the audience it serves. The IA “directs” (in the sense of a film director) designers and developers and works with the client to allow them to see how best to communicate with their audience. These things require change, project and man-management skills. Some also see their role as defining technical architectures and data models as part of their direction of the process overall.

Nice. But there is a problem with this. How should the IA fit in to an existing web development team? Such teams typically consist of a project manager, some developers, an art director and a graphic designer or three – and of course a client or at least project sponsor of some kind. Various others also make an appearance from time to time, like copywriters, testers, sysadmins and DBAs.

All of these people have valuable experience, domain knowledge and specific skills to bring to the business of creating the best website they can, measured by their understanding of the brief and by whatever standards prevail on that particular project. They are not used to simply listening to what an IA tells them to do, and then dutifully going off to do it. For one thing, some of their roles (and salaries!) just don’t fit that model, and if the IA adopts a role that’s broader than it is deep, they run the risk of at best duplicating – and at worst impeding – the work of other members of the team. Trouble, and sometimes terrible trouble, can ensue if issues of branding, functionality or scope are knocked too far off course in the name of “architecting the user experience.”

In an agency context this potential for disruption can also be acute for another reason: web projects don’t typically come to the team as blank slates. Those who initiate projects (MDs, CEOs, brand teams, marketers) will have spent a few iterations on a business case with some direction on content and target audience, and will also have pretty clear ideas about how they want the site to work. The expectation is that the team will then fulfil these wishes in the appropriate manner. Far be it for anyone to wade in and start ripping up their rulebook, or suggesting they conduct six weeks of user research into navigational prototypes to uncover whether they should be creating the web site at all. Not surprisingly, this hardly ever actually happens in real life, but the received wisdom about IA seems to imply that maybe it should.

Not only that, but for all the millions of words written about what IA is and what and IA does, very little seems to be from the perspective of people like art directors or account managers, let alone developers or project managers. The assumption seems to be that these people should move aside and let the IA do the work of “directing” them. I would guess that at least several people on a typical team might look at IA activities like defining business cases, KPIs and data models and think, “I do that already – and I probably do it better than some generalist IA.” In particular, account managers or planners might be thinking, “What does a jumped-up tecchie know about my client’s brand values?” A technical architect would be equally miffed if they had to take orders from an IA based on a notion of “appropriate technology.” And so the list of possible blunders goes on. In short, information architecture needs to be a lot about co-operation as much as anything else.

So We Don’t Need No IA, Right?

Wrong. Most information architects know that their role enjoys a good degree of hype right now. If they did even half the things they are sometimes attributed as doing then they’d threaten the success of most projects. They do however contribute a great deal by providing something that most web development teams sorely lack: useful documentation, effective requirements management, and a balance to unfettered creative treatments.

Because of this, the role that perhaps has most to gain (or lose, depending on your point of view) in the presence of an IA is the project manager. In most agencies, the PM (or Producer) has to work on the administrative overhead of the project: sorting out budgets and schedules; yakking to recruitment agents, facilitating meetings, etc. But they also find that they have to capture the ideas that cascaded from meetings, phone calls and chats around the water cooler about what the website should do and how it should achieve it. This dual role means that most projects are neither well managed nor well documented because there are just not enough hours in the day to do justice to both.

If the arrival of the IA role brings new media development one more step out of the dark ages, it should do so by allowing people to play to their strengths. Properly managing even a moderately complex project is time consuming. With more than one to run it’s a full-time job. Properly eliciting, capturing and communicating functional and non-functional requirements on a project is equally hard work, and leaves no time for reading CVs or fiddling with Gantt charts, budgets or contact reports.

IA Is An Activity, Not A Person

In the long run, IA should really be a team activity in which all but the project manager needs to regularly participate in. It is too broad to be encompassed by one person but too important to be ignored. There is a parallel here with the role of quality assurance manager in the old days of software development. For example, this is what the Rational Unified Process has to say on the subject of QA:

A common misconception is that quality is owned by or is the
responsibility of one group. This myth is often perpetuated by
creating a group, sometimes called Quality Assurance (other names
include: Test, Quality Control, or Quality Engineering), and
giving them the charter and responsibility for quality.

Quality is and should be, the responsibility of everyone. Achieving
Quality should be integral to almost all process activities instead
of a separate discipline. Thereby making everyone responsible for
the quality of the products (or artifacts) they produce and the
implementation of the process for which they are involved in.

What is true of QA is becoming true for IA. While the principles of IA are becoming more widely understood, there is a need for individuals to evangelise it. So what would a good team dynamic look like in the presence of an IA?

Firstly, it’s best to acknowledge that project sponsors are domain experts and know broadly what they want to achieve; they don’t necessarily want or need an IA to tell them about their business. Their ideas may be challenged on the basis of research or other rationale, but at the end of the day it’s their project. Further down the chain, account managers look after the relationship with the sponsor and focus their strategic thought usually in order to make money out of that and other relationships (mercenary, but true). Project managers should facilitate the work of the rest of the team by looking after the administrative overheads, and should be freed to do this without having to worry about whether the home page has the right content to attract first time visitors, or what that button is doing at the bottom of the screen. It is that activity that falls to the IA, but she will leave ideas about whether something should be a cloud of spinning cherubs (as opposed to a popup menu) to the creative team. The IA might temper these ideas by facilitating audience research, but creativity needs to be respected for what it is: fragile genius and a vital part of any new media project. Similarly, if this creative goes too far off beam for whatever reason, the IA will put it right by referring either to experience or to the project documentation. In other words, it’s checks and balances, but the IA is the judiciary. Meanwhile, they also make sure that all stakeholders – but particularly the developers – can understand the minutia of what needs to be created by producing specifications and models that they can use to start the build.

Some readers may recognise the above utopian description. Replace “information architect” with “business analyst” and it all becomes much more familiar in an “old school” IT context. Indeed, the role of BA itself came out of systems analysis at around the same time as QA managers became subsumed in the complexity of software development. Roles evolve, people change. So perhaps if we think of an IA as a BA and treat IA as a process that all team members need to focus on, we’d get better websites made faster and with fewer of the confusions that currently plague the industry. Whatever, either way, the information architect is dead – long live IA!

—

This essay was originally written in December 2003