301 Moved Permanently

This blog’s title (and URL) begin to feel a bit narrow. This seems better.

The knowledge-doing gap

People are smart. Not all of us all the time, certainly not me. But by and large, people are smart. This seems odd when considering that we frequently encounter less-than-desirable situations that often have endured for a long time.

But people often know what could be done to improve even such long-lasting situations — this knowledge just isn’t put into action. Jeffrey Pfeffer and Robert I. Sutton discuss this phenomenon in their book The knowing-doing gap: how smart companies turn knowledge into action and in a related article.

From this perspective, it becomes obvious that addressing such less-than-desirable situations as a knowing problem is unlikely to be effective — the people affected likely have all the knowledge required to improve the situation. Addressing such situations as a doing problem, i.e. working with people to put their knowledge into action, seems likely to be much more effective…but only if the people affected think a problem exist, want to do something about it, and want (my) help in doing so.

Now putting the knowledge in this post into my actions would be a big step toward closing one of my major knowing-doing gaps.

Content strategy, service design and physical objects

I had the opportunity to begin learning about content strategy in the last two months or so.

I’ll probably have more to say on how this changed my perspective in thinking about a lot of things in another post. Sarah Wachter-Boettcher’s book  Content everywhere: strategy and structure for future-ready content got me started and Jonathon Colman’s Epic List of Content Strategy Resources pointed me to more great resources on the topic.

I might have stumbled across the term content strategy in Milan Guenther’s book Intersection: how enterprise design bridges the gap between business, technology and people. The enterprise design framework uses 20 aspects (organised in 5 layers) of design work in an enterprise context. The second layer, anatomy, includes these aspects: actors, touchpoints, services, content.

I was happy to find a strong element of service design in the framework, but thought emphasising the content aspect odd. Well, maybe for mostly digital services that made sense… But what about (physical) evidence? But then I’ve had issues with overemphasising service evidence, too.

By now I see the point in discussing content (strategy) at this layer in the framework, but I still feel uneasy about the (state of the discussion) of physical objects in service design. (Or am I just not reading the right stuff or talking to the right people?) Thinking of physical objects (including goods, physical products) as vehicles for provisioning services (as discussed by Dave Gray, among others) seems promising. Physical objects can certainly also be vehicles for delivering content. (We could also view content delivery as a type of services.) And then there’s a role for physical objects in a service evidence context (in a narrow sense, please).

Is it time to bring these thoughts together and elevate the discussion of physical objects in service design?

Updates
2014-09-21: Tom Graves has written a brilliant post titled From Product To Service.

The customer lifecycle isn’t

There’s a lot of talk about the customer lifecycle and the benefits of paying attention to it out there.

A typical customer lifecycle goes like this: A potential customer discovers our offerings, learns about them and our value proposition, buys our offerings and thus becomes an active or current customer, and finally stops buying our offerings and thus becomes a former customer.

But is this really a typical customer lifecycle?

I don’t think so anymore. I think this more typical: A potential customer is born, grows up, lives through adulthood, grows old, and finally dies.

Obviously, this is quite coarse-grained and could be detailed by adding many significant events.

The first lifecycle above really describes the relationship between a customer and a business (and this only in a very limited way).

Paraphrasing Chris Potts, businesses need to decide how they want to appear in their customers’ activities, experiences and lives. I think this a lot easier to do when taking the second perspective on the idea of a customer lifecycle.

Digital experiences: journey first or content first?

Both. Sort of.

Recently the topic of whether to take a journey-first or a content-first approach to delivering digital user experiences came up. The former seems to be favoured by more “traditional” user experience designers while the latter is favoured by many content strategist. No surprise here.

For now, my take is this:

I think I want to start with the customer experience in a conceptual, coarse-grained and probably channel-independent manner. A concept map (or a service ecology map, despite this grandstanding name) is a good basis from which to start mapping a customer journey.

Digging into more detail, increasing the focus on content seems useful, both in terms of detailing the content model and the actual content.

