How do you design employee experience?

You have collected needs and ideas, you have prioritized them, but now the overriding question remains: “what do we do?

Identifying a friction point is one thing, addressing it is another. Do we just need to improve? Transform things in depth? What is the ideal target for the employee? For the other impacted people?

Sometimes the solution comes by itself

Sometimes the solution comes by itself and is obvious. A simple problem has a simple answer. It is in this case that idea boxes work best, but for the most complex things it is often necessary to go back from the problem perceived by the employee to the root causes and we find ourselves having to really design solutions, entire journeys.

I would just like to remind you that what we call ” journey ” and that some people spontaneously put in the box ” design and other lightnesses ” is another way of saying ” process “. These are two facets of the same reality: what employees experience and the way the company organizes itself to make it work. The debate is then about which one takes over the other.

In addition, this often involves taking into account the needs, constraints and possibly divergent interests of several types of populations.

Alone, one hits the wall…

Faced with so much complexity one may be tempted to go alone and think everything through in “top-down” mode. After all, with a few good brains at the top of the ladder you can easily solve all the problems at the bottom.

This is not specific to the employee experience, but since it is our focus, let’s take the opportunity to point out something that everyone should know if they don’t implement it: it doesn’t work.

The “top” can decide on the main axes, arbitrate at the level of the “what” (the problems to be addressed) but not at the level of the “how” (what will be implemented to solve it). And this for two obvious reasons:

  • The first is that what “falls from the sky” is generally not well accepted in terms of change management. The relays that you need to mobilize to implement and carry the change to the field will go backwards and the end user will refuse or bypass what is being proposed.

I’m the first to say that when you solve people’s problems and make their work easier, they generally accept it willingly, and this is generally true. But sometimes it doesn’t happen and more often than you think, for two reasons. Either the method doesn’t please (“people don’t hate change but the way you want them to change”) or the solution doesn’t suit them. This is precisely the second cause of failure.

  • The second is that the solution does not solve any problem. Sometimes I’ve had to talk to HR or people in the employee experience function about what they wanted to “transform what people experience in the field” and told me about a host of initiatives they were planning to roll out.

Now I have a question. How can one at the head office, in the upper layers of the company, envisage transform people’s daily lives, if we start from the principle that their daily life is to do their work.

Even with the best will in the world who really knows what customer advisors in a store, a project manager, a stewardess, an operator in a factory, an assistant really live and feel?

When I wanted to tackle the problem I had to really get into people’s daily lives to understand what they were really doing. Not just their job in a macro way but all their tasks, their flow of work. We had to map all the flows and processes to objectify what was happening and discuss it. And at that point you only have an objective and rational vision of things, which is not enough. You can objectively understand that things are not going well, but you don’t have the feeling of someone who experiences it day after day, month after month, year after year.

So thinking things alone or in a small committee above the ground and disconnected from the client doesn’t work.

…but together we do better…

The solution is known and widely implemented: involve the field and the various stakeholders who, I repeat, are not necessarily part of the population concerned. Change something in the field and you will have an impact on the support functions. You can say that this change may upset them, but often you will realize that the current situation does not suit them either. But without involving them it is impossible to know this and to convince them.

When we say “involving” not everyone understands the same thing. For some it is to inform, for others it is to listen, for others it is to collaborate.

Today what we see as the panacea is design thinking. For those unfamiliar with the approach, it is an approach to innovation and its management that is halfway between analytical and intuitive thinking. It is based on a co-creativity process involving feedback from the end user. The starting point is the understanding not only of the “customer’s” need but also of his feelings and even his context.

The literature on the subject is so abundant on companies that have been transformed through design thinking that I won’t go into detail on the subject. I will add that design thinking is at the basis of design sprint, a methodology that I like because it allows to solve organizational, managerial and operational challenges in a relatively agile and, most importantly, time-constrained way.

You can read for example how IBM has co-created its employee experience using design thinking.

In short, if you want to come up with solutions that really work, this is the approach to use.

But I didn’t take IBM as an example by chance. Some will see it as proof that it works in a very large company and on a large scale. I see it as proof that …. works in a very large company and on a large scale.

…but you need to have the resources to do so…

Not everyone is IBM, not everyone is a company with hundreds of thousands of employees. And even in a large company, sometimes you have to think things over a scope of a hundred or even a dozen employees.

