In my last article we talked about the importance of knowing what the design specifications you are building and how end use is more important then what people ask for in what they think is their ideal product. In this article we are going to talk about strengths and weaknesses in the creation process.

In any design process there are real people with experiences, skill, knowledge and bias. The trick is to emphasize the strengths and exploit the knowledge's while minimizing the bias.

So lets start with a fictious company, ACME Hammers Inc., to build our hammers.

Lets face it hammers is in its name, it's what they know and what they are known for. That means that the nailgun from the last post, while it might be a better tool for what we need, is not going to be built. This is not a bad thing either, they have tons of knowledge and equipment that has been specialized and gives them a competitive edge.

They have a set amount of equipment that they own and that they have workers trained on. Needless to say whatever they are going to build will be made suing those machines rather than going out and buying new ones and training people.

So the capabilities of the team and the company determines a lot about the product.

If you're a company with a history of making databases and you have a lot of guys who like to code in C then everything you make is going to be created through that filter. The lead developer might think that Ruby on Rails is the worse language he has ever seen and ban people from using it. One developer might love UML and insist on using it every time he can. The manager might have come from a conference on "Extreme Programing" and think that its the bee's knees and revamp the entire way things are coded. Everyone has there opinion on why their way is the best way and they tend to see everything from that subjective viewpoint.

The problem is when there is an easier way to make a better tool by leaving your comfort zone. Most people who design forget the old adage that if you have a big enough hammer, everything looks like a nail.

Lets get started by talking about the hammer. It's one of the earliest human tools and something that people still constantly try to improve upon. So lets boil down what the function of the hammer is at its simplest form and figure out what its features should be and then we can decide what are good features and what are bad features. Then lets convert it to software and see if we can apply the lessons learned from the hammer exercise.

What is a hammer? The funny thing is that the hammer is just a way of transferring kinetic energy to an object. It is a lever with more mass at one end of it. When you say hammer to most people and this is the image they get.

That a carpenter's hammer and its a false assumption. We need to decide what the application we really want to do with the tool. You can't let the assumption of what the tool is decide it's features or even what type of tool it is. If you don't know what the users need the tool for you can't even start the design process. Otherwise you might end up with a hammer like this.

or thisor even this .

They are all still hammers, but they all have different design specs. They all have different applications. I've been in to many meetings where we were told to design an e-mail tool or a Gigabit Ethernet hub or some other THING without any regard to what the end user REALLY needs the tool to do. Part of it is that no one likes to write up a Design Requirements document, part of it is everyone assumes that everyone else knows what they want and mean, part of it is the desire to avoid the months of meetings that some places require to get consensus on what users really want. In some cases they hear what the users want "We want a hammer" without looking into what the problem they are having, "We are trying to fit square pegs in round holes."

So lets set up a basic Design Requirements:

1) The hammer needs to be one handed for ease of use.

2) The hammer is intended to drive nails into wood.

Very simple, but it does get rid of 90% of the features that could have been designed; war-hammers, sledgehammers, ball-peen hammers, etc.

And you have an application that might not even need a hammer like we were told. Its possible that what people thought they needed was a hammer, but the best tool might be a something different.

Like a nail gun.

So when you start designing you should look into what you want the end result to be, not what you think is the best way to solve what they tell you they want.

There is a lot of talk about the concept of a "Usability Bubble". This refers to a larger circle that refers to the features and a smaller circle inside of it that represents the features that the users use. The less empty space between the edges of the two circles the better.

So you have Features

And you want the amount of features that users use to almost fill it.

I'm a big believer that one of the greatest selling products in the world would be a cell phone that fits comfortably in the palm of the hand with buttons that are easy to push that only gets cell phone calls and text messages. (And I'm still not to sure about text messages).

I'm a big believer in getting a firm mental picture of the users too; how old, what other tools they use, where they shop and so on. The more complete the picture the better. Then create the anti-user: the person who others target. It might sounds strange, but if you are targeting Linux users then Windows users are your anti users. These are the people that you need to take out of the equation because by trying to make those people happy you will be adding features that no one wants or alienating your REAL target audience.

If you are designing a program for the average home user, don't put in features that only professional power users demand. While people might brag about how many features the program has, they will be much more likely to use the software that does exactly what they want in the way they want to use it and not much more.

And there is still the matter of the hammer...

Welcome to The Feature Creep Blog. This blog will discuss the hardest thing to combat in design, the dreaded feature creep. Many times features are added to software that make a product harder to use or adds cost and complexity on the programing side. I'm hoping that CR4 will stand as a shining example of good design; I won't get into the hours spent on icons, layout and other details that users will probably never notice after the first 10 minutes of using it. But that's OK, that's what good design does.

I'll be making a new post discussing hammers, and what they have to do with software design.

And if you have questions about the UI of this new CR4 you can private message me or ask it here in the blog.