Real Lessons from Real End Users

As many of you know, before joining Telerik, I was a customer (and a MVP). I met Telerik while developing a hosted web application (or SaaS, if you will) for managing career fairs, and I picked Telerik's tools for my UI development since they were (and still are) the easiest to use on the market. When I joined Telerik, the application lived on, and from time to time I like to visit with my customers and participate in end user training sessions. I did just that this evening with one of our bigger customers, and to my surprise I was reminded of two very important "end user rules"- two rules I think we as developers all forget too often:

1. Rule 1: Training and Re-Training is critical- Whenever you develop an application that has "features," innevatibly some of them get overlooked or forgotten. While talking with "real end users" tonight, I asked them to describe some of the problems they've faced running career fairs in the last 6 months. At least half of the problems they described were already addressed by features in the software system that were either A) overlooked, or B) misunderstood. Now, I understand that some features get burried and I could have guessed some of the features they'd miss. But some of the features seemed obvious to me. "You mean you didn't notice the big button that says "Solve My Problem" when you logged-in?" I thought. As developers, we tend to overlook the "obvious," especially in systems we build ourselves. It doesn't come natrually to us that users might not be aware a feature exists, especially if we think the feature is very cool. Simple "reality checks" with your "real end users" (or REUs going forward) can save you support time and the users lots of manual work (because they will finish their task, they just won't use your "helpful" feature).
2. Rule 2: Just because you don't get complaints, doesn't mean it's not broken - Later in the training tonight, while still asking users to list their problems from the past 6 months, one user said, "Oh yeah, and I get these error messages all of the time." What? We had never received any angry emails from this user. "You have?" I asked. "Yes," she replied, "I just figured I was doing something wrong." In the developer community, I think it's really easy to forget this fact about REUs. If they hit an error in your application, they are very likely to think it's their fault and not report the problem (often out of fear of sounding dumb). As developers, this concept is foreign since we are accustomed to firing-off bug report emails whenever we hit any problems (real or percieved) in the applications we use. REUs are different. This rule highlights the importance of having good, uncluttered error reports that you review proactively for problems and the value of occassionaly asking your users what problems they're having. Not only will that improve your customer service reputation, it will help you fix problems before they start costing you business.

And while these rules are derrived from application development, I think they are also true for the RadControls (though Rule 2 probably doesn't apply as strongly to you helpful developers). Since our product teams see the controls everyday, and since I've worked with them for so long, things to us often seem "obvious." Of course RadGrid can bind to web services! Of course you can use the RadEditor image editing classes outside of the Editor! Of course RadCombobox works when JavaScript is disabled! Obvious to me. New to you? As we approach 2009, I want to make sure everyone knows about all of the features in the RadControls that are designed to make your developer life as easy as 1-2-3. Unfortunately, I can't gather you all in a room and get your feedback, but I'd love to hear it! What have you had trouble doing with the RadControls in the last 6 months? Send an email to todd.anglin@[the company I work for].com and help me make the misunderstood or overlooked features of the RadControls obvious! Maybe I'll post a follow-up, "Real Lessons from Real Developers"...