What they ask, what they want

One of the saddest things I have heard/experienced in my years working in software is when a software team gets an RFP (i.e., request for proposals) from a client that asks for a specific project developed with a certain set of features. The product team sequesters itself for a couple of months, builds the software, tests it to make sure it works reliably. Then, for the big reveal, the client callously admits that what the team created was not really what they had in mind. But…. you literally asked… for just that. Worse yet, they go with a competitor that fit what they were seeking for one reason or another instead.

My, my.

This is an unfortunately reality that happens all too often in software design. It shows the disconnect that has existed for years between software development and the client experience. We’re still talking about innovation, but it’s an innovation in process. It’s about listening to the meaning behind the request. So, I’m hearing you, please stop yelling, yes I can hear you. It’s very easy for me to stand in my house, which happens to be glass, and throw stones at the development process of some good software design teams.

This is not a problem with the people doing the design of the software. It’s simply a matter of trying to understand why. It’s about digging a little deeper. As opposed to accepting the problem as given and figuring out how to solve it, it’s figuring out what the problem is in the first place. Why was this request made? What situation surrounds the way this request will be utilized? Who are the people who will need this?

Elephant and the blind men aka don’t tell me what I’m touchin’

There is this classic story about some number of blind men (I’ve heard it with different numbers in different tellings) trying to describe an elephant to each other. Being blind, they use their sense of touch to feel around some localized areas of the massive elephant, who’s being a great sport by the way. As they feel the elephant, they describe what they are touching to the other blind men. One man touches the trunk and calls it a snake, the other the tail and calls it a rope, yet another the tusk and calls it a spear, and so on. They cannot believe what each of the other men are telling them.

blind_monks_examining_an_elephant
Courtesy of Wikipedia. For the full story, visit this page.

So, here’s the moral. When all we’re allowed to see is part of the picture, we’re going to misunderstand the problem. It also makes it a lot harder to believe others who have different perspectives. This is one of the reasons being an innovator is so hard. You’re arguing against people who have been looking at elephants from the ass-end, most likely. It can be lonely.

So, now we can see 2 problems emerging. One is expanding one’s own horizons and realizing the larger problem at hand. Secondly, we need to communicate this new perspective to everyone else. Both of these are topics I’d love to explore in later posts. For now, let’s say if you want to understand what you are doing, you really understand the context and the bigger picture first. (Or don’t agree with me, that’s your prerogative).

Is that my job?

I personally learned my lessons about digging deeper at the school of hard knocks. I started my career in software as a developer. I started an internship with Sony’s facility in Mt. Pleasant, PA. It was actually an awesome opportunity. I, as the developer, was given full control over a small internal project including requirements gathering, sitting and speaking with the end users, developing, testing for quality, and getting feedback on the end product (well at least that’s what I learned as I went).

Nearing the end of my internship and once I had completed this application, my boss comes up to my cubicle and we have the following conversation.

Boss: Hi Will
Me: Hey
Boss: So your project went live today.
Me: Yep, it’s pretty cool.
Boss: So…did you see no one used it?
Me: I didn’t know that I was supposed to make sure they did.

At the time, I thought it was ridiculous I was being asked about this. I was still a green computer scientist. We never talked about how the software was going to be used or why in any courses I took. We really didn’t acknowledge that the software needs to be used at all. All I really needed to understand what the user needed to do and it ended there. But, the more I thought about it, the more I realized how important the why, the context, and the person using it really was. It was a question that really motivated me on this path to get into Design and UX in the first place.

I needed to dive into the people who were using this, understand their work, understand why they were doing what they were doing, and use this to create better software. It was a missed opportunity. Thankfully plenty more remain.

Until next time.