(first published December 2007, edited in 2015)
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 right site is 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.
Effective by Design 