It's intended to provide short, general answers to broad topics about user-centered design. (They're considering adding a separate section to handle the non-usability questions, which do, of course, get submitted. Should be fun!)
This week several of us in InfoDev attended a 2-day seminar on Web Content Usability, taught by Expero, a local usability firm. Lots to say about that, but I'll start with the end, where we asked for and received a quick evaluation of usability issues with our new Helpsite. Here's what we got, in the order they were brainstormed:
- Do not display internal codes (especially system-generated Guids) to the customer.
Examples: If 0 represents no selection, display something like "(None)," not "0." If 1-99999 represents a range of values starting at 1 with no maximum, display "1-", not "1-99999." Even if there is a physical limit to the maximum value, the customer only sees a value if he/she specified the value.
- Currency values are displayed in a fixed-width font with the proper number of decimal places for the currency (e.g. 2 places for US dollars), right aligned, and with no currency symbol. However, the abbreviation for the currency in use (e.g. USD) is displayed somewhere on every page that has currency values. If a page displays values in multiple currencies, then the currency for each value must be unambiguous.
- Dates and times are displayed according to the conventions of the locale.
- If the customer cannot enter a time, no time should be displayed. (Do not display midnight in this case.)
- Recommended: Display the day of the week only when it is helpful and there is space.
- Recommended: Display the month as a word (e.g. January) only when some formality is called for (i.e. in a printed letter) and there is space.
- Numeric values (including currency values) are displayed in a fixed-width font and right aligned. Note that alignment should be with other values, not with the right edge of the panel.
Recommended: Try to avoid different numbers of decimal places in the same column, or align to the decimal point.
Exception: ID numbers (such as zip codes, phone numbers, part numbers, SSN, and the like) are left aligned, even when they are entirely numeric.
- For numeric values where the number of places varies (e.g. quantities, which could be pounds, ounces, gallons, each, etc.) trailing zeros after the decimal place will be removed. For example, 3.00 shirts will be changed to 3 shirts.
Rationale: This may cause misalignment, but it is not that important because it will rarely happen and is not all that confusing. Nobody is going to be scanning the column or trying to add 3 shirts to 2.5 pounds of nails, so alignment is not all that important in this case.
- Display fields in the order they are usually displayed and in the order they normally occur.
Example: On order forms, invoices, and throughout the system, the number of items precedes the unit of measure, so the user sees 1 Box, not Box 1.
- Omit labels and put several fields on a line when it is natural to do so and the meaning is clear.
Example: 1 Box, not
Quantity 1 Unit Box
- Recommended: Controls that are not available (because of other parameter choices, security, roles, etc.) are shown disabled (gray).
Alternate: They may be hidden instead if a case can be made that the page would be too confusing or cluttered, taking into account the sophistication and training level of the user, and the likelihood that someone for whom controls are disabled or hidden would need those controls.
Exception: Surf-to-Edit controls are hidden from those not authorized to use them.
- When a page is first displayed, the cursor is placed in the field where the customer is most likely to want to enter data, usually the first field on the page.
Items of Note: None
Presenters: Ted Sienknecht, Marcia Kerchner
Concept: We're overlooking a wealth of usability-related data we have on hand!
Where to gather information?
. Lessons learned: Study system usage statistics and user feedback from current/prior releases for possible improvements and functionality
. Software evaluations: Study other software users currently use for implementations they expect or understand
. Field observations: Watch users while they perform relevant tasks and note process, actions, systems, problems, needs, etc.
. Interviews & Focus groups: Use structured inquiry with users about their opinions and experiences
. Task analysis: Investigate typical tasks users perform on the system
. User profiles: Create representative identities for user subgroups (personas)
. Help desk logs: Read help requests for areas for improvement or new functionality
From: Jim Sneeringer [Jim@Sneeringer.com]
Sent: Tuesday, June 12, 2007 8:47 PM
Subject: UPA Conference Report to Date
Tutorial on Pattern Libraries
a. The main think I learned here is that Sara did a great job of setting up or template.
Attached is the workbook from "Creating a Custom UI Pattern Library"
From: Dean Barker [mailto:firstname.lastname@example.org]
Sent: Friday, June 22, 2007 12:49 PM
To: email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org; email@example.com
Presenters: Janice (Ginny) Redish, Whitney Quesenbery
Usable content lets users:
 Find what they need.
People find what they need when
. links use words they know
. content on information pages is in small pieces with good headings
 Understand what they find
People understand information when the content speaks directly to them with
. personal pronouns
. action verbs
. active voice
. words they know
Presenters: Daniel Schwartz, Arin Bhowmick; Oracle
Summary of their experience:
• Specific use case design pattern set = domain abstraction
• Valuable for organizations of any size
• Documentation demands _large_ time commitment!
• Need to create balance, when to reference existing patterns vs. build new
• Critical: properly scope what are pattern vs. product features
• Critical: efficient post-design strategy (just as key as optimal design)
• Design pattern success = documenting best practices for domain + being actually implemented org-wide
Presenters: Laura Mason, Ecora; Gregg Almquist, Experient Interactive and Design
Without Style Guidelines (“The Frankenstein effect”)
. Product was fragmented – page design and language seemed pieced together
. Inconsistency made product harder to use and undermined users’ confidence
. Most important information wasn’t always first on page
. Various synonyms used for the word “enter”
. Tone bounced around from formal legalese to very casual
Presenters: J. Goldberg, Oracle; J. Helfman, Oracle
Recommendations from a usability study of new widescreen page layouts (what users preferred and how they expected such pages to behave):
- Left justify content.
- Make content resize and flow as pages resize.
- Keep page splitters stationary, and let right-side content resize and move in proportion to available page area.
- Have tables always show all columns, unless there's a horizontal scrollbar.
- Make graphs and maps resize with constant aspect ratio, with predefined min/max sizes based on intended tasks.
- Overall: Use a constraint-based liquid layout, rather than redesigning for each display.