If all you have is a screwdriver…
So, I was building some personas this morning. And by “building”, I mean “pulling out of my ass” – I had some other UXA’s notes from a total of three user interviews and some more notes from a project manager who’d interviewed a bunch of other project managers at the client’s company… and from this I’m expected to craft a persona or two who supposedly represents the audience of a whiz-bang new intranet.
(For anyone who’s not aware, a persona is an archetype, based on observations or interviews of real people who you expect will use your website or product. By watching them go about their day, or asking them about their goals, you can begin to craft a single, target uber-customer. The theory is, that it’s easier to design and build a website for one person than an audience of thousands or millions. And in practice it works – if you actually get to talk to some of those prospective customers.)
At one point, I got tired of staring at these notes (not because they weren’t interesting, but because there were so few of them), so my attention started to drift. Behind me lay a set of self-assembled bookshelves that had been sitting, unassembled, on the floor for about 6 weeks. So I went to the IT department to borrow a screwdriver (that in itself says something – that our IT department is responsible for holding onto all of our tools.) In about 10 minutes, I had most of it assembled, except for this card board panel that was supposed to be nailed onto the back of the shelving frame.
I hadn’t thought to borrow a hammer, and the nails were pretty small, so I proceeded to nail rear panel to the shelves with the handle of the screwdriver, wielding the screwdriver more like a rock than any kind of real “tool.” Ironic, I suppose, that given the choice between getting the right tool, and using the one I had handy, I choose the latter, less elegant and technically “worse” solution.
Actually, it worked pretty well.
So anyway, I’m writing up this persona, and it’s becoming obvious to me that the single defining aspect of the target audience is that they do not want to use this new intranet. They don’t want it, period.
Now partly, this is because the resources they have now are a scattershot collection of internal websites that GlobalMeganonCorp B’s many internal factions have put up on their own. This is not all that uncommon for large, multi-national corporations. Each department wants to “educate” their internal customer base about the great ideas/products/stuff they have to offer, and everyone does it differently. Sure, there are intranet standards and style guidelines to follow – but everyone uses them differently.
Should we be surprised about this? Nah. If you had a 100 people who were each building a new house in a neighborhood, and you wanted them to do sensible things like build their curbs all to the same height, make sure they used the same diameter pipes for their sewer lines, and didn’t plant trees in the middle of the road, would you:
a. Publish a Building in Your Neighborhood document and hope that they followed it?
b. Make approval of their zoning contingent upon following those guidelines?
I’ll be the first to say that “standards and guidelines” can be the death-knell of any creative endeavor. But guess what? Organizing an intranet isn’t a creative endeavor. Writing content for it is creative, but determining the organization of that content, and the navigation that takes people to it, isn’t.
Style Guides (the kind that Big Organizations and the Technology Consultants love to write) can be really useful when they’re done well, and followed. The problem is, most of the time when I get brought in to “overhaul” a failing intranet, I find that the failure springs either from a poorly written Style Guide, or a really good Style Guide that no one has to follow.
So, for the record, here’s what I think a minimally useful style guide *must* contain:
- Personas
Who is the intranet for? What do they do with their lives? What are they trying to accomplish?
If you can convincingly define in unambiguous terms who the intranet is supposed to help, everyone who’s in charge of managing one part or another of that site will design it for themselves – thus ensuring that overall, the intranet is designed for no one.
- Target browser and platform requirements
Has the IT department determined that everyone in the organization will have 1.5 GHz Dell with a 17-inch monitor set to 1024×768? Say so. Will some people have a MacBook or a 21 inch monitor – good for them. But if the organization has a standard, use it.
Defining browser and platform standards up front will save everyone involved about 1000 hours of mind-numbing conversation with corporate vice presidents and IT help desk staff.
- Navigational conventions
Where does the main navigation go? How should navigational labels be written? Is there secondary navigation? How are people supposed to get back to the homepage?One navigation scheme, even if it’s poorly defined, will be better than 5 or 6 poorly-designed navigation schemes. When in doubt, slap that navigation down the left hand side – it’s called the 90% solution (because 90% of sites do it that way.)
- A standard color palette for all text, headers, backgrounds and navigation.
Everyone has different preferences when it comes to color. Which is why we have Casual Fridays. Eye-piercingly cacophonous fuscia and yellow plaid should be reserved for Doris-from-Accounting’s dress, not for some HR department homepage. Give everyone a limited set of colors and strict guidelines for where and when to use them.
That’s it. Want to throw guidelines for “appropriate imagery?” Fine. But not until you’ve nailed those first four things down pat.
Now, supposing you’ve done all this, and you have your Shiny New Style Guide? If you’re like most corporations, you’ll distribute copies to the senior management, and store it in a shared folder where it will go unread, unused, and grow increasingly irrelevant.
If you want to avoid wasting that time, and you actually want to experience the joyful productivity gains spurred by a standards-driven intranet, you need to make sure that someone is in charge of enforcing those standards. Ideally, this person will have:
- Leadership skills
- Budget authority over intranet development
- An absolute fanatical devotion to making the intranet a valuable and customer-centered resource
All three are important. Anyone who’s missing one of the above will be a tyrannical Intranet Overlord, subjecting many worthwhile contributors to torturous “standards reviews” and “user acceptance testing,” while totally missing the point of having a set of standards in the first place. Which is…
…wait for it…
To make easier the lives of people who have to use the intranet to get their jobs done, or to do their jobs better. Because let’s not forget, it’s all about the users.
Intranets often go unused and neglected, or grow increasingly complex and impossible to use, because no one takes the time to think through the Big Picture. Style Guides and Standards are just tools for doing that, and imperfect ones at best. They can be used well, they can be used poorly, and they can be left unused altogether. But if the standard are designed with just a a few and essential details included, even the inelegant use of them can produce a well-designed, user-centered intranet that withstands the test of time.
Most software just assumes that if someone goes to the trouble of clicking that button, then they must have meant to delete all of their customers’ orders. After all, the confirmation message was perfectly clear.