For All My Life I´ll Feel It:
Lack of Empathy Kills User Adoption
User adoption is the Holy Grail. Yet, it eludes you, and you don’t know why. Your software or app is brilliant. Everyone on your team says so. Management is over the moon. Months later, it’s basically an icon or tile sitting on a screen, ignored and idle. What happened?
Software delivery team managers, leaders, executives or [insert whatever title makes you happy] of this world, stop everything you’re doing right now, book a meeting with your team(s) and tell them this:
“Keep up the great work, guys! But remember: only 25% of what you build is really going to be used...”
Can you imagine their reaction?
The Painful Truth
The truth is that, for most development projects these days, this has indeed become a reality. When it comes down to software development for large organizations, you traditionally see layers upon layers of communication, documentation and processes being established. And these create a large detachment — a chasm, we’d say — between users and the solution they eventually receive.
It’s like a game of gossip, you know? Instead of going directly to the users to capture their true needs, you add unnecessary middlemen, who can unwittingly spoil the message.
The thing is, we should really be all about maximizing efficiency and minimizing waste. And this process just seems to add a lot of waste. Lots of effort, money, and even creativity end up being lost in translation.
A Little Bit of Context Never Hurt Anyone
During my first decade working in IT, I was very proud of the solutions I was responsible for, in many capacities: as a developer, a business analyst and a project manager. Had I known then that only a fraction of it made a real difference — that 25% — I might not have been as motivated and driven as I was. I did it because I thought I was really helping users.
After some years in the business, I eventually started meeting product owners who had not seen, met or had any kind of interaction whatsoever with the users they were building solutions for. How crazy is that?
This is an issue agile software development tries to address. However, in my experience, many organizations still fail at it because they just do not involve users directly. And unless delivery teams get the chance to meet real users, they will still be unable to relate to their pains. As a result, they stray from using the applications that have been provided to them. And away goes user adoption.
Feelings, Nothing More than Feelings
If you don’t understand, if you don’t feel the problem at its roots, how can you really solve it? Direct interaction with users helps uncover hidden assumptions. It also unveils the overall big picture and specific context, as well as all the pains and gains related to how their actions impact the business.
Sometimes the problem at hand doesn’t even require a complex solution. And that would have been quickly understood if the right people had gotten to interact with the users. Yet, we form layers of communication channels to capture the users’ needs, their wants and requirements. We pass them through multiple teams, until they reach the delivery team — convoluting and diluting the real needs.
Some organizations use the excuse that their users are too busy to provide input… to something that would just make their lives better. Where have I heard that one before?... Oh, right.
Delivery partners and their teams are often an afterthought. They’re handed over deliverables — in the form of requirements or user stories — and are tasked with crafting state of the art software solutions, with the latest and greatest tech available. With little to no context.
Jeff Gothelf and Josh Seiden mentioned this problem in their Lean UX book:
Empathy is the Name of the User Adoption Game
In the last decade or so, by embracing a lean software development approach, UX (User eXperience) and modern business analysis skills, in conjunction with working side by side with users, I learned a lot about user adoption. It all starts with empathy.
"Empathy is the ability to understand and share the feelings of another."
We need to empathize with users, really walk in their shoes. Ask yourselves: how can a person, sitting in all alone in a cubicle understand the needs of users without having done what the users do? How can someone on a delivery team truly understand the needs of a bio-technician, of a warehouse worker, a sales representative, if they’ve never been exposed to that particular work environment?
Empathy is a trait that everyone building software needs to acquire and nurture. Some people are naturals, others need to work that muscle. Understanding users and what they really want (or need) is laborious. But so worth it. Only by making use of empathy can we create better software that users will want—love!—to use. That’s the secret sauce for a higher user adoption rate, right there.
User Adoption Make or Break—Story Time
One of my projects was about providing a sales team convenient access to their data in a format that was easy to use. Our customer had decided to relinquish a commercial off-the-shelf (COTS) product. Using and configuring it had become cumbersome.
During initial discussions while we were gathering context, their leadership told us they wanted a custom solution, specifically tailored to their users’ needs. But, they didn’t think it was important for us to meet and get to know their users. After a lot of convincing, we finally got to talk to users directly. After our UX team did their research and analysis, the same leadership that initially blocked access to users was extremely surprised with our findings:
- Sales reps were not all using the COTS product and absolutely hated it.
- Of those who didn’t use it, most used their own spreadsheets instead to keep track of their numbers.
- There were many different versions of the spreadsheets.
- These reps spent countless hours creating and maintaining these silos of data and coordinating them with other teams — and were mired in data reporting issues.
Once we shared this research with the customer’s leadership, there was a clear and immediate change in their attitude and approach.
Fast-forward one year. When I checked in with the IT management, they were beaming with joy. Their solution had a fantastic user adoption rate. News of how simple the solution was to use had spread throughout the company. Even better, the application had become one of the most successful deliveries in company history.
Sometimes Users Themselves Don’t Know What They Want!
Throughout the years I gathered many more examples of success when users were involved, and of failure when real users were just an afterthought. To be fair, though, I need to add that users don’t always make it easy. They can think they need something when they really just want it. In other words, they might believe a “nice to have” is an imperative. Or, they might not even know what can help them.
That’s why you can’t stop looking for context after the initial discussions are over. Research is an art. Exploring what users think they want, and learning what they really need is a craft. (So much so that a few companies now have user research departments. Learn more about Mozilla's user research in this podcast.) Skillfully drawing out assumptions and validating—or invalidating—them using multiple tools, is something that needs to happen throughout the delivery.
With the experience I’ve acquired, there are few questions that keep popping up in my mind:
- Am I really understanding the problem at hand?
- Does the proposed solution solve the issue?
- Am I taking the information at face value or am I challenging and improving processes, enhancing the experience while never forgetting the importance of user feedback?
- How does this solution impact the daily lives of users? How will it ultimately affect the business?
Rules of Engagement
In the end, remember that business is engaging with delivery partners to solve a business problem. Business is operated by users, so involve them as early and often as possible. So, next time you hear that you’ll have to “work it out without involving the users directly,” make sure you fight for access to them.
I hope I’ve inspired you to start that conversation. It’s never too late to make your stance on why direct user involvement is not just necessary but also beneficial in the long term.
If you need help getting the discussion started or you have a user adoption story (good or bad) to share, let me know. You can find me on Twitter at @Bendre.
