| Usage Guidance |
Task: Design the User-Interface and Task: 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 Identify 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.
|
