BLOG AND EMILI / If your company has a brand manual, why it doesn't have a customer journey?

If your company has a brand manual, why it doesn't have a customer journey?

Many companies have communication guidelines. Fewer, however, have a UX resource library. But, just like the brand manual, they are essential references for any project that impacts the customer.  

Consistency First (or Not?)

A company should always speak to the customer consistently: it should ensure that every external communication is unambiguous, functional to business objectives, and meets expectations. This is why brand manuals exist, prescribing the correct use of graphic elements as well as tone of voice and lexicon in communication with the customer.

If this seems obvious to you, I invite you to consider some cases I have observed:

  • A company is working on two apps simultaneously, with largely overlapping purposes; the projects were commissioned by two different entities, without one being aware of the other's work.
  • A new website replicates part of the functionality of an existing project of the same company and targets the same audience. Only the manager who commissioned it changes. The result is that the customer will face two different sites telling them more or less the same things.
  • Two company projects directly compete: two applications for managing products registered by the customer both require installation and registration, without it being clear which is the "right" one.

What was missing in these cases? A shared corporate perspective on the occasions when the user comes into contact with the company. 

It's as if the company presents itself to the user as a many-headed monster, each head loudly calling to attract attention.

Se l’azienda presenta all’utente percorsi diversi e contraddittori viene meno la coerenza

Companies cannot afford these wastes. We're not talking just about communication in a marketing sense: we're talking about any contact opportunity between the company and the customer/user, from evaluation to joining, from registering purchased products to buying additional services or spare parts, from usage suggestions to support. All these aspects contribute to forming a customer's User Experience with our company, whether in B2C or B2B. 

To return to the parallel with communication guidelines: if the brand manual allows us to speak to the customer with a consistent voice, we need the same consistency from a User Experience perspective. Otherwise, we'll give an impression of fragmentation and lose credibility (just as when we don't follow brand rules).

How to avoid finding oneself in this impasse? Through the creation and sharing of corporate UX resources, which provide coordinates for all customer-facing projects.

Mapping UX: Coordinates

Let's focus on two particular UX resources: personas and journey maps.


Personas are synthetic representations of our customer and their salient characteristics: background, habits, goals, and challenges.

All in relation to our product or service: for example, we're not interested in broad life aspirations or demographic information if they're not connected to what we expect the user to do with our product (this is one of the differences between UX personas and marketing personas, which have partly different purposes).

Why are personas useful? Because it's not enough to say "this project is aimed at potential leads, our customers, the public": in companies, each department has its own view of the customer, inevitably partial for structural reasons. In medium-large companies, knowledge is often strongly compartmentalized, and organizational complexity does not favor the exchange of information between functions and departments.

There are departments with more empirical knowledge of the customer (e.g., Customer Care), others based on representations based on data and studies (e.g., Marketing), others still that rarely have access to the customer in one sense or the other (e.g., Information Technology). However, each of them could be the client and responsible for a project impacting the final customer.

A shared persona has the ability to unite and condense customer knowledge and allow evaluating the opportunity to undertake a project for all departments. Provided one fundamental condition: the persona must be based on user research, not on prejudices or personal beliefs.

AND EMILI specializes in development and strategic consultancy for digital channels.

Discover Digital Product Design services

Journey map

Journey maps are timelines that narrate the relationship between a customer (in the form of a persona) and a company's service or product.

Depending on the purpose and level of detail, they can be classified as Experience Maps, Customer Journeys, or Service Blueprints.

In general, a typical journey map includes:

  • A scenario, i.e., the context and motivations in which the customer/persona interacts with the company's offer (e.g., the need to subscribe to a new supply contract);
  • a series of subsequent phases, the last of which will represent the story's goal (e.g., purchasing the product or service);
  • touchpoints: all points where the customer directly interacts with the companies, both physical and digital (e.g., sales points, website, call center, social networks...);
  • Friction points and opportunities: closely linked, also called “moments of truth”; critical points where the customer can advance in meeting their goals or get stuck and remain frustrated; these are the points where the company can make a difference by improving the customer's UX.

Exactly like personas, it's necessary that the maps are founded on user research, and not on what is believed to be known about them.

What can a journey map help with? If shared, and if based on real data and observations, it allows us to understand the opportunity of undertaking a project in terms of the overall relationship between the company and the customer: understand if there are already touchpoints overseeing a phase of the journey, or conversely, if we find ourselves in a “blind corner” where the customer is left to fend for themselves. If it's an already overseen point, we can question whether the current oversight is doing what we expect and if synergies or reinforcements are appropriate.

A project, therefore, is not just undertaken because it's an initiative of department X or manager "Tizio": it's carried forward because it harmonizes with business objectives and the relationship between the company and the customer as a whole.

To summarize, every time we think of starting a project, we can use corporate UX resources to avoid waste, overlap, and conflicts, maximizing the accuracy and effect of our efforts. We do this by adopting the correct persona, i.e., the typical customer we are addressing, and identifying through the journey map the occasion in which the persona will interact with the new touchpoint we are designing.

A proposal: Journey Maps Ops

How to adopt a common perspective in the company? It involves sharing a customer-centric vision on which to map current projects and evaluate future ones. This vision must transcend departmental barriers, overcoming competence "silos" to spread a high-level vision of the relationship between the customer and the company's offer.

For this purpose, Marc Stickdorn proposed the solution of Journey Maps Operations: a process through which activities impacting the customer are mapped and designed thanks to the combination of different levels of strategic and operational detail.

In fact, Journey Maps Ops allows for "zooming" in on processes from a higher level, representing the customer's relationship with the company over a broader arc, to more detailed levels, where more specific experiences that are part of that broader one are mapped and narrated.

© Marc Stickdorn

Example: Airline customer

An airline might use a high-level journey map, representing the story with the customer from the travel preparation phase to arrival at the destination: this path will include all the "macro" phases, from planning the trip to comparing fares, from preparing luggage to arriving at the destination.

The company will then use more detailed journey maps to better describe individual parts of the story: for example, the airport will have its own map showing the different steps (travel to the airport, passport control, check-in luggage...) with the respective touchpoints (information boards, self-service touch screens, information desk...).

Journey maps serve both to map the current state and to design future interventions: for example, the creation of a smartphone app that guides the customer in the boarding process will be evaluated in relation to the journey phase and existing touchpoints (e.g., some airports might provide their own apps for the same purpose).

The high-level vision is the common reference for the whole company, detailed maps are those on which the references of a single project evaluate opportunities, always in a customer-centric and UX-centric vision shared by the entire organization.

Where to start?

Can Journey Map Ops be the right answer for all organizations? Let's say it's a possible answer, and its applicability depends on organizational adaptations and, above all, efficient communication flows (Stickdorn, for instance, talks about "Journey Maps Coordinators" who take care of interdepartmental alignment).

What we can keep in mind is that building resources to map the User Experience at the corporate level is a continuous, collaborative process that does not end in a circumscribed research phase but needs to be nurtured and kept up to date to be truly useful to the company's objectives. Personas and Journey Maps are living documents, to be cultivated with research and disseminated through good communication. Working on a specific project will lead us to learn something more about the user, consequently updating the UX resources in the corporate repository; all departments can benefit from it in evaluating future projects.

AND EMILI specializes in development and strategic consultancy for digital channels.

Discover Digital Product Design services


This page has been translated using automated translation tools and artificial intelligence technologies. We strive to ensure that the content is accessible in multiple languages, but please be aware that the translation may not be perfect. If you have any doubts or need clarifications, please feel free to contact us.