Defining a simple interface

In our last article we talked about the process for determining the importance of features in a new agile software project. One of the most important features of any website, which is a "general" feature rather than a specific one, is creating an easy to use, yet powerful user interface. This is doubly important in developing web software since complexity on the user-interface side typically requires more coding and development than complexity on a dedicated application (due to working with multiple browsers). If your application becomes too complex it could force you into a front end development interface such as Flash or Silverlight due to the limitations of a browser based system. To retain the best cross-browser compatibility sticking with AJAX/Javascript/CSS/DHTML/HTML is the best solution.

In our last exercise we identified 85 new features to potentially be added to the product and gave them a subjective ranking based on making binary choices. How do we keep the product from falling over under the weight of so many features? How do we maintain the idea of a simple interface without sacrificing important capabilities?

One way to do this is to apply a subjective score to each feature for whether it ADDS COMPLEXITY (from a user or administrator's point of view) or whether it SIMPLIFIES the user interface. This should be pretty easy - if there are more buttons on the screen, user interface elements to learn, or processes to train someone on - then it ADDS complexity. If on the other hand it eliminates or streamlines processes, removes administrative burden, or simplifies already complex tasks - it REMOVES complexity. Remember here that we're not yet considering whether it adds CODE COMPLEXITY, we're only considering user interface complexity. This is a simple binary choice, and in most cases won't require a lot of discussion.

Let's say for instance that our current user interface requires a user to upload a graphic to the website for inclusion in a post, using the traditional "browse and upload" methodology, and that one of our suggested features (never mind code complexity yet) is to allow users to drag-and-drop a graphic onto a particular spot on the website and handle the upload itself - requiring no directory browsing to accomplish. Does this add or remove complexity (from a user point of view)?

That one's pretty easy - it removes complexity. We're replacing 5 steps (press browse, find a directory on your hard drive, select a file, click upload, link file into current content) into 2 steps (open directory and find file, drag and drop onto content where you want it positioned).

Let's look at an example that increases complexity. Say you want to allow users to chat while posting a blog entry, and to record that chat as a link to the blog. That increases complexity. You need an entirely new user interface for storing and displaying the chat itself, presence indicators to indicate who is available for chat, a way to link chats to blog entries, and a way to initiate and terminate chat sessions - all new administrator or user interfaces. This feature adds complexity (from a user point of view).

We're not really making a judgement at this point whether the complexity added is worth the perceived benefit - we're just determining whether it adds or removes complexity from a user's point of view. So for each weighted item on our list we add a column and record a zerp "0" if it simplifies complexity and a one (1) if it adds complexity. We can later add a weight to the "1" records if we want, or score the amount of added complexity on a sliding scale (1-5 where one might represent a single new button, and 5 would represent an entirely new interface and administrative burden). These are flash, subjective evaluations, and are done based on putting yourself in the end-user's role.