This reminds me of an old debate on employee participation on enterprise social networks, which finally touches on a rather similar issue.

When there are 300,000 of you, you will always find the few people you need to create a dynamic, to participate. Because no matter the size of the final population addressed the size of the hard core does not change. When you have 5 or 10 hyper active people in a community it will work, no matter if the passive audience (those who read regularly or occasionally) is 100, 1,000, 10,000 or 100,000 people. Weren’t we used to say that these so-called community dynamics functioned on the 1-9-90 rule? 1% active contributors, 10% participants (who comment) and 90% passive audience who just read?

If you are on the scope of an SME or a small unit of a large company, it will be less easy to mobilize the 5 or 10 people needed than if you can draw from a pool of 100,000 people. The onboarding experience of a large company concerns everyone, whereas reviewing the operational experience of a team of 10 people concerns only the 10 people. When you know that mobilizing people on such a process is like taking them out of operations, it can seriously degrade the functioning of the company even for a short period of time.

Let’s face it: not everyone can afford the luxury of being able to put together a group of 10 people to lead a week-long design sprint!

This is for the “logistic” constraint. I will skip over the fact that not everyone wants to get involved or that some, disillusioned by all the promises made in the past and never kept, consider that they have better things to do.

Feedback is better than nothing

Many will therefore have to find some kind of middle way. I am not convinced that there is a magic recipe for this, but there is one that I have seen and made work.

The context: having to transform the operational employee experience (i.e. at the heart of the flow of work) of a globally overworked team, at the heart of the company’s business (i.e. every hour spent on something other than their work has an impact on the turnover), some of whom no longer believed in the company’s ability to transform and improve things for them.

There is no need to think about involving them strongly at the outset. On the other hand, having a discussion with everyone about ” what is preventing you from doing your job as well as you would like to do it ” is possible.

Then it was necessary on this basis to formalize and map their daily “journeys” and workflows. Normally if you are their manager this should not be a problem and if it is the case you should seriously think about changing jobs.

At first glance there are improvements and above all obvious simplifications to be found and you will certainly have picked up a good number of ideas, good or bad, during your interviews. It is therefore not complicated to propose a first draft of experiences (in other words, improved workflow).

It is at this point that one should not make the mistake mentioned at the beginning of this article, which is to want to continue alone. Thinking alone, ideally, after consulting is one thing, but it is moving immediately to execution is the real problem.

While it is not easy in some contexts to involve people in the design of the solution, they will readily respond to a first version of a solution you have designed. Why?

  • Because things become concrete and they see that it’s not an idea that won’t come to fruition.
  • Because if they have not been very involved in the elaboration of this proposal they know that they are a little responsible for it.
  • Because as it becomes concrete they know that they have a chance to give their opinion if the proposal does not seem relevant to them, that this may be the last opportunity and that if they don’t say anything they will be really responsible to see something happen that doesn’t suit them.

At this point you should achieve a level of involvement and participation that you would not otherwise have had. Without achieving what you would have in a true design thinking approach you can collect a lot of feedback that allows you to improve your proposal and move forward in successive iterations.

The downside is that it is up to you to do a lot of work with just feedback and not active and synchronous participation in the design, but it is better than nothing and that is the price you pay for making things happen.

But this has positive effects in the medium and long term. Once your teams have been proven by example, you will in the future have more and more spontaneous participation and more desire to do so even if for operational reasons you will not be able to mobilize them as much as you would like.

Then it’s the first step to get the team involved in a long-term continuous improvement process, which I’ll talk about later.

It’s about dosage

“Alone we go faster, together we go further” says the proverb. And I would add… “we do better”. But there are plenty of reasons that prevent us from going together or from doing it in a reasonable time and in these cases we must, even reluctantly, accept to go forward in degraded mode.

In an ideal world we conceive things together but sometimes we have to be content to make others react to what we have done alone, ideally after having consulted them. But under no circumstances one should do everything alone and put people in front of a finished result, which is valid for any change, by the way.

Head of Employee and Client Experience @Emakina / Former consulting director / Crossroads of people, business and technology / Speaker / Compulsive traveler
Head of Employee and Client Experience @Emakina / Former consulting director / Crossroads of people, business and technology / Speaker / Compulsive traveler

Recent Posts