Abstract Specifications written in the formal specification language Z often make use of a form of decomposition that is novel to programmers. A published Z specification is rewritten using the form of decomposition familiar to programmers. Whenever decomposition is used, there must be some strategy for deciding what is to go in one component and what is to go in another. At the highest level, the strategy underlying the rewritten specification is the well-known strategy of separating user interface issues from deeper system functionality issues. The effectiveness of the strategy is put to a simple test by showing how a modification to the interface can be supported by a modification to only part of the specification. The conclusions drawn are that care over decomposition is important in specifications, just as it is in programs, and that lessons learned from programming about effective decomposition strategies can be applicable at the specification level, too. In particular, the lesson relearned is that it is important to separate information about a system's functionality from information about how this functionality is presented to users.