Learning the Customer Isn’t Always Right

Tim Roberts
4 min readSep 21, 2015

How I learned that I’m not just the client’s developer, I’m their only source for what they should be doing on the Internet

Being a freelance developer in bohunk Tennessee can be summed up as simply “feast or famine.” When the clients are coming in and your JavaScript doesn’t need to be debugged, you feel as if you own the world. When no one needs your services and cold-calling leads turns up nothing, you question why you ever stopped studying economics in the first place. How we handle the famine sets us up for success when the feast comes our way.

Like most of my clients, SPR found me through word of mouth. I had done a simple events page for a friend of theirs and they wanted me to build a simple Single Page Application for their start-up. Simple enough, I thought. Looking at their competitors, it seemed anyone with a Bootstrap template would at least be on par with the market and adding any jQuery or Angular would make it look light years ahead. I sent them a contract and figured it wouldn’t take more than 20hrs to finish. Then the questions poured in.

At least 5 times a day I would receive an email from my contact at the company (always know the one person you are going to be talking to!) with “ideas” that he had gathered from his Google searches. He wanted to add databases, web sockets, live updates through Instagram, even a custom CMS since “there’s so many out there, can’t you just build us one?” After the first week of niceties, I knew I had to make a choice. And as I was in famine mode, it was a pretty hard one.

We had a contract that outlined the things I was responsible for and since he was a friend of a friend I was giving him a rate of almost minimum wage. Adding to the contract would have been easy and each component that they wanted would have meant more money in my pocket and more importantly more food on my shelves. But what was in the contract was all that they needed to get started and test the market. Sure having all the “extras” would make them feel as if they were more superior than their competitors but all of the extra components either didn’t add value to their page or in some cases took value away. I could take the money or I could help them understand what the page should do for them.

I asked them to coffee to discuss the “upgrades” they wanted and even as I was sitting down with my java I wasn’t quite sure which way I would lean. Running through the list of ideas they had, one question came up time and time again and they never seemed to have an answer: “why do you want that?”

I quickly realized that they didn’t understand that the point of the web page was to simply sell the user on clicking the button they wanted them to click. Even though the clients were computer literate and surfed the web as much as their customers, they couldn’t see that the page they were building in their minds was the same type of page that they click away from in the wild. My choice was made the moment I realized adding anything to their contract would be like taking candy from a baby. And momma didn’t raise no candy thief.

After talking to them for an hour and getting nowhere closer to a resolution on their needs vs their desires, I decided to change gears. If they didn’t understand what they needed from a web page, I was going to have to figure it out for them and the only way I was going to do that was with their help. Taking out my notebook and pen, we started building user profiles.

I never discussed UX with them nor did I try to explain to them the current best practices in design. Instead I used what they knew, their customers, and what they wanted their customers to do, register for services, and we slowly started building a user interface based upon that. Instead of fighting over what needed to be included and what didn’t, we all started wireframing our own ideas based upon the user profiles. Some ideas were better than others, but the gauge was always “how does this help the user succeed and the business succeed?” Without me having to dictate what was best and what was garbage, they started to realize it themselves.

After a long UX wireframing experience, we had finally fleshed out their needs, their customers’ needs, and how the web page needs to facilitate them. I had found that my ideas of what they needed were not only wrong but harmful. They saw that their desires for cutting-edge tech and bloated Flash was harmful to both themselves and their users. Through doing what we should have done during our first meeting, we finally had a strong starting point and a solid understanding of each other’s goals in the agreement.

On top of it all, I felt invigorated for the project. No longer was I building a page for some random person. Instead, I was apart of their team. We had overcame our egos and our desire to be right in order to build something that wasn’t ground breaking but fulfilling.

Sure, I was still in famine-mode and the cash would have been nice. But there’s something great about helping others find their answers instead of using their ignorance to pad your pocket book. From this client on, however, UX/UI is going to be the first discussion, not the last.

--

--

Tim Roberts

dev kid who likes to write in english instead of code