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:
- 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).
- 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.