Know Your Customer

I’ve been creating computer software for a few years now, enough to know that one of the toughest lessons to learn when designing software is that you should not design the software as if it were for your own use.  Rather, you need to try to put yourself in the shoes of your customer (figuratively of course) to understand what they really want to get out of the application and how they expect to interact with it.  Actually, let me expand that rule to any product or service, not just software.

What do I mean by that?  Well recently I heard a story about the Chevy Volt.  Perhaps you know about this car.  It is an all electric car, not a hybrid.  According to the story, it is not selling as well as folks in Detroit expected.  Sure it is economical.  Sure it is environmentally conscious.  Sure the President wants everyone to buy one.  However, sales have been disappointing.

Some people believe that the reason many people will not consider the Volt is because they fear being stranded somewhere without a place to plug the car in to recharge its batteries.  Without a small gasoline engine to take over when the batteries are down, that certainly could be a problem.  But even if you just drove the Volt to and from work in well populated areas over relatively short distances no more than 25-30 miles in each direction, would you feel comfortable?  What if you forgot to plug in the car the night before because you got home late and were so tired that you simply forgot?  How do you tell your boss that you will not be coming into work that day because your car needs to charge?  (A good argument for working from home.)  Or maybe you just cannot pull the car into your garage to plug it into the recharge station because your garage is just too full of junk?  (Come on, you’ve seen those garages when their doors are open that are so jam packed with ‘stuff’ (a synonym for trash) that people have to squeeze through a narrow tunnel of boxes to get to the door into the house.)

So while the intentions of the designers may have been great, they forgot to consider the human factors in owning and operating an electric car that make it different from a standard gasoline car or even a hybrid.  Maybe eventually fast recharge stations may be more available, perhaps even as additions to regular gasoline stations just like diesel pumps were added to many stations years ago.  Maybe parking lots and parking garages will include recharging stations that will just add the cost of recharging to the cost of parking.  But that’s the future.  Today the number of people willing to depend on an all electric vehicle as they primary vehicle is very small.

Let’s go back to software.  When you get a new project, what is your first inclination?  Is it to rush back to your computer and begin coding the application?  And if so, do you continue to code day and night Monday through Sunday until you finish the application and then go to the customer to proudly show off your wonderful creation?  Does the customer echo your praises telling you what a brilliant programmer you are?  Probably not, and why not?

You designed a perfectly good application based on what you thought you heard using capabilities, features and tools you are comfortable with but those may not be the same things that the customer thought they were asking for when you first met.

What went wrong?  Sometimes it takes more than one meeting to get to really know your customer and to really understand what they need especially when they have not articulated their desires clearly.  The way I suggest approaching this dilemma is by iterative design.

At the first meeting, try to identify what the absolute needs of the customer are and what are features that they would just like to have.  Ask about each feature and function and how it serves to meet a specific need.  Take the time to really know the customer’s pain.

Then go back to your desk and design a prototype system.  I’ve designed prototype systems on paper, white boards, Visio, and even using Visual Basic to create simple forms and reports without any really code behind them.  Remember that they are just visual tools that you can take back to the customer in a week or two (or longer if the project is really large and complex).  When you meet with the customer the second time, go through the design explaining how users would interact with it going from screen to screen following the path of the data from entry through processing and finally to storage or reporting.  Encourage the customer to ask questions.  But most importantly, don’t be afraid to modify your design either on the spot (as with a Visio, white board, or Visual Basic model of the system) or to go back and create a new paper model based on your improved understanding of what the customer wants.

While you may be able to nail down the design in one shot, don’t be afraid to evolve the design over a series of meetings.  Changing design at this point is relatively easy and inexpensive compared to changing the design after you spend countless hours coding an application to work a specific way.

Even after you get a design that the customer agrees to (and get them to actually sign off on the design), you should periodically take portions of your application back to the client for a quick ‘show and tell’ session to let them see your intermediate progress.  Not only do these sessions make sure that the design stays on track for the customer’s needs, you will build a lot of goodwill with the customer because they will see you as actively partnering with them in making the project a success.

Well, that’s just some thoughts on design methodology for this week.  Hopefully it will help you with your next application design project,

C’ya next time.