George Bernard Shaw once said that,
“the single biggest problem in communication
is the illusion that it has taken place.”
Art and history oriented, collections-integrated, museum and gallery website projects involve multiple stakeholders and departments, address broad audiences using diverse content types, and integrate with multiple systems. Such complex projects, with large project teams, introduce many opportunities for communication illusions to abound.
This month’s article will pinpoint some of the subtle, yet pernicious ways that communication failures can derail website development projects. And how they can be overcome.
Communication Breakdowns
As Shaw observed, communications fail not so much because of what is said or not said, but because of what is presumed to have been understood. These kinds of assumptions can derail communication in even the simplest of conversations. Even more so when we try to communicate about abstract and complex subjects—particularly when we’re unfamiliar with the terminology of the subject. Confusion increases all the more if we add multiple participants to a conversation. And when communication unfolds over long stretches of time, forgetfulness can introduce further distortions, causing even more communication gaps to occur.
That makes website design projects particularly vulnerable to illusions of communication. Websites are complex and abstract. They are filled with technical jargon and concepts unfamiliar to the average client. Websites for museums and archives often involve many stakeholders, each with their own goals and priorities. And it’s not unusual for these projects to span six to twelve months, or longer.
For clients and developers to effectively communicate throughout a website development project much care needs to be given to the process. Unfortunately, quite often, web development processes not only fail in this effort, sometimes they introduce even more confusion.
A Minor Rant on “Agile”
“Agile” is a popular software development process that is often used in web development projects. But even though websites do consist of some software elements, they are not entirely like a software development project. And while Agile is great for software development, it’s not always the best process for other kinds of projects. And frankly, since the Agile process is heaped with its own jargon, rules, and procedures, unless you’re already trained in it, the process itself can end up making an already complex process into a complete quagmire.
But if I had to give one main reason why processes such as Agile are not the best fit for web design projects it would be the initial requirement of establishing the “product backlog,”which is a limited set of goals and requirements that direct the first “sprint.” (A sprint is a one or two week focused effort to deliver an initial, minimal set of objectives.) For a sprint to be effective a team has to focus on just these minimal goals. Without that focused list, and rigid focus on it, Agile doesn’t work.
But how can a project team, consisting of stakeholders from various departments, unfamiliar with this process, determine what should be on such a list? I take exception to the assumption that a client team can be expected to know what the first or most fundamental goal should be. In the context of art- and history-oriented websites, the likelihood that the client team will synthesize the entire institution’s priorities into a sprint product backlog is very low.
Rather than conquering the illusion of communication problems, Agile processes can often just add more confusion. So if Agile isn’t the solution, how can website projects overcome the illusions of communication?
How to Conquer the Illusion of Communication
There are two ways that Cuberis addresses communication issues and minimizes their impact on our projects. One is somewhat unique to our firm, the other is something any project team could potentially adopt.
Leveraging Experience
The first solution to this problem is leveraging experience. And this aspect can’t be provided by any development process no matter how well crafted. In fact, one of the reasons processes like Agile are so popular in the software and technology space is that they are the best alternatives available to replace the lack of experience and expertise.
You see, one of the reasons that modern processes like Agile are so popular among software and technology teams is that they don’t require any specific concentration of experience. Because tech is such a rapidly growing sector of the economy, staffing and resourcing is a continual challenge. Growing technology firms have to be able to onboard new team members, and move and replace members regularly, in these rapid-growth environments. They can’t afford to rely on the experience of one or two key team members—that’s not scalable enough!
And so modern software processes are designed to be problem agnostic. Ideally, a team with the right skills, following a clear process, should be able to solve any problem within their skill sets. Agile teams focus on raw skills and consistent processes. They replace depth of experience with cross team collaboration. Holistic team participation and comprehensive team ownership of projects are a scalable replacement for individual expertise. That’s not a bad thing of course, and if there are no team members with specific experience, then that is the way to go. But such processes, while intended for good, can sometimes have the unintended consequence of disenfranchising team members with relevant experience.
Expertise and experience on projects with very similar problems can bring far more value to a project than the most consistently run and perfectly maintained formal process. Experts become experts because they continually focus on the same problem until they can start to see patterns and anticipate needs before they occur. That’s why experts are so valuable: for leading complex projects where communication must be clear, and on projects where they must anticipate which solutions have implications that the team may not be able to connect to the final product. The expert needs to know exactly what the client doesn’t know, and can’t be expected to know.
Very few creative firms have the discipline to stay focused on one area of expertise and repeat projects with very similar requirements. Designers and programmers are more inclined to pursue new concepts and the latest technologies. They’d rather not repeat the same kinds of projects over and over again. But the only way to gain expertise is through repetition. This is one reason why Cuberis decided to focus on art and history, collections-oriented websites, such as museums, archives, and galleries. Before we made that strategic decision, just about every project introduced new problems to us, in industries we knew nothing about. And we had to rely on our clients to educate us and bring us up to speed. But with repeated experience comes insight and reliable foresight from pattern matching.
Expertise is a better alternative to even the tightest processes, with the most highly skilled resources. Of course expertise, with a tight process, and highly skilled resources is better still. And so in addition to providing expertise, we also provide an effective process.
A Better Process Suited to Website Projects
At some point in a planning process you have to put pen to paper—or code to screen. Whether you’re building software or a house you have to workup blueprints before you build.
And this creates the main problem in communicating website plans across large teams. What form of documentation works best to confirm and establish these important plans? In website development those tend to be technical specifications and wireframes. Between website designers and developers these kinds of documents are very effective at defining project specifications. But are they as effective for client teams? Not so much.
Let’s think about a website as if it were a physical building, whose planning would start with blueprints. An architect, engineer, and contractor can stand look at a set of blueprints, and due to their professional training and experience, they can readily extrapolate from those plans to imagine the final product. As a buyer, though I might be able to get the gist of the plan from a set of blueprints, my ability to fully imagine the final product is much more limited.
But going back to our construction illustration, what if a buyer could view a virtual 3D model of a completed house instead of a blueprint? Or better yet, what if they could walk through a fully built model home? That would remove almost all uncertainty.
So what is that equivalent form of communication in website development?
A Model Website Prototype
If a model home is the ideal way to present a house, why not build a model website? Rather than static wireframes that rely on symbolic representations of page navigation and content elements, why not actually build out an actual website? In the same way that walking through a model home, moving from room to room, opening closets, checking windows, standing on the floors, gives us a real feel for the house, so to does clicking through an actual website, rolling over the menus, scrolling down the pages, clicking on the links, provide a concrete understanding about this complex and multifaceted structure.
Back in 1999, when I first began using web-based prototypes rather than printed wireframes, we had to manually build them with Dreamweaver. It was quite a time investment to build an actual website rather than sketch wireframes. But when we saw how much better our clients grasped the details of our prototypes compared to the frequent illusions of communication we’d experienced with wireframes, the effort was worth it. Eventually, we built our own prototyping system to improve our efficiency in building these models.
Today, CMS platforms make building web-based prototypes much easier. We developed our prototyping platform using WordPress, a specialized theme with helpful plugins, and some other components that enable us to rapidly produce website prototypes. From the first steps of information architecture, all the way through the planning stages, we present each iteration as a fully functioning website. And since we focus on art and history, collections-oriented websites, our repeated experience enables us to anticipate many of the specific needs our clients will have, such that we’ve pre-built certain repeated content types and functions, making our prototypes even more detailed and efficient.
One way we keep the prototyping process efficient is by making them visually generic. They are mostly black and white representations of content which, if you were to print the page, would actually look a lot like a wireframe. Keeping the aesthetics generic also helps clients to focus on the core content, structure, and functionality without getting distracted by design issues that come later in the process. But though wireframes and prototypes both have the same look and feel, the experience of reviewing a clickable, scrollable, model website, in a browser, delivers a much better feel for how the final site will function and flow.
This small difference in presentation enables deeper observations and elicits greater understanding from the client teams. A clickable model also reveals flaws more effectively. Some ideas sound good conceptually, when we talk vaguely about a site, but when experiencing the real thing we realize we may need to rethink them. Prototypes also elicit new ideas, options that simply did not, and probably could not, occur to a team until they are experienced on the website. And since prototypes are built so early in the process, these new ideas can often be integrated without impacting the budget or schedule.
I don’t want to suggest that we don’t still experience some illusions of communication, but through web-based prototyping we drastically reduce them. Ultimately what matters is the final website, not how we get there. But if we want to end up with the best possible site, that serves the interests of all stakeholders—and most importantly the people who will use it—we must conquer the illusions of communication that get in the way, and pave the way for effective communication.
