blog.frederique.harmsze.nl my world of work and user experiences

January 31, 2012

Barriers to a successful adoption of the intranet

Filed under: Adoption,Governance — frederique @ 23:08

We’re developing a new intranet at my client. But we know we don’t just need a great system – we’ll also need things like communication and governance to make it a success. So we’ve been looking at the barriers that the users may encounter and how we can overcome them.

Generically, we see the following barriers to a successful adoption of intranet features and the following solutions for it:

  1. Don’t know about it. So:
    • Communication: Intranet, local communication vehicles, announcement mailing
    • Getting started kit: show and tell what’s available, in the site and outside (flyer, QRC)
    • Champions: drive adoption
  2. Cannot access it. So:
    • Opens by default in browser
    • Simple URL: redirect if technical url too hard
    • Invitation: get account data on Day 1 (user management)
    • Support for forgotten account data (ongoing user management)
  3. Don’t understand how to use it, afraid to mess up. So:
    • User friendly site
    • Help content, link to help and handy navigation + search within help
    • Policies
    • Training of contributors of News, Blogs and Files
    • Support in case you get stuck
  4. I see nothing relevant here. So:
    • Make sure the site works (incl good performance)
    • Relevant content at the start
    • Ongoing relevant content (content governance)
    • Releases of relevant new features
  5. Not worth the effort to contribute, what’s in it for me. So:
    • Incentives (recognition, games, gadgets,..)
    • Management commitment: it’s part of your job
  6. Disappointed in the lack of response. So:
    • Set an example (e.g. HR)
    • Champions make extra effort
  7. No time for it. So:
    • Management commitment to make time for it
  8. Afraid to stick out their neck. So:
    • Set an example (e.g. HR)
    • Open culture where management encourages contributions actively

August 31, 2011

Duds – Why do some solutions fail?

Filed under: Adoption,Governance,Usability — frederique @ 23:56

I’ve been developing small-scale information worker solutions for the same company for a few years now. Different departments and teams needed different solutions to solve their problems in the domain of communication, collaboration and the optimization of business processes. And because I am still here, some time after we’ve launched the solution, I can see where it all led.

Well…

On the one hand, some solutions are still a great success, helping the teams to increase productivity and quality, and reduce cost and frustration.

On the other hand, other solutions completely fell flat. They have never been used for real, and got swept out ignominiously as a dead site by the house-keeping team.

What went wrong with those duds? It’s not always clear, but these seem to be important negative factors.

Solving no problem.
We create a solution – in my case usually specific functionality in a teamsite – to solve a problem. We identify that problem in the beginning, with a rough business case. However, sometimes an expected problem does not actually arise. So the solution is sitting there in a vacuum, solving nothing of substance.

An example that I encountered recently, was a solution for issue tracking in a high profile project. When I asked after a few weeks why I did not see any issues in the tool, the answer was that there were no issues so far…
Maybe I should see that solution as an insurance policy: you hope you don’t need it, but you make sure it’s there just in case your house burns down or – in this case – the project gets swamped with issues. Unfortunately, I fear they did find issues later on. By then, original project leader had left, probably nobody remembered that they had this tracking tool and they solved the problem some other way.

So: If you create a solution for a problem that hasn’t arisen yet:

  • Double-check that they need the insurance.
  • Keep it as simple as possible, to avoid wasting too much time.
  • Make sure the team know about the solution, so that they can start using it as soon as the problem does arise.

Functionality insufficient
We do our best to create a solution that meets the users’ needs. But sometimes the result just isn’t good enough. In my case, the available platform and toolkit definitely limit what I can create. In other cases, the technology may be up to it, but the budget it too restricted to get the job done.

An example that I won’t forget in a hurry is a sales tool for a Russian team. We knew from the beginning that we were pushing the envelope. But as the project progressed, it became clear that it just wouldn’t work. The American third party tool didn’t understand the Russian date format. The client became more emphatic that his huge amounts of data needed to be connected in multiple ways. And there just was no way that we could solve the problems in a reliable way. In the end, even the parts of the tool that did work, were never used and the entire solution was deleted in our last spring cleaning campaign.

