UX Model Mapping

A useful mapping to create is that between the UX and analysis models. The mapping is simple, expressed as dependencies from analysis boundary classes and UX screens. This mapping becomes more valuable as the analysis model evolves into a proper design model. However, creating this mapping early helps to ensure that both the UX and the analysis teams are working together on the solution to the same problem.

Figure 10-12 shows a simple mapping class diagram that can be found in the analysis model. The recommended procedure is to draw the mapping from the analysis/design class to the UX screen, which by default makes the owner of the mapping relationship the analysis model, not the UX model. The analysis model is the preferred owner because it's more likely for analysts and designers to be familiar with objected-oriented analysis and design than are UX team members, and therefore it is more likely for the mappings to be maintained properly.

Figure 10-12. UX model mapping

In all but the most trivial system, analysis is carried out by a team. Each member of the team usually works on a package or set of packages independently and simultaneously. Early on, team members get together frequently to discuss and to negotiate their public interfaces. As the model is refined and the interfaces become more stable, these meetings are not needed as often. However, it is still important to have regular get-togethers and reviews to ensure that everyone is still marching in the same direction.

At some point, a package is considered completed and ready for design. This milestone is usually identified by having all the use cases and scenariosboth main and alternative flowsaccounted for. The package should be reviewed before proceeding to design.