Simplify, don't “dumb-down”
As UI designers, we implicitly start with the assumption that all applications and products need to be simplified – is this necessarily true? What makes a product or application complex? It could be many things – the complexity of its workflows, number of information input sources, number of transaction, integration with other systems, security protocols needed, validation procedures, whatever…
In all the years I have been working in Human Factors, I have always looked for ways to make things easier for the "User". Ways to reduce the physical and cognitive burden by trying to reduce the number things to remember, reduce the number of interactions, reduce the need to think etc. We all “know” that the key to usable products and applications is simplification.
What if we are wrong? What if we are short-changing the user communities we are designing for? What if we simplify things to such a point that a user is helpless when faced with a problem? Can our efforts actually hinder the user of a product or application when faced with an “abnormal” situation?
Problem solving, decision making under uncertainty are both highly valued qualities, in any environment – business, military or civilian. When we surround people with applications and products that do not require them to reason things out, or to investigate different options, we may be undermining our user’s ability to form a good mental representation of the underlying processes and thus their ability to respond to “out of the ordinary” situations.
When we talk of simplification, what do we really mean? Does it mean bringing everything down to the lowest common denominator? What would it mean if we designed everything like that? Is simplification the same as “dumbing down”?
Dumbing things down does not make them usable, does it?
Does “over” - simplification really make things more usable? If a function or process is complex in nature, due to whatever reason – criticality, number of interactions, inter-related processes, time critical responses, etc – it is possible that they can be simplified only to a certain extent – beyond that, simplification may prove to be a detrimental factor because it conceals the true nature of the beast.
What if we are doing is actually deleterious to the user’s understanding of the system? Is there a way that they can rip off the cover to get at the innards? After all, we are not in a factory environment where the most efficient interaction is valued the most because it increases manufacturing production. We are usually looking to streamline workflows to increase user effectiveness, reduce errors and enhance the user’s experience with the system they are interacting with. A simplified system that leaves the user with a false sense of security because they are unable to view the “hidden” processes may prove disastrous in an emergency situation.
Usability cannot mean “dumbed down”, and the role of an UI designer is not to look for ways to dumb down the product interface and interactions to fit the so called lowest common denominator among their end-user groups.
How does dumbed-down design occur? There are 2 ways – the first is when a process or interaction is automated, and the user is relieved of “decision making” responsibility for a particular task – this reduces the burden on the user, ostensibly leaving them free to concentrate on more important tasks. However, some portions of the process may not be automated, leaving the User Interface with a vestigial screen or two which the user has to interact with, even though it serves no useful purpose.
Whatever interactions the designer chooses to leave behind, it is usually to preserve the user’s perception of process integrity, so they will have the feeling of going through all the steps they are used to. This implies that the user cannot cope with change or accept improvement in processes – basically, dumbing-down!
The second is more deliberate – an attempt to actually conceal the underlying processes through restricting the user’s access through a very limiting user interface, which provides just enough interaction and controls for the user to view and use only their portion of the process – strictly partitioned by role, and thus usually has a very vague idea of what happens in the process before their involvement, and what happens after they are done with their bit.
This sad state of affairs is more prevalent than you might think – look around you…. How many applications and web sites take the trouble to provide users a clear and simple map of their process? I don’t mean navigation aids like bread-crumbs or such – I mean usable information about what happens to the information you provide or transaction you execute.
There is - simplification by prioritization, simplification by streamlining of processes, simplification by masking, simplification through standardization, simplification through elimination, simplification by integration, simplification through decomposition (modularization) and simplification through automation….
I’m sure there are a few more ways, but what’s important is – all of them are valid, to a point. What’s more important - they are not mutually exclusive – a project teams can utilize all or some of the above methods of simplification in developing a valid solution.
Of all the methods of simplification, the most cosmetic is Simplification by masking – basically, throwing a sheet over the mess, so the user does not see the inner workings, if they do not need to interact with it on a regular basis. This approach is just as valid as the others, of course… and often, that is the only recourse that a designer has when told to make it “usable”. Although this approach can be utilized at any time in the development process, it has minimal impact if applied by itself, ignoring the rest of the “simplification” methods available.
Of course, the designer may not have the authority or skill to apply the other methods, it is important to know that these other methods are available. Project teams tend to discuss or utilize most of these simplification processes at some point or the other, but not necessarily in a systematic way –
If they are used properly, it would make the life of the UI designer that much easier, since he or she would be “skinning” a optimally designed application, i.e, one that has taken ALL system component needs into consideration, INCLUDING the human.
There is the fear, of course, of treating the user with indifference by reducing them to the level of a system component, but that is easily addressed by understanding that the human in the loop is the “control component” and thus at the top of the system hierarchy. This cannot be emphasized enough – but keeping this in mind, it should be possible to simplify without “dumbing down”.
_____________________________________
copyright 2004 ajoy muralidhar. all names, websites and brands referenced are the copyright or trademark of their respective owners.
In all the years I have been working in Human Factors, I have always looked for ways to make things easier for the "User". Ways to reduce the physical and cognitive burden by trying to reduce the number things to remember, reduce the number of interactions, reduce the need to think etc. We all “know” that the key to usable products and applications is simplification.
What if we are wrong? What if we are short-changing the user communities we are designing for? What if we simplify things to such a point that a user is helpless when faced with a problem? Can our efforts actually hinder the user of a product or application when faced with an “abnormal” situation?
Problem solving, decision making under uncertainty are both highly valued qualities, in any environment – business, military or civilian. When we surround people with applications and products that do not require them to reason things out, or to investigate different options, we may be undermining our user’s ability to form a good mental representation of the underlying processes and thus their ability to respond to “out of the ordinary” situations.
When we talk of simplification, what do we really mean? Does it mean bringing everything down to the lowest common denominator? What would it mean if we designed everything like that? Is simplification the same as “dumbing down”?
Dumbing things down does not make them usable, does it?
Does “over” - simplification really make things more usable? If a function or process is complex in nature, due to whatever reason – criticality, number of interactions, inter-related processes, time critical responses, etc – it is possible that they can be simplified only to a certain extent – beyond that, simplification may prove to be a detrimental factor because it conceals the true nature of the beast.
What if we are doing is actually deleterious to the user’s understanding of the system? Is there a way that they can rip off the cover to get at the innards? After all, we are not in a factory environment where the most efficient interaction is valued the most because it increases manufacturing production. We are usually looking to streamline workflows to increase user effectiveness, reduce errors and enhance the user’s experience with the system they are interacting with. A simplified system that leaves the user with a false sense of security because they are unable to view the “hidden” processes may prove disastrous in an emergency situation.
Usability cannot mean “dumbed down”, and the role of an UI designer is not to look for ways to dumb down the product interface and interactions to fit the so called lowest common denominator among their end-user groups.
How does dumbed-down design occur? There are 2 ways – the first is when a process or interaction is automated, and the user is relieved of “decision making” responsibility for a particular task – this reduces the burden on the user, ostensibly leaving them free to concentrate on more important tasks. However, some portions of the process may not be automated, leaving the User Interface with a vestigial screen or two which the user has to interact with, even though it serves no useful purpose.
Whatever interactions the designer chooses to leave behind, it is usually to preserve the user’s perception of process integrity, so they will have the feeling of going through all the steps they are used to. This implies that the user cannot cope with change or accept improvement in processes – basically, dumbing-down!
The second is more deliberate – an attempt to actually conceal the underlying processes through restricting the user’s access through a very limiting user interface, which provides just enough interaction and controls for the user to view and use only their portion of the process – strictly partitioned by role, and thus usually has a very vague idea of what happens in the process before their involvement, and what happens after they are done with their bit.
This sad state of affairs is more prevalent than you might think – look around you…. How many applications and web sites take the trouble to provide users a clear and simple map of their process? I don’t mean navigation aids like bread-crumbs or such – I mean usable information about what happens to the information you provide or transaction you execute.
There is - simplification by prioritization, simplification by streamlining of processes, simplification by masking, simplification through standardization, simplification through elimination, simplification by integration, simplification through decomposition (modularization) and simplification through automation….
I’m sure there are a few more ways, but what’s important is – all of them are valid, to a point. What’s more important - they are not mutually exclusive – a project teams can utilize all or some of the above methods of simplification in developing a valid solution.
Of all the methods of simplification, the most cosmetic is Simplification by masking – basically, throwing a sheet over the mess, so the user does not see the inner workings, if they do not need to interact with it on a regular basis. This approach is just as valid as the others, of course… and often, that is the only recourse that a designer has when told to make it “usable”. Although this approach can be utilized at any time in the development process, it has minimal impact if applied by itself, ignoring the rest of the “simplification” methods available.
Of course, the designer may not have the authority or skill to apply the other methods, it is important to know that these other methods are available. Project teams tend to discuss or utilize most of these simplification processes at some point or the other, but not necessarily in a systematic way –
If they are used properly, it would make the life of the UI designer that much easier, since he or she would be “skinning” a optimally designed application, i.e, one that has taken ALL system component needs into consideration, INCLUDING the human.
There is the fear, of course, of treating the user with indifference by reducing them to the level of a system component, but that is easily addressed by understanding that the human in the loop is the “control component” and thus at the top of the system hierarchy. This cannot be emphasized enough – but keeping this in mind, it should be possible to simplify without “dumbing down”.
_____________________________________
copyright 2004 ajoy muralidhar. all names, websites and brands referenced are the copyright or trademark of their respective owners.
posted by gentlepoet @ 9/27/2004 08:41:00 AM
0 Comments:
Post a Comment
<< Home