So:

  • Identify the full extent of the client’s needs at the beginning of the project, especially complex showstoppers.
  • Double-check that you have grasped the essence and that you have a solution, especially if there are further complications, like a language barrier (I don’t speak Russian any better than that third party tool that got stuck on the date format…).
  • If there is no good solution, cut your losses and stop the project. Launching an inadequate, unstable solution will only make your life harder, when they call you to save them when it collapses.

Usability insufficient
Our solutions are created to help employees be more productive, or more generally: help the users reach their goals. That will only work, if the solution is user-friendly: if the users can do their job quickly, easily and pleasantly.

With on a fixed, old platform, usability of any of its solution is sub-optimal, to say the least. For instance, readers see an Edit button and only discover they do not have the required permission when they try to save the item and all their content is gone. And when contributors enter metadata, there is no connection between the data they enter. So if they first select a country and then a city, the selection list of cities is not pe-filtered. Stupid system…

However, sometimes a solution is not user friendly just because it is an IT system, regardless of its “objective” usability. I’ve sat next to users who told me “No no no, this is just too difficult for me“, until I pointed out that – basically – they just had to click the prominent button ‘Upload document’ to upload a document. “Hm, that’s actually quite easy”. Such users don’t feel friendly towards any new system, because it always takes some energy to check out something new, and they don’t see it as their core business. But that has more to do with user adoption driven by management commitment.

So: optimize usability as far as possible

  • Determine who the user groups are and what they need, and cater for their needs specifically. For example, remove the Edit buttons from pages that are mostly visited by readers who cannot use them anyway.
  • Test this with real users, even if it is very informally: just drop by and see what they do. I see a lot of interesting things when visit my less intranet-savvy contacts. They sometimes click in very unexpected places…
  • If you can’t use technology to make things clear and the fixed styles don’t give you any help, be as clear as you can in text and sorting:
    Include the right words in title bars, link texts, explanatory texts, document titles.
    Order the content in such a way that the information that is most important to most users is at the top of the page, at the very least above the fold: most recent documents, my tasks, key links, etc

User adoption insufficient
A solution can be set up brilliantly, if the users don’t use it, it is still a dud. Of course none of the solutions I created were absolutely flawless. But I have seen good solutions ignored for other reasons.

One of the solutions where we really made a huge effort to make it as functionally useful and user-friendly as possible, is a program management tool. The project teams of the individual projects should update the project status and other key indicators in the tool, so that all participants can monitor the program’s progress and the program managers can intervene where needed. But most project leads just don’t do it. The tool is not that difficult to use. But determining the status and key indicators of the project is difficult. So they are very reluctant to adopt the process itself, let alone the tool they can use to facilitate that process.

Another example I’ve just encountered, concerns a very savvy project lead, who is definitely able to handle both the process and the solution he could use to make that process more efficient. But he insists on using some “old fashioned” solution that he has always used and that he is completely fluent with. Except that it is rather unpractical for collaboration with the other stakeholders. In this case, the main obstacle for adoption is probably the ‘Not Invented Here’ syndrome.

So:

  • First of all, the users need to understand how it all works. Ensure that the users know what the business process is and how to handle that. And then how the solution can help them with it and how to use it exactly. So provide training and help material, both concise (FAQ, quick reference) and more detailed (user manual, help pages). Even if they don’t consult the material, many users feel more secure in the knowledge that it is available if they need it.
  • Communicate not only theoretical knowledge to the users, but also a clear sense of what’s in it for them: how will this make their life easier (saving them time and effort) or richer (informing them better than before).
  • Is this an important business process? Then using the tool to make that process flow more efficiently is a core task for the participants, and not just something they can ignore. This implies that management commitment is needed and the managers need to act upon their commitment.

Management commitment insufficient
In the context of intranets, the goals that the employees are trying to achieve – with or without using one of our solutions – fall under the responsibility of a manager. If the manager feels that the goals will be achieved more effectively and efficiently using a tool, they can ask us to develop such a solution. But then the managers are also responsible for the adoption, usage and maintenance of that solution, even if they delegate the actual work to another employee. However, I’ve seen quite a few solutions fail because of a lack of management commitment.

