THE worst thing that can happen to you when you try something new is that you’ll succeed. The problem with success is that it normally goes unexamined.
When something that we do actually works, we tend to take that as the natural outcome of our wonderfulness and assume that we’ve discovered whatever we needed to know about carrying out this task. When we approach the next task, we bring along the lessons that we haven’t really learned.
It’s different, of course, if it’s someone else’s success. Right now, I’m technical-editing a book for Apress on user interface construction in Visual Basic .NET. There’s a lot of really good material in this book, but I find that all I point out are the things that I would have done differently or that could have been done better. I think that when all the input from the editors is in, the author is going to be able to make a good book into a great one. But I also think that it must be discouraging for the author to read nothing but one complaint after another. Part of the problem is that pointing out other people’s problems makes us feel so much better about ourselves. Pointing out other people’s successes isn’t nearly as much fun. I do this with my kids—they’ll come home with an exam on which they got 92 percent, and I’ll want to know where the other 8 percent is.
However, while I’m really good at pointing out the flaws in other’s successes, I tend to only talk about the wonderfulness of own my personal successes. For instance, let me tell you about a recent consulting gig that I was on.
I was consulting with a company about the user interface design for their Web site. They’ve had a Web site up for a number of years, but the site was only there to display marketing material. The site worked very well, and they’d received a number of positive comments about it. The problems arose when they added a Web application to their site to allow customers to order material. Convinced that they’d solved the problem of Web design, they used the same techniques for their new application pages as they did for their existing content browsing pages. They were caught completely by surprise when their clients started complaining about how hard it was to use their Web site.
They’d actually made two mistakes. The first, as I implied, is that UI design for applications is different from UI design for content. The other problem was that they failed to look at the kind of users that the application site would attract. When the developers didn’t follow the model, they’d established on the browser portion of the site, they followed the model they’d established for their internal applications. Again, these applications had been very successful. However, unlike the applications that the developers were used to building for the company’s employees, the Web site attracted untrained, casual users from all over the world. The site simply wouldn’t work for people who didn’t know what they were doing.
I came on board and pointed out the differences between the applications and audiences that they were working with now and the applications/audiences that they had succeeded with before. With this new attitude and recognizing the blinkers that their previous successes had imposed, the company has started rebuilding the application portion of their Web site. You’ll notice that I left the project before they fully implemented my advice and discovered the next set of problems. Why ruin a perfectly good success story?
My clients had been seduced by their successes. I find the same problem with Access developers who started as power users and gradually moved up to become full-fledged developers. For many Access developers, their initial application was a reporting system. These kinds of systems can be very forgiving of errors in the database design. Reporting only requires that the database be in first normal form. Based on the success of these early applications, new Access developers often don’t realize the importance of effective database design once they start updating their data. The result is an application with real data integrity problems, enormous quantities of code to solve the problems in the database design, and utility programs whose job is to find and fix the typical problems in the application’s data.
No matter how well your last project worked, you must begin each new one in a spirit of humility. The first question on your mind as you approach a new project should be: “How is this project different from other projects?” Once you recognize those differences, you need to take them more seriously than anything else in the project. They’re the ones that will cause you the most damage.
