I’m much indebted to Jesse James Garrett and his book The Elements of User Experience. Much of my work had been in bespoke large-scale, enterprise software systems and this book provided an invaluable introduction to the field of user experience design.
Most importantly, Jesse’s book presented the field in a highly accessible and approachable way for software developers like me. (Alright, back then I was one…guess I don’t qualify anymore…)
Jesse achieved this by acknowledging what he calls “[the] basic duality in the nature of the Web”, i.e. acknowledging the web both “as a platform for functionality” as well “as an information medium” (Garrett, 2011, p. 27). (In the first edition, Jesse called this the web as software interface and the web as hypertext information space / hypertext system). This duality is one of the key organising ideas in Jesse’s elements diagram. (This is the diagram as of the first edition. In the second edition, “visual design” is called “sensory design”, “site objectives” are now “product objectives”, and the two sides of the duality are called “product as functionality” and “product as information”.) This diagram may well be the web’s Rosetta Stone: at least software developers and web designers now had the ability to clearly express what they fundamentally disagreed about.
The diagram (especially the one in the second edition) is great as it is. Perhaps I’d rename “functional specifications” to “functional requirements” to avoid the (in my perspective) arbitrary difference from “content requirements”, but that’s not a major problem.
But — you knew there was a “but” coming, right? — this diagram also made me realise how much this basic duality actually irks me. Thinking about it, this duality rears its ugly head everywhere (more or less openly): object state & behaviour in object-oriented analysis & design, business information & process models everywhere (e.g. TMForum’s SID and eTOM), data & application architectures in TOGAF…I’m sure you can easily think of more examples.
Staying with websites as an example, we realise that even content-centric (or information-centric) websites usually require sophisticated functionality, and functionality-centric websites (or web applications) can achieve little without information or content to work on. The diagram is easy to “fix”: remove the divider in the middle and stretch the different disciplines or methods across the entire width of the different panes. Done. (Note that Jesse’s diagram is explanatory rather than prescriptive: he didn’t propose thinking about websites from two unrelated perspectives.)
In the rest of this post, I really leave the web example and the points Jesse made in his book behind — so this is not a criticism of the book.
To me, there’s more to it: First, it increasingly seems ineffective to me to think of function and information as two (fairly) unrelated concerns — or even two only describe them in two (fairly) unrelated architectural views. This connects to Tom Graves’ discussion of how services act on and exchange assets. (Summary of and pointers to sources here.) Second, I’m somewhat uncomfortable with the notion of information architecture (at least as derived from web information architecture): among other things, the term seems to give short shrift to the dynamic or interactive aspects of a product’s structure and it fails to adequately address the information modelling concerns arising from software, enterprise-IT and business architecture. (Also I’m not quite sure what’s up with the apparent rift between (some groups in) the information architecture and content strategy camps. And while we’re at it, how come information design and information architecture are considered to be so fundamentally different, almost unrelated aspects? Can we find another field of architecture/design that holds similar views?)
Trying to take a somewhat unifying view of information architecture / modelling / analysis / design, it seems to me that we need to consider information in at least two different contexts: First, and perhaps simpler, information is an asset that our products’ functions act upon and exchange. Second, we use information modelling techniques to understand and describe the context that we, our organisations, and our products & services live and operate in.
Even if we use similar techniques and methods, it seems useful to differentiate between the context and content of our services, interactions, etc.
And maybe it’s time to consider functions and information less of a duality and more of an interdependent, interwoven whole than we seem to have done in the past.
The end. Yeah, I know: it surprised me as well. I guess I have some more thinking to do here. More later, methinks.
Garrett, J.J. (2011) The elements of user experience: user-centered design for the web and beyond. 2nd ed. New Riders.
Also see Functional flow and structural composition on my new blog.