For several solutions, including what was supposed to be an important tool to aid marketing strategies, my contact for the entire project was an intern or another temporary employee. I knew the names of the responsible managers, but I never got any input or feedback or questions from them. So when the temporary employee left, the entire project just stopped.
That marketing tool was almost finished two months ago, and it still is almost finished. An HR site was almost finished two years ago, and it is still gathering dust without any further progress. The positive only example was the HR site for another country, where the intern managed to launch the site before he left. That is a rather static information site, so it does not matter as much that it has not changed since then, because at least the information is available for the readers.

In some other projects, the managers were personally involved, but the solutions still failed, because the managers did not see them through. In one case, the most eager sponsor left the company. The other one had very little time, as complications within the organisation distracted her. I noticed that she lost her enthusiasm for the project, but I was unable to re-energize her. The fact that she was in Australia and I was in The Netherlands played a role: we could only have a real time conversation in the hour after my midnight and at the start of her work day. That solution had cost us a lot of effort and was ready for launch, But it was never used and flushed out in our last spring cleaning.

So:

  • Don’t do a project with an intern without on-going involvement from the responsible manager. If they won’t do more than just give the order to develop a solution, then it apparently is not important enough.
  • Get more explicit and well-founded Go/No Go decisions: Is the problem that we are trying to solve still serious? Do you still think you can achieve the benefits? Can we take a sprint to finish the solution with a burst of energy? Or should we just stop wasting time on something that is just bleeding to death?.
  • Make it clear that they need to invest some time now, in order to save a lot of time later, when the solution allows them and their team to work more efficiently.

Most of these reasons for duds to fall flat don’t have anything to do with technology, but with people. So getting a cool new toolkit is not going to help me get more solutions up in the air and soaring to great heights. It’s

getting a cool new toolkit
AND
determining exactly what solutions I should create with it to allow users to reach their goals
AND
making those solutions so user-friendly that they will get their quickly, easily and without frustration
AND
getting the users up-to-speed with its workings and eager to use the solutions
AND
Ensuring management commitment so that the tool that facilitates key processes is considered key as well.

February 28, 2011

Exploring intranet governance

Filed under: Governance — frederique @ 02:30

When we build an intranet, collaboration environment or any other system, we don’t just want it to look good when we launch it. Cracking open the bottle of champagne on the bow of our gleaming new intranet is one thing. But what happens once she has set sail and is navigating the shoals of real life usage?

We’ve build the intranet – or whatever other system we built – to achieve a goal: to increase productivity and employee satisfaction, be compliant with legal rules, save money by saving time, travel and paperwork …
Therefore we firstly have to build the intranet in such a way that it can reach that goal: it needs a steering wheel, a compass, streamlining, a good engine or sails, or it won’t be able to get anywhere. It needs to be governable.
And secondly we have to set up processes  and organizational structures  to direct the intranet: who takes the wheel, where will we navigate, who takes care of the engines, anybody watching out for icebergs in the middle of the night? It needs governance.

Let me explore some aspects of an intranet, what we launched, what can go wrong afterwards and how we can govern that.


What does the intranet offer the user: functionality

In our development project

Issues after launch

Governance needed, such as…

Required: We determined what functionality was needed and made sure that worked when we launched it

Is it all still working?

Find out: Set up a contact for users to report issues
(please note: users don’t know if something actually is a bug in the intranet. They just see that it is not working as they expected)

Decide and plan: Appoint an intranet management person or team who prioritizes big issues.

Do it: Set up tech support who fixes bugs

Understandable: We made everything as user-friendly as possible and included Help and training in the launched intranet.

Do the users know what they can do and how to do it?
Is it really as understandable as it is supposed to be?

Find out: Appoint champions and set up a helpdesk who can answer the users’ questions, and let them capture the questions. Conduct usability tests.

Decide and plan: Determine who is responsible for help and training. Make a communication plan and training plan, and guidelines for the help and training content.

