How To Build Simple, Complex Software

Judging from the response I got from yesterday's blog posting about customer-centric design - I thought I'd do a more practical follow-up. The feedback that I got went something like this: "Yeah, well, ok - but how do we accomplish customer-centric design (in processes as well as our software)?".


I think that there are many different ways to accomplish the same things, and because custom software is such is personal endeavor there's no one-size-fits-all sort of approach. However, here are some time-tested, real world, fundamental truths to help stimulate the brain cells:

• If you start with the user and their needs - you will be far ahead by the time you actually get the software into their hands - and because they were part of the process - the chances for success increase dramatically;
  
  
• Realize that in terms of application flow - you're the expert - but the users have to actually use what you've written. So, during development, take 45 minutes and put yourself in the user's seat, and actually perform the same task(s) that they would do. I guarantee, it will absolutely transform your application;
  
  
• If you're building a general-purpose site - go to your parents house (bring flowers and dinner) and fire up your software and watch how easy (or not) it is for them to "get" the site. Remember, AOL really only became successful because Steve Case wanted to build software easy enough for his mom to use (who was in the target group he was trying to reach);
  
  
• Simple is good;
  
  
• Complex is bad;
  
  
• Powerful = Simple Complexity. Think Apple. Stuff "just works." Whether you love or hate them - the iPhone and iPad have gained huge consumer traction (some would even say - they define the spaces of tablet computing and mobile communications) because those devices have software that is easy and sophisticated at the same time;
  
  
• Pretty < > (does not equal) useful. This may sound like a direct contradiction to the last point - but just because your software looks good, or has a good flow to it - it doesn't mean anything unless it actually gets the job done;
  
  
• Multiple, incremental releases are better than a huge, massive, feature-crazy, overwhelm-the-user, 2-years-in-the-making release;
  
  
• Show the user your overall designs before you "get it all working". It's much better to code the user interface, get your color scheme in line and work with the user to make sure all the elements are place in logical places (their logic - not yours!) before you hook everything up. You need to make sure your job as "interior designer" happens before your job as "construction boss;"
  
  
• Pick a software tool/environment/platform that doesn't suck. Again, this one is highly subjective and because whole wars have been fought about the benefits of Java vs. C# vs. Ruby vs. VB vs. PHP (etc, etc) I'm not going there... but you need a tool that allows you to quickly iterate, quickly deploy (and rollback in case you screw it up). Although I'm biased - I use FileMaker Pro for smaller projects that have modest data requirements, are for a client without a dedicated server, in an environment that needs (or wants) a LAN-only solution - for everything else - I use Servoy;
  
  
• If you don't intimately understand what your end user's job is and what their required output is (be it emails, reports, etc.) - your project will - with 100% certainty - fail. Oh sure, you may deploy it. It might have been under budget and ahead of schedule. But unless the users use it (and like it) - it's a waste of time and money;

The bottom line is that you should engage and delight the end users. Figure out a way to reduce their workflow to a few clicks. Display the most-used, most-important-to-the-user items in the most prominent place on the screen. Use pop-up menus/type ahead fields wherever you can to keep the data consistent.

Build the type of application that not only you would want to use, but build an application that your user would want to use.