Structured Design The Structured Design Approach (also called Layered Approach) focuses on the conceptual and physical level. As discussed earlier: Conceptual Design tells what is required, i.e. what the system should do, what the users need to know, etc.

Structured Design continued Conceptual design also deals with the necessary structure that is required for the system to achieve its purpose. Physical Design tells how things that are required can be achieved and how the system does things, what the system looks like etc.

Structured Design continued Conceptual design also deals with the necessary structure that is required for the system to achieve its purpose. Physical Design tells how things that are required can be achieved and how the system does things, what the system looks like etc.

Structured Design continued In contrast to Conceptual design, Physical Design aims to focus on * when and where actions and decisions are taken * which actions may be repeated * which options are optional * in what sequence actions are undertaken.

Structured Design continued In other words, Physical Design is more concerned with the necessary actions and decisions, whilst Conceptual Design is concerned with the structure of the system.

Structured Design continued The purpose of this is to allocate tasks to humans and systems and to understand what the consequences of those allocations are. Operational examples are how the system controls the dialogue with the user, what the user must do and what feedback is given by the system.

Structured Design continued Representational examples are the display of data or the presentation of a coherent system etc.

Structured Design continued The conceptual layer in the structured approach (=layered approach) is used to specify the logical structure of the system, i.e. the functioning of the system. Subsequently, the task allocation stage maps this logical structure onto the physical design.

Structured Design continued After the task allocation stage is finished, i.e. after the tasks have been allocated to humans and machines, the operational aspects can be specified (operational aspects = what actions the user can take and what the system does to respond to these actions)

Structured Design continued At the same time of specifying the operational aspects, the representational aspects should be considered as well. They indicate what the system will look like.

Structured Design continued At both operational and representational levels, consistency is very important, e.g. there should only be a small number of ways of issuing commands. The same should hold true for representations, i.e. the visual display (for instance that error messages always look the same).

Structured Design continued Objects in one particular class should always appear in the same style. A consistent metaphor should be chosen, with careful consideration of abbreviations and the design of icons (think about any previous knowledge that users bring from the external world, e.g. what what associations they form for particular symbols, pictures etc.)

Structured Design continued 3 main aspects to describing the operational nature of the system: How can the system reveal its current state? How can the system make clear what actions the user can take? How can we consider system feedback?

Structured Design continued How to display the current state of the system: two possibilities: Either the system state is visible to the users with the objects on the screen showing what state the system is in. Or the system state is observable through the actions the users take.

Structured Design continued How to display the current state of the system continued: It is generally recommended to prefer the first option, i.e. to make the system’s state visible (e.g. when you download something there could be a display how much downloading time is left).

Structured Design continued 2. How the system can inform the user what actions s/he can do: Design of buttons, screen displays etc. that make it obvious what actions can be performed through pressing, clicking, touching etc.

Structured Design continued 3. How system feedback can be considered: Provide continuous feedback messages so that the users know about the effect of their actions. Recently, intelligent feedback has become more common, e.g. a system that learns about the users’ behaviour.

Structured Design continued Operational design, central features: Deciding on the type of interaction style: Example: Command language interface (e.g. UNIX (but not all versions of UNIX), MS DOS)), Direct manipulation on Graphical User Interface, etc.

Structured Design continued Representational design, central features: How to actually implement what was decided in the operational design stage: Examples: conforming to standards, styles, shape and size of buttons, flicker on screens, height of display, etc.

Structured Design continued Summary: The combination of behaviour, look/style and consistent metaphors will help to meet the usability criteria. The design often needs to be tested, adjusted, tested again, etc.

Envisioning Design How it differs from Structured Design: No clear distinctions are made between different levels of the system. No rigorous ordering of stages. Envisioning Design defers consideration of the physical design until late in the design process.

Envisioning Design continued What does Envisioning Design mean?: Envisioning design conceptualises the form of the design at a very early stage in simple terms that users (even inexperienced users) can understand. This is often done through prototyping, game-playing, discussions in meetings etc.

Envisioning Design continued One popular example of envisioning design: Holistic approaches, which are based on exactly those principles (see the two previous slides). Holistic approaches view design as a whole, which means that decisions about the way interface should look are made in relation to how this will be physically communicated to the users.

Envisioning Design continued One popular example of envisioning design: A characteristic of Holistic approaches is that attention is first focused on the conceptual model, but that the application of actual examples/prototypes etc. also starts very early on in the design process.

Envisioning Design continued Envisioning design principles also make heavy use of metaphors, e.g. metaphors can help to understand the system as a whole or significant parts of the system. Examples are the cut and paste commands in a Microsoft Word processor, its equivalence in Microsoft Powerpoint or Microsoft Excel processors and the scissors symbol for cut.

Envisioning Design continued Other examples of Envisioning design techniques: Scenario: fictional story with characters, events, products, environments (e.g. the Museum store device we did as a practical exercise, your coursework options) Visual Brainstorming (sketches, cardboard representations)

Envisioning Design continued Other examples of Envisioning design techniques: Snapshots (visual cartoon-like images that capture possible interactions) Storyboards (pictorial representations of scenarios)

Envisioning Design continued Summary: The advantage of these techniques is that they provide more concrete and practical representations that are applied to real-type situations. This makes the design process less abstract. End of Chapter 4.