We spent our rather intense day getting to grips with the role of empathy in our work as designers, developers and decision-makers. One insight stood out clearly: the importance of listening and the compelling need to apply listening really well. Since the training I have been practicing, keeping my eyes open in my own work for places where empathy is lacking.
Before giving you an example, I must emphasize that Indi’s course tackled Practical Empathy. By this, she meant a cognitive practice which is repeatable, reliable and purposeful. I found nothing fluffy or imprecise in the work. We focused as clearly as we could on understanding the thoughts and needs of others in order to do our work better.
Hearing different needs
Just a few days ago I encountered a great example with an IT team struggling to deliver an executive dashboard. Their traditional process of gathering requirements had resulted in a huge document, detailing dozens of KPIs and numerous charts they would have to implement. The prototype pulled data from over sixty tables and had twenty tabs. Performance was fine - QlikView is good at this stuff - and, as Miss Jean Brodie said “For those who like that sort of thing, that is the sort of thing they like.” IT liked it, the users not so much.
For a start, who can easily navigate a dashboard of twenty tabs? Developers proposed to add a contents page, with buttons and selections enabling a user to choose their area of interest and a time period: they might then see only the relevant tabs and data.
At this point, I met with the team in the course of some other business. We took the opportunity to look at the work in hand. Quickly, I noticed that while they had taken down many requirements from their internal clients they had not deeply listened to user needs. IT had great information about the data users wanted to see, but very little idea about why they wanted to see it.
For example, one tab focused on Sales Team Performance. One could see top and bottom performers by revenue, margin and number of sales, tracking sales performance over time and with data on incentives earned. The developers were particularly pleased with this tab which delivered so much information on one screen: it served many purposes and was only to be developed and maintained in one place. In other words, the dashboard delivered the necessary information, and made life easier for IT. They were baffled why users were not happier with the result.
However, while the dashboard served many purposes, it showed no good understanding or empathy for any one purpose. For example, although developers knew that users look at products sold by profit margin, they had little sense of why they should do so. Was the VP of Sales comparing those who put effort into selling difficult high-margin products, with those making easy sales at lower margins? Or was the CFO looking to find ways of improving margins?
As we talked through such scenarios I learned that the IT team did in fact know about them, but regarded the cumulative problems of covering all scenarios as too complex to handle: easier to skip the details of users’ needs and focus on the data as a more-or-less abstract information problem.