Building Software with Empathy
The team has been working for months, QA has tested everything, all your unit and integration tests have passed, and now it is time to put your application into production and take a well-deserved victory lap.
Instead, in the first few days, you hear complaints from customers that “the application is not working,” and “it’s slow.” The usage statistics reflect that a lot of customers are reaching the site, but are quickly dropping off. You start asking yourself questions such as “What was missed” and “How can I put myself in and replicate the customer’s situation?”
Some questions I utilize to assist in thinking about how I can empathize with the customer include:
How well do I know my target audience and how technical can I expect them to be?
What form factor are my customers using?
What kind of internet connection can I expect customers to have?
Where are customers in relation to where my application is hosted?
What type of decisions are customers most likely going to need to make?
What are some likely accessibility considerations of my target audience?
As a map of Azure data centers illustrates, internet access is available all over the world, with some regions having better service than others. This map reminds me that there is a lot of cable between me and my customers that I cannot control and have to share with many other potential global users.
As I build software, I try to put myself in the mindset of a customer. What are they trying to do, and what are their assumptions? I almost never fully succeed, and this is when I reach out to others, preferably on a different team, be it in a tech, CX research or UI/UX team. Just asking a developer from a different team to use my product may expose good feedback, and if you can walk into the office of a non-developer and ask them for 30-60 minutes of feedback based on best practices or customer insight, the results are often invaluable.
Another technique that I like to use to understand customers is to try and simulate a low bandwidth connection. I am always surprised at the number of people whose ISP’s do not provide reliable service in more rural settings. Cutting down the available bandwidth on my connection to 4G, or even 3G, can reveal customer experience insights. Two such insights I have encountered are that my app is too chatty or is moving much more data than is needed. If you have geographically dispersed team members, their experiences may be helpful in considering your customers’ connectivity circumstances. Listen to their concerns, and act on those as if they were end customers.
And, for those of you building software with regulated accessibility requirements, consider employing an accessibility expert, and consider turning on the accessibility settings of your OS. You may even have an old PC laying around, maybe with an out of support OS, which you can leverage to extend your testing. Although your IT department may restrict access on the network to specific specifications, if a specific profile is representative of a sizable portion of your customer base, I have found IT is generally receptive if you will work with them, perhaps suggesting a DMZ somewhere so that legacy system cannot impact the corporate network. Beyond these techniques, there are also reader tools to assist those with visual impairment to read the contents of a web site.
There are a lot of tools and techniques for improving web applications, and this blog explores several ways to empathize with your customers. As a matter of practice, I try to put myself in the customer’s position and draw upon my experience supporting the products I have built to assist in creating better software and customer experiences.