Published originally on medium on June 12, 2017
If you lead any software delivery team as an executive, manager, leader, or whatever title makes you happy, take a moment to meet your delivery teams and tell them this: “..keep up your work, just remember that whatever you are building, only 25% of it is going to be really used…”
What do you think their reaction will be? In today’s enterprises, it’s a reality. There is a lot of waste: of effort, money, and creativity.
Especially in large organizations where we have:
- Removed the involvement of users who really need help to solve their problems
- Added layers of communication, documentation, and processes to capture their needs, that in turn are handed over to somebody else developing the solution (with little to no context of the problem)
During my first decade in IT, I was very proud of the software solutions I was responsible for: as a developer, business analyst, and project manager. Had I known only a fraction of it made any real difference, it would certainly not have helped my motivation. I have met product owners who have NOT seen, met, or had any interaction with the users they are building the solutions for.
Agile software development tries to address the gap, but, in my experience, many organizations fail at it because there is no direct user involvement. Unless the delivery teams meet the real users, they cannot relate to what problem the users are facing. If you don’t understand the problem, how can you solve it? Direct interaction with users helps uncovers hidden assumptions, provides the overall big picture and specific context, pains, gains of how their actions impact the business.
At times, the problem doesn’t even need something to be done by the software! Yet, we form layers of communication channels to capture users’ needs, wants, and requirements and pass them through multiple teams until it reaches the delivery team — convoluting and diluting the real needs. Some enterprises provide the excuse that their users are too busy to provide inputs to the new effort to make their lives better. (Where have I heard about it…Oh, wait!)
Delivery partner(s) and their teams are often brought in as an afterthought and are handed over deliverables (requirements or user stories) to craft the state of the art software solution with the latest and most remarkable technologies.
Jeff and Josh mentioned this problem in their book Lean UX.
In the recent decade, using more and more of lean software development approach, UX (User eXperience), and modern business analysis skills, in conjunction with working side by side with users, taught me a lot.
It starts with empathy.
Empathy is the ability to understand and share the feelings of another.
We need to empathize with the users, be in their shoes. Ask yourselves how a person sitting in a cubicle, who has never been a part of the domain in question, can understand the needs of a user (Example: a bio-technician, a warehouse worker, salesperson, etc.) who is using the software in a particular environment?
Empathy is a life skill that everyone in software needs to acquire. Some people are naturally skilled and, others need to work at it. Understanding users and what they want is a laborious and challenging skill, but one worth acquiring. Only by empathy can we create better software that has a higher user adoption rate.
One of my projects was about providing an on the ground sales team access to their data in a convenient format that they could easily update. The customer decided to move off a commercial off the shelf (COTS) product as it was too cumbersome to use and configure. During the initial discussions of the project, we were told by the customer leadership that they wanted to have a custom-built solution to tailor to their user’s needs.
The challenge was that they did not think it was important for us (the delivery team) to get to know the users. It took a lot of convincing of the immediate leadership to get us access to users. Once our (User eXperience) UX team did their research and analysis, the same leaders were surprised to find things that they were completely unaware of:
- The sales reps were not at all using the COTS product and hated it.
- They instead created shadow excel spreadsheets to help themselves track their numbers.
- Each group and every person had their own different versions of it.
- These reps spent a lot of time creating and maintaining this data, spent time coordinating with other teams, and still had data reporting issues.
Once this detailed research was shared with the customer leadership, we saw an immediate change in their attitude and approach. A year after delivering the solution, when I checked in with the IT management we were interfacing with, they were beaming with joy and shared that the offered solution had a very high adoption rate. The simplicity and usability of the solution had spread throughout the company, and that application is one of the most successful deliveries in their company history.
I can cite more examples of success when users were involved early on and failed projects where users were an afterthought. Sometimes the user themselves don’t know what they want!
It is an iterative process, an art to research and explore what the users want. A method of skillfully drawing out assumptions and validating (or invalidating) them using multiple tools in your pocket — continuously throughout the delivery.
In my experience, when we focus on the following:
- Do we really understand the problem?
- Does the proposed solution solve the issue?
- Just don’t take the information at its face value: Challenge and improve their processes and enhance the experience.
- What impact does it have on their lives (and, in turn, the business they represent)?
In the end, remember that business is engaging with delivery partners to solve a business problem. The users operate the business, involve them as early and often as possible.
So next time when you hear in your enterprise projects that “..we will have to work without involving the users directly..”, I hope you will challenge that stance and help initiate the dialogue about why user involvement and input is necessary, beneficial, and economical in the long term.
