Where do You Want to Be?

If you have never undertaken research of this nature before, put yourself in the position of a market researcher who stops you in the street. When they approach you their manner will determine how well, or if at all, you answer their questions. People like being asked their opinions as long as there is no compulsion to 'get the answer right'. What you have to do is ask the right questions to the right groups of people. All these lists are open-ended - you have to tailor the questioning to your own situation.

Research, Research, Research

Researching what you need may be a little alien to you if you are a hands-on coder and think you can see clearly the path you want to take. However in order to refine your system specification you need to involve the people or groups of people who are your audience. This serves two purposes - first it enables you to refine your ideas and second it makes the users feel involved. Remember that an intranet is used by a closed and relatively well-defined set of users compared with the Internet. Iteration is the key - once you have your initial research results go back and involve your users once again. There's a double benefit to this. First you are getting closer to your audience and enthusing them more, and second you're refining your model so that you stand a chance of producing a better product.

• You have to determine who are the key major stakeholder groups in wishing to get the intranet right. There may also be some major groups who want you to get it wrong, maybe those who think they should be controlling it in the first place.

• Get some really honest research conducted. Ask the questions that may hurt. Don't be scared of poor results, it only serves to support the project you're about to undertake. In a sense, the worse comments are the better!

• Make sure that you are able to understand the issues from a user's perspective. If the users have difficulties, make sure you understand where they are. When you go back with your redesign, address the solution to those difficulties directly with the people who brought them up. That will get them on board for your solution and make them your ambassador.

• You could think about running an anonymous survey where the answers are not attributable. Although this may have been a more acceptable practice in the office environment of the 1950s, the more you can get people to identify the problems with the intranet personally the better you can commit to giving them service. If there is no other choice then get the survey anonymously, but in my opinion it is very much a last-ditch option. Also if you adopt the anonymous survey approach you will not be able to either ask for clarification or give follow-up except generally.

• Sometimes in this process it is absolutely critical to get senior management onboard. Without them you'll get nowhere. However you have to choose your moment and your subject carefully. If one member of senior management could be thought of as having an interest in what you're aiming for, target them. If you get one person on board, there's your ambassador for the rest.

• Ask what is your intranet costing you now? If you can drop the duplication factor by x percent, you'll be reducing the cost of managing the content by the same percentage. If, by implementing standards, you can reduce development costs or by implementing Linux servers over Windows servers you reduce the licensing costs your accountant's going to listen at least.

• But also take time to find out what's good about the intranet as currently arranged. In performing all your miracles (you'll feel like they are once you've finished) you definitely don't need to throw the baby out with the bathwater. Take the example of the person we identified above who has given you some useful feedback about what's wrong - also ask what's right. Taking back a solution to their problem alone you may find that you've just gone and inadvertently removed what they really liked - and in so doing you've just lost an ambassador. It may have been something simple like the color scheme - and they may be color-blind - you weren't to know and your new sleek scheme has reduced the contrast for them so the pages are more difficult to read. If you know about this, you can compensate for them in their browser by supplying an alternative stylesheet, assuming you're taking the Standards route for writing web pages.

• In your research, find out just who has web sites hidden away. What do they do, how are they maintained, and who uses them? We'll be using this information to make some instant improvements.

So listen to your users - they're the only ones you've got, and they alone will determine whether your regeneration project is going to be a success. This may seem obvious, but maybe ignoring the users got the intranet to where it is, fragmented and difficult to use. We'll be addressing user buy-in and selling and marketing your solution later on. Just be aware for the moment that it's the way you're going to have to go. Enthusiastic user support does not come without effort. And without that you'll have a slow take-up for your new designs.

The Joined-Up Intranet - Leaving Things as They are but Improving the Mapping

Let's return back to the example company mentioned earlier. They first carried out a survey, and then started by making the navigation of the existing intranet easier by redesigning the main page of the existing intranet as a portal to the existing server and all the other machines scattered around. That is the start of being both able to organize the intranet, and show users an immediate improvement.

Figure 6: organizing the intranet

Note

Be aware that in doing this you may compromise the security of your intranet. If you have implemented a single sign-on facility then you will need to have checked that all sites you are integrating use this. Security considerations and strategies can also alter across operating system, you will have to ensure consistency of approach.

Having gathered information about the web sites that exist and what they do, construct a portal page that will improve the navigation. The links between departmental and individual machines are not shown - they are the same as before. The portal is sensibly organized with respect to menus - it's one of the developments that was necessary to start making inroads into the redesign.

Applying it to Your Company

By constructing a very simple web page the issue of navigation can largely be solved - at least temporarily. What you have is a very simple quick and dirty fix - publicize the address of the portal and encourage its use. Publicize it personally to the ambassadors you've selected from the research stage - this need not be time-consuming, maybe a personal pre-announcement e-mail. If you do this you start keeping them attuned to the intranet.

At this stage you've done nothing to remove any of the functionality or links that already exist even on the existing intranet server - you can still have people work the same way. So you also pre-announce the changes to the owners of the departmental and individual web sites you found during your research - it shows you value their contribution and want to make more of it.

So now onto the next phase as you've finished the research.

Hold on, have you actually finished? Or is this just one stage of an iterative process that you're going through? Maybe you add items to the portal gradually as you find out what they are whilst performing the research and then you get feedback so that modifications to the design become easier. Whatever you do you have to apply all this to your own company - so there's no absolute right and wrong way as long as it works for you in the end.

