Ask the right questions, listen carefully and make sure that you’re not hearing just what you want to hear..
OK, this example may be “ancient history”, but the lesson is still valid and the algorithm I created is still being used, 30 years later. And, well, it’s my favourite example, so humour me..
Background
I was consulting at the time for a large Canadian Bank. There are fewer banks in Canada than the US, but they tend to be bigger with millions of customers across the country. The timeframe was around 1990 and systems were mostly text based, like MS-DOS. GPS’s, the Internet, gobs of memory and graphics were uncommon or non-existent. (I know, prehistoric, but stay with me here..)
One day I was called into the VP’s office and he described the next problem he wanted me to solve. A team of about half a dozen people and their manager had been working on a graphics map system to solve a problem with their call centre. The call centre had a 1-800 number that customers could call into with their questions. The bulk of the questions were about finding their nearest ATM machine or bank branch.
The team had been developing a graphics system that could display parts of a map to help locate the branches and ATMs for about a year. I spoke with them and they appeared to be stuck on a few things.
- In trying to find “the closest” branch or ATM, they were stuck on finding an algorithm to sort the facilities by distance to the caller.
- They could only find machine readable map data for one city and we needed to do 30 cities.
They didn’t realize it at the time, but there were several other issues. I asked if anyone had been out to speak with the people at the call centre (which was in another city). Apparently not.
I travelled out to the call centre to ask questions. It was a huge auditorium with dozens of desks, phones and, maps tacked on to each wall. Push pins were used to locate branches and ATMs across the country. Sure enough, most of the calls coming in were about locating the facilities sending the agents to the maps on the walls to locate them.
A Failure to Communicate
The most important question I asked that day, was:
“When callers call in, do they usually have addresses of their location?”
“Almost never. They usually have either cross streets, like I’m at the corner of these two streets. Or, they will have a hotel name if they’re from out of town.”
This was critical, as the machine readable data that the team had used in building their system was based strictly on street addresses, only. Fatal Flaw.
Intersection of Intersections
After a few days of thinking about this, I had a meeting with the VP.
“I need a person who can do accurate data entry for about two weeks, and I’ll have a prototype system in a month.”
We bought 30 street maps for the cities we needed to cover. We built a database based on the street indexes found on each map, with the grid information that each street was located in. We also entered the grids that hotels were located in as well as the bank facilities.
The “intersections” that callers would call in with, were simply the “intersection set” of grids for the two cross streets.
The facility didn’t have to be the absolute closest to the caller. If there were several within reach, the agent could list them off and the caller could make the choice. Finally, we also built in a soundex algorithm to catch misspelled streets that the agent might type in. (eg. In Toronto, we have a “Yonge Street” that agents might type in as “Young Street”.)
Good algorithms can outlive their implementations. The solution was called “Brilliant!” by their chief architect at the time. While the code I wrote is almost certainly gone, their current implementation lives on their website and uses the same basic techniques (and pulls up a Google map of the area now).
Lessons Learned
Understandably, the developers at the time were excited about doing graphics programming. It was new technology and all the cool kids were doing it. They heard what they wanted to hear and didn’t ask the critical questions to solve the real problem.
Does this happen today? Unfortunately, yes. Tools teams building tools without asking critical questions about how they’ll be used. New technologies being adopted because they’re cool, rather than analyzing how they will really improve the business. Developers building features with only a vague understanding of how it will enhance the user experience are some examples.
Solving actual problems requires asking critical questions of the user community and listening. How will a proposed solution actually enhance the user experience?
Postscript
If you’re asked to design a “toaster”, don’t design a “breakfast cooker” unless it really would improve the user experience..