Internal tool adoption

22/11/2021
22/11/2021 Andreas

Internal tool adoption

My firsthand experiences

Photo by iMattSmart on Unsplash

You’ve worked hard and you’ve finally reached the goal: going to production with a new system that transforms the way how a whole department operates plus provides a better customer experience for your customers. You are nervous, but with a great team around you ensuring and testing that everything works perfect – you can be relatively confident that there’s no need to be overly worried. It’s however the moment that the project have been building up for. Sometimes maybe for a long time. For me, it was over 2 years!

So we went live with a new system, and apart from the initial shock for introducing a completely new tool for employees everything went pretty well! This was my first massive internal tool project that I was designing from scratch, so it was super exciting! What were the concerns I faced when closing in on the publish date? First and foremost, UX designer wants to  know how the product is received:

What’s the impact?

Employees were provided training in advance, but as they were practicing in the test environment, they didn’t see the full benefits of the tool yet. They may have experienced it as an distractive little training they need to do aside their real work (with their old tools). Once they had to migrate to the new tool, there was an initial panic reaction but it settled very fast. The core product and flow worked well and there were only minor tweaks that had to be done. We fixed all those, and people genuinely started to enjoy using the tool and once this tipping point was achieved, there was no going back! Some adapted it faster than others, but in the end I’m very happy about the adoption! Everything went relatively well because we had end-users representing the department from beginning till the end. And of course the groundwork and technical work was exceptional. Perfect!

How does it perform?

Naturally, it’s also very important to survey new data pouring from the system and see how it performs. These are the metrics the management likes to follow and see reports of. Raw quantitative data is useful and provides concrete results of the performance. Absolutely critical!

The human factor

In addition to quantitative data, it is important to conduct in-depth interviews with the end-users after the dust has settled and the tool has been adopted.

There were some other surprises in the way, since this was a first tool I’ve been designing. We tried to cover every single what-if situation and blind corner during design and development, but there are always aspects that you cannot predict or forecast. Neither are they necessarily even plausible to be baked in to the product. What I’m talking about are the organic needs that the tool or service produces, and how they are being tackled in a human level rather than in a system level. For instance, our users developed a new way of managing their workload while they were preparing to go for their holiday. The system provided a way for this to adjust your personal WIP-limit, but I didn’t take this into consideration that the function would be used for a “soft transition” to holidays. Awesome, unexpected use case!

Also while an employee is away, they need to assign a collegue to take over their on-going / pending work. The team also found a way to organize this among themselves – although I as a UX designer could see this as a nice-to-have feature in the system UI itself.

It was such an intriguing experience to witness the team organizing organically around new ways of working. This was definitely the most fascinating aspect and took me by surprise! People can be creative once you give them tools that are flexible enough!

, , ,