Usability and Functionality
Products with high functionality are often quite difficult to use. I'm sure you've run across this yourself. You hear of a great product that people recommend so you go out and download a demo or buy a copy from somewhere and install it on your PC.
You start the program and you are immediately inundated with options with no clear idea of what to do next. The menu bar has a plethora of choices, some of which make immediate sense and others which are so esoteric you have no idea what they do. Data entry screens are so crowded with fields, drops downs, radio buttons, data grids and buttons that you can see the screen for all the controls. And the application just looks plain ugly (yes I'm talking about you MYOB).
Alternatively highly usable applications are often seen as very simplistic or single tasked. This is usually because simple applications are easy to keep clean and tight. WinAmp has always been highly usable but it just plays MP3's (and other media) - it's not a point of sale system, or an accounting package.
Does this mean that your highly functional application can't also be highly usable? No. However highly functional applications require a lot of thought to be placed on usability at the start of the design process, not at the end (where it is usually done).
Please note: Usability is not polish. Eye candy does not equal usability. Wizards and other automated assistance tools do not equal usability. Skinnable applications are not necessarily usable.
Usability is helping the users of your software to do what they want, as fast as they want, when they want. Without any distractions.
What does this mean for your application design? What should you try and do?
1. Design for multiple input methods.
Some people use like keyboards and other prefer mice. Think about both.
2. Think about the tasks.
Functional design usually focusses on getting functionality right, but not on streamlining the tasks that the functionality is meant to support. Sure, you need functionality to create a customer, and sure, you might need 150 data fields to record all the possible data, but do you need to show the user those 150 fields all at once, and are they used every single time? I doubt it.
3. Think about your users.
Contrary to popular belief not all users are programmers, and not all users have a strong background in computers. Some people have no computer skills at all and are actually afraid that making a mistake may cause loud popping noises and black smoke to rise from the back of whatever that humming beige box is under the desk.
4. Don't let programmers design screens (if possible).
Most programmers are "graphically challenged" and "usability challenged". They know what applications look nice and which ones are easy to use but can they actually make a nice looking app or one that is a pleasure to use? I doubt it - just ask them to design a customer entry screen with 150 data fields and see what they produce.
You start the program and you are immediately inundated with options with no clear idea of what to do next. The menu bar has a plethora of choices, some of which make immediate sense and others which are so esoteric you have no idea what they do. Data entry screens are so crowded with fields, drops downs, radio buttons, data grids and buttons that you can see the screen for all the controls. And the application just looks plain ugly (yes I'm talking about you MYOB).
Alternatively highly usable applications are often seen as very simplistic or single tasked. This is usually because simple applications are easy to keep clean and tight. WinAmp has always been highly usable but it just plays MP3's (and other media) - it's not a point of sale system, or an accounting package.
Does this mean that your highly functional application can't also be highly usable? No. However highly functional applications require a lot of thought to be placed on usability at the start of the design process, not at the end (where it is usually done).
Please note: Usability is not polish. Eye candy does not equal usability. Wizards and other automated assistance tools do not equal usability. Skinnable applications are not necessarily usable.
Usability is helping the users of your software to do what they want, as fast as they want, when they want. Without any distractions.
What does this mean for your application design? What should you try and do?
1. Design for multiple input methods.
Some people use like keyboards and other prefer mice. Think about both.
2. Think about the tasks.
Functional design usually focusses on getting functionality right, but not on streamlining the tasks that the functionality is meant to support. Sure, you need functionality to create a customer, and sure, you might need 150 data fields to record all the possible data, but do you need to show the user those 150 fields all at once, and are they used every single time? I doubt it.
3. Think about your users.
Contrary to popular belief not all users are programmers, and not all users have a strong background in computers. Some people have no computer skills at all and are actually afraid that making a mistake may cause loud popping noises and black smoke to rise from the back of whatever that humming beige box is under the desk.
4. Don't let programmers design screens (if possible).
Most programmers are "graphically challenged" and "usability challenged". They know what applications look nice and which ones are easy to use but can they actually make a nice looking app or one that is a pleasure to use? I doubt it - just ask them to design a customer entry screen with 150 data fields and see what they produce.