Do it: The champions and helpdesk answer the questions. An editor (role) updates and adds to the help and training content. A trainer gives real life training, remotely or in class. A communicator points out interesting functionality in blogs, newsletters etc.

We may have postponed part of the functionality to a later phase, or we may have missed something that turns out to be important.

Is something important missing, at the highest level, for all users?

Find out: Conduct user research. The helpdesk and champions know what is asked or complained about.

Decide and plan: The intranet owner / steering committee decides at a high level what major changes or additions will be carried out, in a release planning. A general guideline is that it has to fit the vision and current functionality of the intranet, and it has to be done with the standard development method.

Do it: A development team does a project for this.

 

Is something missing at a lower level (e.g the level of a teamsite) for a small group of users?

Find out: These users request a functional solution.

Decide and plan: A solutions manager decides, based on a business case. Guidelines: For this, stick to no code solutions that do not need anyone directly on the server. And follow the best practices that have been established for such solutions on this intranet.

Do it: A business solutions team carries out the project at the front end.

 

Is the current functionality still relevant?

Find out:Statistics and user research.

Decide and plan: The day-to-day intranet manager or the high level intranet owner (depending on the importance) decide what can be removed or made less prominent.

Do it: A tech support or functional support team carries out the change.


What does the intranet offer the users: content

In our development project

Issues after launch

Governance needed

On launch, the intranet does not have that much content yet. The contributors add that later.

Is the relevant content available and up-to-date?

Find out: Allow the user to contact the owner of the section where content is missing or outdated (by clicking a button or by calling the listed contact person). Periodically check the most important content. Check the search statistics for missing content.

Decide and plan: Determine who owns the content, in particular important central content, who is allowed to add or edit it, and which content requires approval by whom. This very much depends on the content and the section of the intranet. Is anyone supervising at a higher level, via a reminder and escalation mechanism?

Do it: Editiorial teams for central content (such as corporate news, HR info). Give enough people contributor permission.

Is the new content readable?

Find out: Allow the users to give feedback via a rating system. Conduct research.

Decide and plan: The authors and editorial teams are responsible for their own content. Is there some overall editorial board that checks the quality of the content? The authors get guidelines for writing on the intranet.

Do it: The authors and editiorial teams make sure their content is readable, by following the guidelines and using tools like a spell checker, wysisyg layout editors, Flesch readability index etc.

Records management: records are a special case. We may have included special functionality like automated document ID and policy management when we built for compliance

In practice, are the records created and managed according to the rules?

Find out: Records owners or managers will have to check before the auditor arrives.

Decide and plan: A records management plan guides the record manager – in general or for a specific domain .

Do it: Check and perform the tasks that the automated routing, archiving and disposal actions generate.


What does the intranet offer the users: team sites

In our development project

Issues after launch

Governance needed

We work with SharePoint and that allows the users to create new sites after the launch, without involving a developer. We provide templates for that.

Is the new site necessary or is there already a site available for that purpose?

Does the new team site fit the rest of the intranet /collaboration environment?

Find out: Let users request a new site instead of directly create it. Check if it is necessary.

Decide and plan: Make a Content Lifecycle Management (CLM) plan. The day-to-day intranet management team approves the request, following the CLM plan. The owner of the new site then has to adhere to the guidelines or best practices for site use.

Do it: Create sites automatically from the selected template after the request has been approved. The new site owner configures the site to fit the needs of his team, adhering to the guidelines. The day-to-day intranet management teams monitors this.

Is the site still relevant, or is it just cluttering up the intranet?

Find out: Periodic automated check for sites that have nog been used a specified period (e.g. 6 months).

Decide and plan: A house keeping plan that allows the day-to-day intranet team to do these checks, and to deal with exceptions.

Do it: For example, the day-to-day intranet management team every 6 months gets a list of ‘dead sites’, contacts the site owners and delete sites that are not explicitly said to be still useful.


How do they find it: findability

In our development project

Issues after launch

Governance needed

It only makes sense to offer the users anything if they can find it. So in the development project, we paid serious attention to the findability

