Thank you very much indeed for your thoughtful input. Some comments below.
>> 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). Years ago, at BlueCross & BlueShield, I was taught to use Use Case (UC) methodology but I guess UML is gaining ground. > >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. Sounds similar to UC. > >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. I was alerted to a potential project essentially called "XYZ Interface Assessment", and this XYZ may very well be a legency system/application. > >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). Yes and No. If the house's builing material is real, man, the house simply can't be built on that foundation otherwise possible. > >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. I agree it's never enough to stress the importance of usability through project phases. Probably, application or system may be more representative than "site" since the former could cover legency system as well. >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 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