In turn, the content model as well as representative content elements can be an effective basis for designing the actual user journeys for a digital service.

Thoughts, please? Thanks.

Content strategy: a new chance for benefitting from domain modelling?

I have been interested in domain modelling for a long time. Analysis Patterns by Martin Fowler, Domain-Driven Design by Eric Evans and Streamlined Object Modeling by Jill Nicola, Mark Mayfield & Mike Abney greatly influenced my thinking and (some of) my work.

(The fundamental concepts described in Streamlined Object Modeling might actually be some of the most under-appreciated ideas in software development and information modelling.)

While I understood the benefits of good domain models early on, I can only recall one project incorporating a domain model into its software. Even when technology was able to effectively support implementing domain models, many developers seemed happy to read and write data structures to persistent storage manually and to manipulate these data structures with imperative code. To project managers, these things were probably too abstract, too invisible and too far removed from the myriad of immediate concerns they had to deal with in parallel.

And, of course, I probably didn’t make my point as well as I could have.

I was intrigued when I learned that content strategist had discovered domain modelling (and in particular Eric Evans’ work) for their purposes. Content strategists, if you read this, go and read Analysis Patterns and Streamlined Object Modeling, too — I’ll still be here when you’re done.

As I’m learning about content strategy and content management systems, I get a hunch (hope?) that this might actually be another chance to bring the benefits of domain modelling to the enterprise. This might be another chance to benefit from structured, connected and annotated information, and achieving objectives by interpreting these connections and annotations rather than writing lots and lots of imperative statements in code, process charts, rule lists or, for some of us, PowerPoint and Excel.

Content is likely to be much more tangible and immediately accessible to stakeholders than domain models ever where — as almost everyone has an opinion as to what needs to happen on the corporate website, I’m confident many stakeholders can be nudged into having an interest in content.

Let’s see how far I get this time…

Competing concerns in information modelling

This has been a recurring theme in my work so I figured I’d write about it:

Information models (domain models, object models, data models, content models) are typically subject to many different forces influencing their designs, and some of these forces can act in opposing directions. Some of these forces are specific to the problem at hand and its context while others are more generic and keep showing up in my work.

This post is about some of these more generic forces. (Or maybe its only about two potentially useful approaches.)

Avoiding redundancy vs. ease-of-use: Avoiding redundancy pushes towards fine-grained models in which classes and instances can be (re-) used in different contexts. A fine-grained model can be difficult to understand and may be difficult to use for developers, application/information managers and end-users. Ease-of-use pushes towards coarse-grained models which may be easier to understand but have a higher risk of inconsistencies if data is kept redundantly.

Instance-based vs. class-based differentiation: Class-based differentiation introduces different classes (and often inheritance hierarchies) to models in order to represent specific concepts. A high number of different classes can make a model unwieldy, difficult to understand and difficult to use, especially when the intent of and differences between classes are not described well. In contrast, instance-based differentiation represents specific concepts through instances of generic classes. In order to so, the model often has to introduce additional classes, e.g. for type, state or group objects. The resulting model typically has a simpler fundamental structure (fewer classes for core elements), but a necessarily higher level of abstraction can also make the model difficult to understand.

A few thoughts occured to me in this context:

Information access and modification are different concerns and might warrant different approaches: Command-Query Responsibility Segregation is one approach that might help here.

Information access & modification by administrators, developers and end-users are different concerns and might warrant different approaches:

In my experience (yours will vary), software systems tend to structure data according to development/runtime concerns, with some allowance being made for end-user concerns. Administration concerns tend to get little attention. Interestingly, this seems to be somewhat different for content management systems, likely because content managers are an essential end-user group in this context. CMSs are built to administer information in one structure and make it available in many different structures.

Could content management systems help address the different needs of administrators, developers and end-users? Even of administrators, developers and end-users of other integrated software systems?

And could this also have beneficial side effects with respect to automated testing, continuous integration & delivery, etc?

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.

Reference

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.

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.