Designing for the employee experience
I often say I’ve always worked on employee experience, albeit not always intentionally.
My work history looks like most people’s — I started in a bunch of admin jobs, answering calls, filing and organising things for an office. I then moved to a one-man-band marketing company, worked in a few universities, did a few medium/large businesses and after that, I was freelance for a bit. I now work at booking.com where I actually work in an employee experience team.
All throughout these different roles I’ve been either working directly on actual employee experience projects or improving internal processes whilst working on other projects. I’ve also been listening to people talk about their own experiences.
As someone who is obsessed with solving user problems, I’ve been gathering these things up and trying to solve them, which has lead to the thoughts in this talk on solving employee experience problems and how to design for this experience.
Why is employee experience even important?
Throughout all of this experience I’ve found a lot of similar problems within the employee experience and wherever there are, these issues stem from one key problem:
I’m not saying this is every case, I’m lucky enough at the moment to work in a company that cares about its employees, but in a lot of places, employers just don’t give the same level of care and thought to the employee experience as they do the customer/user/partner experience.
Richard Branson sums up why employee experience matters in a nutshell. If employee experience was a higher priority for companies, employees would be motivated and empowered to make a difference for their company and the company and its customers.
It’s just good business.
Besides the fact that it is the right thing to do, there is also a cost of not improving employee experience:
The time cost — a summary of time lost per day
- Trying to contact people is the biggest time waster — if we had an easier way to find people’s details and their availability, perhaps this number could go down.
- Trying to find key information is also really high — I’m sure all of us here have spent time searching for policies or processes in some kind of wiki only to come up empty.
- Duplicating of communications is at nearly 40 minutes per day.
- “Attempting” to schedule meetings, not just booking them, wastes 33 minutes a day.
Imagine if companies approached employee problems the same way they approach customer problems. For example, if we take on the meeting booking problem from above, imagine if we could cut the time from 33 minutes to 3 minutes. That would save a person 30 minutes every day, simply by designing a system that books meetings more easily.
And if we don’t solve some of these problems, we can cause a fair amount of stress through time loss and frustration.
The monetary cost
- Stress is known to causes accidents and turnover and every time someone is replaced it costs approximately 20% of that person’s salary to sort the replacement
- Even if it’s not causing that much stress, frustrations and that feeling the you’re not cared about can cause disengagement and that causes:
- 37% higher absenteeism, 49% more accidents, 60% more errors and defects, 18% lower productivity, 16% lower profitability, 37% lower job growth, and 65% lower share price over time
Taken from: https://hbr.org/2015/12/proof-that-positive-work-cultures-are-more-productive
Things to consider when designing in this area
Positive work culture
To avoid all these costs (money, time, and effort) we have to create a positive employee experience. However, doing this is actually very complex as it doesn’t just involve the tools used, but also the employee interactions and the physical environment.
IBM did some great research on the 3 main areas that affect the employee experience and named these ‘spheres’ the social, work, and physical spheres. These all have to be taken into account when designing employee experience.
When you design a new UI for an employee, these things have to be considered (amongst others), in order to see the full journey of your users.
For example, if we attempt to solve the problems around booking meetings, it might not be enough to just improve the interface that’s used to do the booking itself, but you need to consider the physical and social factors as well.
Things such as these may influence your design decisions:
- How do people normally contact each other?
- How are the rooms set up?
- Are there remote employees that you need to account for?
As well as these spheres, there is also the aspect of HR to consider as you go.
HR principles are just as important as your design principles.
Another aspect of designing employee experiences that can get complex is the merging of HR and product.
HR employees are experts in these fields and what they do is often based on years of research and testing from seriously academic firms or consultants.
This means that without involving them, you cannot design a full experience that benefits employees. Let’s go back to our meeting room problem for an example:
If we asked all employees what they want from their meeting booking system, they would probably want it to be quick and easy to use. For example, there may be too many fields in the booking form and employees want to remove a required agenda field.
But what if HR research has found that without an agenda, meetings aren’t as productive. Would we still remove the mandatory field?
Not only are they experts in the field but they also know policies. If your design work affects HR processes in any way, there are people that must be consulted first, the changes must be signed-off on, and there has to be a change management process in place to let employees know what is happening and why.
Also, HR employees have been listening to your users for years, finding out themselves what the big problems are and attempting to fix them. They understand employee problems and motivations all day long just by doing their jobs and this can be very useful to you.
Employee motivation is different to user motivation
One of the key differences between designing for employees or customers is that their motivation to use a tool is very different by nature.
When we design things like apps or websites, we’re often designing a product that may or may not be used.
In the case of an app for example, it has to be useful or cool or beautiful or fun, in order to entice people to use it. For example one of the most successful mobile games is Clash of Clans. I play this, a lot.
But I don’t have to play this, it’s not part of my day-to-day needs, it doesn’t help me make breakfast or get dressed, I play it because it’s fun and as a user of this app, this is my motivation.
But at work, there are things I need to do. I need to book meetings, I need to book a room with the right equipment, I need to invite people. I need to be able to log on to that system with little, or preferably no effort.
So when we design in this space, it’s often first and foremost about the base functionality of the taste, more than fun, coolness, or edginess. We probably cannot improve the time it takes to book a meeting just by making the UI nicer for example.
So our mindset has to change a little.
Let’s say in our meeting booking tool there is currently low engagement, people used to come to the site but now they come less and less. Someone from a marketing background may come up with an idea to gamify this process for example. Maybe add points for meetings booked and attended, make it more fun, give it a refresh so the numbers go up, but this may not have any effect.
Research is paramount in creating a successful product. No matter the problem.
Special thanks to Miranda Slayter for articulating the above so well for me
Finding out the real reason for the low engagement is really key to understanding how to solve it.
User research is one of those things that companies often knock off the project plan first because you can’t see the value in it until you’ve done it.
But user research, as the UXers reading this will know already, is so key to a product. In our previous example, knowing the reason for low engagement may have made us come up with a whole different idea of how to fix it.
For example, could it be low engagement has nothing to do with the tool itself but the physical aspect of the process? It could be that whenever I go on to book a room, every meeting room is booked and so I just never check anymore. In that case, it’s a physical problem rather than a UI one and solving for this becomes very different.
Also, if this is a global system, how do you know that the problem in your office is the same in other offices? Again, this is that physical and social overlap that occurs whenever you start to look at these things.
This brings me to my next thought:
The audience is damn broad.
Most of the time when we design a website or an app, there’s a key audience in mind. They have certain behaviours and skills that you design for, such as a level of technical knowledge, age range, or interest in the topic.
Employee experience is a little different to this, especially in bigger organisations, as you get different kinds of people across departments. As an example, I was involved in an intranet project once where the main problem was that staff members couldn’t find information (especially key policies) very easily. To fix this we made a new private site, rewrote and reordered the content, and created a better user flow. But we had to consider along the way, things like the level of technical skill, accessibility and even the UX of page content, to cater for more audiences. As we worked on the designs, the amount of different feedback that we got was astonishing. The more we tweaked and researched, the more we found that each department had different types of skills, traits, and personalities that needed mapping out and taking into account.
Two things that we had to re-design for was a varied level of technical skill and colour-blind employees. If we’d have made everything easy to find but designed a UI that needed technical awareness from its users (such as a fancy menu system or filtering and search) it’s possible that not everyone would have been able to use it. If we’d have designed a red and green system of colours, we’d have alienated those employees that were colourblind. Essentially with employee experience you cannot ignore edge cases because you put them at a disadvantage that affects their work, which affects their lives.
Not only are there different types of users there are also different stages of employment (such as on-boarding or exiting) and different layers of management that need different information, access, and tools.
Let’s say we’re building a simple dashboard for an employee’s performance — in this tool an individual employee would want to know their contribution and therefore rewards. If that individual becomes a manager they then need to continue to know their own performance data, but also the data for each one of their direct reports. As you go even higher up, say to a department head, your own performance is often intrinsically linked to the performance of the teams that you oversee and not necessarily the individual performance of each person in the department.
This makes this seemingly simple interface, turn into a complex web of different needs — and so mapping out these differences is so important.
One more point on audience — don’t forget that you too, are the audience.
Unconscious bias is where your own experiences and viewpoints influence how you design things.
For example, in my case I might design my new meeting tool based on the fact that I know where most rooms are, I work in the office and so do my colleagues and I have no accessibility needs. Again, this is down to doing the right research and mapping out the types of users you need to design for.
Measuring success in this area
How do even work out whether what you did was good when we can’t look directly at revenue.
I think generally speaking this is really the same as any user experience problem — you can go macro, so this could be app downloads for an app, signups for a blog, and for employee experience, depending on the project, this could be things like turnover, productivity or employee engagement and satisfaction over time (although this takes a long time to see!).
And you can go micro level in the same ways as you would with most digital products- how many clicks, where do people scroll to, where do people turn back etc.
But what we also need to look at the product’s social, cultural and physical counterparts.
I wrote at the beginning of this talk about the effects of badly designed employee experiences and this is where I’d start to look at the detailed metrics we might need.
The key is to really understand what problem you’re trying to solve (including these other aspects) and try to embed design and product principles into the process of fixing those problems.
Often in traditional departments such as HR, product development is mostly — we need a new tool, we get companies to bid on it and we pick the best value one. But often these processes miss the assessment of what the problem really is, why its happening and thinking of that problem like a product. Doing all this really enables us to figure out the data points of a problem and make sure they improve as we do work to solve it.
For example, earlier we talked about the meeting room tool having low engagement. If we understand that the problem of low engagement is caused by the fact that meeting rooms are always booked and so people aren’t visiting the tool then, when we come to solve the problem, we know which metrics to look at — we look at engagement as before and we can track other things like cancelled rooms, empty rooms, or even people having meetings, not in rooms.
By understanding the problem well enough we can find data points so that we keep track of progress in more detail.
Thoughts for the future
My hope for the future would be that we do give the same attention and money to employee experience as we do to customer-facing systems. I’ve described in the list above, what the basis of a good (digital) user experience might look like, but the things on this list are standard for most system designs. It’s the basics we would give to an app we’re selling.
I’m looking forward to the time where every company sees how important this is, and contributes to improving it.
This post was a talk that was originally given at UXify in Bulgaria — http://uxify.net/eu/
I’m available for speaking — get in touch!
