UI design myths revisited
Eons ago - uh, actually, make that 2001 - Dr. Paul Smith, a HCI professional at IBM's Toronto software lab wrote an interesting paper titled "Debunking the myths of UI Design". The good doctor updated it in early 2002, with fresh insights.
Reading it again in August 2004, I was struck that many of the same misconceptions Dr. Smith talked about are still prevalent now... you'd think that with the hard knocks the industry has taken in the aftermath of the Big Bust, we'd be well grounded in reality by now.
Anyway, I was wondering if my fellow UI designers felt the same way.I know we have made a great deal of progress over the years, and although I probably still cling to an irrational belief or two (the irrationality just proves that I'm still human, after all. machinespace hasn't assimilated me completely - yet)
I'll start by restating the myths that Dr. Smith originally listed, and then discuss them one by one with my interpretation of each in terms of current realities. There are some myths and misconceptions still left to debunk and destroy.
Myth 1: Design is a Luxury
Reality: hmmm. No way. Design was never a luxury, even if it is narrowly applied to just the UI. Design of a website or application goes far beyond the UI, making everyone involved in the development project a designer of sorts. However, even if we take the "narrow" definition and limit it to just the User Interface, design cannot be considered something "nice to have, but not really needed". Even if we were to disregard an aesthetically pleasing UI, the customer demands at the very least, a well laid out, easily understandable, clearly marked interface. That's design, isn't it? And what of the client? they don't consider the protection of their company image and branding a luxury, do they? Things have definitely changed... User expectations for web sites and web based applications are so high now, and demands excellence in design. Mediocre doesn't cut it anymore, even if it meets all functional expectations. And no, we aren't even in the realm of "experience" here - just basic expectations.
Myth 2: Developing a customer solution is just conceptually and logistically too big to tackle; people working at the solution level will get bogged down in unmanageable issues. You should develop the product as a set of components, and then organize your development team to mimic the product.
Reality: That may very well be true - developing a complete solution is challenging, and requires the cooperation of the whole team. It is very easy for people to scurry off and build their little components and bring them back to be assembled, but this leads to duplication of work, missed requirements, integration problems etc etc, let alone having something that works as a seamless whole. If there is anything that we have learnt in the last few years, it is that the application or web site information architecture and system architecture have to be worked out fully, with all the interaction between the various components accounted for. A solution cannot be considered valid if it does not meet this criteria. The Development team should understand the product as a whole, and should not be broken up at the component level. Failure to do so will result in a product or application that may be functional, but which is difficult to maintain, upgrade or scale.
Myth 3: User interface design responsibility is best distributed within components. Each implementer designs the user interface for his module.
Reality: We know that this is a sure recipe for disaster... the application as a whole needs a consistent look and feel, and having each component developer design the UI for their module will result in a hodge-podge of design styles and runs the risk of visually and logically fragmented.
Myth 4: User interface guidelines solve the problem of distributed design.
Reality: Guidelines have their place, and serve a useful purpose. A designer depends on his or her past experience in creating a design and irrespective of what a design guide may recommend, that designer's interpretation of the guide is ultimately what is going to be in the design. The application look and feel itself may be dictated by corporate identity standards, but the application interactions should allow for some flexibility in interpretation for the UI designer and the developer. Making the guidelines more rigid does not work - they cease to be guidelines and become specifications, limiting the designers' options. Worse, strict guidelines may influence designer behavior adversely, resulting in cookie cutter solutions for every problem.
Myth 5: Teamwork happens.
Reality: Who are we kidding? We've known for years that application development for the internet cannot be factionalized, but to this day we cannot get beyond labelling each other - we're still UI designers, web developers, business analysts etc etc etc. This sectarian approach to application development is non-productive and wasteful of resources. Team work cannot happen in an environment where there are differences in perception of the importance of each other roles - a UI designer is not more important than any other team member, no matter what their level of involvement. The first step to true teamwork is to accept this fact. The second step is to acknowledge that we are just the steward of our primary tasks -The ownership of each component of the solution (whether it's the UI, databases, hardware, whatever) is with the whole team.
Myth 6: Human-computer interaction experts should carry out both design and feedback activities.
Reality: Not true then and not true now. Who are the experts anyway? Are they not practitioners like you and I? Does years of immersion in the internet world somehow give us a special insight and perspective on the merits and drawbacks of one approach over another? Expertise and education does not free us from bias... not by a long shot. Since we aren't talking about just UI design here, I'll admit that the HCI expert as designer can do a great job in designing the information architecture and planning the interaction models for each user interface, in order to provide the best possible user experience - but unless the HCI specialist is also trained in graphical arts, I'd leave the visual design to a graphic designer. Intranet based applications which already have a defined UI look and feel " corporate wrapper" don’t count, of course, unless there is are some unusual display needs to be accounted for. As for carrying out the "feedback" - the HCI expert cannot compare to the subject matter experts drawn from among representative users and support personnel. It is advisable to solicit feedback from as many types of users and stakeholders as possible, since no HCI specialist can possibly acquire the necessary depth of business process knowledge to be able to account for every possible interaction.
Myth 7: Software companies generally assign usability a high priority.
Reality: High priority yes, but only as it does not impact production schedules. In a crunch, the company's need to make their products "feature rich" seems to override the need to make the existing features usable. Much effort is spent on making the added features functionala at any cost, so marketing can claim that they are available in the product - even though they may be inconvenient or non-intuitive. In most cases, Usability is the first casuality of the shrinking budget or slipped schedule, and although the usability situation has improved vastly over the years due in part to the relative ease of upgrading web sites and web-based applications. Software Companies generally want to project an user-friendly image and are willing to do a great deal to accommodate their user's needs, since usability is equated with acceptance and thus increased sales. They are keenly aware that their competition would use any usability deficiencies as a weapon in their battle for market share. Still needed - Usability to be viewed as a non-negotiable business requirement on par with Performance.
Myth 8: Industry pressure requires a full-court press on the current release.
Reality: Nope. Not at all... The phased release model with a product being released with core functionality only, and then upgraded over a series of followup releases seems to be working - especially if upgrades can be provided at a low or reasonable cost (and of course, all security related patches being provided in a timely manner free of cost). Anti-virus software makers, Yahoo Messenger, MSN Messenger etc have been using this model for years now. Also, the acceptability of the updates is enhanced if it is done unobtrusively without affecting ongoing tasks, and the user is permitted to retain control over downloading and installation. However, I have noticed that this approach seems to work better for Utility software that business or entertainment software. These classes of software have a better chance of succeeding if they are " functionally complete" when they are released, and upgrades are aimed at improving experience rather than functionality.
Myth 9: Successful software companies develop technology, package it, and market it. The packaging is essentially assembling available parts into a customer solution.
Reality: Successful companies, by definition, are those who provide Customers with usable solutions that meet one or more business needs - whether they choose to do so by assembling an application from parts and components they have laying around, or by designing something from scratch to meet a specific customer's need. The solution offered has to be stable, innovative and offer definite cost and resource advantages over the existing or currently utilized technology or process. No amount of marketing hype or fancy packaging can get away from that simple truth - to provide the customer with what he or she wants. Sometimes, the need may be there, but a customer may not be willing or able to expend the resources that are needed to acquire the solutions that are most suited for their business needs - a successful company is one that is adept at recognizing the constraints that their potential customers are bound by, and offering solutions that help them work around the constraining factors - flexible solutions that can grow as their customers need grow, without requiring a huge investment in money, time and people resources. Solutions have to be truly customizable down to the last step. Pseudo-flexibility (or is it quasi-flexible) doesn't cut it. A company that can provide such flexible, scalable solutions at a reasonable cost will have the widest customer base, and thus the greatest chance of success.
Myth 10: Usability and functionality have separate requirements.
Reality: This one deserves a separate article, so please see the article "User Requirements = Business Requirements" dated 08/24/2004
____________________________________
More to come - watch this space. Dr. Smith discussed 21 myths in his paper, so we have a bunch more to explore :)
for those who are interested, the original paper may be downloaded from the IBM site. Here's a link.. I commend IBM for making their archives available. They are a great resource.
http://www-106.ibm.com/developerworks/library/us-myth.html
_____________________________________
copyright 2004 ajoy muralidhar. all names, websites and brands referenced are the copyright/trademark of their respective owners.
Reading it again in August 2004, I was struck that many of the same misconceptions Dr. Smith talked about are still prevalent now... you'd think that with the hard knocks the industry has taken in the aftermath of the Big Bust, we'd be well grounded in reality by now.
Anyway, I was wondering if my fellow UI designers felt the same way.I know we have made a great deal of progress over the years, and although I probably still cling to an irrational belief or two (the irrationality just proves that I'm still human, after all. machinespace hasn't assimilated me completely - yet)
I'll start by restating the myths that Dr. Smith originally listed, and then discuss them one by one with my interpretation of each in terms of current realities. There are some myths and misconceptions still left to debunk and destroy.
Myth 1: Design is a Luxury
Reality: hmmm. No way. Design was never a luxury, even if it is narrowly applied to just the UI. Design of a website or application goes far beyond the UI, making everyone involved in the development project a designer of sorts. However, even if we take the "narrow" definition and limit it to just the User Interface, design cannot be considered something "nice to have, but not really needed". Even if we were to disregard an aesthetically pleasing UI, the customer demands at the very least, a well laid out, easily understandable, clearly marked interface. That's design, isn't it? And what of the client? they don't consider the protection of their company image and branding a luxury, do they? Things have definitely changed... User expectations for web sites and web based applications are so high now, and demands excellence in design. Mediocre doesn't cut it anymore, even if it meets all functional expectations. And no, we aren't even in the realm of "experience" here - just basic expectations.
Myth 2: Developing a customer solution is just conceptually and logistically too big to tackle; people working at the solution level will get bogged down in unmanageable issues. You should develop the product as a set of components, and then organize your development team to mimic the product.
Reality: That may very well be true - developing a complete solution is challenging, and requires the cooperation of the whole team. It is very easy for people to scurry off and build their little components and bring them back to be assembled, but this leads to duplication of work, missed requirements, integration problems etc etc, let alone having something that works as a seamless whole. If there is anything that we have learnt in the last few years, it is that the application or web site information architecture and system architecture have to be worked out fully, with all the interaction between the various components accounted for. A solution cannot be considered valid if it does not meet this criteria. The Development team should understand the product as a whole, and should not be broken up at the component level. Failure to do so will result in a product or application that may be functional, but which is difficult to maintain, upgrade or scale.
Myth 3: User interface design responsibility is best distributed within components. Each implementer designs the user interface for his module.
Reality: We know that this is a sure recipe for disaster... the application as a whole needs a consistent look and feel, and having each component developer design the UI for their module will result in a hodge-podge of design styles and runs the risk of visually and logically fragmented.
Myth 4: User interface guidelines solve the problem of distributed design.
Reality: Guidelines have their place, and serve a useful purpose. A designer depends on his or her past experience in creating a design and irrespective of what a design guide may recommend, that designer's interpretation of the guide is ultimately what is going to be in the design. The application look and feel itself may be dictated by corporate identity standards, but the application interactions should allow for some flexibility in interpretation for the UI designer and the developer. Making the guidelines more rigid does not work - they cease to be guidelines and become specifications, limiting the designers' options. Worse, strict guidelines may influence designer behavior adversely, resulting in cookie cutter solutions for every problem.
Myth 5: Teamwork happens.
Reality: Who are we kidding? We've known for years that application development for the internet cannot be factionalized, but to this day we cannot get beyond labelling each other - we're still UI designers, web developers, business analysts etc etc etc. This sectarian approach to application development is non-productive and wasteful of resources. Team work cannot happen in an environment where there are differences in perception of the importance of each other roles - a UI designer is not more important than any other team member, no matter what their level of involvement. The first step to true teamwork is to accept this fact. The second step is to acknowledge that we are just the steward of our primary tasks -The ownership of each component of the solution (whether it's the UI, databases, hardware, whatever) is with the whole team.
Myth 6: Human-computer interaction experts should carry out both design and feedback activities.
Reality: Not true then and not true now. Who are the experts anyway? Are they not practitioners like you and I? Does years of immersion in the internet world somehow give us a special insight and perspective on the merits and drawbacks of one approach over another? Expertise and education does not free us from bias... not by a long shot. Since we aren't talking about just UI design here, I'll admit that the HCI expert as designer can do a great job in designing the information architecture and planning the interaction models for each user interface, in order to provide the best possible user experience - but unless the HCI specialist is also trained in graphical arts, I'd leave the visual design to a graphic designer. Intranet based applications which already have a defined UI look and feel " corporate wrapper" don’t count, of course, unless there is are some unusual display needs to be accounted for. As for carrying out the "feedback" - the HCI expert cannot compare to the subject matter experts drawn from among representative users and support personnel. It is advisable to solicit feedback from as many types of users and stakeholders as possible, since no HCI specialist can possibly acquire the necessary depth of business process knowledge to be able to account for every possible interaction.
Myth 7: Software companies generally assign usability a high priority.
Reality: High priority yes, but only as it does not impact production schedules. In a crunch, the company's need to make their products "feature rich" seems to override the need to make the existing features usable. Much effort is spent on making the added features functionala at any cost, so marketing can claim that they are available in the product - even though they may be inconvenient or non-intuitive. In most cases, Usability is the first casuality of the shrinking budget or slipped schedule, and although the usability situation has improved vastly over the years due in part to the relative ease of upgrading web sites and web-based applications. Software Companies generally want to project an user-friendly image and are willing to do a great deal to accommodate their user's needs, since usability is equated with acceptance and thus increased sales. They are keenly aware that their competition would use any usability deficiencies as a weapon in their battle for market share. Still needed - Usability to be viewed as a non-negotiable business requirement on par with Performance.
Myth 8: Industry pressure requires a full-court press on the current release.
Reality: Nope. Not at all... The phased release model with a product being released with core functionality only, and then upgraded over a series of followup releases seems to be working - especially if upgrades can be provided at a low or reasonable cost (and of course, all security related patches being provided in a timely manner free of cost). Anti-virus software makers, Yahoo Messenger, MSN Messenger etc have been using this model for years now. Also, the acceptability of the updates is enhanced if it is done unobtrusively without affecting ongoing tasks, and the user is permitted to retain control over downloading and installation. However, I have noticed that this approach seems to work better for Utility software that business or entertainment software. These classes of software have a better chance of succeeding if they are " functionally complete" when they are released, and upgrades are aimed at improving experience rather than functionality.
Myth 9: Successful software companies develop technology, package it, and market it. The packaging is essentially assembling available parts into a customer solution.
Reality: Successful companies, by definition, are those who provide Customers with usable solutions that meet one or more business needs - whether they choose to do so by assembling an application from parts and components they have laying around, or by designing something from scratch to meet a specific customer's need. The solution offered has to be stable, innovative and offer definite cost and resource advantages over the existing or currently utilized technology or process. No amount of marketing hype or fancy packaging can get away from that simple truth - to provide the customer with what he or she wants. Sometimes, the need may be there, but a customer may not be willing or able to expend the resources that are needed to acquire the solutions that are most suited for their business needs - a successful company is one that is adept at recognizing the constraints that their potential customers are bound by, and offering solutions that help them work around the constraining factors - flexible solutions that can grow as their customers need grow, without requiring a huge investment in money, time and people resources. Solutions have to be truly customizable down to the last step. Pseudo-flexibility (or is it quasi-flexible) doesn't cut it. A company that can provide such flexible, scalable solutions at a reasonable cost will have the widest customer base, and thus the greatest chance of success.
Myth 10: Usability and functionality have separate requirements.
Reality: This one deserves a separate article, so please see the article "User Requirements = Business Requirements" dated 08/24/2004
____________________________________
More to come - watch this space. Dr. Smith discussed 21 myths in his paper, so we have a bunch more to explore :)
for those who are interested, the original paper may be downloaded from the IBM site. Here's a link.. I commend IBM for making their archives available. They are a great resource.
http://www-106.ibm.com/developerworks/library/us-myth.html
_____________________________________
copyright 2004 ajoy muralidhar. all names, websites and brands referenced are the copyright/trademark of their respective owners.
posted by gentlepoet @ 8/23/2004 04:45:00 PM
0 Comments:
Post a Comment
<< Home