information architecture - Domain strategy from a UX perspective?

Having a domain strategy seem to be the latest thing. The discussion about it circles mostly around legal, seo or branding issues but if you want to look at it from a usability perspective - how should you actively structure your url or domain strategy. I've seen a couple of approaches:

• Google has put its different online services such as maps.google.com, mail.google.com as sub domains. The benefit that I could see here is that its quicker to reach these tools by only typing the product name in the browser adressbar and let the autocomplete functionality in the browser do the rest.


• 37 signals uses a similar approach for their online service Basecamp. When I have registered my company I get this url: mycompany.basecamphq.com. That way makes it easy for me as a user to quickly reach my specific web space.


• Apple on the other hand uses the directory approach for their products such as apple.com/iphone, apple.com/store. They also redirects domains such as www.iphone.com to apple.com/iphone which I guess is for mainly legal reasons.


• Proctor and Gamble separates all their different brands using unique domain names.



• I've seen other companies structure it's content by target groups and then their products (brand.com/business/productname) or by product category (brand.com/productcategory/theproduct) which makes it easy for me to understand where I am on a large web site.

Answer

(tl;dr: Click through the presentation mentioned below to see how the BBC designed their URLs and to learn a bunch of other stuff you probably hadn't thought about much)

The best approach to this I've seen is described by the BBC's UX director Mike Atherton in Beyond the Polar Bear (SlideShare).

One of his main arguments is the use of domain-driven design, a concept explained in the book of the same name, Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans. Mike's takeaway of "domain modelling", which is what domain-driven design teaches you about (slide 18):

• A way of representing the important "things" within a subject, and the relationships between those things


• A way of using the subject knowledge of users and experts to influence software design


• Inspired by the abovementioned book

Mike explains in the presentation that the BBC was looking to reorganise all of its sites into a simpler model. This is what he says a model could look like:

He explains that to approach modelling the domain, his team talked with domain experts (eg. the people who makes shows for the BBC) and to users of the website and tried to build up a model of the whole thing using their feedback. When talking to domain experts it was important to determine how their language differs from that of end users and decide which approach you want to use in your domain (probably that of the end user).

After that, he says, you look for the different canonical "things" in your domain model. This will help you build up a URL structure later on, but is also just a good domain modelling practice.

Another point he mentions is that you should make sure that your "things" are named the same throughout your information architecture. That means that a thing has the same name in the URL, in the content of the page, in the code, etc. This will also help prevent headaches later on.

Following his approach, he argues will lead to:

Skipping forward a bit, we find:

This is a fantastic hierarchy of needs for a URI. Many programmers will tell you URIs are hackable, human-readable and persistent, but this maps each of those to users, which is what UX can be really great at.

So what did the BBC actually end up doing with their URLs? Mike shows up some options that didn't make it:

and the one they ended up going with:

That ends up not being very human-readable or hackable, but it is persistent. He explains why they decided to go with this solution:

• In the BBC's case, programmes need to be uniquely identified, and this does that regardless of the context of the show


• Losing human readability is an acceptable compromise to get persistence



• Marketing-friendly URLs can still be used with a 301 redirect

Later, he mentions that this solution means that the user experience is enhanced without undermining the structure. From a domain modelling point of view, that's a win.

A large part of the presentation is dedicated to a case study of how they approached the domain modelling challenge at the BBC. I recommend reading through all of it, as a site of the BBC's size doesn't come along very often and you can learn a lot from it.

Some of Mike's closing slides are great food for thought. On slide 88 he mentions "UX thinking goes all the way down" and explains that user experience is more than just presentation and interaction, it can include things like business logic, SEO, document and URI design. Arguing in favour of domain modelling, he says you should try using it on projects of any size, not just those as hefty in scope as the BBC. Beyond making URLs hackable, human-readable and persistent, he says you should make your content portable and sharable too. He also mentions that you should start designing from information, not from wireframes, which he calls a bottom-up approach.