MoragJ

(first published December 2007)

Here’s my little tap dance on BAs. It’s not so much “here’s why we’re so great”, but “here’s the evolution of the need for them in Web projects”. I originally wrote this as an email explanation for some one who was coming from an environment where she’d managed banner ad and microsite production.

…

IN THE BEGINNING, around 1993, ‘94 or so, you’d go to your local computer geek and say, “I need a Web site”. He’d build it for you. You’d be so damn excited it existed, you didn’t care that it was ugly and the words were mis-spelled and the whole thing ungrammatical. If you were lucky, the geek had a friend who knew how to use some graphic design tools and your logo would there, loud and proud. You had a page with links. Links! How exciting to be part of it all!

When the Web started to catch on among non-academics, a lot of advertising agencies got into the game and hired their own geeks. They figured that they knew about creating brochures and other print-like marketing material so why not? They would show images of what the page would look like to the geeks, the geeks would work with the graphic designers and maybe copy writers, and create a site.

The agency would show the site to the client, who would immediately make a bunch of changes: “oh didn’t we tell you? this page needs to show the hoozy, and we need a separate page for the whatzit. The whatzit is really important and should be in the top bar of links”. The agency team would then go back and re-create the site — pretty much from scratch. Since Websites were often billed outside of the agency’s retainer, they often lost money.

Eventually agencies got wise, and had the client approve the copy decks and imagery before building. They even created site maps so that the client would see how all their pages linked together and how many pages there would be. That way, the agency could at least charge them on a per page basis. Some one, usually a production manager or an account executive created the site map and presented it to the client.

Then came the database driven website, e-commerce and content management systems. Development got a lot more complicated. Site maps just didn’t cut it anymore. Some one had to decide and keep track not only of what pages had to be built, but which of them were static and which were dynamic, and on the dynamic pages, which elements were static and which were dynamic. There was the beginning of the recognition that the end users should be consulted about how the site worked. This all had to be communicated to the client, the tech team and the designers. Agencies that didn’t document this stuff well still lost money because they couldn’t communicate it well and the wrong thing was built.

Agencies then figured out that if they hired an information architect to keep track of all this stuff, document it and present it to the client, then everyone could agree what was going to be built, instead of freaking out when the launch date loomed and the client needed to make lots of changes. The IA took over all that site map and navigation stuff too. Based on the IA’s documentation, tech teams could tell the PMs what it would cost to build, and the designers were more likely to design something that could accommodate the information from the database. Even better, all that work was done before the designers spent time fiddling with pixels.

Since the great Internet crash of 2000, companies have learned that they need a website, and they also know it takes a lot of effort to maintain a website. Everyone is a lot more sensitive to costs. The types of things that companies want to let their customers do on the Web got a lot more complicated than just reading documents and buying things from a public catalog.

Agencies were still getting the, “oh didn’t we tell you?” thing from their clients after seeing the built site. They also got the “we specifically told you that our CTP was BAU and I don’t see that reflected in the page design”. By this time, agencies had run the numbers and realized that the later in the development process an error like this was caught, the more expensive it was to fix — some software engineering estimates say 1000 times more expensive or even higher.

In meetings, clients would say things like, “All our customers are presented with offers on the site. Except those who aren’t authorized users. Everybody else. Well, actually everybody sees offers for virtual account numbers. Unless their card doesn’t support virtual account numbers. Or if their account is delinquent. Or if they live in Idaho. And Nebraska. Maybe South Dakota. I’ll check.”

The IAs would put together the wireframe documentation. Unfortunately, some IAs didn’t want to admit that they didn’t understand the client’s business or how their products worked, or assumed that the client knew exactly what they wanted and had told them exactly how things worked, or the IA was so focused on creating a “great experience” that they didn’t get all that business stuff — they figured that tech or QA would work it out.

The client would approve the IA documentation — even if some flow variation wasn’t shown it had been discussed, so of course it would be in the end product, right? —, the tech team would quote, and the agency would provide the costs to the client. When the site was all built, it would be wrong. The client would be disappointed and the agency would be out of pocket. Agencies realized that they needed some one who was willing to wrestle the business logic into submission.

Enter the BA. Gestated in the software industry, we browbeat the clients into admitting that they don’t know their ass from their elbow — in the nicest way of course. Most of the time, clients think they’re telling you everything you need to know, it’s just that so much of their business process is second nature to them that they don’t think to tell you about it. To be kind, we’re like business ethnographers. BAs are both patient and pigheaded enough to force the client to go through their work processes step by painful step, so that the end software — not really a Website anymore — really reflects what the business needs it to do.

