Perpetual Design-Think

Let’s face it, software is sometimes poorly designed to begin with and the interface should be scrapped and rebuilt from scratch. But more often than not, I see software that started with a decent design and has since had features added onto it with each release, squeezed into the existing design rather than being designed in. People aren't in a design mindset but an "enhancement" mindset somehow.

As things keep being added, in minor and major releases, no one seems to step back and say “Whoa! Suddenly we’ve got three buttons labeled ‘Add’ on this screen and they’re each adding something different. Maybe we ought to rethink this. Should we really be adding all these things here? Or should we at least rename the buttons to “Add Server”, “Add User” and “Add Widget”?” Even that simple change would improve things but someone has been told that buttons should be as short as possible, preferably one word, so they end up with three buttons labeled Add, all on the same screen because that was the “most obvious” and easy thing to do.

Starting Over

Sometimes designers beg to be able to start over from scratch, and this is appropriate at times of course. The issue of starting over seems similar to me as when programmers are begging to “rewrite from scratch” to reduce maintenance loads and make the application “cleaner”. Frequently management decides the benefit, as defined, does not justify the cost of a rewrite. The software works as is, there are paying customers, and they “know” good programmers are obsessed with tight and clean code and not too concerned with profits and schedules. Unfortunately, programmers have the reputation as seeing it as more “fun” to start over and do it all “their way” than it is to work around someone else’s architecture. Management knows that and understands the risk that in rewriting, something might break. It shouldn’t but it surely does.

In fact, good programmers keep the maintenance issues in mind while adding to the code and don’t push for a rewrite as often as those who get sloppy and can only think about starting over as the solution. Programmers who “clean up as they go” can delay the point at which the program should be rebuilt. In fact, minor rebuilds should probably be going on all the time, but within isolated functions and modules. Of course, this begs the point of whether your programmers are talented enough to be thinking this way.

The Risk of Redesigning the User Interface

There is an added risk to redesigning the user interface that you do not face when rebuilding underneath the hood. Theoretically you could rebuild the code from scratch and never have a customer notice. But when you move things around in the user interface your customers do notice and you run the risk of confusing them. Perhaps your software is designed poorly, but your customers have memorized the awkward architecture and suddenly re-organizing functions on them can be very detrimental. If they have to relearn the whole program, they may reassess the purchase decision and think about relearning your competitor’s program instead.

The risk of never redesigning however, is that you end up with a hodge-podge of features apparently bolted together somewhat randomly and if anyone gets past the learning curve they’re continually having to think about where that option is rather than just getting their job done. Your software becomes unlearnable, unusable—and ultimately un-sellable!

Bolting Things On

Whenever I use the phrase “bolting things on” I’m always reminded me of the late Johnny Cash’s song about the guy built his car out of stolen parts from many different kinds of cars. No design took place but it did function, we presume! Software that is bolted together hasn’t yet had a song written about it, to my knowledge, but the end result is an application that has features stuck on randomly here and there, menus that don’t have a cohesive grouping that makes sense to anyone, and keyboard shortcuts with mnemonics that still relate to menus that existed ten years ago and have been renamed, but no one bothered to create new keyboard shortcuts because “our users have memorized the old ones!” I guess if you’re not hoping to attract new customers and make it easy for them to use your software, I wonder why you bother renaming the menus!

“Bolting on” a feature rather than designing it in leads to horridly long confusing documentation and books about the “secret works” of some application because you have to be totally obsessive to figure it all out. Using any slightly complex feature in bolted together software feels like driving a car with your CD player in the trunk where you have to stop the car to switch CDs! Oh wait, there are cars like that…Obviously, it’s not just the software industry that suffers from the bolting-on concept.
Certainly many applications could be vastly improved by simply moving a few things around and creating a few new categories of things at the right time—when there are new features users will want to explore. Rethinking a design does not have to mean rebuilding from scratch, although that could certainly be the outcome. But there are many gradients of reorganization between “rebuilding” and “bolting it on somewhere.”

When to Redesign

So how do you decide when to redesign? I think it’s very similar to the same question raised by programmers. And there is no hard and fast answer. But the equivalent to continually rebuilding modules and functions in the code to provide the longest lifetime possible for the whole application exists for user interface design as well.

When a feature is added, step back a little bit and decide whether this thing can live bolted on in bits and pieces or a set of related functions need to be rethought in terms of where and how they are accessed by users. It’s much easier to redesign when adding a chunk of new features because the users will be in an exploratory mood to begin with and are ready to learn something new. They have something to gain (the power of the new features hopefully) and are more willing to relearn a few things as long as the benefit to them is big enough—and the new home of the old function makes sense given the new features being added.

Doing a facelift to some existing design features while adding new ones will allow you to make some changes that will have a minor impact to existing users and hopefully make using the program easier for both new and existing users. This is typically much safer than redesigning the user interface from scratch—unless the existing interface is truly horrid.

New Buckets

Think about creating a new “bucket” or holding area for common features and then creating a place for that bucket to live rather than squeezing various related features onto whatever dialogs had some extra real estate or adding a new tab to an already overloaded dialog. And if you have new features that obviously need a new bucket to live in, look around at your old features and see what else should move into that bucket now rather than leaving them where they currently live. Typically, a new set of fine detail features are easier to fit into an existing design than a major architectural-level change.

For example, if you’re adding extra formatting options, allowing your user to control 3-d effects, you can probably easily imagine a new spot on the format dialog or under the format menu to handle them. But if you’ve decided that in addition to printing you’re also going to export multi-media flies or something equally drastically different, don’t think “oh, export is taking something out, like printing, so we’ll just create a virtual printer driver and people can select the “multimedia printer driver” and then set its properties for movies or music and then when they “print” we’ll create the files.” To you, maybe they are all “output” but I can guarantee that most users won’t think about perusing your printer driver list to create a music file!

Task Orientation

Keep your tasks organized in ways that make sense to your user—not the ways they make sense to the programmer. Trying to keep the tasks of your users in mind will help you decide when to reorganize and where to put new features. Keep in mind the sequence of their tasks as well and the grouping of like tasks becomes somewhat clearer. Don’t put things in the order that they were developed or added to the product so that users have to jump from one thing to another in order to get one large task done.

In Summary

Keeping the design mindset when you are adding new features, however minor, will allow you to smoothly integrate the new functions into the user’s workflow and keep your users adept at their tasks. New users will find your software easier to use as well, without having to understand the entire history of your product to make sense out of it. Remember—it’s not supposed to be a puzzle or a challenge for users to find your new features, unless you’re in the game business. Keep the mysteries out of your application software.