Revision as of 15:14, 14 June 2007

DISCLAIMER: This is an initial draft of a general guidance on how developers shall work with UX. Please feel free to comment on it, suggest changes, or ask questions about it at any time. As soon as a first stable version emerges, I will announce this on more public channels.

Thanks, --Lutz Hoeger 13:30, 14 June 2007 (CEST)

Why work with User Experience?

User experience (UX) engineering advocates the user perspective by providing insights to the user’s mental model. Within the development process, UX can take on a variety of tasks, from UX design (interaction, UI, graphic design, layout, terminology), through usability evaluations (requirements engineering, competitive analysis, heuristic evaluations, usability studies), up to HCI research (HCI know-how, GUI style guides, usability metrics).

When do you need UX?

Some changes have a high impact on users. We strongly advise you to include UX into the development of such features or issue fixes. Here are some general examples for these features:

• Changes to the "first impression" part of the user interface (overall appearance, main menu, tool bars, standard shortcuts)
• Work flow changes (introducing new work flow steps, dialog boxes, error messages, streamlining the work flow)
• Changing default settings, in particular if it affects the two above

When do you not need UX?

Changing the UI does not necessarily mean that UX engineering needs to be included. For changes that have lower impact on the user, you can often apply common HCI guidelines by yourself. Here are a few hints / examples for changes, where you do not need to include UX engineering:

• Changes to "well hidden" parts of the UI, like the "more"-part of a rarely used dialog.
• Changes that have already been designed (or sketched out well) in a related specification document.
• You know how to apply HCI or UI design guidelines on your own.

How to contact UX / how to request assistance

• • send an e-mail to mailto:discuss@ux.openoffice.org (later to be changed into mailto: issues @ ux.openffice.org)

What UX needs from you

• • issue ID
  • short description of the change & why you changed it
  • if your change affects the UI, ideally provide a screen shot of your patch in action
  • optionally: provide a URL to an install set (preferably Windows, but Linux/MacOSX/Solaris work, too) including your patch

What can you expect from UX?

• • initial response within one week
  • a name / OOo issuetracker ID of a UX engineer to assign the issue to
  • alternatively, the answer may be "no resources, go with your best guess"
  • if you don't hear anything from UX within two weeks, just proceed