That’s yer basic BA — making sure the site’s built right. Yer advanced BA helps make sure that the right site is built. Many clients still don’t understand that the Web is there to support many aspects of their business, not just have a sticky home page that users return to on a regular basis to build their brand loyalty. The BA says, “so tell me what your business is about? what are your short and long terms strategic goals? How do you see the Web helping you reach those goals? “…

Of course, you’re still going to get the “oh didn’t we tell you” thing, but a lot less often.

(first published December 2007)

Ah, the heuristic usability site analysis — how fun is that? You get to point out how badly someone else did the experience planning meanwhile implying how much better your work is going to be.

As some one who’s done a few site reviews and lived to tell the tale — barely — as much as the site sucks in your mind, start out the report with all things positive to let the client know that you appreciate the thought that they’ve put into their darling site. As objective as they may *claim* they want the analysis to be, they also want to hear that they got something right. If you don’t acknowledge this, the next meeting with the client may be a frosty one. I’ve seen client-vendor relationships ruined through site evaluations. (Guys —site analysis is the equivalent of the “does this dress make me look fat?” question)*

Also, the client may read your remarks as “the sky is falling” and rush into a blind panic. You don’t want this. This may be how they got themselves into trouble in the first place.

When it comes to report format, generally, I’m a big fan of sub-heads, bullet points, lists and pictures, even in executive summaries. Expect that any paragraph longer than 3 lines will not be read. The person will read the first sentence, then skip to the next paragraph if they don’t immediately grasp the point. Also, provide a quick and dirty wireframe that illustrates your suggested changes for a page. Pictures speak louder than words: annotated screenshots make your docs effective.

*Should you ever be asked the dreaded DTD (does this dress…) question, your response should be immediate and without falter: “No sweety pie, how could anything ever make you look fat?” Any other answer, or even the slightest pause, implies that you are considering the issue — there may indeed be a piece of clothing that could make your beloved look fat — and we know that “fatness” is impossible.

(first published in August 2005)

There are a lot of companies in Toronto clamouring for information architects right now.

When I realised this, as an IA consultant, my reaction was, “By George I think they’ve got it! Let the good times roll!” I thought that the industry must be picking up, and that over the course of the past 3-5 years, Internet agencies have come to understand that IA requires some specialized skills and even, hope against hope, deep experience.

Then, when I start to read the job descrtiptions and talk to people, I realize that nothing much has changed. Many companies are still looking for IAs to double as programmers and designers, OR they want them to just provide some pretty diagrams to illustrate what the account manager has constructed.

It’s enough to give a gopher the heartburn (W.O. Mitchell).

… but teamwork and intelligence wins championships.” - Michael Jordan

(first published in Aug. 2005)

I freelance as a business analyst and information architect. When I started in the biz in 1995, like most everyone, I did back end work, front end work, client work - everything. I was working on some good size sites too: within a year I was doing a database driven tax law research site tied in to an SGML publishing system.

As the Websites I work on get bigger and the Web industry evolves, my role in the process is changing and not always in a way that’s comfortable.

On my last project, a large ecommerce site, I was the information architect. I developed navigation flows and wireframes. While I contributed to the creative concept, the final decision about creative direction was not mine. I created wireframes knowing that the navigation could move, that call outs and additional levels of subheads might be added, that the conversational flow might change from what I’d documented. I haven’t coded anything more than a simple CSS based site in years. It’s a little unnerving for me. I’m used to having much more control.

This distributed planning process can go two ways. I’ve been part of both:

1. Each team member feels a link in a chain. The more apathetic of the group take the project input from their Inbox, add their layer, and stick it in their Outbox. The more driven people can ensure that it is their vision that makes it into the final product. With little team discussion the process moves quickly. The quality of the final product is very dependent on the talent of the most dominant person on the team, and on the ability of each person in the chain to complete their work exactly; holes at any stage are filled in by guess work and/or experience by the person who is currently in the hot seat, or the dominant team member.

2. Each team member recognizes the team’s interdependency: how they contribute to the whole. The process is more iterative; not linear but a cursive, forward moving set of loops. Everyone’s work is reviewed and discussed by everyone else on the team. Team members have to be able and willing to give and get constructive criticism. It is not a fast process, especially if the team has not worked together before. The quality of the final product depends on team members’ tolerance for group work. Revision cycles need to be controlled to control the budget. Team members have to be brought in early enough, but not too early. Holes at any stage are more easily dealt with as the responsible team member is easily available.

I obviously think the second process is better, but only if there is a really good team. It would be absolute hell to go through it otherwise. However, if it is a bad team, the first process ain’t no picnic either.

Moral of the story: work with good teams.