The Edsel as everyone knows was a failure; what everyone might not know is that it was brilliantly engineered vehicle with many features that are just now becoming standard on vehicles today. Software architects are involved in many facets of a product: designing the system which the developers create, deciding which technologies to use, and discussing the system and it’s requirements with the customer to name a few. The one item I’ve noticed that gets lost in the shuffle is the user interface. The user interface is the entire system to the user. They don’t care how brilliant and reusable the underlying components are, they care about how easy it is to use. Don’t let your product become the Edsel. Don’t forget the customer; they are the ones that will be using it on a daily basis for (hopefully) a very long time. A wonderfully designed and technologically marvelous system might make you feel great that you pulled it off, but if the customers hate it — you haven’t succeeded. There are a few techniques you can use to prevent this from happening: a walking skeleton, a project champion, and frequent demos.
First is the walking skeleton; a perfect solution to keeping your customer involved with the design of the system. Once the requirements are set, the user interface can be tested by users and allows you input on the user interface. If they’re happy with it, they’ll be happy with the system. If they dislike the user interface, you’re on your way to an Edsel. As the architect it is your duty to prevent feature creep, so be prepared to delay or ignore implementing some features the users may ask for. A simple “we can plan that for the next version,” or “thanks for the feedback, we’ll see what we can do” lets the users know you’re thinking about them and making the program with their best interests in mind and not as a vehicle to add a bunch of buzzwords and bullet points on your and your developer’s resumes.
Secondly, the walking skeleton can net you a project champion user. This will be a user (or users) who really love the idea of the new product and evangelizes the new system to less receptive users. Try and identify this user quickly so you can have them help you gain acceptance within the user community and alleviate fears about the product. Again, using something sly to get an end-around on the users will not make them happy campers — even if you know they have no choice but to use the system, show you care about their ideas and want to use their ideas to create the best system for them.
Finally, frequent demos of the walking skeleton system can help you gain a project champion or calm the waters (and gain a champion) if the users are complaining about the system. Personally, I’ve found the more demos one gives of the system the better off you’ll be when figuring out exactly how people want to use the software. You’d believe the requirements gathering would cover everything, but more often than not, I’ve found out I’ve learned more from the users with a simple demo than a whole list of requirements. The walking skeleton demos are another way to get to the root of the requirements.
Remember brilliant engineering with no focus or incorrect assumptions on the users creates an Edsel. You might sell a few, but you’ll be dead, gone and forgotten shortly after.