1ST QUESTION: What is the difference between these two types of paper or electronic documents often created during a UX process for a website or app:

1) Information Architecture document (IA Hierarchy or IA Diagram or IA Model)

2) Site Map

NOTE: By site map I am NOT talking about a graphical representation of a website that used to be a common feature of web sites in the early 90's nor do I mean the file used by search engine robots...I'm talking about a paper or electronic document a UXer would create.

If you put the two documents side by side what would be the difference between the two for the same site or app?

I was postulating that maybe the difference is, bottom line, that an IA document is about identifying content types or categories while a site map document is about how one would navigate to that content but I'm not sure. Both documents present organizational structures for content.

Could one say that the IA document is about the content types or categories your site will have as in “my site will have page about dogs” while the site map shows where the dog content will be located in your Pet Store’s web site hierarchy and how users will be able to navigate to it?

2ND QUESTION: Should the FUNCTIONS one can do on a site or an app be part of either a Information Architecture document OR a site map OR both? By function, I mean like in a task management app, being able to attach a document to a task you've created is a function.

  • That all sounds like useful information to capture, but I'm not sure that there are widely-accepted-enough standard definitions of these documents for this question to have a meaningful answer. Commented Jun 1, 2016 at 16:13
  • check this out might be useful: IA documentation example - slideshare.net/ujjaini.lahiri/ia-documentation
    – Dave Haigh
    Commented Jun 2, 2016 at 8:57

3 Answers 3


1ST ANSWER: I normally don't really care about the terminology used to describe the assets that are created using a UCD process, but I do care about the quality and accuracy of the information it captures. So to me I think your description of the two types of information captured is pretty close to the mark, but I couldn't tell you if that's the exact terminology used.

Basically you need to capture two main things that you have identified. First, the hierarchy or organisation of information/content/data that you are going to present to the user (i.e. the content types or categories as you mentioned, but also their relationship to each other). Secondly, you need to capture how that hierarchy or organisation is mapped to the various parts of the website (i.e. how the users will be able to navigate/discover it).

Even though I can't really tell you what to call them, the fact is that they capture related but different information, so it will be obvious when you show it to someone. Again don't get too caught up on the terminology as it takes time from doing more important things like capturing the information.

2ND ANSWER: I don't think the functional details of a site fits in with the IA document, only because it is generally good practice to separate the underlying information or data from how it is actually presented. For the 'sitemaps' that you refer to, I try and put the high level functions as labels on the document, and use it as a link to the business or functional requirements that need to be implemented on the user interface so it is quite helpful there.

UPDATE: Thinking that I might not have actually addressed what you really want to answer, it might be more accurate to say that doing site maps is part of planning and creating the information architecture. But information architecture work can be at different levels, including the basic data, individual page content, or overall site structure.

Some examples that might help you out:

'Site' level information architecture: http://bitstrategist.com/work/information-architecture/

'Page' level information architecture: http://bitstrategist.com/img/work/infodesign/medfi_wireframe.gif

'Data' level information architecture: http://bitstrategist.com/img/work/infodesign/db_schema.gif

  • I appreciate your answer Michael. The confusion over terminology for me get's even more intense when I search Google Images for examples of Information Architecture documents and what I see looks exactly like site maps to me. I need to find example documents that make the differences clear.
    – Steve Crow
    Commented Jun 1, 2016 at 3:05
  • IA is a much broader term that can be applied to a whole range or practices and deliverables. Site map or site structure would be one of the IA deliverables
    – Sheff
    Commented Jun 1, 2016 at 11:03
  • Michael, thank you for the links to documentation examples - always interesting to see how others do it
    – jackiemb
    Commented Aug 11, 2016 at 6:39

Information Architecture is a huge subject (so much so there is a very large but excellent book written by Louis Rosenfeld and Peter Morville on the subject - Information Architecture for the World Wide Web 3rd Edition).

A site map is a simple output of all of the IA work, and is consumable by the end user.


Site Maps will speak to what is where--even to functionality and purpose. IA will convince your project manager to spend $X on Y.

I can't say how others tend to view/do it, but in practical terms, here's an example I dealt with recently. Shopping cart project with 'related items'...it's easy enough to stick them in a design and attach them as logical additions to a model, saying they go here or there. But the why, starts differentiating the site map/IA function almost immediately.

And, I really like Michael Lai's answer, by the way. Far more in depth and refined than mine. However, I tend to think functional details more often than not do belong in IA.

