We’re reorganizing our Intranet right now — or, more accurately, keeping the department-centric organization but overlaying task-oriented navigation.
Task-oriented is customer-focused, and it’s a better way to organize information into useful groupings so that your target audience can find it. But task-oriented comes with its own set of problems, especially over time as new content and services are added to the site. Among the problems…
Distributed Publishing. I’m working in a decentralized publishing environment, where publishers are based in a department and rights on the Web server are assigned to main folders. So I’ve got to keep the files collected on the server along department lines (or change my publishing security strategy, which I’m not currently willing to do).
Traditional Expectations. We’re all about cross-departmental teamwork here, but let’s face it — we’re still very department-centric. So the publishers are naturally going to think in terms of “My Department Home Page” and anything under it (e.g. linked from it) is theirs. ‘Course, that’s a good thing in that it helps to get the department publisher to take ownership of “their” content, but I think I will now have to sell them on thinking upwards as well as downwards.
Not only that, but some (maybe most) of our customers are used to dealing with minor bureaucracies, and they understand that to get something done, you first have to work the org chart. So if I yank the departments, some will get lost — especially if they start with an employee: “Oh, yeah, the Information Center handles that.”
I can’t say for certain what the effect will be of using two navigation metaphors (three, if you count search). My guess is that staff will use the department-centric list to get around and students (our customers, in this case) will use the task list.
Change Management. So you’re on a Web page that you got to from a service list, and it appears to be out of date. Who owns this page?
Top Layer Management. If the department publishers will be handling everything from their department page on down, then I’ve got to keep up the task-oriented overlay. No problem, right? As long as department publishers tell me what they’re working on, so I can add new information and services to the appropriate task list. If they don’t, those top layers of task information will have holes in them….
Most of them tell me when they add things — partly because Web publishing is new, so they’re excited and they seek validation. But the gloss will wear off this soon, and they’ll realize that it’s like word processing: we’re not going to alert the media every time someone performs a mail merge. But I’ve got to communicate that it’s not exactly the same (although maybe just as boring, eventually): because of cross-linking, you’ve got to think outside your cube walls when you publish.
Or tell me, and I’ll do the thinking for you. That works too, I guess.