Can the users really find the functionality and content?

Find out: Conduct user research and check the statistics (If a site that we think is important never gets visited, the reason may be that the users cannot find it. Or it is just not that important after all).

Decide and plan: The intranet owner is ultimately responsible for the findability. The could ask the day-to-day intranet management team or a specific “findability expert” to monitor and fix it.

Do it: Who does what to improve the findability depends on the solution for the problem.It should, as much as possible, be something that can be done at the front-end, by non-developers.


How do they find it: information architecture

In our development project

Issues after launch

Governance needed

During development we’ve designed and implemented a good, user-friendly IA: a clear and efficient structure where the most important items are most prominent and everything fits in a category that makes sense.

Do new items (sites, articles, functionality) fit in the information architecture?
Does the information architecture still fit reality (naming, structure)? For instance, elements that reflect the organisational structure are no longer correct after a reorganisation. New k knowledge domains or products need to be added.

Find out: Conduct user research to check for clarity. Check if people who add items know where to put them. Keep an eye on developements in the organisation.

Decide and plan: The intranet owner decides on major changes or additions in the (portal) structure. The could ask the day-to-day intranet management team or a specific “findability expert” to monitor and fix it.

Do it: Who does what to improve the findability depends on the solution for the problem.It should, as much as possible, be something that can be done at the front-end, by non-developers.


How do they find it: search

In our development project

Issues after launch

Governance needed

We provide the search functionality when we launch the intranet.

Can users (still) find what they are looking for using the search functionality?

Find out: Conduct user research and check the search statistics.

Decide and plan: So do we have a “findability expert” or search manager who monitor and fix the search settings?

Do it: The search experts add and update the keywords in the taxonomy, and maybe tweak the relevance criteria of the search engine.


How do they find it: taxonomy

In our development project

Issues after launch

Governance needed

The taxonomy is the basis for the information architecture and the search keyword. We launch the intranet with a basic taxonomy for the main navigation and, sometimes, with the main keywords for the search.

Are terms missing from the taxonomy?
Do the terms in the taxonomy correspond with the reality of the users, or do we need changes or additional synonyms?
Is the hierarchy correct or do we need to reorganise the terms?

Find out: Conduct user research and check the search statistics.

Decide and plan: We allow an uncontrolled folksonomy in the intranet or in some specific sections of it, but somebody needs to be the owner of the official taxonomy: the “findability expert” and utlimately the intranet owner for high level decisions. We need a plan lay down which changes can be approved and carried out by who.

Do it: In SharePoint 2010 you can change the taxonomy in the Central Admin, and promote terms from the folksonomy to the taxonomy.


How do they experience it: stability and performance

In our development project

Issues after launch

Governance needed

In our development project, we have chosen a technical architecture that ensures stability and performance.

Is the intranet still as stable and fast as it was when it was launched, now that it has filled up with content and users?
Users refuse to work with an intranet that is too slow or unstable.

Find out: Check the user complaints and perform objective measurements.

Decide and plan: The Service Level Agreement (SLA) with the hosting party specifies what is acceptable.

Do it: The tech support team handles the servers, but the functional support people can also optimize the configuration of bottlenecks in solutions. Site owners have to take care of their own sites, guided by best practices about performance killers.


How do they experience it: look & feel

In our development project

Issues after launch

Governance needed

When we developed the intranet, we branded it properly and created the appropriate styles and templates.

Are the (new) content and sites (still) branded correctly?

Find out: Check the sites, especially important central content.

Decide and plan: Document what is allowed in which section of the intranet in a styleguide. The day-to-day intranet management team can enforce compliance, if site owners do not adhere to the styleguide. Or is that a job for the marketing & communication team?

Do it: Stick to the predefined styles and templates. Give the site owners a styleguide and material like images that they can use.

January 31, 2011

Why governance? Some thoughts

Filed under: Governance — frederique @ 22:57

Lately we have been discussing governance in our Colleagues Club (mostly with people like Jason Sindram, Willem Oosterhof, Mike Fortgens and Maarten van den Dungen). The funny thing is that we notice that many others see governance as bureaucracy for the sake of bureaucracy. Yes, the term does sound a bit pompous. But that does not mean that governance is useless.

