Tuesday, August 01, 2006

Design Fallacy - Lesson 1

Design and deliver only What you Need



Recently I was writing a WSS (Windows Sharepoint Services) utility to help my user to eliminate some tedious repeatative.

Due to the access restriction for documents in document library, the sys admin need to customize the security setting for certain document library in the wss site. This is quite a tedious task as new site is created quite often and each site has a few document library. It takes many mouse clicks to accomplish the process.

I figure that it is possible to write a utility to automate this series of tasks using the WSS SDK. As i am writing this utility as a personal favor, there are not proper requirements, no time constraint and no limit to features.

Halfway through development, i was kind of stuck thinking what is the best way to present the UI and I realize i make a design philosophical mistake that many people tend to make as well.

The problem here is overdesign and attempt to go beyond the requirements.
The admin only need three functions:

  1. Add a predefined list of domain users into the new site.
  2. Remove the default groups from the document library.
  3. Add the new groups/users into the document library with specific permission.


The admin only need a simple car and I was on my way to build a car with turbo engine with backfire. I was trying to build a general document library administration
tool instead which is way more comprehensive.

Obviously, my utility application will be able what the sys admin want to do and even
more. But when I sit down and think of the usability issue, I quickly realize it was too ambitious, too general and too much functionalities.

Having more is not a bad thing, but it is not always a good thing either. Having more functionality than necessary mean the user need to have more interaction
with the application.

So, the problem is :

  1. The more functionality the application have, the more interaction the user need to do.
  2. The more interaction the user need to do, the more decision the user need to make and the more discoveries the user need to make.
  3. The more decision the user need to make, the lower the productivity the user become.
  4. The more discoveries the user need to make, the more distraction the user is going to have and the less usable the application become.


Eventually the user will find the application too complicated for simple purpose and revert to the old ways of doing things. Then all your hard work will go into drain.

The best application is not one with many features, rather it is one with the function that solve the user's problem at heart efficiently.

By focusing only on the absolute requirements and nothing more:

  1. You will need less development time which will drive down cost.
  2. Simple application with less but important functions.
  3. You will have a simple application which require minimal learning curve.
  4. User is more productive because the application does not require them to make decision.

So, I went back to design the application just to have only that three functions and nothing more. It took me only half a night to complete the application and ready to ship by the next day. And most important, the application is way much easier to use.

The lesson here, focus only on core requirements and nothing else. Don't make your life and your user's life complicated. Just because you can do something, doesn't mean you have to do it. You don't show value by delivering more functions, rather by showing user you understand their real problem and solve it in the most elegant way.

Labels:

1 Comments:

At 9:23 AM, Blogger Firedancer said...

Like what is said in Extreme Programming (XP), "Don't develop anything where you aren't gonna need it". Just focus on the current business requirements and deliver a simple solution. Future requirements are bound to change anyway.

Also, when you build tools like what you intend to do, try to decide between generic components (the ones that can do everything) and automation (the ones that do one thing over and over again). I realised most developers spend their time developing generic components which is complex to build due to catering for various programming situations. Some problems can actually be solved by automation instead i.e. writting a script or simple program to run the tasks.

 

Post a Comment

<< Home