So, we have some products. You've got products of various sizes, in primarily horizontal and vertical orientations, usually every particular size/dimension has a corresponding opposite orientation. You have a card, for example, in 3x5 horizontal orientation, and a corresponding one in 5x3 vertical orientation. You're only going to show 4 related products on a page, and you have multiple sizes...3x5/5x3, 4.5x6/6x4.5, 5x7/7x5, 8x10/10x8. That's 8 products. Which 4 are the related products?

They shared major category and attribute commonalities, and you could put any 4 at random (except you don't want to display the same primary item again). A site map doesn't really reveal what you do here, or how to approach it, but IA does. In this case, the four items that are 'related' had a consistent pattern. Opposite orientation was first--if they're looking at 4.5x6, maybe they want to see an alternative in 6x4.5. Then, same orientation and one size up, same orientation and one size down. Then, repeat, one size up and one size down. Skip what doesn't exist or is already shown. Trying to push them to larger sizes for the up-sale so the one size up comes first.

So, if you have a customer viewing the horizontal 4.5x6, they get shown the following 'related' items:

6x4.5 vertical (opposite)
5x7 horizontal (one up)
3x5 horizontal (one down)
8x10 horizontal (one up is 5x7 so skip and next up is 8x10)

But, what if they're viewing the 5x3 vertical? You show them:

3x5 horizontal (opposite)
6x4.5 vertical (one up)
7x5 vertical (one down is the current product, so go up one)
8x10 vertical (one down is 7x5, so go up one)

And when they're viewing the 7x5 vertical. You show them:

5x7 horizontal (opposite)
10x8 vertical (one up)
6x4.5 vertical (one down)
5x3 vertical (one up is 10x8, it's been shown, no more ups, so go one down)

The more options, products, choices, the more ways it could go, but we needed a structure that kept 'related items' to what the customer is likely drawn to, a product in a particular orientation, with a related size thrown in in case it's the size/space to be filled. So, I haven't created any code to get these things anywhere, but I know with absolute certainty whatever product I go to, what will be shown in its 'related items' section. By having the IA/logic/functionality in hand, I only need to map out one product page in a category even if there's 300 products to arrive at either a starting point for code or a content management workflow.

Site maps don't really get to the core of why, and IA does. It's still just 4 items with 4 links, but the IA provides the context that's lacking when the site mapping tells you there are these 4 products and the links go to 4 products because they are related products. IA can stand up to an argument about why those 4 products and not 4 other products, or convince someone to spend money on plug-ins or extensions that bring a ready made and needed functionality, where site mapping doesn't really argue to the bottom line the same way (and not that it doesn't in other ways). IA can also suggest to you that perhaps you need to show a different number of related products, or create questions about what is related, and thus cause you to refine or redefine your model.

What happens when you only have 3 similar related products and that 4th product that should be shown should, or needs to be, something of an entirely different category? A site map doesn't deal with pattern/logic exceptions necessarily, whereas your IA can and will.

Again, that's a practical and perhaps over-simplified example, but it's the real-world sort I find myself dealing with as much as any when trying to bring logic/consistency into decisions about a project. I usually work alone or in small teams and it just seems functionality is almost always in the IA mix. Then again, maybe I'm thinking about and doing it all wrong. There's that possibility, too.

  • VERY much appreciate all the detail, clearly this took some time to write out. My conundrum really had more to do with the IA document itself as a deliverable, not Information Architecture as a discipline. I couldn't actually get a clear answer to: if someone asked me to create an IA Content Model DOCUMENT how will that look different than a site map DOCUMENT? The answer I ultimately settled on is that the IA Content Model document is really all about showing GROUPS of related content, somewhat like a mind map. You might draw connecting lines between these but it's not a navigation scheme.
    – Steve Crow
    Commented Jun 3, 2016 at 3:41
  • I agree, it's about groupings. Should have elaborated that all of the above stuff gets referenced as groupings and boxes having key/# references. All the above goes into addendums. Presentationally as a deliverable, it ends up a stack of paper, similar to some of the examples Michael linked to, with stuff like logic_submission#01A or view_user#02B in the flow diagrams and which reference pages attached. The model/diagram stands alone, but the keys/addendums are there for drilling down. But yeah, not really a navigation scheme in the doc. Your question has fueled my own search for new IA tools. Commented Jun 3, 2016 at 20:58
  • Hey Sean, I'm very glad my question sparked some new thoughts and investigations for you. It certainly did for me as well. I have asked this same basic question on multiple forums and websites and had a heck of time to even get people understanding what I was talking about. I'd say at least 75% of the IA Content Model documents I see posted online are really site maps - no difference as far as I can tell. Now I'm on a new quest to discover if UX site maps should include the actions or functions a user can take once on a page. That will be my next posting!
    – Steve Crow
    Commented Jun 5, 2016 at 16:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.