During the early stages of the web or app design process, should a site map include listing functions or actions a user can take once landed on a particular page? Let’s say you have a site map indicating a blog page…should the site map list the actions a user can take on a blog post like commenting, liking, rating, linking, forwarding etc?
If not, then in what UX document should site or app functions be listed?
Sitemaps is more of an information architecture tool
A sitemap relates to the structure of an application. It helps you understand how to :
Card-sorting is a strong technique to build an efficient sitemap; this technique does not rely on the functionnalities associated to each page.
By including the list of actions in this diagram, you might add noise and unease its understanding.
You would generally see the functionnalities listed in the early days of an application in documents like:
It's been a while since I actually looked at a site map, probably due to most websites in a given category being more or less the same. Also, there are "typical" places (side bars, menus, if all else fails bottom of the page) where you can find "enough" navigation to get to your target with one or two clicks.
Also, web sites usually load fast enough (for me) that I'd click on "Blog" and see for myself if comments or voting were enabled.
Using a separate page to look this up seems so, well, 90s to me.
Now, if we're talking about "work sites" instead of web sites for the general public, the site map would be an ideal entry point for the manual that the users didn't bother to read. In this scenario, having a short description of the functionality would be tremendously helpful to users and support personnel.
Edit: Site maps used during design
After the clarification, my answer is a definite yes, as I do it like this "all the time". My drafts usually show data familiar to the user garnished by basic links with a bit of details added as hover text.
That's a quick way to get the discussion going about what the client really wants. Like in writing, the enemy is the blank page; fixing a "wrong" site is much easier than creating a "right" site.
