When is Simplicity Simplistic?

Vignelli's Doomed MasterpieceIn the early 1970s, Massigmo Vignelli re-designed the NYC Subway maps, making them beautiful abstractions of streamlined simplicity. The idea was based on a notion that the existing maps were too complicated to read, and that riders wanted simplicity.

Unfortunately, the Vignelli maps were pretty quickly scrapped because they were so divorced from user reality (the streetscape was completely out of scale) that folks had trouble locating where a street they entered from in their neighborhood actually was located on the map. They didn’t want streamlined. They wanted clarity. Dumb designers (actually, Vignelli was one of the 1970s greats, and the maps ARE beautiful.)

As with the NYC subways, University cultures and processes are difficult to understand and navigate. What is it about navigational design for a University site that makes it almost impossible to find anything? I wish I had the definitive answer, but in this space, I will begin to unpack this issue. For now, I’d like to address the issue of overanticipation.

This phrase came up when we were designing the TeachUMW Web site last semester. Our group (The Provost, DTLT, Teaching Center Advisory Committee members, and myself) was designing a site that preceded the actual program for which it was to be the initial online communications vehicle. As a result, we really had no way to anticipate information architecture when there was, well, little information to go by.

The structure of the site had to address the possible architecture of a conversation that had not taken place. This included not only which tools to provide (wikis, blog posts, event calendars, etc.) but how to structure access to them to enable new conversations to begin and branch out. Sounds like social networking, right? Right. So we used Drupal, a content management system that enables social networking. Since much of our conversation on campus is done within committees, task forces, and the like, Patrick Murray-John tweaked the application to allow these tools to be deployed based on membership in, or participation in discussions with, a particular group.

This all seems fine, but there was a piece missing, and we kind of knew there would be. There is no tool for users to create static Web content in the form of traditional information architecture: sections with sub-pages. An administrator can do this if they want, but we avoided it for the masses, at least at rollout. Why?

After much debate over this issue, we had to face a hard reality: How could we anticipate information architecture for static page content when the structure of the program was not yet in place? If we were to have a capability for static content, we had two choices:

Let the users develop their own static information architecture
We had seen how the UMW site had become like the wild west, with an information architecture so byzantine as a result of democratizing these decisions. One person’s “registration” is another person’s “academic catalogue” is another person’s “course listing.” The one who gets to make the decision is the person authoring the content. This person is an expert on their content, but completely unaware (nor should they be) of where that content fits into the overall architecture of the University. As a result, folks go to the search box. It’s kind of amusing to note that, during the design process, Jerry Slezak sarcastically suggested that the home page for TeachUMW simply BE a search box. That sounded great, until we realized that Google already exists.

Anticipate the information architecture as best we could
Never does the term “the best laid plans” seem to play itself out more than in over-engineered information architecture. The entire discipline is about anticipation of the user experience. When the user at a University is not only a consumer (like at Amazon), but one of MANY stakeholders with a wide variety of relationships with the University, this is almost impossible. People visit the site for hundreds and hundreds of reasons, representing students/prospective students, faculty/prospective faculty/retired faculty, parents, administration, staff/prospective employees, alumni/benefactors, Forum attendees, Gallery visitors, etc. And each of these groups breaks down by further granularity in their relationships with the University. Residential student or commuting student? Full-time faculty or adjunct? Administrative Faculty or Classified? State resident or out-of-state resident? If you are able to unpack that into a single information architecture that makes sense, I’ll call the Nobels and you are a candidate for the next Peace Prize.

The classic solution to the above is to have what’s known as a hybrid information architecture. We categorize by audience (alumni, student, etc.), and also by topic (Academics, Admissions, etc.), and sitewide supplementary navigation (directory, AtoZ index, search). What if I don’t want to take a second to determine if I am a student, faculty, staff (I may be more than one), or if what I’m looking for is within any of the topics that have been presented as the top level appropriate topics? Lots of folks don’t want to take the “beat” it takes to determine that. It’s cumbersome. As a result, the search is where a user will go. We simply cannot, at a single point in time, determine within what structure most users will be able to find where what they are looking for fits in.

So, let’s throw up our hands? No, but it fails so badly that I believe we should be willing to blow it up and start fresh. To that end, I offer the following possibilities if the University plans on taking the opportunity for the Sharepoint migration to mean more than simply a backend switch. Here are a few ideas:

1) Transactional Structure: When I go to a site, I kind of know what it is I want to be doing there: Research, purchasing, exploring, chatting, etc. What if there were a way to invite folks in based on the transaction they are planning with this visit?

2) Welcome Boostrapping: Attack the site design issue as an interative one. I’m not talking about “tweaking” so much as an annual, systematic analysis of analytics resulting in a well-researched plan of attack for upgrades and improvements deeper than cosmetics. Be open to wholesale change when indicated and be willing to “kill your darlings” if they don’t work.

3) Customer Service vs. “Design”: We like to have Web committees to talk about Web design. We are better served to have customer service committees to talk about ALL University transactions and relationships, and determine where the Web site fits into that initiative first. That way, any Web design changes and improvements are based in more than anecdotal preference, are coordinated sitewide by Enterprise Designers, and are part of a bigger picture that serves the University community.

4) Tagging Content: Let’s stop asking departmental Web managers/authors to anticipate fitting the content into a structure. It’s too overwhelming a task, and has led to the “wild west” phenomenon we see now. Let them do what they do best: Author accurate content, have it vetted, and publish it to the Web. Enterprise designers should develop a taxonomy for tagging, and templates to contain, aggregate, and display content based on tagging. Authors should be asked to select from a pre-determined taxonomy a list of tagged content based on its transaction type, audience, concerned offices, processes, etc. The CMS will present it as the Enterprise designers intend, based on the University’s customer service initiatives.

5) Expiring Content: Authors should be asked to set a beginning and end date for content so that old content GOES AWAY when it’s no longer needed.

Keep in mind that I say all of this knowing how instrumental I’ve been in creating the mess that’s now there. But the mess is a sign of progress. There is so much content by so many people, and that’s a mixed blessing, not a curse. In the long run, that’s a very, very good thing. We have just come to a point where we need to re-address not just the scalability of the technology, but the scalability of a dynamic information architecture based on solid information and a customer-centric focus.

In short, it’s not just about streamlining entry points based on aesthetics and anecdotal notions of simplicity. We saw how that worked for Vignelli. It’s not about shying away from complexity. It’s about embracing it, and making it work for you. With current CMS solutions, that is now a very real possibility, if the University has the will to start anew.

1 comment so far ↓

#1 Gardner on 12.10.08 at 12:38 am

Welcome bootstrapping indeed. After two standing ovations for Doug Engelbart this afternoon, I say welcome bootstrapping indeed. If you can get to the ultimate stage of bootstrapping in which the users become developers, and vice-versa, you’ll have done something pretty amazing.