news article background image
2016-06-27App features

Ruminations on The Development Process – Part 2

Collecting feedback. (Or, what goes wrong when you leave it to someone else)

In last month's post I wrote about why I think it’s important for me (and other developers) to know about the businesses and users that are going to use the product we develop. So, meeting clients and getting feedback via customer support are really useful sources of information for us. But what happens when we simply receive a request, with no opportunity to understand the user’s context? Let me guide you through some of my past experiences to give you an idea…

"Nice, but how do I print?" – Miscommunication and Preconception

When you ask users what they need in a product, they often leave things out. Because we all operate from within our own worldview, we take certain things for granted and have implicit expectations. The thing is, it’s not always obvious to us when our assumptions aren’t shared by those we’re speaking to.

If a user says:

"I want to be able to create documents that I can save"

The user probably takes for granted that a saved document can be printed and shared too. From a user perspective, why wouldn’t it? That’s how many other programs work.

And if a user says:

"I want this to be presented as a table"

There might be an expectation that it’s possible to sort the table, because that’s how it works in Excel. Not an unreasonable expectation, but an unspoken one, none the less.

"I want transparent charts" – Design by User

When working on another project many years ago as a consultant, we got a feature request from the product manager:

"Users want transparent backgrounds in charts"

This wasn’t difficult to implement, so we added it to the product. Great, we thought, and ticked it off our list. But then we got another request…

"The users are not happy with the transparent charts. They want to control the x and y axes too, so that they are perfectly identical in all charts. Please add the settings so that the users can control all aspects of the axes. This is a request from the head of market data working for this very important client."

I didn’t understand why this was important, or why it was mentioned in relation to transparent charts. So, I asked the program manager. He in turn asked the head of market data, who asked the users. A couple of weeks later I got the answer: they want to stack several charts on top of each other. No closer to understanding why someone would want to do that, I asked again. After another long delay I got the answer:

"The users want to combine lines and bars in the same chart."

Well why didn’t they just say so? We could easily have created a much better solution than stacking transparent charts! What had happened was that when users wanted to combine bars and lines, they tried to solve this by stacking charts. It didn’t work. But, since they thought it would be easy for us to make charts transparent, they asked for that, rather than describing what they really wanted to accomplish. This is very common. Many of the requests and the feedback we receive are for specific features and do not actually describe what problem the user is trying to solve.

The Error of Omission

Different people have different ideas about what makes a thing, that thing. To start with, developing software is quite abstract, open to a degree of freedom you don’t see when designing something like a car. Add to this the very human habit of leaving out bits of information that we take for granted. Then add people. Each with their own ideas about what makes a thing, that thing, all involved in passing messages and information back and forth, leaving out all the things that people took for granted and didn’t mention… Well! If it seems like it’s confusing to write about, try building it.

As I see it, when you talk to someone about a design or feature, you both build a mental model of what the result should be like. The difficult part is to synchronize those models. But, learning more about each other’s needs and experiences can often help.

The Moral of the Story

We, the developers, need to understand how you, the users, work in order to understand what you need. What’s even better is if we can learn about what you want to accomplish, and not only how you currently do things, or how you think they should be done. One way for us to learn is for us to come out of hiding, and meet you. That’s how really good products are created. Together.