Though I thoroughly understand your concern, I think there are things at play that need to be considered.

First, your concern with exposing the underlying information model. Suppose we expose the entirety of the information model to the user, what will your average user be able to do with it? The idea behind an aggregator is to abstract the user from the model and simply immerse them in data that is collected for their convenience. Signposts are intended to lead the way to the information you want, not add complexity to a system that was just simplified.

To impose the requirement that they understand where all data is arriving from could undermine the useful nature of some sites. Consider a website that aggregates reports for users on a corporate intranet. Would it be more useful for the average user to know which reporting system compiled each piece of data or is it more useful for the user to have an aggregated dataset they can use for reference?

Let’s consider an even more challenging case. Suppose the data is aggregated and presented in a visualization. In this case, to present all systems and associated data would defeat the very purpose of the visualization, making it less readable and less usable.

On the other hand, if we consider usability and content continuity, I don’t see any reason that this proposal of incorporating signposts necessarily excludes your concerns. I think you’re a little more concerned with core function and site content than site signposts. Perhaps the solution to your concern would be better transparency in site function and architecture than attempting to clutter the site with “signposts” that are really reference markers and footnotes.

A key limitation within silo’d systems meant that when I was working with personnel I had to be connected to and logged into my HR portal – be that SAP, PeopleSoft, or what have you. Therefore I had an intuitive understanding of the source which provided the data I was interacting with.

Now I may be working on a portal site, interacting with personnel data, but I have no idea where the data is coming from, how fresh the data is, nor whether changes to it will be reflected back to source systems that I mean to impact. There is a great risk of breaking the trust as we push data further and further from the source systems into dashboards and mashups.

At the same time I get client requests demanding data, reporting, and features be implemented in the user interface for which there is no source and possibly insufficient granularity to provide. Business intelligence tools in particular expose the limits of how data is stored and reference when the user experience fails to provide meaningful reports because data domain concepts do not match implementations. Explaining to the business that a personnel list cannot definitively identify the difference between employees and varying types contractors because insufficient metadata is captured during onboarding is definitely a non-starter of a conversation.

So – Yes to road signs! But let’s also talk about road signs and markers that are expressed between the user experience and the business information model – and how those elements should be expressed as part of the design process to drive the interesting discussions that lead to solutions or drive alternate approaches.