Function & information: a useful duality?

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.

Service results need to be considered in their context

This post has been triggered by an interesting conversation with Kristof Dierckxsens, Tom Graves and Chris Potts that took place on Twitter during the last two days.

Chris challenged a sloppy statement I made earlier:

Services don’t deliver experiences. They appear in, and influence, them.

(Chris Potts)

This is difficult terrain: In the context of a service, a service provider and a service customer (in the simplest case) strive to co-create specific outcomes and experiences for the customer. The service provider is unable to bring about these outcomes and experiences without the (collaboration of) the customer, and circumstances might prevent the desired outcomes and/or experiences being achieved.

Against this background, it is not useful to say that ‘services deliver experiences’. Nonetheless, services are designed and provided with the intent to bring about, contribute to, or influence specific outcomes for and experiences of the customer. (Also see this). However, a service provider can’t guarantee that such outcomes and experiences can be actually achieved for a specific customer in a specific context.

As an example, I might get into a taxi to get to catch a train at the station. The taxi driver is friendly, drives responsibly and takes me to the train station without delay. For some reason, the train has already departed and I miss an all-important meeting. Even though the taxi service resulted in a successful outcome and experience in a narrow context (the friendly driver safely got me where I needed to be in good time), my outcome and experience in a wider context (I’m upset about missing the train and thus the meeting) wasn’t successful. I’m unlikely to keep favourable memories of that taxi ride–although none of this was the driver’s fault.

Chris provided another example:

Over a latte in your favorite cafe you choose & book a skiing vacation. Which #service created this #experience?

(Technical answer: Service (loosely) implies someone doing something for someone else. Thus no service created the overall experience. “Services seek to bring about experiences” doesn’t imply “Experiences can only be brought about by services”.)

This example shows that experiences, like many other things in life, can be considered fractals. The overall experience here is composed of a set of more fine-grained experiences (sitting in that cafe, enjoying the drink, booking the vacation, anticipating the joy of going on holiday & skiing). Service outcomes, and services themselves, can be viewed in a similar way.

Interestingly, none of the service providers (cafe owner & staff, travel agency) could have foreseen how I would use their services concurrently. Consequently, they also couldn’t design for this.

In conclusion, designing and providing services with the intent of co-creating specific outcomes and experiences with, for and of customers is (self-evidently, I think) a useful concept in a narrow sense. In a wider sense, we need to acknowledge that we can’t control the our customers’ broader outcomes and experiences. That’s a tough lesson calling for a humble stance–and maybe slightly less conviction and certainty when designing services.

In this wider context, one of the questions Chris raised in his books is highly relevant:

How do we want to appear in [influence & contribute to] our customers’ experiences?

By analogy, the following questions seems equally relevant:

How do we want to influence & contribute to the outcomes our customers’ realise?

Thanks for the conversation, folks.

Service ecology maps and the enterprise canvas

Andrew Polaine, Lavrans Løvlie and Ben Reason describe the notion of service ecologies and the benefits of mapping service ecologies in their book Service Design: From Insight to Implementation. They provide relevant figures from the book here, here and here. The service ecology map has three main purposes:

1.  To map service actors and stakeholders 2.  To investigate relationships that are part of or affect the service 3.  To generate new service concepts by reorganizing how actors work together

Polaine, Løvlie & Reason (2013, pos. 1496)

The service ecology map dimensions proposed in the first link above are well known: what, how, when, where, who and why. These dimensions and the above definition link the concept of a service ecology map directly to the scope or context layer and the business services layer of Tom Grave’s (2010, p. 37-38) enterprise canvas.

A few happy thoughts:

  • The notion of a service ecology resonates nicely with previous discussions of the enterprise-as-ecosystem.
  • The service ecology map, together with the enterprise canvas, provides a nice link between ‘classic’ service design and enterprise architecture (architecture of the whole and shared enterprise).

With a respectful bow to Tom Graves and his work, this leaves me with the following layers of abstraction for my service decomposition work:

  • Purpose
  • Context
  • Concept   (implementation-independent)
  • Implementation   (implementation-specific)
  • Deployment   (operations-specific, action-plan, resource-schedule)
  • Action record   (record of actions as occured)

Tom has very good reasons for designing these layers in the way he did, e.g. congruence with the Zachman framework. I really only combined Tom’s scope & business services layers into a single context layer and slightly renamed some of the lower layers. This is a pragmatic approach that I expect to work in my context–you are probably better off with Tom’s approach. References Graves, T. (2010) Mapping the enterprise: modelling the enterprise as services with the enterprise canvas. Tetradian Books. Polaine, A., Løvlie, L. & Reason, B. (2013)  Service design: from insight to implementation. Kindle ed., Rosenfeld Media.

The problem team & the solution team

We have great problems to solve.

So we task someone to describe the problem and we task someone else to describe the solution, which yet someone else is tasked to implement. For reasons of efficiency, we let them all start at once.

The bad news is that this doesn’t work. (And it hasn’t worked before. Ever.) Most problems worth solving today don’t have obvious solutions. In fact, often it isn’t even obvious what the real problem is.

In reality, that nice process of describe problem — describe solution — implement solution looks a little more like this.

“No way!”, the lizard screams, “Our process is way more disciplined than this!” Well, maybe it is disciplined (I bet it’s not), but is it effective? Does it yield effective solutions to the real problems?

If The Squiggle is too much to stomach, let’s take a more conservative example: Where would we draw the line between the problem and the solution here?

Having a problem team and a solution team is wonderful way to foster adversarial mindsets. Instead, let’s have one team with different strengths and a common understanding of what success means. And then let’s get the -bleep- out of their way.

Also read Bob Marshall’s The Same Old Way.

Requirements are design decisions

I believe that the success of software development projects and many other types of initiatives could be greatly improved if we came to terms with a simple insight:

There is no such thing as a requirement. A so-called requirement actually is a design decision.

Why does this matter? First and foremost, I think we want to consciously make potentially far-reaching decisions, especially when other peoples’ lives and livelihoods depend on them. (Well, this dependency might be more pronounced in your business decisions than mine…) Second, when we see these design decisions for what they are, we can make them more effectively, e.g. by applying design methods to them.

Requirement statements are best understood as statements of stakeholders’ interests, needs or wants. Rather than taking them at face value, we ought to seek insight into the stakeholders’ deeper, underlying motivations.

For example, stakeholders frequently express perceived mechanisms for achieving desired ends as requirements. Identifying these desired ends will often lead to discovering better ways of achieving them.

Design decisions come in two flavours: decisions relating to the problem space (i.e. ultimately deciding which problem to solve) and those relating the solution space (i.e. ultimately deciding how to solve it and implementing the solution). Rushing to working on the solution may feel like progress, but this might well be progress in the wrong direction.

A request: I know that I’m not the first one to state that requirements are design decisions. Please let me know if you know who said this first (or, at least, early). Thanks.

In what context? For what purpose?

Dean Bubley (Disruptive Dean) said the following on Twitter yesterday:

The OSI stack for networking should have Layers 8 & 9 added to it: context & purpose. That’s where the value is going.

The underlying thought seems to be applicable to other areas, including service design, enterprise / business / solution architecture and software development.

Tom Graves’ describes several layers of abstraction in his service-centric view of the shared enterprise, starting with the enterprise layer, which defines purpose, and the scope layer, which defines context.

When describing a software service, for example, I typically begin by describing its intent and depicting the service in its context (both static and dynamic).

So, when faced with a new concept or a new challenge, one of the simplest ways to start adding value is asking two questions:

  • In what context?
  • For what purpose?