Instead of diving into the exact definition of the term and the meaning of governance, let me just address a few issues I’ve recently encountered in my projects.  Most of these actually turned out quite well, because we do have governance in place. I’m working in intranets these days, so that is what I focus on.

  • “Aha, we can just upload those documents? Cool!”
    The HR department in one of the countries of our multinational still hasn’t put any of its information on the intranet, although the intranet has been available for more than five years. Today I had a meeting with the trainee they delegated to find out if they could actually upload documents into this intranet thingy and avoid all these phone calls from employees looking for information. Well, yes…. And not just upload them, but also update them when the information changes, which it will certainly do.
    Seasoned intranetters and intranet developers hardly believe it. But unfortunately, the intuitive interface and the available materials are not enough to help all users understand what’s the use of the intranet and how to get the most value out of it. Fortunately we do have a team that they can contact if they want to know more. And this team has a communication specialist, although apparently she hasn’t reached everybody yet.
  • “So how do I upload a document again?”
    Some users had found out that I could help them and responded by phoning me for any button click they hesitated about. Very sociable, but highly inefficient for me.
    Fortunately I could point them specifically to the live training sessions we organize, the quick reference cards and the rest of the Help Center. RTFM…
  • “No we cannot risk losing this information!”
    One of the team sites had grown far beyond the official size limit. At that size, we could not guarantee that a back-up of that site could be restored properly. And this site contained important documents and process information that the company has to safeguard for legal reasons.
    Fortunately, the Portal Management Team does regular housekeeping sessions to check for overweight sites. So they became aware of this and we secured the information before any accidents happened.
  • “My colleague has already set up a site for that?”
    The Europeans and the Americans in the multinational both came up with the idea to create a site for the standards for efficiency. Do these need to be separate? Or can they join forces or at least connect to each other?
    Fortunately, we have Content Life Cycle Management in place for team sites. The users cannot directly create a new teamsite, but they request one. The intranet team checks if the site would not be redundant with another site and if the requester has picked the right template before they create the site. Also, we regularly check for ‘dead sites’, where nothing has happened for ages and that just clutter up the intranet.
  • “But the big photo I put on the homepage looks great”
    I regularly see team site homepages torn apart by overlarge images or other content that literally pushes the limits of the page. Usually the creative site owner has designed the page on a large screen, without realizing that the innocent user with his 1024×768 screen gets terrible scrollbars and an unreadable page.
    Fortunately, we have a team that can intervene and tell – or even help – the site owner to fix this. And we have a help center and a best practices blog that give the site owner information and tips on how to do this.
  • “Can we get a team site that really facilitates our request process?”
    Many teams in the organisation have processes in place, for requests for example. And they need something to deal with those in a more efficient, reliable and systematic way than just sending some e-mails and picking up the phone.  Their needs were not catered for in the intranet as we originally set it up. But now we can give them a tool tailored for their process.
    Fortunately we have a Solutions team that can create solutions for collaboration, processing or information sharing problems for which a standard team site template is not enough. This team does not develop code that needs to be rolled-out to the server. But you can do a lot on the front end with SharePoint and some third party tools. We don’t just go ahead and start configuring, but we set up a simple project, based on a business case, and we start by analysing their needs and determining what features would meet those needs.
  • “Intranet not available? Waaaaa!!!”
    A few weeks ago, I could not use the intranet in our office building due to a technical failure. It was hopeless, I could not get any work done there. So I went to the other office complex – 30 minutes of cycling – where to my relief the intranet was available.
    Fortunately we do have a technical support team that fixes the intranet as soon as possible when it breaks.

