Sad developer :(

Image © iStockPhoto

It’s important to know how to measure success when building a new website. For example, it’s not enough to know what features you want, but you also need to set some expectations for what those features will actually do for your customers and visitors. Business Web Strategies recently wrote a great post on this.

But this idea applies at smaller scales too. Recently, a client came to me with a bug. Google Analytics tracking wasn’t working, she said. She provided a date after which the tracking stopped working and let me know that some other tracking pixels had been added to the site around that time that were potentially interfering with Google’s tracking. All good information to be armed with, but when I investigated, I found several more basic issues, including the tracking code duplicated to another area of the page. I wasn’t surprised to hear that it wasn’t working.

Very long story short, it turned out that the primary problem was that the client didn’t know how to read the reports she was looking at! I spent hours chasing rabbits down irrelevant holes, all because I took the client at her word and didn’t ask her to describe the problem she was actually having. Normally, I don’t accept “it doesn’t work” as a complete bug report, but because my initial look at the code showed a lot of problems, I assumed there was a match between the problems I was seeing and the problem she was dealing with. To my consternation, fixing the problems I had initially seen did not fix her problem (of not being able to read the reports).

If you come to me with a bug or a new feature you’d like me to implement, don’t be surprised if I ask you what problem you’re trying to solve by doing this. Partly, it is for my own edification — I like to know what kinds of problems you’re trying to use your website to solve. But mostly, it’s so that I can be sure that I don’t waste my time and your money by implementing a solution for a different problem, or implementing a solution that is inferior to another simply because I didn’t know or understand the full scope of the problem.

Finally, the onus doesn’t lie squarely with the developer; you, the bug reporter, aren’t off the hook. More descriptive bug reports will make the world a better place, so the next time you report a problem, don’t just say “it doesn’t work.” Take the time to describe what you’re seeing, what you expected, and the steps to reproduce the problem. Screenshots are always welcome as well.

Pin It on Pinterest

Share This