PHASE 4: A "FOOD AND SHELTER" RELEASE
The next significant turn of events occurred when the major release was
intercepted by plans to do a much sooner release. Work on the Next Major
Release would continue, but a large portion of resources were temporarily
rededicated to the urgent "Food and Shelter" release. The
remainder of this briefing will focus on this "Food and Shelter"
release. This release was to have back-end changes only, no UI changes and
no new features. It was nicknamed "food and shelter" to indicate
that it would contain only the essential underlying changes needed to ship
it as soon as possible. Another popular phrase for referring to it
internally was "low-hanging fruit", to give the analogy that the
very apparent, easy, quick things were to be fixed, and nothing else (just
as ripe, low-hanging, fruit is easy to grab). With this philosophy, the
ever-growing number of usability issues in the database had little hope of
getting reduced in the short term.
Reconciling Usability vs. Food and Shelter
To respond to this
change in schedule, the persistent usability team also adopted the
"low-hanging fruit" attitude and compiled a short list of
usability issues based on testing and submitted this to product management
and development. This list included only high priority issues that would
be quick, easy, and low-risk to fix. When an issue was extremely high
priority, but very difficult to fix, the usability team documented the
ideal solution in the database and proposed one or more possible compromise
solutions to development. If the list were too long, it was sure to be
overwhelming and summarily rejected.
UI Specification, Refinements, and Iteration
Fortunately for the usability team (and the end-user), product management
was concerned with finding ways to keep customers satisfied with
improvements to the product without causing further delays. Some of the
largest cc:Mail customer sites had voiced dissatisfaction about some of the
same high priority usability problems observed in testing. Product
management requested that the usability team work with development to find
solutions to these problems.
At this time, the UI designer was still assigned 100% to the ongoing
work on the Next Major Release. She acted in a
consulting role to the usability team and communicated usability results to
the developers on the major release. Due to the limited design resources,
the usability team adopted multi-disciplinary responsibilities and began
writing design specs for some of the highest priority issues in the
usability database. Design rationales were recorded in the Notes database
to ensure against backtracking on an issue in subsequent design
iterations.
Although everyone understood and agreed with the usability issues,
development didn't know what to do about most of them without making major
implementation changes. As this was not possible, since all UI changes had
been forbidden from this release, the usability team presented suggestions
in a more manageable form. Instead of large-scale, ideal solutions to the
biggest problems, multiple partial solutions were presented to development.
Development could then pick the solutions that were most feasible.
Beginning of Document
|
Top of This Page (Phase 4)
Phase 1
|
Phase 2
|
Phase 3
Results and Examples
|
Conclusions