With an intranet – or another site – it is not enough to build the system and then just toss it at the users and hope for the best. Why? Because we have set up the intranet to achieve some purpose – like increased productivity of our information workers . And it can only achieve and keep achieving that purpose if we manage it properly.

  • Intranet = ‘living system
    Our intranet is not a book that we write, send to the printers and then it is finished. The intranet is meant to evolve with the latest content, with our organization itself and with the latest insights. Otherwise we should just print the company handbook and have done with it. But this living system will not necessarily grow in the right direction, if we don’t water it, fertilize it and prune it where needed.
  • Intranet = open
    Modern intranets are not filled by a small editorial team. The intranet is more lively and certainly more useful if all users can contribute something somewhere and if many users can add lists, design pages and perform other decentralized site management tasks. This can get completely out of hand, if we don’t give some directions and lock down the really sensitive parts.
  • Intranet = indispensable
    We cannot risk our intranet getting completely out of hand, because it is indispensable for our company, as a collaboration platform for our knowledge workers, and a self-service tool and an information source for all employees. So we’d better make sure our intranet remains in peak condition, up-to-date, fully functional and meeting our latest needs.

So just set up some governance to make sure your intranet reaches its full potential and keeps making your and your users’ lives better…

November 30, 2010

Business Taxonomy. Just Do It.

Filed under: Governance,Information Architecture — Tags: , — frederique @ 22:53

Taxonomy. Scary word. Biologists classifying the animal kingdom? Lots of old school librarians or latter day information scientists setting up huge and complicated structures? Not necessarily.

In the context of websites or intranets, we have business taxonomies that are the schemes for organizing the content, usually in categories and subcategories, so that the users of the site can find it more easily.

Recently, I’ve attended a series of taxonomy webinars organized by the American Society for Information Science & Technology (ASIS&T) and given by people from Project Performance Corporation. In that series, they discussed detailed best practices for getting a taxonomy. But they also emphasized some very basic key notions that tend to be overlooked.

First of all: A taxonomy is a means to an end and not a goal in itself.

You don’t create a taxonomy for your site just to have a beautiful taxonomy, but because you want your users to find information easily. If we keep this in mind, we see that:

  • You need to be clear about the goal
    What are you trying to achieve with the taxonomy? Sell more shoes in your webshop by allowing the users to browse through the kinds of shoes they like? Increase productivity in your information workers by enabling them to search and find the information they need?
    It helps to formulate this goal explicitly, so that you can communicate it and keep checking against it.
  • The taxonomy should be intuitive for the users, both the people entering and tagging content and the people searching for content. This implies that:
    • You have to understand the audience, keep your audience in mind when you design it, and you should involve user groups in the process, to make sure that you end up with something that makes sense to them.
      You can do that with workshops, interviews and card sorting exercises.
    • The taxonomy should be simple, not too fine-grained and consistent.
      The best practice is to use a subject-based categorization of no more than 12 to 15 subjects and no more than 2 or 3 levels of subcategories for your main navigation. Avoid jargon, avoid overdoses of metadata fields and over-long picklists . And check with real users if your taxonomy is indeed as intuitive as you think.
    • Communication is key, two-way communication.
      Listen to the users, to get their input and feedback. And talk to them, to get everybody on board and to get them to use the taxonomy properly. The users need to understand why the taxonomy is relevant and how to use it, especially when you ask them to tag content based on this taxonomy. If even 10% of them mis-tag content, the whole system gets messed up.
  • The taxonomy should evolve.
    If it does not fit the needs, it has to be changed. And this is not just a case of fixing mistakes and learning from real life. Your organisation, your users, your market and everything else changes, so your taxonomy should change along with it to stay up to date. This implies that:

    • The taxonomy should be flexible and extensible.
      Don’t carve it in stone so that you would need to demolish the entire site to make small change in the taxonomy. Don’t waste endless time chipping out details of something that probably won’t last until next month’s reorganisation.
    • You should plan an incremental process to get a working taxonomy:
      Start with the basics and build iteratively from there.
    • You need good governance.
      Another scary word, but you need to “govern” your taxonomy, so that it doesn’t grow obsolete or spin out of control as soon as it has been implemented. As a taxonomy of a site is never finished, somebody has to keep an eye on it and where necessary keep a tight rein.

So, your business taxonomy, Just Do It. You just need one. And you can just get started somewhere and let it evolve from there.

« Newer Posts

Powered by WordPress