in which Sarah attempts to be less snarky and more complex
After three weekends away and too many late nights at work, I finally decided tonight was the night for watering the garden. It was starting to look extremely droopy, full of unhappy flowers and healthy weeds instead of the other way around. I’m uncertain how the weeds thrive while everything else suffocates in this heat. I guess the plants with the staying power—the ones that grow anywhere in any conditions—eventually win. I’m sure that’s a metaphor for something, but there’s no need to analyze it. That’s just how natural selection works, I guess.
The thing I find even more surprising, no, irritating, no, umm…I don’t know. The thing I notice every summer as if it’s a new phenomenon is how the plants I didn’t plant with my own two hands thrive. The hostas and ferns and creeping ivies come back bigger and better every year. There’s usually something new too, something hidden in the ground making a comeback or something dropping in from a neighbor’s garden.
Speaking of neighbors, my next door neighbor walked down our shared driveway as I was tugging on the hose.
“Isn’t it going to storm tonight?” She asked, while I wrestled with the tangled mess.
I shrugged and said, “It needs it. I neglect it [the garden] because I can’t stand dealing with this hose.”
“You should get one of those rolling things like we have,” she suggested with a nod toward her perfectly coiled water-delivery system.
As we continued chatting, my mind wandered a bit. I pondered why I didn’t get one of those rolling things or make more time for such a simple chore like watering. After all, I did spend nearly two whole weekends purchasing and planting all those flowers. The ones hanging from the trellis have died. The hydrangea is getting too much sun at the back of the house. And someone or something stole the only red tomato my plants have produced so far. The raspberries are great, but that’s because they grow like weeds. Red, ripe, juicy berries are popping up on seemingly lifeless branches. Every other day or so for two to three weeks, I’ve harvested small handfuls, enough to cover my morning granola. Nature is amazing.
So why don’t I put in the effort? For a totally stupid reason: because the hose is a situation. The spigot to turn on the water is at the opposite end of the house from where the water comes out—and in the basement. I have to go down into the basement, walk the length of the house, turn on the water, walk back to the other end of the house, up the stairs, and outside to the hose. Then I have to unravel the hose and drag it from the back of the house (where we have a few fruits and veggies) to the front of the house (where we have copious plants and flowers). Invariably, I then have to walk back along the length of hose and work out the kinks so the water will come out the spray nozzle. Rinse and repeat that last step until the entire garden is soaked.
This evening, my neighbor, Mrs. Green Thumb (not her real name), was strolling by as I stepped out onto the front sidewalk, balancing the hose under one arm and firing it like a canon at the cracked earth beneath my plants.
“Hello!” I greeted her cheerily.
“Oh, good,” she replied.
Her response did not match my greeting in the slightest, but I beamed back a warm smile that matched her own.
“We’ve been away,” I said, to excuse my obviously neglected plants while she stopped to appraise the situation.
“I think you’ve caught it in time,” she nodded her approval.
I nearly dropped the hose to throw my arms around her in gratitude. When it comes to matters of the earth and green, growing things, an endorsement from Mrs. Green Thumb is like a mandate from Mother Nature. I was proud and relieved by her words. I managed to restrain my joy as we chatted a moment longer. Then she walked on.
As I stood under an ever-darkening evening sky, I brooded about how much control I have over what grows. Most days (when I’m in an ever-darkening mood) it seems as though what wants to grow will grow, and what doesn’t won’t. My garden teases me. It gives me a false sense of authority. I can put things in and pull things out. But I can’t choose what will flourish and what will wilt during a week of 90+ degree heat. (That’s in Fahrenheit for any un-American readers.)
Standing in the hot dusk, the warm breeze pushed me around. The wind battered my skin blowing the thick, tight air closer. The cool spray from the hose provided some relief, but I focused the stream on the ground in an attempt not to waste the precious drops. As I concentrated the water and my attention on green leaves, my mind turned to my adventures in Africa. It has been Africa-hot here this week. Zimbabwe in early summer hot.
In Zimbabwe in early summer, Mother Nature performs an awe-inspiring and delightful trick. Barren, lifeless-looking trees sprout delicate, barely-visible spring buds in preparation for the approaching rainy season. Now you’re wondering, What’s so great about that? That’s what happens in spring, right? If creating something out of nothing doesn’t strike you as that amazing, ponder what happens next.
Gaya sends a rain storm, one short rain. The water disappears into hard-packed clay seemingly lost forever. But indeed, that one rain rallies the trees and shrubs to defy months of drought. Dry branches shrug off the dusts of winter. Leaves open. Trees turn green. That one brief rain primes the soil in preparation for rains that are yet to come. The leaves open, against all odds, to catch waters that are two weeks away yet. That one short rain forces the change in season. It gives the African bush the courage to grow and renew itself year after year. A rain storm that quick wouldn’t even register on the radar of a resident of Seattle, London, or Boston. But that storm forces the leaves to open so they can catch the coming storms. Two hot, humid weeks later, the heavens will open and the rains will start in earnest. Life will defeat death this year as it did last year. How the leaves and trees remember that while they sleep through dry and dusty winters may be just another example of natural selection. But it’s a wonderful, beautiful mystery to me.
As the evening light retreated, I pictured viridian Acacia leaves towering above rusty grasses surrounded by pure azure sky. I took my time finishing the watering. And when I was done, I coiled the hose neatly. Just as I finished, the sound of thunder rolled in on the breeze.
In a previous post I talked about an example of technology constraining us in ways that don’t conform to the way we speak or write. We let the format dictate our attention span. For instance, I’ve broken this article into two posts because I was concerned it was getting too long for my (imaginary) readers.
We allow technology tools like a content management system to dictate how many words we’re allowed to use. Once again, there could be a more depressing explanation. It may not be a technology problem. It could be a cultural problem, a limitation that we humans built into the software. It could be some old school print journalism rule about character limits on printed headlines. Which makes the whole situation crazier. Because we are perpetuating rules that work against us. We should be enabling Web technologies to set us free from rules that apply to printed paper. If the printed word is dead, the BBC news team should be allowed to use more than 36 characters to create a headline that both catches the interest of their online audiences and conveys an accurate summary of the article.
This is at least the third example of technology constraining communications goals that I’ve encountered in the last couple of months. One quiet spring afternoon, I was browsing through business school Web sites doing research for one of my clients. Browsing from site to site, I was gobsmacked by the Columbia Business School home page. They have a nifty scrolling news bar that serves rotating headlines to push as many stories as possible while keeping the design minimalist. Good strategy. Except the 1024 pixel wide page design and the font size of the headlines means that only 1 ½ headlines fit at a time. And when I opened the page, it said, “Event Celebrates Launch of Joint.” And I thought, Wow, that’s a funny thing for a business school to celebrate. (In this case funny means some combination of strange, unusual, and unexpected.) Being a designer of these sorts of features, I immediately realized what was going on and I waited to see what would happen next. Sure enough, the headlines scrolled left and the complete title said, “Event Celebrates Launch of Joint Academic Center.” And then I thought, Ah ha! That makes a lot more sense. (And good for Columbia!)
This happens to us all the time. I can imagine what the design team (not mine) was thinking. They there thinking they needed to streamline headlines into one slim spot on the page. But they also needed to show one full headline and a smidge of the next one so readers knew there was more coming. It’s a great visual cue for users. It primes them to wait for the auto scroll or to click the manual scroll control. But they probably used placeholder copy (lorem ipsum) in their designs. And then they gave the business school a suggested character count for headlines. It all made sense to everyone until the news team started to interpret the character count as a maximum limit rather than a recommended number of letters and words. And they started to shorten the headlines. To be fair, sometimes headlines don’t need to be long. Less is more, as we say. So perhaps this all happened naturally. Whatever the cause, the result is that sometimes the partial headlines don’t make sense. The words that appear can sound funny, off-putting, or just plain offensive. And so, I’m making a note for myself that the next time we propose a similar feature, we’re going to show complete headlines and only complete headlines.
The third example is one of our own. A client recently asked us to copyedit some text for a corporate video we designed for them. The copy was going to zoom in, hold on the page for a second or two, and then zoom out. The text needed to be short to promote easy on-screen reading. That all made sense to us. But removing words from the copy changed the meaning of the facts our client was presenting. We hemmed and hawed over it for a while. And then we decided to do minimal editing. We cut an unnecessary word here and changed a 25 cent word to a penny word there, but overall we changed very little. Rather than removing words that changed the meaning of the video, we slowed down the pause between transitions, holding the text on screen for a half beat longer so viewers had enough time to read all of the words.
Sometimes less words changes the argument. Sometimes, it’s better to use the same number of well chosen words and speak them slowly and with conviction.
A week or two ago, a BBC News headline popped up on my RSS reader. The title said, “Ancient cave women ‘left home’.” Typical, I thought and sniffed in disgust at my monitor. I stared at the headline a moment longer, pondering an unhappy, dirty, hunched-over woman with bad hair sweeping a cave, tending a fire, and caring for unhappy, dirty children. In a flash, I realized my imaginings were preposterous. Where would she get the broom? That thought piqued my curiosity, and I clicked through.
On the full article page, headline read, “Ancient cave women ‘left childhood homes’.” Ahh, I thought. That’s different. In fact, that means sort of the opposite of what the short headline implied. And now we’re on to something.
Nature is smart. Our genetic code (and the code of all the animals that I can think of off the top of my head) is hardwired to prevent incest. Survival of the species is not enough. Nature intends for creatures to thrive by the resulting reproductive problems.
With lots of mammals, bears and lions for instance, adolescents are left on their own when they near sexual maturity. In the case of bears, a mother abandons her cubs around 17 months of age, when she is ready to for her next chance at reproduction. This is partly due to the fact that she won’t have the resources to for care for her teenagers if she is caring for a new litter. And partly because her previous mate may not be her future mate. She needs to protect the cubs from a potentially territorial male who will think nothing of killing them and her if she gets in the way. This makes good sense from the perspective of evolution even if the life of a bear seems lonely and estranged.
A lion’s situation is slightly less grim and a whole lot more social. A female gets to stay in the pride of her birth for as long as she chooses. In most cases that means she gets to spend her whole life with her mother, sisters, aunts, nieces, cousins, and daughters. They share chores like hunting and caring for cubs. When the boys become sexually mature around two years of age, they get chased out of the pride. As unhappy a fate as that sounds, they get to take their brothers with them. They roam and form bachelor prides. Joining together with other young males, they hunt and sleep and laze about until they are ready to rule their own prides. All in all, it’s not a bad deal. Diversity in the gene pool is ensured, and siblings get to stick together.
Reading the article about cave women was the first time I really thought about what this means for humans. We know this is a good practice, avoiding incest. Every country in the developed world has legislation against it. (Although I have no idea how you would go about enforcing a law like that. It’s not like pulling a guy over and checking if he’s wearing a seatbelt.) But in cave man and cave woman days, how did they know? Maybe they didn’t know. Not really. Maybe making out with your sister or your cousins has always been weird. Or maybe the women were claimed in tribal warfare. Perhaps they were kicked out of their tribes when menstruation began. There’s no way to know based on the information gathered so far.
I’m fascinated by this. I’m fascinated by cultural history and how we are and are not like the other mammals. I’m even fascinated by my own accidental misunderstanding of the article. The idea that ancient cave women were left home—I assumed that mean they were left at home as domestic help while the men were doing all the “real work.” I wish I could take an Anthropology elective for my ALM at Harvard Extension, but it won’t count toward my English Lit degree so it will have to wait.
But, what got me started on this blog post was that headline—the first headline—the one that was so misleading. My misunderstanding (I think) was easy to understand. The title said, “Ancient cave women ‘left home’.” This was the short version of the longer title. This was the one that appeared on my feed, the version that prompted me to navigate to the full article and read more. This could have been intentional, written by a witty copywriter with an eye on the click-through statistics. But more likely it was done by a person in the BBC’s online department who helps manage Web content. That person could have a writing background and editorial control over news stories, or she could be an intern who believes the limit on the RSS feed headlines is somewhere in the neighborhood of 36 characters. Except it’s not. Because there is no such limitation on the feed. Which makes the situation a whole lot worse. The worse situation is that the content management system used by BBC News probably includes a content type called something like “short headline”. This is the content that is used in RSS feeds. And the person managing Web articles is forced to shorten the standard headline to conform to the character limit of this field. And, voila, we get RSS headlines that mean something very different from the standard article headline. This works as long as subscribers click through, attracted by rather than repelled by the short headlines. And it works as long as it doesn’t happen so often that frequent readers feel duped or annoyed and stop subscribing to the feed.
It doesn’t work if the meanings of articles are radically changed to meet the limitations of the software managing the content. The mantra “content is king” has been drilled into us for so long, we’ve almost forgotten that the content must be trustworthy. Misleading headlines damage journalistic integrity and a reader’s trust in the provider of the news. Lacking trust in the content, readership drops and a Web site and a brand can be wrecked. At the risk of sounding melodramatic, that 36 character limit in the hands of an unskilled person can destroy a news source. If you’ve only got 36 characters, choose them wisely.
I had a chat recently with a long-time colleague and content strategist, Margot Bloomstein. She was doing some writing on IA and wanted to pick my brain about how I use that term and why. I referred her to my blog post and we had a humorous chat that seemed worth expanding on here.
First, a confession: my business card says “Director of User Experience.” Even though I use the term information architect in casual conversion, I do prefer to the term user experience (UX) for formalities. I think user experience as a skill set (and buzz phrase) is gaining traction amongst the people who are in the know. It also helps me separate the hands-on work that I do—the on-the-ground, in-the-trenches wireframing, sitemapping, and usability testing—from the consulting and strategy services I offer my clients. It’s a bit aspirational on my part. I don’t want to draw wireframes forever. (I am still looking for someone to do that work for me, so if you know anybody…) “Director of User Experience” is also a title more often used in a bigger studio or agency, and I like to keep on par with my peers. Mostly it just makes me sound important. And let’s face it, that’s the most important thing when it comes to running a business and selling a project.
There are distinctions among the differing skill sets that a typical user experience designer can offer. The first thing to know is that there is no such thing as a typical UX designer. Not all of us are good at everything, even though we try to be. The technologies change and so does the demand for specialized skills. Before mobile phones and iPads caught on, we were generalists. During the bubble, when demand was high and there was a shortage of skilled people, we wore many hats, playing Web strategist and information architect, consulting and building site maps and wireframes. Sometimes we were also asked to do some light design or, in my case, HTML.
It worked for us and our clients because the skills themselves were closely interrelated when we were creating basic marketing Web sites (aka “brochureware”) that needed clean navigation structures and thoughtful layouts to move our client’s printed brochures onto the Web. When ecommerce caught on, we added interaction design to our tool kit, although at the time it was not interaction design the way we talk about it now. It was more like transactional design. We had to design process flows that were predictable and useable for consumers. But those interactions mostly revolved around user goals like, “I want to buy a book.” Customers wanted to get from point A to point B. There was not a ton of complexity involved. Once the standards were established (add to cart > check out > enter shipping information, yada, yada, yada) and technology packages were created, ecommerce sites popped up overnight, seemingly out of nowhere, without the aid of an information architect. And that worked too.
Next came the portal wave. Content reigned, and our clients needed help reining it in. Their sites exploded with hundreds, sometimes thousands of pages that no one claimed responsibility for. It was like our clients believed the shoemaker’s elves were adding content to their Web sites while they were sleeping. When they woke up and realized they had more content than they knew what to do with, we became serious taxonomists. Our site maps spread across pages and pages and we had to come up with rules around how many levels of content a site could have, mostly determined by how much space we had to display navigation links in an 800 x 600 screen resolution. Design became more sophisticated and so did our wireframe layouts.
At some point, the expectation that we could also be interactive strategists lessened as that role was split out and placed in the hands of strategists, creative directors, and account managers. And then Web technologies evolved. Users started demanding the ability to buy more than books online. They wanted to pay their electric bill and manage their bank accounts. Those demands evolved into a complex Web of software that, when done right, became transparent to users. (Whether you know it or not, you are using software in a Web browser. That’s what us technology people call Web applications. All those sites and pages you use to move money around in your eTrade account or to read and send Gmail is software served to you through a Web browser.) And this is where today’s version of interaction design comes in to play. New technologies made is possible for us to keep you on the same page while we popped up, slid open, and overlaid features to flag messages for follow up, move them into folders, add tags, reply, reply all. All of these functions require thoughtful interaction design. An interaction (IX) designer or a team of IAs, IX designers, graphic designers, and UX designers, got together and figured out if that thing should be a button or a link and what happens when you hover over it and when you click on it. Someone made a decision about every feature and function on the page. Every button. Every link. Everything you see (and lots of things you can’t see).
Today’s version of interaction design more closely resembles traditional human-computer interaction (HCI), a skill set that has been around since the invention of computers, than the information architecture work Web teams did before the introduction of Web application technologies. Some of the IAs on those Web teams had HCI training, which often came with usability testing skills (oh, right…usability…I left that out on purpose. Usability has always been that other thing we do. But usability has always been usability. Neither the skills required for conducting testing nor the methods have evolved a ton over the years. Either you can do it or you can’t.) Some of us were self taught (with the advantage of a background in some science or another like psychology that helped us understand cognition, personality types, and basic research methods). Others came from library sciences backgrounds, and they rocked at building taxonomies and organizing content and interfaces.
Where was I? Oh yes, interaction design. IAs had to learn Web application design or get left behind. And then the technology changed again. Handheld devices and tablets took off.
Another quick digression first: if any of you have an inkling of the history I’m attempting to relate, you may wonder where the Flash movement fell in all of this. The answer is in the brief history of Web graphic design, which I am not up for tackling. Believe it or not, Flash design was done by Flash designers. Even though Flash was all about the interactions, us interaction design folks were left completely out of these projects. This was great for IAs and designers who had a penchant for Flash. They were allowed, encouraged even, to specialize and the rest of us were left behind. However, if Apple successfully wins the mobile battle against Adobe in the next year or two, Flash designers will be forced to learn HTML 5 or die.
Okay, back to cell phones and tablets: these new technologies, all of which include interfaces (UIs) and Web browsers created two new specialties or sub-specialties. Mobile UI design became its own thing. And in the last two or so years now “app” design has become a whole new thing. The designers who work on these teams need to understand the capabilities and restrictions of each of the devices that serve their interfaces or apps. And the interactions themselves have changed with the creation of touch screen devices. Clicking and dragging no longer means reaching for the mouse. It involves the tactile expression of a finger meeting glass.
It would be tough to find one person who could do all of these things for you well. I’m sure there are a handful of people out there. But for the most part, we are better at some of these things than other things.
To review, here’s a list of all the things I’ve been referring to.
Here’s the point. All of these skills, jobs, tasks, people, can fall under the umbrella term User Experience Design. I don’t have a problem with that. As I’ve mentioned, I use the phrase myself. But I do think it’s important to call a spade a spade. I mean, duh. I wouldn’t be good at my job if I didn’t consider labels important, right? And so I believe it’s important for anyone who calls herself a user experience designer to specify which of these skills are part of her toolkit.
It’s been roughly 12 years since the Internet Bubble. That’s enough time that the kids who are the heaviest consumers of these technologies don’t know what the Internet Bubble was all about; they were 6. Those of us designing for them can remember life before the internet. (Heck, some of us can remember the world of black and white TV. Gasp.) Nowadays, college students can major in interaction design. But if you ask them about site maps and content hierarchies they’ll look at you like you’ve got two heads. “Content?” They’ll say. “What’s that?” They can’t be bothered to read. They barely use email. And they think you’re a dinosaur if you still use your phone to make phone calls.
So when interviewing a self-proclaimed user experience designer, I want to know what you’re good at. All of the stuff I listed above, you say? Great, but tell me what you’re really good at so I know if you’re a decent IA and a great IX designer or vice versa.
And finally, my conversation with Margot. It’s about calling a spade a spade, or in this case, calling a duck a duck.
Margot: so… here’s my question: i’m writing about IA and want to make sure i’m using it appropriately. i recently saw on your site–you relaunched!–that you hew closely to “IA”–not “UX” or any other newer term. why, and what does it mean?
Sarah: funny you should ask
i wrote a blog post about that recently
http://www.sepmorton.com/?p=49
there are a lot of words and phrases people use
Margot: OOOH! I’ll read it. part 2 is that i’m exploring the issues an IA must wrangle; many are similar to to those encountered by a good PM, like “how long will this take,” “how much should we budget,” “how many pages/screen/modules” … at least in my opinion. are those issues/questions accurate? any you’d add?
[We didn’t really get to part 2 of her questions, but answers to part 1 appear below.]
…
Sarah: interaction design feels more like web app design or mobile design to me
ia sometimes just feels like taxonomy
…
Sarah: user experience design covers all that
Margot: hmmm.
so ixd [interaction design] is a connotation difference?
Sarah: i think it depends on the person
but mostly i don’t think clients know the diff
so i still call it IA because i can use my real estate analogy to explain
Margot: hmmm…. in the post, you reference the Bentley program. but where did IAs come from circa 2000? were they just designers who’d gone a less graphic, more organizational route?
Sarah: totally or human-computer interaction people
either self taught or HCI people
Margot: ahhh
ewww… “content architecture”?
i haven’t heard that.
wtf is that.
Sarah: i think it’s some blend of IA taxonomy and site map stuff plus what you do
for people who can’t decide between IA and content strategy as a label
Margot: that’s stupid. we have words for what we do, and people should use them. and what i do is pretty big and complete in and of itself, and what you do is pretty complex and giant too. who has the time or expertise to combine them?
Sarah: good question
Margot: i like turkey, i like duck, but turducken is never going to be as good as both separate foods prepared to accentuate their distinct properties.
Sarah: haha
it could also be for interaction designers who don’t actually know what it means to draw a site map. i think there are a lot of youngsters whose skills may be too specialized
so they expect the content person to draw the site map and voila, you get content architecture
Margot: yeah. i blame turducken.
Sarah: i hear ya 
Margot: we should just let duck be duck.
Sarah: so long as we can use the duck fat for frying the eggs, i’m in!
And on that note, it’s time for second breakfast. Maybe after lunch we can chat about guided navigation, faceted search, content management systems, and blogs.
In recent weeks I suffered what I consider to be the most grievous insult ever spoken by a client to a designer. A client of mine said, “Thanks for the work you did. Don’t worry about the revisions. Our IT guy will take it from here.”
All manner of expletives popped into my mouth. I barely managed to stifle them back with a cough and leave my client’s office with the shreds of my dignity mostly intact. I drove back to the office in a daze, narrowly avoiding two cyclists and several pedestrians. I was Driving While Distracted, my mind too busy spinning over all the things I wanted to say to my client to see anything on the stretch of Mass Ave between Boylston and Central Square. It’s amazing I didn’t get pulled over. (Although, as a friend recently pointed out to me, bad driving has become so commonplace in Boston it’s practically expected so I needn’t have worried.)
Back at the office, Best Tech Guy heard me climb the stairs, my slow, heavy tread indicating not-so-good news, and my face, as he turned to greet me, emoting despair. Wearing that wry, bemused look he does so well, he cautiously inquired, “How did the meeting go?” My mind was tangled. I was so hurt by the words, “Our IT guy will take it from here” that I could barely speak. I stuttered. I sputtered. I collapsed into my chair and said, “You won’t believe what that [client] said to me.”
When I finished my story, Best Tech Guy was silent. (Like any tech guy, Best Tech Guy thinks he’s the Cleverest Man on Earth, and he is never-ever at a loss for words. Until that moment.) After a pause the length of the Amazon (the river, not the ecommerce site) he said, “Wow. Are you okay?”
The complete understanding and genuine expression of sympathy was exactly what I needed. It knocked me back to my senses. I replied, “No, you [donkey’s behind]. Of course I’m not okay!”
Best Tech Guy braved my juvenile name calling and dramatic exclamation with a calm smile and asked, “Are you sure? Because you sound like you’re okay.”
I sighed, pouted, and acquiesced to his smug smugginess. “I’ll survive,” I admitted. And then added, “But only if you take me to Mariposa and buy me something fattening.” (I admit it. I was acting like a complete child. I figured I could drag out his sympathy a bit longer. It was a nice reprieve from the never-ending stream of sarcasm I typically endure in his company. And I should at least get a cookie or something out of it. Plus, he’s scared of what happens when my blood sugar drops.)
We walked and talked and I vented and ranted a bit more. Ultimately I agreed that it was not the end of the world. We would wait to see what the IT guy came up with. And I could get over it: the worst insult ever. I was tough enough to handle it. But then…
Two weeks later, Best Tech Guy and I were invited back to that [client’s] office to review the wireframe changes completed by the unidentified IT guy. We had a productive conversation and asked several questions, pointing out issues and challenges to the user interface they had drawn. We made helpful suggestions to improve the experience and smooth out the development process. And then the conversation turned to one particular feature that we didn’t understand. The feature and our issues are unimportant. What’s important is the [client’s] response to our questions. We suggested the functionality would not be clear to his end users. He replied, “Well, that’s a training issue.”
And that’s when I nearly died. The effort and willpower required to stop myself from jumping across the table and choking him nearly killed me. I thought I was angry about the whole, the IT guy will update my wireframes, thing. But this was an all new low. That [client] expected his end users to figure out how the non-intuitive interface worked because he was unwilling to either A) ask his end users how they thought the system should work or B) design the system based on best practices and insight offered by his user experience designer (i.e., me). Seriously?!?
Now mind you, my ego was over the fact that the [client] was clearly not going with option B. And he was obviously uncomfortable with option A. But the fact that he was unwilling to go with (previously unnamed) option C was just unconscionable to me. Because option C (obviously) is to do what makes sense.
Best Tech Guy, noticing that I was once again struck dumb by the turn in the conversation suggested, “Maybe you could put some instruction copy on the page, something that explains how it works.” He knew it was a lousy compromise. I didn’t need to cite chapter and verse to him from the usability bible. He’s heard it all before. Jakob Nielsen documented it in his Alertbox and Steve Krug explained it in his masterpiece Don’t Make Me Think. Users don’t read. That’s not a solution to any user interface problem. More text on the page just creates more clutter. Best Tech Guy knows that. But he was stalling for time in hopes that I would rejoin the conversation.
I didn’t. I sat quietly thinking through the options. We couldn’t talk to their end users. The [client] wasn’t going to take my word for it (nor was he going to listen to Best Tech Guy). And he was totally uninterested in doing what made sense. Because in this case, doing what made sense meant changing the business rules of the system. Business guys don’t do that. They don’t question the (business) rules. It just isn’t done. So I bit my tongue (again) that day and three days later when he said to us (again), “That’s a training issue.”
Here’s my real problem with all of this (as I am sure you are wondering, if you are even still reading at this point). My client resembles a reasonable person. He is intelligent and well-intentioned, which is a good combination in my book. I think he’s even good at his job. (Although, I could be wrong. His job falls into that category I call jobs I wouldn’t want and therefore I hesitate to criticize.) He’s a business guy and therefore he’s a penny pincher, which again I can both understand and appreciate. But his math is wrong. He took up two weeks of his IT guy’s time not just updating my wireframes, redrawing them from scratch because he didn’t ask me for the Visio file. The changes they made to my drawings were so minimal I could have turned around the revisions in under two hours. Then he scheduled six of us in two review meetings that required follow-up emails and phone calls totaling way more hours than it would have cost had I been allowed to gather proper user requirements from the people who would be using the Web application or to have them check our work after sketching the user interface.
And that’s my real problem. Gathering end-user requirements and/or doing a quick usability test doesn’t have to be a whole big thing. Sometimes it can be as simple as walking around the office with paper print-outs of wireframes and talking to whoever happens to be in that day. It can be as easy as asking a question.
I do this all the time at home with my husband. We try to share chores around the house on the basis that there are things one of us refuses to do. For instance, I refuse to fold laundry. I will wash it, dry it, and put it away. But I absolutely refuse to fold it. It’s weird. I know. I’m even weirder about the dishwasher. I will load it. And I will unload it. Except the silverware. I hate putting away the clean utensils. Lucky for me, he refuses to clean the bathrooms so the kitchen is entirely his responsibility. Once in a while when he is out of town, I will take the clean dishes out of the dishwasher and put them away (except the silverware; I leave the utensil basket-thingy on the counter for him). Inevitably I put something away in the wrong place. When he goes to look for the liquid measuring cup or the cheese grater, he can’t find it. And then we have this ridiculous fight the next time he goes to put it away. He asks me (in his slightly accusatory tone), “Where does this go?” And I respond (in my most-patient academic voice), “Where did you look for it?”
Interactions like these, believe it or not, provide insight into solving bigger problems. Asking one simple question is sometimes all it takes. If I could just find a way to convince that [client] to let me show the wireframes to his end users, we could sort out this feature that follows business rules that nobody understands. I would simply point at it and ask them, “What do you think this does?” And then we could make it do what everyone thinks it does. And viola, a well-designed interface is born.
To make a short story long, it’s a training issue. I need to train my clients to understand that a little usability goes a long way. And I need to convince their budget-controlling bosses and accountants that I am not trying to sell them more hours. In fact, I am probably trying to sell them fewer hours. After a long lunch with their end users, I could have answers to all of our questions. And we could skip all those review meetings, follow-up emails, and phone calls and get on with bigger and better things, like teaching them how to break their (business) rules.
We had a client once who defied all of our efforts to please her. No matter how hard we tried, no matter how many brand and design workshops we did, we could not get her to articulate her expectations regarding her site’s visual design. And as a result, we completed iteration upon iteration before gaining her approval and sign-off on a final design.
This situation is nothing new to anyone in the design business (or any customer service business). Most of us at one point or another have had a hard-to-please client or customer. We did what anybody would do in that situation. In front of her, we blamed ourselves for not asking the right questions or anticipating her needs. Meanwhile back at the office, we ranted to each other about what a loony she was. (We designed five home page directions. The statement of work called for three. Why couldn’t she just pick one?) At the time, both positions were valid; she was a loony and we were failing her. Looking back on it now, the drama seems too commonplace to matter in the grand or not-so-grand scheme of things. But there was something about it—something about her—that has stuck with me all these years.
Loony Lovegood (not her real name) said, after rejecting all of our proposed design directions and asking for more options, “It’s like porn. I know it when I see it.” Those two sentences dissolved any tension between us, she the client and we the design team, sitting on opposite sides of a conference table in a sterile board room. She was likeable, so we worked it out. But I’ve often replayed this sentiment in my mind and wondered if she was right.
Harry Gordon Selfridge would say, of course, “the customer is always right.” But I’m not convinced she was. For starters, it’s an imperfect metaphor. She implied that our design directions would evoke the same feelings for her as viewing porn. She thought she would experience some instant emotion (shock, horror, trepidation, titillation, joy, wonder, embarrassment) and cry out, “Yes, that’s it!” Perhaps she should feel that way. Perhaps the right design direction is like that perfect pair of jeans. You know how it goes. You swore you were only window shopping; you saw them hanging just inside the door and had to get closer; there was one pair left in your size so you had to try them on. You put them back on the rack, headed for the door, then turned around, grabbed the jeans, and found yourself standing at the checkout with cash in hand. You took them home, put them on, and refused to take them off until there’s nothing left of them but tattered patchwork.
But selecting a design direction is not about love at first sight. It’s about experiencing a design over time, getting to know it, and appreciating it for the lasting impression it creates. More often than not, you have to try on a half dozen pairs before finding the right fit. Okay, I am not really suggesting that choosing a design for your Web site is like shopping for jeans–except that I am. When you shop for those jeans…hmm…I can’t really speak for you the reader or the general populace, can I? Warning, what follows is a totally unresearched, unvetted, un-scientifically unproven metaphor. So, when somebody somewhere shops for a pair of jeans, she usually has a set of requirements in mind: waist size, length, cut, color, etc. Those requirements are based on one or two things and sometimes both of them. The first criterion is the shopper’s personal style, because, after all, a pair of jeans is not just a pair of pants; jeans are an expression of a consumer’s personal brand. A pair of jeans says a lot about who she is as a person: trendy, hipster, timeless, sophisticated, practical, or confident. Purchasing a pair of jeans can also be an expression of an occasion. A special date, casual-Friday jeans, and weekend-at-home jeans: sometimes they are the same pair; sometimes they are not. It depends on the customer. Once the shopper has narrowed the selection down to that one pair she thinks will make the final cut, she must take a look at the bigger picture. The final purchasing decision is as much about how the jeans fit as it is about how they make her feel and what they say about her.
In the design world, we would describe those three criteria as the functional, emotional, and self-expressive benefits of your jeans or your Web site design. Sometimes the jeans you need are not the pair you set out to buy. Sometimes you bring friends along to provide a second opinion. Occasionally the perfect pair jumps off the rack and into your hands, but more often you will take them home and wear them around the house for an afternoon with the tags still on them before committing fully.
In the case of Ms. Lovegood, she was focused too intently on the emotional benefits and couldn’t see the bigger picture. She didn’t understand that the directions we presented met her functional and self-expressive benefits—the self-expressive benefits of her consumers, because after all, the site was not designed for her. The site was designed for the students at the university she represented. This is where design options get tricky. Ms. Lovegood wanted a site that made her feel good, one that appealed to her emotional side. But the site needed to appeal to her target audiences.
This is where we look not to Selfridge but instead to Steve Mulder who wrote The User is Always Right, the definitive book about using personas in the creative design process. Ms. Lovegood may have been our customer, that is she was footing the bill for our services, but she was not the end user for whom we were designing. So, Mr. Selfridge, the customer is not always right. The user is.
This is where I consider myself the lucky winner. My design team constantly makes compromises that go against their years of experience, design sensibilities, and better judgment. I hear things like “Sure, we can tweak that color” and “Of course we can make the logo bigger” all the time. And most of the time they make those changes whether they want to or not. But as the in-house information architect, when our clients as me questions like “Can you move the registration to another part of the page?” I get to say, “No, because [insert the vetted, accepted usability rule here].”
Maybe Ms. Lovegood is right to a degree. Our design presentation can be very much like porn (especially after weeks of my boring wireframes). Maybe it’s not like the full-on X or even R-rated stuff. But they are definitely like serious PG-13 eye-candy.
In contrast, good IA is noticeable only in its absence. If it’s done right, you never think, “Wow that was some good IA.” But if it’s done poorly, you think, “Where is…?” and “Why can’t I…? and “Man, this site sucks!” Well-designed information architecture is like the glue that holds the user experience together, the part you have to do to get to the good stuff. If your Web site was like a porn mag, the graphic design is like the pictures and the IA is like the articles. You have to write the articles to call it a magazine, but nobody’s reading them.
As the lone woman in an office full of men, I often find myself the loser in the War of the Toilet Seat. This war is made up of a series of battles. Each battle brings a new reversal. It’s up. It’s down. It’s up again. No wait, there are five of them and one of me. So that would be: it’s up; it’s up; it’s up; it’s up; it’s up; it’s down; it’s up. Lather. Rinse. Repeat. Oh goodness, I hope they wash their hands.
Most of them are married, which begs the question, are they not housetrained? This is not a question I am prepared to ask their wives. From one married woman to another, I know that would come across as an insult. I will ask, “Does he leave the toilet seat up at home?” They will hear, “Why can’t you get him to put the toilet seat down?!?” I would never do that to another woman, at least not the ones who have to live with these monkeys.
So today I found myself pondering the options, keeping in mind that they don’t charge me rent or make me bring my own tp. I don’t want to make too much of a fuss. I want to make just the right sized fuss. I was thinking, I could put up a sign or maybe find a Sharpie and write in big black letters on the underside of the toilet seat. It could say, “Put me down.”
But then I realized that would be a huge mistake. Because then they would all be standing there, hurling insults at the porcelain basin, the head, the john, or whatever it is they call it in their tiny, childlike brains when nature calls, when they play fireman, shake the dew off, check the tires, or send a message. No wait, those last two are for calls of nature when you’re in nature; no toilet required. So what would they say to the underside of the seat while they are hitting the target? I imagine juvenile things like, “Your momma holds potted plants.” Or, “Your daddy cracked under the pressure.”
Hmm…hitting the target…I really hope they have good aim. If not, I can hold it.
I’m often a tad dishonest when people ask me what I do. I don’t fib to deceive them. I fib for their own good. When people ask what I do, I say, “I’m a Web designer.” Usually they go, “Oh, okay,” and change the subject. They think they get it. It’s not that interesting. We talk about something else.
There are those rare moments, however, when people perk up at my reply. They say, “Oh, really, [insert follow up question here]?” And that’s when I have to say, “Well, actually, I’m an Information Architect.” And that’s when they pull faces at me. (It’s the awkward face and the more awkward pause that I try to avoid with my standard “Web designer” reply.) And that’s when I feel compelled to ramble. My response to their stink face usually starts something like, “Um, ahhh, well,…” and continues with some combination of the following words and phrases: not a graphic designer, usability, not really, um, navigation, user experience, well really, interaction. When I pause in my babbling, I find a fair few people still listening (more nowadays than in the past). If they don’t think I am a complete spaz, if they are still paying attention, if they are still breathing and mostly making eye contact with me, I ask, “Wanna hear my Spiel?”
The Spiel, or, more accurately, the spiel before the Spiel
The term “information architecture” has fallen out of favor lately. Information architecture used to refer to the set of discovery and design exercises that resulted in a solid navigation system, clear site hierarchy, and templated site layout. In the past, Information Architects were also responsible for usability testing and interaction design. With the advent of academic programs like Bentley University’s certificate program in User Experience, there are more people with more skills in information architecture, usability testing, and interaction design. More people means fewer generalists and more designers with specific skill-sets like mobile interface design.
With the advent of new non-hierarchical navigation systems in technologies like wikis and blogs and anything else that uses tags and categories or user generated labels, information architecture as a skill is not as valued. As a result, information architecture itself has come to mean something more specific and no longer serves as the catch-all phrase for the work that I do. To sum up, the phrase itself no longer carries the same weight or meaning it used to. And the skills are not as highly valued. (There’s an underground movement attempting to move this role into content strategy and call it content architecture. Uncharacteristically, I don’t have an opinion about this. At least, I don’t yet.)
So why am I holding on to a title that is falling out of favor? For two reasons:
The Spiel
The real reason I still refer to myself as an Information Architect and to my services as information architecture is because people get it when I describe it. They get it because there’s an obvious metaphor that they can grasp instantly. I say, “Pretend you’re building a new house or putting an addition onto your existing house. What’s the first thing you do? You call an architect, right? Well, if your space was virtual, you would call me. And I would ask you all the same things that your architect would ask you. I would ask, ‘What do you want to do with your space? Who’s going to use it? What do you want them to be able to do and not do? Do you know what you want it to look like or how big it should be?’ And so on. I will talk through your requirements and chat with anyone else using your space to get their opinion. And then I will draw you a blueprint.”
They get it. It makes sense to them because it reflects an experience they can relate to in the real world. I’m happy because at some point during my Spiel, they stop making stink face at me. And they’re happy because they feel smart when they understand what I’m talking about. The best part is (by “best” I mean selfish and money grubbing), I can extend the metaphor to up-sell my team’s services. I can ask, “Do you have a decorator yet? How ‘bout a developer?” And then I can pitch my team’s graphic design and tech development services.
Information architecture: it’s not an out-of-date reference to an unneeded service. It’s the old-school, usable, and useful way to describe what I do. And it’s all about the user experience.
As a designer, or designer-type-person, running a design shop without in-house technical capabilities, I’ve worked with a lot of different developers and technical type guys (usually guys) over the years. I’ve used different guys for different work. Some of them are better at front end stuff, and some of them are better at back end stuff. Some of them are better at smaller projects, and some of them are better at bigger projects. Some of them have been fun to work with, and some of them, well,…not so fun.
You get the idea, and you can probably relate. There are ups and downs when you outsource anything, when you have to find someone else to do the work you cannot do with your own two hands. There’s a level of trust involved that can be downright scary, especially when it’s your client. (It’s my client, dammit! Don’t screw this up!)
Here’s where I am going with this. Some of these guys have been good, and some of them have been bad. Good and bad, however, are absolutes in this case. They are not relative terms when it comes to picking a dev team.
Here are the things you should be able to take for granted. A good tech team has all the skills required to complete the project. They have the staff to complete the project on time. And they have the management skills to deliver it on budget. Hopefully, your team can do all that.
However, they can do all that and still not be a good dev team. Because only a good tech team can read requirements—business, user, and technical requirements—and deliver the site or application or whatever that you’ve asked for. (A better tech team will work with you to write those requirements. My tech team can do that, but that’s not where I’m going.)
Today, I am on a happy rant about my tech team and what makes them great. What makes them great is their ability to keep their fat mouths shut about our design work. It’s not because they don’t have an opinion. They definitely have an opinion, and they will share it if asked. But what makes them great is that they know what kind of feedback we find constructive. They know better than to say, “I don’t like that color.” They will speak up when technology can improve our designs: make them more flexible, interactive, fun, interesting, or easier to manage. They make these suggestions thoughtfully, not so they can get the client to pay them to learn some new technology or to add something flashy just for the heck of it. We are always open to the kinds of suggestions that make the user experience better and/or make the site management experience better.
What makes them the best is that we can trust them to build the site to pixel-perfection. They follow our design specifications—the pure look and feel specifications—without question, even when they’re unhappy about it. For instance, about 20 minutes ago, one of them (I don’t need to name names, he knows who he is; he is sitting behind me while I type) said, “People who put gradients in their headers are [expletive deleted]!” He was loud and proud about this proclamation (even though he said “header” when he meant “global navigation menu”).
My reply? I know you’re dying to know. Did I berate him, curse him, throw things at him? Nope. I laughed.
He said, “I mean, really [expletive deleted]? They put gradients in the header!”
I laughed harder, and said, “Of course they did.”
He sighed, turned back to his computer, and finished coding the gradients.
And that, to a designer, is the absolute definition of a good tech guy and a great tech team. They know when to challenge us. They know when to make suggestions. And they know when to shut the [expletive deleted] up about stupid [expletive deleted] like gradients in the header.
This post is something I wrote years ago at BigBad. One of our clients, Rhodes College, asked me to help them sort out their academic department and administrative subsites. I’m amazed to discover that, six years later, I am still getting this question from my higher ed clients. And even more amazed that my answer is still very much the same. I might not make the same recommendations today about bridge pages between the majors and minors list and academic departments–too hard to manage redundant content, too much effort when a CMS will do it for you, or maybe I would recommend dynamic bridge pages built out using the CMSs technology. It depends on the school and on the CMS package.
Anyway, here’s what I wrote many moons ago…the part that applies to any school. I’ve cut out my review of Rhodes’ subsites. They’ve sorted themselves out since my original draft of this was delivered.
Reigning in Rogue Sites
When designing corporate Web sites, designers occasionally have to organize unrelated products and services in a structure that can be understood easily by clients, customers, and partners. But higher education Web sites often include a large quantity of diverse information. In addition to the traditional admissions, financial aid, and academics content, colleges and universities have to organize departments, faculty, courses, student groups, and administrative offices which may be a part of an overall university, a particular college, or several colleges across a university. And this information must be accessible for many varied audiences: students, faculty, staff, parents, alumni, employers, and the community.
More often than not, academic departments, faculty, and administrative offices have completely separate Web sites dedicated to explaining their requirements, course offerings, office hours, services, and processes. These separate sites can create identity and navigation challenges. They often look very different from each other and from the main school site. They are hard to find and once you find them, the content you are looking for is either hidden under links that are too vague or use language specific to the institution (i.e., words and phrases that are a complete mystery to someone outside the school) or the content is missing altogether.
The biggest challenge higher education Web site designers face is answering these three questions.
This document outlines several answers to each of these questions and the plusses and minuses of each approach. Because each school is unique, we will not provide strict recommendations. However, we will provide general guidelines for reigning in these rogue sites. For the purposes of distinguishing these sites from the main university or college sites, we refer to them as “subsites” in the remainder of this document.
The first challenge when handling subsites is to determine where in the school’s Web site they live.
Why does it matter?
Every page or subsite within a college Web site must have a home. This is the primary place the content lives within the overall organizational structure. Understanding where the page or subsite lives allows both users and designers to understand when clicking a link will keep them in the same section vs. taking them to a different section of the site. (This is called cross linking.) Within-section links and cross links are often given a different visual treatment on a Web page. Cross links are placed in a separate “see also” area to distinguish them from the within-section navigation. Treating these links differently sets users’ expectations about where they will go and what they will find.
Also, assigning a home to each page or subsite is required frequently by content management systems. The content lives—and is managed—in a single dedicated section. This is a huge benefit for college Webmasters. Links to departments and offices can appear on multiple pages in the site but the content is managed in one place.
Okay…so where do they live?
Academic department subsites typically live under the “Academics” sections of most school sites. This is the best, most logical place for these subsites. Other labels for this section include “Majors and Minors” or “Programs and Departments”. Whatever words you choose, it’s good to include two views of the academic departments: one list of majors, minors, and programs and a second list of departments. Two views of academics accommodate both prospective students who want to know what they can major in and faculty who want to know what department they can work in.
Academic department subsites are not cross linked frequently to other areas of the site. However, they can—and should—be cross linked to each other to show the interrelationships between the departments, particularly at schools with interdisciplinary programs. For instance, the International Relations department should include cross links to History, Political Science, Economics, and Modern Foreign Languages.
One final note about accessing academic department subsites: consider using “bridge” pages between the list of majors and minors and the department subsites. A bridge page is a single page of content that acts as a transition between the Academics section and department subsites. These pages are especially useful for colleges wrestling with inconsistent department subsites. They create an opportunity to control the Web user’s experience and make the jump from the main school site to rogue subsites less jarring. Bridge pages give you a place to introduce each department and provide information that’s consistent across all departments. These pages can include a paragraph describing the department, a list of majors, minors, concentrations, and programs, affiliated research centers and institutes, the name of the department chairperson, and contact information for the department with a link to the subsite.
Student groups most often live under the “Campus Life” or “Student Life” sections of a Web site. These subsites can be cross linked to other Activities, Events, or Performances areas of the site. They can also be cross linked to academic departments. For example, cross link the Poetry Club to the English Department or Creative Writing program.
Faculty and courses can live either under their respective departments or in their own dedicated sections. At schools where faculty are highly involved with students, research, or curriculum development, it makes sense to devote a robust section to faculty. Alternatively, some schools utilize a faculty directory. Professors are listed alphabetically, by department, or by expertise. These listings are valuable to all audiences; the list by expertise is especially useful to members of the media looking for subject matter experts. (On the other hand, requiring journalists to go through media relations rather than contacting professors directly has its benefits too.) Other schools list faculty solely within the academic department subsites where they teach.
Each approach is useful, but they address different goals. Web visitors looking for a specific professor’s telephone number are task oriented. They will use a directory to find information quickly and easily. Visitors browsing majors and minors will read about faculty within the context of academic departments.
Whichever approach (or combination of approaches) you choose, your site should include (at a minimum) a complete list of faculty members, names, titles, department(s), phone numbers, email addresses, and short biographies. Students, faculty, parents, the media, and grant institutions also look for office hours, résumés, publications, research interests, and syllabi. Other details or personal Web pages should live in the department in which the professor teaches or the faculty section of the Web site and can be accessed from cross links in directory listings.
Course listings and descriptions often live within a third-party tool such as BannerWeb (or they did when I wrote this in 2005). Although typically stored in a password-protected location, these listings are extremely important to prospective students shopping for a school or program of study. Whenever possible, academic department subsites should include (at a minimum) lists of courses offered, descriptions, and instructors. Students also look for number of credits, syllabi and the semester, days, times, and location the course is offered.
Administrative offices and services subsites often live under an “Administration” or “Offices and Services” section of a college Web site. But some—like Admissions and Financial Aid—can live on their own. So the answer to the question of where these subsites live is, “it depends.” It depends on which subsites we’re talking about. The subsites that can stand on their own should stand on their own. However, those Administrative subsites should be listed in a directory of their own. A complete alphabetical directory listing of all campus offices and services is a valuable tool. It’s quick and easy to navigate and acts as a one-stop-shopping portal for easy references.
It’s important to note that the list of these offices should not always reflect the internal, organizational structure of the college. For instance, just because Alumni Relations and Development live under University Advancement, that doesn’t mean the offices should be listed this way on the site. Forcing users to look for the Alumni Network under Advancement can make Web visitors feel like they will be asked to give money before they can find out when the next reunion is happening. Presenting information logically rather than organizationally is important to create a positive user experience for all Web audiences; and it’s particularly important when addressing a key audience like alumni. It’s best to avoid confusion by listing the link to the Alumni Network subsite separately from the link to the Capital Campaign subsite.
And while you are going about the task of presenting these administrative subsites logically, be sure to choose your words carefully. The links to these sites should be meaningful and resonate with all audiences both inside and outside the college. Your Student Accounting Advisor might understand the difference between services offered by Student Accounts, the Finance Office, and the Bursar’s Office. But a list of these offices could be an obstacle for a parent looking for a place to pay a tuition bill online. Always keep your audiences in mind and don’t be afraid to list some services under multiple headings. For instance, there may not be an online bill payment office but that shouldn’t stop you from including a listing such as this:
Online Bill Payment: see Bursar’s Office
Finally, don’t forget to include links to these offices from other relevant areas of the site. For example, link to the Campus Safety office subsite from the Campus Visits and Student Life areas of the site.
We’ve provided some hints above to answer this question. Our reply to this one is, “sometimes.”
Why does it matter?
Whatever words you use to describe the things your visitors use to get around your site (links, navigation, tool bars, menus) they are—very simply—the way visitors get around your site. These tools provide the visual cues for Web browsers to understand where they are and where they can go. Your navigation system should use plain English words and allow users to anticipate what content they will find wherever they click. Navigation menus should intuitively answer the questions:
Providing a consistent set of links across subsites promotes the usability of these sites. The same group of links in the same place labeled with the same words allows visitors to browse across these sites and always know where to click to find information “about us” or to “contact us”.
How does this work?
Just to be clear, we are not suggesting that the Career Services office, SGA, Spanish Club, and Ultimate Frisbee team subsites all have the same navigation or content. We do recommend that you work with these departments and organizations to understand the commonalities among the groups.
Academic department subsites have a shared goal of providing information to students. There is a core foundation of content that is common across the departments. All departments have majors, minors, or concentrations and academic requirements. They have courses and faculty. They have a history or mission or other information “about the department”. And they each have a department chairperson, administrator, or other contact person for undergraduate or graduate programs.
As we’ve mentioned, course listings should include the same basic information about each course: course name, number, description, instructor, number of credits, and (when possible) dates, times, and locations.
The same rules apply to faculty listings. Be as consistent as possible, including names, titles, department(s), biographies, and contact information. Full resumes, lists of publications, syllabi, and links to personal Web sites are also helpful.
Student clubs and organizations can get a bit trickier but here again we often find common themes based on shared audiences and goals. The performing arts groups, athletic clubs, and competition teams all have tryouts and performances. They all have a faculty or staff supervisor, meeting area, and contact information. Each of these subsites can share a base navigation menu to help users find their way. But just to reiterate, we would never advocate identical subsites for the Moot Court Team and the Glee Club. The variations in content are what make each group unique; they are the means for expressing the different personality of each organization. The puzzles on the Math department site and the photo galleries on the Photography Club subsites are what make each group distinctive. And these unique features are what attract a diverse group of students and faculty to your college. A shared set of navigation menu items is simply a way to improve the user friendliness of your rogue subsites and overall Web site.
Once again, the same rules apply to administrative offices and services. At a minimum, these subsites should explain what each office does, what services they provide, and who to contact. There is a subset of these offices which also have an application process. These sites should clearly explain that process and include links to forms and applications and deadlines.
The answer to the question, Should these subsites look the same? is an emphatic, Yes. Subsites should look like the colleges and universities of which they are a part.
Why does it matter?
Basic elements of design (color, form, type, imagery) are part of the visual vocabulary people use to recognize brand and identity. For instance, a bright red tin can with a white swirl is as much a part of Coca-Cola as the bubbles in the soda. This swirl is such an important part of the Coca-Cola brand that it has been named (the “Dynamic Ribbon”) and trademarked. Any consumer knows this instinctively from decades of associations with red tin cans and Coke. And now Coca-Cola is the world’s most recognizable brand.
The design elements of the existing brand identity should be leveraged on the Web. A strong brand identity conveys the strength, reputation, and the feel of a school on the Web. Navigating from a department to an office to a club should feel consistent; it should feel like the same college or university. We create this consistent feeling with a consistent look. Without it, site visitors can feel lost.
Consistent branding has become even more important recently on the Web. Search engine technology has evolved and college Webmasters have responded, becoming savvier about tagging pages deep within the university site to show up in search engine results. As the search engine technology has improved, Web surfers have become heavily reliant on Yahoo! and Google, expecting them to serve up the exact page or pages they are looking for. As a result, more Web traffic will originate somewhere within the site, i.e., not on the homepage. Visitors that go directly from Google to the financial aid deadlines page or the political science graduation requirements page should know instantly that they are within the Financial Aid office or the Political Science department subsites of Acme University.
What does this mean?
These subsites can express their own individuality and personality—within reason. Any variations from the school’s brand identity should be done intentionally, knowingly, and with audience needs in mind. The visual design of each subsite should reflect elements of the overall college or university and use the same style and tone.
All of these rogue subsites should include the same page header (school logo and other branding elements) and footer (copyright, terms of use, and contact information). And the subsites should include the same primary navigation as the college or university site, depending on where the site lives. For instance, within the Acme University Web site, the English department subsite should be consistent with the School of Arts and Sciences, and the Accounting department subsite should be consistent with the School of Business.
Color palettes may be varied somewhat but they should stay within the school’s extended color palette, i.e., colors designated by the school’s visual identity guidelines. The same goes for typography. All type should appear within the family chosen by the school. This seemingly minor detail can go a long way to achieving consistency across these subsites and your college or university. The same rules apply to photography. Photography should utilize the same visual style and similar subject matter. For instance if your primary Web site relies on head shots of small groups of students, a subsite that relies on wide-angle shots of sweeping campus vistas will not feel like it’s part of the same school.
These subsites can convey their own personality within the content of their sites. This includes photography and other imagery. For instance, the Intramural Sports subsite should include information about try-outs and practice times and pictures of students playing games and supporting teams. In contrast, the Financial Aid office should include few photographs, focusing instead on conveying information about deadlines and processes in a clear precise manner. But both of these subsites—and all the others—should speak in the same warm, welcoming tone as the whole college or university.
