A Methodology for Crafting Awesome Experiences – Part 3

A Methodology for Crafting Awesome Experiences – Part 1, Introduction

A Methodology for Crafting Awesome Experiences – Part 2, Strategic Measurement Framework

In this installment, we are covering the first of the four stages of the Methodology, Designing the Customer Experience.

Designing Customer Experiences is exactly the same whether you are redoing an existing one, or creating a new one. The largest part of this stage is documentation.  The design of a customer experience always, always will begin with a documented step-by-step, detailed description of the experience.  While there is no specific format for this documentation, and it will change for all companies, it has to answer the following questions:

• what is the purpose of the experience?
• what are the channels it supports
  • is there a difference between channels?
  • are any channels not supported?
• what data is necessary to complete this experience?
  • do we need to create new data?
  • is all the data available and known?
  • are the metrics we will use to measure success and completion in alignment with the strategy?
• what are the systems necessary to complete this experience?
  • are they available and integrated?
• what are the dependencies between systems? data? people?
• which users are affected?
  • which users will use it?
  • is there a difference between user populations?
• are there any offline resources needed?
• are there are any human-driven decisions needed?
• what are the service-levels or time commitments we have made?
  • do they change in different channels?
  • are they documented?

Once these questions are answered, you begin the process of documenting the experience.  You may already have something like this that you did during the days of BPx (Business Process reengineering, design, management, or whatever it was called at that time).  Most processes that were documented back then were done from the point of view of the step-by-step involved in the process.  There was not much done to document the dataflows, the people involved, or the automated or manual actions that were not part of the specific process.  Be aware that all those things are necessary when crafting experiences so you may have to dig a little deeper.

Time to get some paper and pencils.  Lots of paper.

Start drawing a workflow for the experience you have just documented.  You do need to use standards for each step (like diamonds of triangles for decision making, boxes for processing, etc.) but you can make them any way you want.  If you don’t appreciate using paper, then you can use a computer-based program.  You need to have a graphical representation of the entire experience – from trigger to closure.  You must ensure that at each step you include any players or parties involved, data and data flows, systems and integration needed, dependencies on other systems, data or process, as well as additional information that explains better why each action is taken.

It will become very complex with time, it is not simple to draw how the actions combine into a process.  I have included a sample of simple experience (there are details missing, but still gives you the idea) in this next picture.

The complexity of the drawing is intentional.  Once you have the entire experience drawn you can look at the finished product and in most occasions you will notice “spaghetti bowls”.  Those areas where lots of things are happening, lines cross, participants wait for action, and many steps are in sequence or have dependencies.  Those are the first areas where we are going to see improvements when we re-design the experience.

At this point I have to address a little controversy.  We have always and forever said that to design good experiences we have to start by asking the customer what they would like to experience.  I still believe in that.  However, I have participated in customer feedback events (both survey-driven and focus groups) intended to design an experience from the ground up by asking customers about their preferences and have them vote on the decisions.  I would like to never have to go through that again.  If you have 10 people in the room, you will get 24 opinions on any and each item before you can move to the next one.  There is such a thing as overabundance of information.  The previous step, documenting as much as possible to have a drawn and detailed experience, was created to bypass the design-by-committee problem.  The customers will be consulted, but it will be done in a structured and organized way.

Now you are ready to begin to design the new process.  This involves two more steps:

1. Involve the business stakeholders and IT to ensure that your new design will include their future plans and current needs
2. Involve customers to make sure that what you design will accommodate their wants

There is an intentional distinction in the description using the words “needs” versus “wants”.  In simple terms, a need will trump a want – you may need food to live, but you want a hot dog.  Of course, a steaming plate of raw broccoli will do if you have nothing else — you will fulfill your need before your want.  The same applies to this methodology.  You will fulfill the needs of the business stakeholders and IT before you take on fulfilling the wants of the users.  If IT says that the action the users would like to implement could bring down the network or another application, the need for a stable system will trump the want for a fancier experience (at least initially) and the decision to bypass any action will be included as feedback in the next iteration.

The meeting with IT and Business Stakeholders is to validate the technical aspects, the availability of the data and systems, assuage any fears or potential problems, and make sure the assumptions made are valid, and that there are no steps missing.  In addition, Business Stakeholders can ensure that the workflow is correct per compliance requirements the organization must adhere to.  Finally, once there is a sign-off from both teams the sequential set of actions is validated as being able to do what is intended to do.  Any feedback and requests for change must be discussed on the merits for the change request versus simplifying the process for the user – always looking for a win-win situations.

The “meeting” with the user is, not at this stage, a real face-to-face meeting.  There are certain circumstances when this rule might be ignored – but I have to strongly emphasize that before anything is presented to the user for feedback it must be very structured in terms of what the user will contribute.  Nothing fuels analysis paralysis more than users that want to make sure all the aspects are covered.

This methodology calls for using surveys with specific questions for this first round of feedback.  The user will be told what is the experience that is being designed, what is the objective or goal of both the experience and the project to re-design them, and asked specific questions.  As usual, questions will vary depending on the circumstances and process under design, but they align with the following sample questions:

• Does the process look complete?
• Are there any channels or situations when this process should not execute?
• What steps look cumbersome and complex?
• What steps seem unnecessary?
• Would you use this process if it was deployed as is?
• What changes would you make to it to make it simpler?
• Could you describe what this process is trying to accomplish?

All the feedback is collected, documented, considered and – if necessary – changes are made.  A key part of this process is to make sure that the loop is closed.  An account of the success of the feedback event and a summary of the changes made to the design based on it must be sent to the user when the design process is complete.  Closing the loop is the only way to ensure that users will participate in the process at a later date if needed, and propels them to deliver better feedback in future events if they feel their feedback is taken seriously.

There is one more step.  When the process is designed and the experience is known and documented – even before it is validated with the users – you should draw an Experience Maps.  An experience map is a linear representation of the moments of truth in the experience – the specific interactions that make the customer express an opinion about the company, the product, or the service.  This experience map is used to represent graphically, after it is deployed, the feedback scores for each customer interaction.  Your initial version can either have real numbers if you have them, or an estimate of what you expect it to be.  The Experience Map becomes useful over time for comparing the CSAT or other scores for each Moment of Truth.

Here is an example of an experience map.

Once you have the experience map, you can involve the customers to validate it. Alas, that is next week’s entry.

What do you think?