Designing intranet structures – Designing your URLs (Part 3)

June 19, 2011

In all of the posts and articles I’ve read about intranets I’ve never heard much mention of URL design yet this can be a key approach in designing your intranet and will also permanently help your users in finding the content they need. If you’re worried that this might sound a little complicated don’t be.  The approach I’m proposing in this post is simple and low tech.

When discussing the system map in Part 2 I said that categories, genres and other aggregations should not be considered in order to keep the map as simple as possible. The principal points in adopting the URL design approach is to -

  • Map and agree  the top level navigation structures
  • Agree the pages/resources that your intranet needs (and doesn’t need)
  • Indicate which aggregations need sorting e.g. by categories, A-Z, by number etc.
  • Involve everyone in the discussion

So what attributes should our URLs have?

There are many things that have to be thought of when designing URLs but for the purpose of keeping things simple I have gone for four main URL attributes that will be of benefit in intranets -

  • Readability
  • Hackability
  • Persistence
  • One URL per resource or ‘thing’ (not page!)

Readability – A good URL should be a source of information to your users. It should read like a breadcrumb trail with a page for every section of the URL. As search becomes more ubiquitous, even in intranets, a good intranet URL can give instant information to your users on whether the content is what they are looking for.

For instance if I put a search query in for ‘form for booking holidays’ in many intranets (and web sites) you might get a URL looking something like this -

intranet/forms/bqws1234

All I get out of this automatically generated URL is that it is a form and that’s it.  A good intranet URL for the same form might look like this-

intranet/hr/policies/holidays/forms/staff-booking-holidays

You can see that a readable URL presents the user with extra information which will give them confidence in making their selection. Also very importantly it is much more memorable. Once I’ve seen the readable URL above I stand a much better chance of being able to remember it and return to the content at a later date. There is virtually zero chance of remembering the automatically generated URL.

Hackability

‘Hackability’ means being able to access higher levels of the intranet by deleting parts of the URL. If we use the instance above -

intranet/hr/policies/holidays/forms/staff-booking-holidays

If, having booked my holidays, I wanted to see more information about holidays I should be able to snip the URL so it reads -

intranet/hr/policies/holidays/forms/

Which will be a page in the HR section containing all forms related to holidays. I can go further -

intranet/hr/policies/holidays/

Which will be a page containing general links to all content about holidays. In order for users to be able to hack intranet URLs this way there must be a page for every section of the URL. In some informal research carried out a couple of years ago it was found that around a third of users will try hacking URLs to get at the content they are looking for so spending a little time ensuring that URLs are hackable could pay dividends for years to come.

Persistence

This is probably of more importance for web URLs in terms of  achieving better SEO however I think it is well worth considering when designing your URLs. Using terms with a limited life span will mean that your URLs will become nonsense in time. Giving some real consideration to making your URLs as long lasting as possible will help those users who use bookmarks or shortcuts and save you time in the future by not having to go back and fix obsolete URLs.

One URL per resource or ‘thing’

The days when all content was static are now disappearing and are being replaced by dynamic pages. A dynamic page will have its own URL but so will the content that appears on the page. By ensuring that everything has its own URL it then becomes possible to tailor content so it more closely fits your users’ needs.  For instance it becomes possible for users to start creating their own ‘pages’ with links to individual procedures, policies and other content at a quite granular level. Perhaps more importantly it allows content to be accessed from more than one place, from multiple genres or categories that make sense to all your users. It also makes it easy to change your structure when change becomes necessary. Rather than having to change swathes of content it becomes more of an exercise in re-arranging your links.

Designing your URLs

All you will need for this is some different coloured post-its and a wall.

(Taken from Michael Smethurst’s Radio Labs blog post)

Using the systems map as reference start with the highest level sub-domains of your intranet as agreed in the sytems map. These might look like -

intranet/hr/

intranet/mystuff

intranet/corporate

intranet/operations

and so on. Write these on different coloured post-its and place them on the wall in a row. Then start building up the child resources for each sub-domain which should also be detailed in the sytems map -

intranet/hr/policies

intranet/hr/H&S

intranet/hr/forms

and so on. Place these below the ‘intranet/hr’ post-it, stand back and have a think. Keep going, writing up URLs and moving post-its until it all makes sense, not just to you and your team but your stakeholders and even users. Iteration is the key to making this part of the process work. Once you’re happy with your URLs you will have structured your intranet and decided on your top level navigation.

A tip – keep photographing the wall of URLs every time something is changed just in case the cleaners take it down!

The next step is to define and re-define your URL structure and how you can consider ‘future proofing’ your intranet. I’ll show you how this can be done in the next post.

Further info on URL design

Silver Oliver’s and Deanna Marbeck’s presentation URL Design for Information Architects

TimBL’s  Cool URIs don’t change

Rield.com Clean URL Design Guidelines

Manas Tungare’s URL Design Sins

 

See Part 4 of Designing Intranet Structures

(Thanks to RambergMedia for the Flickr CC image)

About these ads

4 Responses to “Designing intranet structures – Designing your URLs (Part 3)”


  1. Designing intranet structures – Designing your URLs (Part 3)…

    This article has been submitted to IntranetLounge, a website with a collection of links to the best articles about intranets…

  2. Erin Says:

    Thank you for your post. I have a question. This is something we’ve been thinking about as we decide what our next-era intranet will be like. (I am not a technical person but I work with our intranet.) Right now we have the “wrong” type of URL as you point out – a bunch of gobbeldygook that doesn’t mean anything to anyone. The upside to it is that it doesn’t change if the document/page is moved to another section. If we went to a more “call it what it is” approach as you are suggesting, what happens when HR says “we no longer want a centralized form section.” or HR gets renamed to “Personnel Services” or something like that. How do you keep things under control?

    • patrick c walsh Says:

      Erin,
      Thanks for a very good question. Generally intranets should change to reflect the current state of its parent organization. Therefore if major organizational or content changes are needed I see no reason why the URLs can’t be changed if required to keep in line with these changes. It’sbasically going back to step 1of my approach and treating it as a re-design of the intranet.

      However this may not always be required. In the example you give above where HR wants to re-brand themselves I would try to get agreement that they will always be ‘HR’ in the URL. It’s short and people know what it means.

      Where HR no longer need a centralized form section that shouldn’t be a problem if the intranet is designed correctly in the first place. ‘Things’ such as a single form have their own URL and this URL can reflect where the form belongs e.g. hr/forms/holidays/staff-booking-holidays. Although the form belongs to ‘holidays’ it can be linked to from anywhere in the intranet. The centralized page is just an aggregation of forms and so can be deleted without altering the structure in any major way. In fact dealing with a piece of content like a form you might well have a landing page for the form which is hr/forms/holidays/staff-booking-holidays and when staff open the form to complete it the form’s URL might just be xyz123/staff-booking-holidays which means that the actual URL of the form need never be changed. There are a number of ways of structuring URLs, the trick is to apply the one that is best for your organization.

      Part of this exercise should also include ‘future proofing’ the intranet structure, that is trying to think of all the possible contingencies that might be required and building these into the structure. I will be dealing with this in my next post.

      Regards

      • Erin Says:

        Thank you for answering my question so completely. Our company is *constantly* reorganizing and renaming departments, so we have a heckuva time sometimes with our org-chart based intranet (cringe).


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: