Achieving user adoption is a challenge that is as unique as the people that make up an organization. There is no exact recipe for it, and no bulleted list you can follow to get there. The reality is, whether you’re switching over to a shiny new tool or revamping an entire process, human beings have a tendency to be resistant to change.
This can make addressing user adoption quite tricky.
At Adore Me, this was one of my most interesting and time-consuming challenges. While I learned a lot of things the hard way, the road to user adoption was also filled with lots of learnings and truly awesome moments. Below are some of the strategies and tactics that worked best for us at Adore Me.
Before Looker, our business intelligence solution was an old platform of manual reports and rogue files. It was a typical breadline model, where I was the provider of SQL-generated reports day in and day out. It was taxing, frustrating, repetitive, and cost me many evenings working after hours to provide data reports for people that had no other way of getting them.
I was first introduced to Looker an hour before a meeting where I was supposed to teach someone else how to use the platform. As a developer, that “not knowing” part of being handed the keys to something so brand new was terrifying. To my pleasant surprise, Looker proved to be much easier than I expected and opened up a world of possibilities for me. I was able to set up all the models and tables without issue, until I hit a problem I hadn’t anticipated — everyone was reluctant to use it.
As time went on, I gradually shifted away from the “developer” mindset of using a BI tool and opened my eyes to the end-business user perspective. By doing this, I learned a few key lessons as we worked on our user adoption strategy, with some of the most important takeaways being to:
Everyone wants to use a reporting tool because it’s easy. However, if you’re a developer, you don’t specifically need it. But without a reporting tool, business users don’t have any other choice than to constantly ask for the data. Considering the differences in everyone's data-related needs is important when aiming for increased user adoption across the organization.
Data, in general, needs to be connected in order to be valuable and actionable. Think about it — you can’t get insights from simply looking at a list of emails. Instead, people want to be able to answer specific questions from well-connected data, such as “Did the customer like their purchase?” and “Did anyone have a bad experience?” If people can answer questions like these right away and from one central location, there’s a greater chance they’ll stay focused and engaged with the data, rather than losing interest and never coming back to the platform.
The automatic view creator is a grand thing to have, but when it comes to the user experience, don’t put too much faith in it. When creating a model, less really is more!
Keep in mind that what you’re doing is in fact frontend work and it needs to have a flow and make sense, especially for a non-experienced user. The fewer decisions people have to pick from when choosing an area to start exploring, the better.
Within explores, if people are seeing all of the data right away during their first exploring experience, it can get overwhelming really fast. While providing numerous choices and anticipating the potential needs of explorers is great, showing too much too early may discourage them from continued and consistent data exploration later on. It’s better to start small, expose less data, and let people request it as they get comfortable exploring on their own.
For someone that knows the data, it’s easy to know which of the fields you’ll need in order to get the information you’re after. But for someone who doesn’t know the data, they’re most likely going to choose the first option that pops up in the search for a respective field.
Will it be the best one for them to use based on the information they’re looking for? Maybe, but probably not.
When modeling your data into views and explores, it’s best to model it around answering business questions rather than SQL results. Although it might be the work of a brilliant SQL generator behind the scenes, if you want your instance to be successful and useable by everyone, you need to design it based on your business model, and not your physical one.
Whether you're transitioning out of a similar tool or introducing a completely new platform, you're asking people to learn something new. And since people learn at different rates and in different ways, some may take some longer than others to get settled in and used to the change.
When considering the learning curve, keep in mind that it’s not just about learning a new app, but also about learning how to use a completely different method of thinking. For us at Adore Me, Looker meant learning for the first time how data is connected and how it works. We had to learn how to design data experiences instead of just adding fields and filters, which, in Looker, is the easiest part.
Oftentimes tutorials, videos, and general user-trainings are the most common ways to help alleviate the pains of a new learning curve. However, you should be prepared if these methods don’t completely solve this for everyone at your organization.
I encourage you to find the sweet spot of training that lies between the knowledge that appeals to users and demonstrating this knowledge with a concept they’ll understand. One way to do this — specifically for an eCommerce use case — is to show how to calculate revenue. By using common concepts people are already familiar with, trainings are more likely to stick with users and be remembered as they continue to learn.
And if you’re like us at Adore Me, as you ramp up your training programs, make sure to reach out to the people at Looker. They will be more than happy to provide you with materials you’ll need to train users yourself.
Whenever you transition to a new platform, there will always be the issue of how much trust people will put in this “new data.” While it’s not actually new, until users get to test the water for themselves, they won’t be inclined to believe you telling them that the water isn’t deep, because you already know how to swim, and they don’t.
Remember, you’re working with people, not computers. Sit down with them, let them tell you their concerns, and if they point out inconsistencies, remember that they’re not pointing at you, they just want to make it better.
Another way to get people to trust the platform and the data is to let them know what goes on behind the curtain. Strive to be as honest as you can about the issues you find and address along the way. If you just fixed a join, let others know! It may cascade into hundreds of reports, and if you share that knowledge, you’re giving people a chance to understand the subtleties of the behind-the-scenes fixes that affect their day-to-day work.
In addition to transparency, bringing in users early on in the implementation process to ask for their help and feedback is a great way to build trust. Not only will they feel that their ideas and needs are being heard, but if they’re helping you throughout the process, they’re more likely to trust the final product that you give them.
At the end of the day, it’s important to realize increasing adoption doesn’t mean developers vs. business users, because you’re both trying to do the very best job you can.
Regardless of whether you’re building off your company's existing culture or setting the stage for a new data-driven era, increasing adoption of a platform everyone can collaborate on will result in a lot less friction as you move forward together.