Getting to the root of the problem with user scenarios

The nature of your data changes over time. Proposals. Status reports. Post-mortem reports. Questions. Answers. Feedback. Requests for feedback. Drafts to review. Requests for you to do something. Requests for your time. Logistical details. SPAM. FYIs

The nature of the information you receive is varied and constantly changing depending on the time of day, day of the week, who's around, who's not around, where you are in various project cycles and where you are in the overall work cycle of your organization.

The Why and How of the data's significance to you changes over time. Things I don't care about. Things I must act on right now. Things that will become relevant in a few weeks. Things that are done. Things I should keep around in case they become relevant. The same item is all of these things at some point in it's lifecycle (with the possible exception of the first state.

The need for structure and organization increases over time as you collect more and more data. People can only hold 5-9 discrete items of information in their head at any given time.

How you need to structure and organize data changes over time. By project. By status. By phase of project. By person. By work context. By time period.

What you call something changes over time. Invert...homosexual...gay...queer

All of this means that people organize and create structure on the go...It is simply not worth trying to construct an apriori comprehensive information organizational structure. Most of us wouldn't know how to begin...and with good reason.

As people accumulate information, they describe it...As people accumulate too much information, they partition their existing groupings into sub-groupings...this tends to happen slowly over time as different areas of the data structure swell with more and more information...As people need a particular view of their information, they create it. Oftentimes however, especially in fixed hierarchical organizations of data, it is simply too much work to re-shape your data into a different view. The process is ad-hoc and usually follows the path of least resistence. The end result is usually a disorganized, unmanageable, complex and inconsistent structure that is hard to use because it is hard to comprehend.

An analogy...

All of this really boils down to the Second Law of Thermodynamics* as it applies to human efforts to represent knowledge in ontologies or classification systems...But with a twist...Because knowledge rarely exists in a closed system, because all things are never equal, the best laid plans for orderly arrangements of information disintegrate into disorder. The very structures we build to make Sense of our data turns into Nonsense when, as The Dude (aka Jeffrey Lebowski) would say, "New sh#$ has come to light! Man." And in our unending quest for more information and more knowledge, "New sh#$ is always coming to light...Man" faster than our stiff-legged classification systems can handle. As a result, the systems ultimately reject the new data and what we're left with is a regurgitated mess of bits and pieces strewn across the landscape of your variegated and uncoordinated information gathering and storage devices: email clients, web mail clients, documents, pdas, paper calendars, sticky notes, notepads, envelopes, napkins, the back of your hand and last but not least, your brain.

*The Second Law of Thermodynamics states that in a closed system, entropy or the measure of disorder, always increases. In other words, the end is nigh, so stop filing your email!

Take home: Attaching semantics to items, so that you can find them again later aka the act of organizing data, needs to be a separate workflow with separate UI affordances from adding structure to data.

Structure is the process of imposing relationships, fixed or temporary between items and groupings of items.

Structuring data is the process of turning implicit patterns and relationships in your data into something that is explicit, concrete, unified and coherent.

Therefore, Structuring data needs to be done when the user has an eagle-eye view of their data...not as users are organizing particular sets of items into ad-hoc groupings...not as users are describing individual items in order to find them again later on.

Organizing items OR Grouping and Describing items should not affect or disturb the overall Structure of the data. At the time of inspecting and evaluating a single item, the user simply does not have the perspective to make system-wide decisions.

Organizational systems however, generally fail to distinguish between these two workflows, thereby forcing users to make all kinds of structural decisions that have system-wide consequences when they are primarily concerned with the details of a single item or a small sub-set of all of their data.

This is the primary reason why information usually only makes sense in small data sets. It is not because the human brain is not capable of absorbing large quantities of data. We are constantly absorbing and processing enormous amounts of data all the time, it's called life. It is because large quantities of coherent, consistent, comprehensible man-made data are a rare if not non-existent phenomena.

The question remains: How do people get an eagle-eye view of their data?

Favorites

The structure of data: how things are, is separate from the structure of the data as you need it to be for day-to-day working needs.