Hi all,
Here’s a pass at adding some more detail to the
charter related activities. It’s still rough but I think in good
enough shape for a round of feedback before fleshing out any further.
Perhaps we can start the discussion here, via email, and at
such time as we have consensus that this is roughly what we want, we can move
it onto the wiki and flesh it out further there. As part of fleshing it
out, we might want to have some supplemental descriptions or links to help project
members understand how to conduct a UI walkthrough, or run a quick and dirty usability
test, etc.
Please send comments.
Cheers,
Troy
POST-MORTEMS
PURPOSE: Assess the state of the project with
respect to usability; prioritize corrective measures and work them into the
release plan
TIMING: At the start of a new development cycle,
during planning phase
WHO DOES THIS: UI lead and interested
others from a given project
APPROACH: Project team gathers usability issues
from sources which may include, but are not limited to, the following:
newsgroup questions, UI walkthroughs, Bugzilla reports, usability tests on the
previous release, etc
OUTPUT:
- Project team members summarize
issues into a list and assign severities to each item (e.g., 1 - prevents
completion of task, 2 - significant delay in task completion, 3 - minor delay
in task completion)
-
File requirements for feature level work, file bug reports for smaller items
-
Post prioritized list on project wiki with links to related requirements/bug
reports for items that have them (example list format: itemID, description,
severity, requirement/bug report link, assigned release)
MID CYCLE SHOW AND TELLS
PURPOSE: Share information about what is under
way in the various projects; early identification and dissemination of good UI solutions,
early identification and dissuasion from not-so-good UI practices
TIMING: Near the middle of the development cycle
WHO DOES THIS: UIBP group schedules these
meetings with UI leads from the various project teams; this will likely involve
only a subset of the projects over a given cycle due to time constraints
APPROACH: A given project team demos the major
features being added for the release. Demos should reflect typical usage scenarios.
Presentation must accommodate a distributed audience (e.g., use WebEx or
comparable technology). Although the meeting will focus on a given project,
each meeting should be publicized to all project UI personnel so others can
optionally attend.
OUTPUT:
-
UIBP group culls potential examples - whether positive or negative - for
addressing in the UI guidelines. These are kept in a sandbox type area of the
wiki.
-
Any suggestions for UI improvements from the UIBP group are communicated
directly to the project UI lead
LAST CHANCE UI REVIEW
PURPOSE: Identify candidates for final hour
usability/UI cleanup. These items will tend to be cosmetic since few if
any destabilizing changes can be introduced at this point.
TIMING: Late in the development cycle - post
code complete but fairly early in the bug fixing phase
WHO DOES THIS: Minimally, the UI team members
from each project; it's also a good idea to invite one or two additional
individuals who aren't as close to the project - they can offer a novel
viewpoint
APPROACH:
-
Members of the review group refresh their recollection of the UI guidelines
checklist (each member can cover several sections)
-
The group jointly walks through the product, in the role of a new user,
following the major usage scenarios, and identifying areas for improvement
-
A list of potential fixes is prioritized and the set that will actually get
fixed is decided upon
-
The final fix list is posted on the project wiki