Usage Guidance |
Tasks to design and prototype the user-interface are performed iteratively throughout the Elaboration iterations. Early
iterations focus on the initial user interface design, which includes the identification and design of the key user
interface elements and the navigation paths between them. Storyboarding is an effective technique that can be used during user-interface
design to gain a better understanding of how the user interface should behave. Once consensus on the initial
user-interface design has been reached, then the development of an executable user-interface prototype begins. Feedback
on the prototype is fed back into the user-interface design (and possibly even the requirements). The initial prototype
typically supports only a subset of the system's features. In subsequent iterations, the prototype is expanded,
gradually adding broader coverage of the system's features. The main benefit of producing non-functional versions of
the user-interface during user-interface design is to postpone the investment of more elaborate and costly functional
user-interface prototypes until there is consensus on the overall user-interface design. It is important to work
closely with users and potential users of the system when designing and prototyping the user-interface in order to
confirm and validate the usability of the system.
A number of use-case analysis workshops may be organized in parallel, limited only by the available resource pool and
the skills of the participants. As soon as possible following each use-case analysis workshop, some members of the
workshop and some members of the architecture team should work to merge the results of the workshop in
the identification of design elements. Members of both teams are essential: the use-case analysis team members
understand the context in which the analysis classes were identified, while the architecture team understands the
greater context of the design as well as other use cases which have already been identified.
As the design work matures and stabilizes, increasingly larger parts of it can and should be reviewed. Smaller, more
focused reviews are better than large all-encompassing reviews; eight two-hour reviews focused on very specific aspects
are significantly better than a single review spanning two days. In the focused reviews, define objectives to bound the
focus of the review, and ensure that a small review team with the right skills for the review, given the objectives, is
available for the review. Early reviews should focus primarily on the integrity of layering and packaging in the
design, the stability and quality of the interfaces, and the completeness of coverage of the use case behavior. Later
reviews should drill down into packages and subsystems to ensure that their contents completely and correctly realize
their defined interfaces, and that the dependencies and associations between design elements are necessary, sufficient
and correct. See the check-points on each design artifacts for specific review points.
|