> Hi, > > The subject matter is new to me and I'll make it short > and "sweet?". So, I'll just throw out something raw, > and pls help me to chew it. > Major premise: I think it's more about Interface > Usability Assessment, rather than functionality > assessment. > > The way to tackle it is first to decompose all the > components of the Interface, then each screen under > each component. Question, would compoment A weigh more > than component B? Would screen A weigh more than > screen B? Yes? depending on each's contribution to > system/application functionality? Consult with the > client as well? What's the usual practice here?
Usability developer's that don't consult with the END USERS (which may or often may not be the client) will have problems. Your main source of information concerning applicability and usability are the people using the thing. Ignore them at your peril! There are several methodologies for development - any good one will include usability as a required aspect. The most popular (or so it seems) right now is UML (Unified Modeling Language). In UML you start "Top down". You first assign roles to each participating user or system (these are "Actors") and then model, in increasing more detail, how these actors interact. The key is that you're moving regularly and cleanly for less detail to more and that all documentation builds from that which came before. The problem that I see is that most companies only use parts of UML - "Business" takes on the role of usability consultant and designer - this is wrong. At first you have vague notions of what you need: "I want a website to sell movie tickets". You define your actors: Theaters, MovieGoers, etc. For each actor you define properties and tasks: a Moviegoer has a name andcan buy a ticket, a Theater has a number of available seats and can sell a ticket. At this point usability work starts. What does a moviegoer want? They want to find movies and buy tickets. How do they want to find movies? They want to search by location, title, star, etc. You get all this information via usability/discovery techniques: interviewing moviegoers, roleplaying (among the developers), industry research/information, focus groups and so forth. Then, as your developer's are continuing down the technical path (database design, security, etc) your usability people are creating prototypes. These prototypes are tested, refined, tested, refined until you're happy. Now the actual functionality (both teams of course are communicating constantly) is bolted on to the interface. The interface is then usability tested again (and maybe again and again) for performance, response, and expectation. Throughout the latter part of this phase visual designers have been working hard as well: they're designs enliven the system and give it the emotional presentation required by the client. These are also tested (focus groups or surveys are common tools for this). > Secondly, what's the value of Interface Assessment if > it is done without correlation to Functionality > Assessment? A nice-looking house built on sand won't > stand. I think what you mean by "Interface Assessment" is what we called "Usability Inventory" - an after the fact usability review. These are good if you failed to do usability during the project cycle, but are by their nature attempts to fix something rather than build it correctly the first time. Everything grows from the ground. A bad architecture can result in bad coding. Bad coding can lead to bad usability. Bad Visual design can lead to bad usability and so on. If a site is written badly (is slow, prone to errors, etc) or looks badly then it's harder to use: thus it has poor usability. You really can't build a "nice-looking house on sand" since the fact that the house is built on sand will cause it to look badly (to really stretch the metaphor). Usability encompasses all aspects of how a site looks, "feels", reacts and works. Usability needs to be considered throughout the project development, as soon as possible. Otherwise it's just a tacked-on aside (and very often when usability is done last, in isolation, it's impossible to make needed changes). All too often this is the case: a site is built then, right before launch, a "UI Guy" gets to do a review. At that point it's really too late to fix many things. Jim Davis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