Do you "launch" after this change? In my opinion, no - you announce it as a minor change to improve navigation. Singing about success too early is going to make the real launch harder. And please retain all the research - this phase has been crucial and you need to be able to justify the effort that will be involved. At this stage each server will have its own look and feel, you've only changed a couple of pointers.

So now you can start on the real work of redesign. Now's the time to start plotting what you want done. You can now more easily review what's out there, and you'll find that people will start telling you about their sites as you may have missed some and they don't want to be left out. It takes a pretty isolationist mindset not to want to belong, so this is a pretty natural process.

In any design you have to start with some sort of vision. Is making all sites use the same design structure important? Are accessibility and standards an issue? Do you want to give the owners of the existing sites a degree of freedom? Think of the pros and cons. If all sites look the same the intranet may look boring and it's more difficult to navigate as you have to read more carefully where you are. So paint a picture of where you want to go - what does it look like? Are you using any existing company standards - indeed are there any that you can use or are you defining the standards in what you are doing? Only you can decide, there's no magic formula. You have a fragmented intranet, but do you have the immediate resources to bring it under a single machine, for instance. How would you cope, both with the loading and the extra administration work? Would it be better to plan stage by stage integration and let existing site owners take some of the work off your hands.

Is it necessary to throw everything away and start again? Sometimes it may be the course of action that's required, but that's rather drastic. How many people would you lose while on this path and would it all really be better when you've finished? Unless you are in a real position of dictatorial power with a load of resources at your disposal then this is probably not an option. So how do you decide what to do?

One way is to run workshops or brainstorming sessions. These are some of the most powerful ways to get honest feedback and attendees feed off each other's ideas. Members of your workshops should include the departmental and individual web site owners. They're the ones who had the inspiration in the first place. You also need to include some of the users, the ambassadors, so that you can both show them that you mean business and that the provision of a portal doesn't mean that the job's done, and get their input in the same room as the designers. And listen - you can learn much from what people don't say as well as what they do. And have your own questions - throw in some really outrageous ideas and see if anyone takes them up - it's surprising how wacky you can be - get some humor going - if nothing else it gets people to relax. All this requires some skill in leadership, but it's not daunting. Once you have got the discussion going you can relax a bit. So for any session set some sort of private agenda - not hidden agenda - so that you are able to cover all the topics you believe are necessary. And when you've covered them, ask if there's anyone who has something else. You could conceivably have missed something.

Note

While doing a brainstorm start off with a blank page - a blank, clean (large) whiteboard, nothing else. Your attendees will then feel compelled to fill it - don't start off by doing any work for them, let someone from the floor start the ball rolling - a single word will do - then the ideas will start flowing. You'll find that the board will quickly become filled. And don't try to lead the discussion all the time - try handing over the marker pens to someone else so that you have time to be part of the audience and absorb what is being said. In the end you'll have a whole load of information that you'll have to reduce to something manageable, but do it with the co-operation of the attendees at the time - if you take it away to analyze then you'll lose them and their support. Make a result from your brainstorm - that way it will have the agreement of everyone and they'll feel that something has been achieved. They'll achieve a sense of belonging to and ownership of the solution.

I know that this has been about something more general than the new intranet design process, but brainstorm sessions are a great way of channeling energy. You have to be something of an energy source to start off with, but there rarely fails to be a synergy and even if those partaking have never met before, the sense of belonging to the team is heightened more than they or you expected. Strange but true. Once you've been part of a brainstorming team you can go back months or years later, even after you've forgotten their names, and start talking to them. They'll remember you as well.

That's only one way and probably by far the most effective. There are formal methods of obtaining feedback:

• Realize that not everything is bad about the existing intranet. There's the old wisdom that developers see only the problems in the product and that salespeople see only what's good. Embrace what's great about your current intranet, build on these strengths.

• Do you have an internal Market Research resource you can deploy internally?

• If you are considering using a range of existing design templates, research users' views. Conduct some usability and heuristics tests to determine what you are proposing is going to work.

• Analyze your technical architecture and infrastructure. Is it up to the job if you're going to move all web serving onto one system? Or would you be better off distributing it?

• Interpret usage statistics to assess most and least frequently used areas and identify trends in user behavior, for example peak times. By running a portal this may be a way of collecting those statistics. You also need analysis of the departmental and individual sites themselves - a way of checking what proportion of visitors are using the portal and how many are going direct.

• Are there other project teams already trying to resolve this issue? This type of activity is often found in Knowledge Management or Internal Audit teams.

• Put in some time to listen and watch what's going on. Spend time away from your desk (do you really need an excuse?) with users and find out about the operation of other parts of the company. Very few people are going to begrudge a ten-minute chat about how you can help them improve their working life.

• Are there elements of your existing intranet that are the worlds best kept secret? Finding out is a different matter - and you can only do this by being aware of what your users are telling you, so keep listening.

• Can you get feedback from each of these activities you're undertaking. If really necessary can you give incentive for feedback? One thing here - if you do this you may get people telling you what they think you want to hear. It's not an option to be used lightly. This type of incentive can be anything from entering a prize draw (pretty crude) to having their name in the acknowledgements on the intranet (name in lights syndrome) which reinforces their sense of belonging to the final product. (Yes, and I'm pretty pleased to have my name on the cover of this book - it works at all levels)

• Identify any business critical facets of the intranet - these must be guarded during the development process.

• You might be re-developing the intranet but it still needs to function. You may try the approach of using your portal and changing links when they're up and running, a process of gradual change. In any phase of your switch over, be sure that you leave the original intact so that if you do make a mistake and it falls all over the floor that you have the reassurance of the original to fall back on. If you don't it could be problematic for you. Leaving alone what works is your insurance policy.