jpope@axion.bt.co.uk (john pope) (06/26/91)
A lot of the discussion in this group seems to be bitty: ie I don't like this, I don't like that. I wonder if anyone has any general `rules of thumb' for considering human factors when designing products. I know this sounds a bit like asking someone to unify the laws of physics in a sentence; but I thought it was worth asking. I'd also be interested in people's views on systems analysis methods. To me, many seem to ignore human factors aspects: I'm thinking particularly of when they are used to communicate ideas to users, eg I've heard that ERDs (Entity Relationship Diagrams) and DFDs (Data Flow Diagrams) are easy to review with users. My experience contradicts this. Some methods, eg Soft Systems (a la Checkland and Wilson - Lancaster University) incorporate cartoon-like representations which are quite good but are very open to interpretation John *************************************************************************** e-mail jpope@axion.bt.co.uk (...mcvax!ukc!axion!jpope) 'phone UK +44 473 646651 Royal Mail Requirements Section, Software Technology, G24b SSTF, BTL Martlesham Heath, IPSWICH, Suffolk, UK IP5 7RE in person Room G24b SSTF ***************************************************************************
wbrooks@potomac.ads.com (Bill Brooks) (06/26/91)
In article <1991Jun26.092540@axion.bt.co.uk> jpope@axion.bt.co.uk (john pope) writes: > >I'd also be interested in people's views on systems analysis >methods. To me, many seem to ignore human factors aspects: I have found that starting at a VERY macro view and considering where the system-to-be-developed fits in has been quite helpful. By very macro, I mean looking at it from your client's boss' customer's perspective. Asking questions like: Does it impact rush hour traffic? Does it impact the environment? Sure, this sounds pretty pointless, but even if you only take a few minutes at these most macro perspectives and progress downward, it really helps a lot in requirements analysis and understanding the problem. I think any experienced system developer will agree (or maybe not :^) that a client almost never states the problem well enough to be solved. He usually has hidden agendas or there are other factors he either hasn't taken into account (like upcoming relocation or an impending telecommuting policy) or isn't aware of (recent technology innovations). So it is important for the system engineer and the system analyst to understand the whole problem. As far as commercial tools/analytical techniques, I don't really have a favored approach. I use what appears to be most effective for each situation or client. That usually means using a variety of redundant tools at first and continuing with those that are best understood or received. I will say though that storyboards have been the most effective (yeah, I know. They take a long time and aren't as useful as other tools for the developers, but they do give the customer a good view of the proposed system). -- William Brooks UUCP: sun!sundc!potomac!wbrooks Advanced Decision Systems Internet: wbrooks@potomac.ads.com
mcgregor@hemlock.Atherton.COM (Scott McGregor) (06/27/91)
In article <1991Jun26.092540@axion.bt.co.uk>, jpope@axion.bt.co.uk (john pope) writes: > I wonder if anyone has any general `rules of thumb' for > considering human factors when designing products. > I know this sounds a bit like asking someone to unify > the laws of physics in a sentence; but I thought it was > worth asking. I've been needing to write down my thoughts on this topic for the people who work for me for a while, so I might as well do it now, and share this with this group as well. (By the way, I also have a physical unified field theory and a proof that for all x>2, there exists no integers a,b and c where a**x + b**x = c**x, but there is not enough space in the margins here for them... (Note 15). Just kidding :-) Some Simple Rules of Thumb for Designing for Usability Copyright 1991 by Scott L. McGregor (Permission to reproduce by request only, please) 0) Remember, the COMPUTER-AIDED in CAW, CAD, CAM, CASE, etc. means that the computer is supposed to aid the user, not vice versa. 1) The human brain, the human sensory system and the human motor system are machines. Like all machines they do some things well and other things less well. Unfortunately, there are many tasks which these machines are asked to do which they are not well suited for. The primary tasks of designing for usability are (note 6): a) identifying the probable failure points of the human machine, and designing the supporting computer system to minimize these demands on these components which would cause them to fail. b) identifying the probable points of advantage in the human machine, and designing the supporting computer system to maximize the use of these capabilities. (Note: typically avoiding failure is more important than maximizing advantage). 2) Major aspects of the human machine are:(Note 1) a) Its ability to retain information, i.e. short term and long term memory. b) Its ability to interchange information with others, i.e. communication. c) Its ability to operate on information, i.e. reasoning ability. d) Its ability to acquire information, i.e. perception. e) Its ability to manipulate its physical world surroundings, i.e. action. 3) Major limitations of memory are: a) very few short term memory "registers" (7+/-2) for storing information used in current reasoning activities. b) long term memory is faulty in many ways: 1) information forgotten (or no longer retrievable on demand) 2) information misremembered. 4) The major technique for augmenting short term human memory is to record data in the physical world where it can be retrieved quickly without the need for remembering (typically this means writing it down and keeping the note in a visible place). In computer interfaces this is a typical function of menus and other precached lists. 5) The major technique for augmenting long term human memory is to record the data in the physical world and organizing it for later retrieval (typically this means writing it down and putting it in a book or file). In computer interfaces this is a typical function of a file or database. 6) The major advantage of the human memory processor is its ability to do associative retrieval on large amounts of unstructured information. 7) The major limitations of human communication are: a) Human communication is frequently imprecise. b) Humans often assume more has been communicated than was actually intended. c) Humans often fail to communicate sufficient information. d) Humans often fail to communicate to a sufficient number of involved parties. 8) The major techniques for improving human commications are: a) Structuring communication and its transmission media to encourage more precision. (Typically this is the role of both paper and electronic forms). b) Structuring communication can also help to reduce problems of assuming that more has been communicated than intended. In addition, feedback loops, either enforced or voluntary can allow detection of miscommunications. c) Augmenting specific communications with explicit copies of information concerning the unstated context of the discussion. (Typically this is the purpose of attachments, bibliographies, references, glossaries, etc.) d) Reproducing information and widespread transmission of information. This is the purpose of nondirective means of information exchange such as publishing, broadcasting, open meetings, bulletin boards and even electronic forms such as Usenet News. and shared databases. 9) Major advantages of human communication forms are: a) brevity -- more is communicated than explicity stated because contextual information is not explictly stated, but understood by both parties. b) ambiguity -- humans are able to communicate somewhat about things that are only imprecisely understood, or for which common context is limited. 10) Major limitations of human reasoning are: a) humans perform tasks best which offer only a limited number of choices (note 2) (a result of the limited short term memory). Humans can perform well tasks which are "wide and shallow" (like choosing dinner from a menu) or "narrow and deep" (like following a recipe). However, they are often challenged by complexity that involves decisions over "wide and deep" decision spaces (such as choosing the right move in chess). (see notes 3) b) humans can perform poorly in tasks that require constant repetition c) humans can perform poorly when demands on their memory or communication capabilities are stretched beyond their limits d) humans can perform poorly in tasks that require consistant accuracy. 11) Major advantages of human reasoning modes are: a) flexible -- able to deal with novel situations b) self-modifying -- able to improve through successive refinement or habit formation (Note 4). c) anticipatory -- able to use past experience and current state to anticipate future needs. (Note 11) 12) Major disadvantages of human perception are a) presumption of the reality of perceived information b) presumption that what is perceived is ALL that there is to perceive. c) selectivity -- you see only what you want to see (or have an established context for understanding) (note 9) d) scope -- For instance your field of vision can only hold so many papers, and they can only be so far before you can no longer read them. 13) Major methods for augmenting human perception are: a) cross checking of multiple information sources b) instrumentation to detect other information c) choice of objective representations (Note 10) d) choice of compact (information intensive) representations (Note 12) 14) Major advantages of human perception are a) covers a wide range of physical world information requirements b) multiple senses can act concurrently to allow greater information acquisition density and automatic data (cross-senses) checking 15) Major disadvantages of human physical manipulation capabilities are the limited strength, endurance, degrees of freedom, speed and precision of human motor skills. 16) Major methods for augmenting human physical capabilities are through applications of simple machines (levers, pullies, screws, inclined planes, gears, ratchets...) assembled to provide increased leverage, endurance, mechanical degrees of freedom, speed and precision. 17) Major advantages of human motor control are human abilities to use perception and motor skills interactively to immediately improve and correct their current performance. (Note 5) 18) Small details matter greatly in their affect on usability. 19) "Logically equivalent" and "mathematically equivalent" representations are not at all likely to be "cognitively" or "usability" equivalent. Also, it is not simply enough that two alternatives support the same desired capabilities, but also that they restrict the same undesired error possibilities. 20) Perceived benefits must balance or exceed perceived efforts, on an INDIVIDUAL basis. A benefit to the group, from the efforts of an individual may not be sufficient to ensure regular performance by the individual if the individual's benefit is too indirect, infrequent or delayed. (Note 8) 21) Take advantage of people's natural skills of anticipation--allow type ahead, mouse-ahead and think-ahead. Pre-cache results of anticipated actions, display status information before it is asked for. 22) Do not lock the user from an action while another action is occuring. Let the user know things are happening, and how things are progressing continuously for lengthy tasks--do not leave a static display (or wait cursor) that leaves the user wondering if something is dead or just slow. 23) Do not gratuitiously entertain the user, but allow the user to enjoy themselves as they learn new things. Make sure they have a good experience with some aspect of the product within 5 minutes the very first time they use it. Ensure there is ongoing reinforcement as they learn more things at least every half an hour, more frequently in environments with frequent interruption. (Note 13) 24) Make the system representations "opaque" so the user focusses on the task and task representations instead. Think DEEPLY about what the user is trying to do, what objects he is concerned with, and what actions he will want to perform on those objects. See if there is a good mapping between those mental objects and actions and the representations, manipulations, and manipulators in the product. Do not fear treading new ground--you may find a representation or mapping that simplifies out many current peripheral tasks and lets the user concentrate on the root tasks--thus simplying work considerably. This may deviate somewhat from conventional ways of doing things--but if it simplifies the work enough it will becoming compelling enough to learn the new habits (a la Visicalc replacing previous matrix manipulation languages). Too often people copy interfaces rather than think deeply and therefore do not contribute as greatly as they might have. On the other hand, gratuitious variation may just inhibit learning and habit formation, so be sure you have a reason based on items above for your variation from convention. 25) Be excellent to each other (and especially to those who would use the products you build). (Note 14) Stand on the shoulders of giants, not on each other's toes (Note 15) -- Read the historical literature, not simply the latest literature, but go back to the 60s and 70s -- Engelbart's NLS, Ivan Sutherland's SketchPad, Xerox PARC's work on Smalltalk and the Altos are still inspirational in the 90s. Notes: Inspirational sources for the above ideas: 1) "Augment Memory, Improve Communication, Enhance Resoning" from Joel Birnbaum. 2) Performance best with few choices ("principle of monotony") from Jef Raskin. 3) "Wide and shallow, narrow and deep" from Don Norman. 4) Importance of habit formation from Jef Raskin. 5) perception/performance feedback loop model from Douglas Engelbart, Don Norman, and Ben Schneiderman. 6) Analysis of the human cognitive abilities from a machine perspective inspired by Herb Simon, Allen Newell, Stuart Card, and Thomas Moran. 7) Electronic Structured Communication ideas leveraged from Tom Malone, Terry Winograd and Francisco Flores. Nonelectronic structured communication theory from Wittgenstein, Austin, and Searle. 8) Individual benefits vs. group benefit economies from Jonathan Grudin 9) Lack of established context preventing perception from James Burke, Thomas Kuhn, Irme Lakatos, Ludwig Wittgenstein. 10) It is not clear if this is really possible--perhaps all representations have their inherent biases they may merely be unintentionally selected . See my writings on 'Visual Literacy". 11) Derived from my own research on "Prescient Agents", and the "Radar O'Reilley Model" of anticipatory behavior. 12) Information density from Edward Tufte. 13) 5 minutes rule from Ted Nelson's "two quarters to learn a video game" rule. 14) Cult Film humor: from Bill and Ted's Excellent Adventure. 15) "On shoulders..." from Isaac Newton, "...on toes" from Brian Reid. 16) "**x ... comment" inspired by Pierre Fermatt. Thanks to all! Scott McGregor Manager of Applications Development Atherton Technology 1333 Bordeaux Drive Sunnyvale, CA 94089 mcgregor@atherton.com fax: 408-744-1607
rsw@cs.brown.EDU (Bob Weiner) (06/27/91)
In article <1991Jun26.092540@axion.bt.co.uk> jpope@axion.bt.co.uk (john pope) writes: > > A lot of the discussion in this group seems to be bitty: > ie I don't like this, I don't like that. > > I wonder if anyone has any general `rules of thumb' for > considering human factors when designing products. * Follow a process like: analyze user needs design test on REAL, naive users, not techno-wizards iterate-design iterate-test ... User testing is essential and all too often left until it is too late. Novice, medium, and expert user feedback is all invaluable. * Try it yourself. Seems obvious, huh? How many people at Microsoft can type command-option-shift-t with verve on a Macintosh? Yet, they seem to put such things in all their programs. (The answer, I believe is that many of them remap their keyboards and so never deal with what they show their user base.) If you're a keyboard junkie, make sure you doubly test your mouse interface. You can generalize these ideas for other types of interfaces. * Employ natural or familiar metaphors accurately. This allows people to draw on their prior experience and thereby become comfortable with the interface more rapidly than if they have no grounding with which to decide how to operate elements of an interface. Example to emulate: Go Corp's use of notebook section dividers (tabs) which when selected/touch, flips the view of the notebook to the starting document page associated with the tab. Example to learn what not to do: Apple's decision to use the garbage can icon as a means of ejecting floppy disks. * Embed deep (as opposed to surface-level) customizability in the product and its interface. Otherwise, people with experience won't be able to make your interface operate in a way they are used to and so most likely won't take full advantage of it. Such a requirement can also drive you to create more modular and coherent designs. * Minimize the focused attention needed to operate your interface (unless it is a proficiency testing or minimal capability testing device. -- Bob Weiner rsw@cs.brown.edu
rpw3@rigden.wpd.sgi.com (Rob Warnock) (06/28/91)
In article <35585@athertn.Atherton.COM> mcgregor@hemlock.Atherton.COM (Scott McGregor) writes: +--------------- | Some Simple Rules of Thumb for Designing for Usability +--------------- Your article is too long; your rules are too many. Thus, your "simple rules" are not themselves very usable. I suggest reading G. A. Miller's classic little paper, "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information" (Psychological Review, 1956). -Rob ----- Rob Warnock, MS-1L/515 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
mcgregor@hemlock.Atherton.COM (Scott McGregor) (06/29/91)
In article <113787@sgi.sgi.com>, rpw3@rigden.wpd.sgi.com (Rob Warnock) writes: > Your article is too long; your rules are too many. Thus, your > "simple rules" are not themselves very usable. Thanks for the feedback. I had a hard time trying to condens e a couple of decades of design experience into heuristics that I could write down in a couple of hours, and which could be read in a couple of minutes and then immediately applied by even our junior staff members who may have had little or no HCI education. While I wound up with too many points (just over 25), I tried to make each one by itself simple--though I would love suggestions on how to state them in even more consise and memorable ways. One thing that always seems to force lots of rules is that there are at least 5 key dimensions: augmenting memory, improving communication, enhancing reasoning, augmenting perception, and enhancing motor skills. Too frequently people only pay attention to one area, and then instead of desigining holistically to the users needs, you get things focussed only on one area: e.g. database (augmenting memory), e-mail and networking (improving communication), agents (enhancing reasoning), displays (augmenting perception), or input devices (enhancing motor skills). In any case,I would welcome more suggestions on how to make the same points more effectively. There are always new people to bring up to speed on this. > I suggest reading G. A. Miller's classic little paper, "The Magical > Number Seven, Plus or Minus Two: Some Limits on Our Capacity for > Processing Information" (Psychological Review, 1956). Great suggestion. I should have referenced this influential paper too (but then again the footnotes were already getting too long as well). Scott McGregor Atherton Technology mcgregor@atherton.com
jtchew@csa3.lbl.gov (JOSEPH T CHEW) (06/29/91)
>I have found that starting at a VERY macro view and considering where the >system-to-be-developed fits in has been quite helpful. Bingo. At the risk of incurring the wrath of Dr. J. vis-a-vis the purpose of this group :) I'd like to endorse a broad definition of user friendliness. It includes everything from the picky details of command wording and mouse dynamics up to the level of product definition. The most treasured compliment anybody ever paid me during my human- factors dabbling was "you have a good systems head," meaning a feel for process flow, feature sets, and user scenarios. You DO have to get down to those picky details, though (regardless of whether or not they are appropriate for discussion here). A product is no friendlier than the sum of its petty aggravations. For somebody whose role is "user advocate," I'd even go so far as to include robustness and freedom from bugs, although that is getting more into ethics and corporate politics than human factors. --Joe "Just another personal opinion from the People's Republic of Berkeley"
yee@osf.org (Michael K. Yee) (07/01/91)
Here are a general list of important 'goals' in designing a good human-computer interface. I don't remember where I got them, but I think that these goals are a good starting point for designing a good graphics user interface. My comments are in '[]'. Important Goals in Graphical User Interface Design -------------------------------------------------- INTUITIVE - If, at any time, the user has difficulty deciphering, manipulating, controlling, or selecting a particular graphical object, that element is too complex. CONSISTENT - All elements of the same type should act identically whereever they may exist on the desktop. For example, pushbuttons should appear the same everywhere on the screen, regardless of the task they perform when selected. [Put simply - "Similar (looking) controls should behave similarly".] CONDUCTIVE TO FREQUENT USE - Cluttered desktops, overly flashy colors, or busy and unessential graphics will tire the users. [Do not over use colors in your GUI as you may end up giving your user interface the angry fruit salad look.] VISUAL CUES - Visual cues direct users' attentions towards necessary elements of the screen; require input, error messages, help, and so on. FLEXIBLE - The ability to customize key GUI elements is important in all aspects ranging from keyboard and mouse usage to the choices of screen colors or appearance of icons. Users must be able to fine tune an application according to their particular habits or tastes. Along with these goals. The work flow of the user of the application should drive the design and layout of the user interface. Without considering the steps used by an user to complete a tasks, your user interface may be awkward for the user to uses to perform daily tasks. A good user interface should be forgiving so that the user can explore the application without fear of inflicting permanent damage. User interfaces that are forgiving and encourages exploration will draw the user into the interface instead of repelling them. Hope this helps someone, =Mike -- == Michael K. Yee <yee@osf.org> -+- OSF/Motif Team == Open Software Foundation - 11 Cambridge Center - Cambridge, MA 02142 == "Live simply, so that others may simply live."