Knowing your users will help make effective decisions

April 8, 2009

If you are reading my blog, there is a very good chance you are interested in the web, web development, or technology management. Today I want to talk about something I have learned more about since I started writing this blog. Its not something completely new to me, but it has become very clear since I started writing Effective Development. That is, most of the people on the web are not like us. Now you are going to say that’s obvious, and maybe you are inclined to stop reading. But read on, I want to talk about why this it is important to us as developers and managers of developers.

This blog is a tech blog. That implies that besides some of my friends and family who may be reading this from time to time to be nice and help my traffic, most of you are technical. So one would think, a large percentage of readers who are interested in this site would naturally subscribe to my RSS feed or Twitter, or one of the other ways of following updates on the site. This is not an arrogance thing. I do not assume everyone wants to come back and read all my updates, but my traffic numbers prove repeat users do come back. 50.4% of my readers are repeat readers. They read 2.41 articles and spend over 3 minutes on the site before leaving. So these numbers say people are interested on some level. Personally, when I am interested in a site and I want to consume the content, I always add the RSS feed to my reader. Then I visit the site when new posts come out, or read the full article in my reader if available.

So naturally this assumption I have about users means you all are using RSS, right? No, not the case at all. In fact, very few people are using RSS, and in the survey I ran a few weeks ago, only 15% of users say they subscribe to the RSS feed.

Why is this important?
Well its important, because if readers to a tech blog are not all using RSS and Twitter, what about users for a site geared for the general public? As developers we need to keep this in mind. Sure we want to always work on the newest widget, and the latest UI function. But we cant always do this, nor do we need to.
I have worked on projects where we spent 20+ hours on a nifty widget for our homepage. We were very proud of all the customization, movement, and dynamic asynchronous data it provided. Finally it was time to launch the widget. When we did, we received emails asking for navigation the the exact tool we just built the widget for. We scratched our heads. It was right there on the homepage, and it looks cool, and it has so many nice features, why couldn’t everyone see it? We had spent so many hours giving users features that we thought would keep them from needing to visit the actual tool as often. And here they were asking for the tool still. So, we made it even more prominent, and simplified it. We added help text and finally people started using it. Now we were really proud, people could see it and they would soon love it we felt. So we added some Google event tracking to monitor all the interactions users were having with our widget. We waited a few weeks, then checked the data. Boy, were we surprised. Sure people had found it and were now using it. That problem was solved, but you will never believe what people were using it for. Basically they used this many featured widget as a login/navigation to the tool it was meant to supplement.

We had spent a lot of time working on a fancy navigation element to another area of the site. Now this wasn’t a total waste, as the technologies we used and the development time invested has turned out to be re-used in even more areas of our site. It was a learning experience for the developer team (and management), and a good technology investment for our team and site. It just wasn’t the drop dead feature we had hoped it would be.

There are lessons to be had here. First, know your audience. Really know your audience, don’t just assume you know them. That means run analytics and keep an eye on users behavior on your site. Run usability tests (a topic i will cover in the future), and keep your users in mind. After the research is in decide if the feature is worth the development and time. You may still decide to build a feature because as i said earlier, it may be a technological investment for your future. Perhaps you decide to build the feature becasue you can monetize it in some way. Your users may not be clamoring for a RSS feed widget, but your sponsors may be, etc…

Remember our view of the web and our users is not always accurate. You have to truly put yourself in their place through testing and analysis. If you learn to make project decisions based on the research, you will certainly be more effective, both in development and implementation.

Share:
  • email
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • TwitThis
  • NewsVine
  • Reddit
  • Slashdot
  • StumbleUpon
  • LinkedIn
  • Netvibes
Sphere: Related Content

Related posts:

  1. Iterative Development is Effective Here at SmartMoney, we have been using iterative development techniques...
  2. deployment schedules are not effective Simply put, deploying code on a set schedule is not...
  3. april fools and technology What is it about April Fools Day and the tech...
  4. web 2.0 expo @ the javitts center i will be at the web 2.0 expo in nyc...
  5. Geocities is closing, marking the end of a Web Era Yahoo! GeoCities is closing. This is in interesting story for...

Related posts brought to you by Yet Another Related Posts Plugin.

1 Other Comment

Leave a Reply

Additional comments powered by BackType

Blog Widget by LinkWithin