Customer Journey as a Bounded Context

Exploring your domain talking with different stakeholders can provide a lot of insight in terms of boundaries and competing languages to describe the business complexity. EventStorming can help a lot during the process, but there may still be a blind spot when it comes to including External Users (not necessarily limited to the customers category) in the picture.

In a typical scenario it will be tricky to invite customer representatives - can you peek one typical Facebook user? - and we're usually set up with representatives of the many involved departments in the business flow, while the customers are usually represented by a Product Owner, and maybe characterized in their multiplicity as Personas.

However, this often tends to create a blind spot, when it comes to model the customer language because the internal and external perspectives are at odds.

Seeing it in the small: Software design EventStorming

In a typical complex interaction, like a payment or a purchase, the user would like to perform a simple task, like issuing a payment but we know that a lot of things will happen under the hood. In a ticket purchase scenario, we may imagine that a Purchase is created in the background, to coordinate a Payment and then create a Reservation and issue the corresponding Ticket.

It sounds very complicated - even if it's not yet the complete story - but the customer just wants to buy a ticket, and this is what we expect to see on the button they're clicking.

Under the hood, the initial command won't be as simple as Buy Ticket, but can be something more specific like Initiate purchase process

I guess you're starting to feel the chasm here: there are multiple competing languages families and it's going to be hard to model our system consistently.

Maybe the picture below will help.

There are several competing languages here, the customer intention needs to be fulfilled in its own language, while the actual steps might involve some more specific machinery language. The external users shouldn't really care, as long as their intents are fulfilled.

The customers initiate the transaction in their own language. If this is a purchase, you've probably selected the best call-to-action with a few rounds of A/B testing (so the customer language is the result of Darwinian selection of what works best).

The mechanics of the transaction behind the scenes are expressed in the languages of the involved bounded contexts. There might be a lot of underlying complexity here, like overbooking algorithms or risk hedging, that the customer wouldn't be aware of, and this will be handled in specific bounded contexts.

When closing the loop, we'll need to translate back into the language of the customer intention, kinda pretending that magic happened. The customer wanted to issue a payment? We need to make sure we display a Payment issued successfully type of message.

We need to fulfill the expectation we seeded in the corresponding language.

Seeing it in the large: the forces shaping the language

On a larger scale, we can assume the many different languages are interacting in a more sophisticated way than we originally thought.

The Customer Language is the one that is consistent with the mental model of the typical user. Like everybody else in the business flow, the external users will give names to things

• rejecting unnecessary complexity,
• preserving the relevant differences in their model,
• being usually consistent with one flat namespace.

It's interesting to note that for new products the customer language can be entirely designed, usually in terms of Information Architecture, choosing the terms that better stick with the customer base.

Terms in the customer language may be different from the backend representation. A common, somewhat embarrassing, example is how train tickets are called by the main Italian carrier: the term "titolo di viaggio" (travel certificate, more or less) is never used by travelers, only by messages and signals, while controllers that face passengers in the real world, just call it 'ticket'.

It's also interesting to see the different approaches when it comes to complexity. The customer language is shaped by the provided UI, and by the external words and habits. New terms can emerge beyond our ability to design them. But most of all, while backend models can need a deep dive into complexity in order to derive sophisticated results, the customer model doesn't really care, and the default direction is usually a search for simplicity.

The dark room: Claims and Customer Support

One thing to keep in mind is that when things go wrong and somebody has to connect the dots, the information to collect - from longs and customer claims - will be expressed in different languages.

The customer will rightfully ignore the complexity of the underlying model, but the customer support specialist needs to be trained well enough to connect the dots without bugging the customer for not being precise enough when reporting an issue.

The customer has their own language, so what?

Apparently this is a 'communication problem'. A few people in the UX field have sorted the surface part a long ago, but we didn't have enough conversations to connect the dots. At the same time, when DDD folks finally feel they can master the language complexity with a context map, they can make the final mistake of exposing this complexity to the customer.

There is some mind trick happening: we might feel proud of having solved the puzzle, but we're nerds and most of the users don't need to be.

The honey pot often lies in offering extremely sophisticated services, under an illusion of simplicity. Google Search is the stereotypical example: all the complexity is under the hood and feels like magic for the user.

Learn with Alberto Brandolini

Alberto is the trainer of the EventStorming Master Class (in-person), EventStorming Remote Experience Workshop and DDD Executive View Training (remote).

Check out the full list of our upcoming training courses: Avanscoperta Workshops.