Design Principles from Don Norman’s “Design of Everyday Things” and Preece, Rogers and Sharp’s “Beyond Interaction Design” Design of Everyday Things • Donald Norman - cognitive scientist and engineer who has pioneered many ideas surrounding user centred- design • worked for Apple, Hewlett Packard, Northwestern University, UCSD • critiques and examines many everyday items as examples of problematic designs • design principles a framework for discussing and thinking about everyday interactions • Norman, Donald A. (1988). The Design of Everyday Things. New York: Basic Books. Design Principles • Visibility- can is see it? • Feedback - what is it doing now? • Affordance - how do I use it? • Mapping - where am 1 and where can I go? • Constraint - why can’t I do that? • Consistency - I think I have seen this before? Visibility • Can see the state of a device and possible actions • Car controls are positioned in a way that they can be easily found and used Visibility • Problems arise when we cannot “see” how to do use a device • Sensor technology like auto faucets - not sure how to use - guess where to put hands • Visible knobs, dials and buttons have been replaced by invisible and ambiguous “active zones” Visibility • Hiding certain functions can be advantageous in interface design • Certain functions are kept invisible until needed; also contained within a group of similar types • Google search makes it clear where to enter text Visibility • Other examples of poor or good visibility in design? Feedback • what is it doing now? what action has been performed? • needs to be immediate and synchronized with user action Feedback • Sound works as feedback - examples? Feedback • Other examples of feedback in everyday design? Affordance • Perceived and actual properties of an object that give clues to its operation Affordance • Perceived and actual properties of an object that give clues to its operation Affordance • Perceived and actual properties of an object that give clues to its operation Affordance • Other examples of affordances in everyday interactions? Mapping • Relationship to controls and their effect Mapping • Relationship to controls and their effect Mapping • Relationship to controls and their effect Constraints • Restricting the kind of interactions that can take place Constraints • Restricting the kind of interactions that can take place • Reduce the chance of error • Can also work to focus user’s attention to needed task Constraints • Other examples of good and bad constraints? Consistency • designing interfaces to have similar operations and use similar elements for achieving similar task • systems are usable and learnable when similar concepts are expresses in similar ways • enables people to quickly transfer prior knowledge to new contexts and focus on relevant tasks • Four types of consistency: • aesthetic •.

1. Design Principles
from Don Norman’s “Design of Everyday Things” and
Preece, Rogers and Sharp’s “Beyond Interaction Design”
Design of Everyday Things
• Donald Norman - cognitive scientist and engineer who
has pioneered many ideas surrounding user centred-
design
• worked for Apple, Hewlett Packard, Northwestern
University, UCSD
• critiques and examines many everyday items as examples
of problematic designs
• design principles a framework for discussing and thinking
about everyday interactions
• Norman, Donald A. (1988). The Design of Everyday Things.
New
York: Basic Books.
Design Principles
• Visibility- can is see it?

2. • Feedback - what is it doing now?
• Affordance - how do I use it?
• Mapping - where am 1 and where can I go?
• Constraint - why can’t I do that?
• Consistency - I think I have seen this before?
Visibility
• Can see the state of a device and possible actions
• Car controls are positioned in a way that they can
be easily found and used
Visibility
• Problems arise when we cannot “see” how to do use
a device
• Sensor technology like auto faucets - not sure how
to use - guess where to put hands
• Visible knobs, dials and buttons have been replaced
by invisible and ambiguous “active zones”
Visibility
• Hiding certain functions can be

3. advantageous in interface design
• Certain functions are kept invisible
until needed; also contained within
a group of similar types
• Google search makes it clear
where to enter text
Visibility
• Other examples of poor or good visibility in design?
Feedback
• what is it doing now? what action has been
performed?
• needs to be immediate and synchronized with user
action
Feedback
• Sound works as feedback - examples?
Feedback
• Other examples of feedback in everyday design?

4. Affordance
• Perceived and actual properties of an object that give
clues to its operation
Affordance
• Perceived and actual properties of an object that give
clues to its operation
Affordance
• Perceived and actual properties of an object that give
clues to its operation
Affordance
• Other examples of affordances in everyday interactions?
Mapping
• Relationship to controls and their effect
Mapping
• Relationship to controls and their effect

5. Mapping
• Relationship to controls and their effect
Constraints
• Restricting the kind of interactions that can take place
Constraints
• Restricting the kind of
interactions that can take place
• Reduce the chance of error
• Can also work to focus user’s
attention to needed task
Constraints
• Other examples of good and bad
constraints?
Consistency
• designing interfaces to have similar operations and use similar
elements for achieving similar task

6. • systems are usable and learnable when similar concepts are
expresses in similar ways
• enables people to quickly transfer prior knowledge to new
contexts and focus on relevant tasks
• Four types of consistency:
• aesthetic
• functional
• internal
• external
Consistency
Aesthetic
• style and appearance is repeated to enhance
recognition, communicates membership and sets
emotional tone
• Mercedes Benz vehicles are instantly
recognizable because the company consistently
feature its logo on all its vehicles
• associated with quality and prestige; respected
and admired; fine craftsmanship and reliable
Consistency

7. Functional
• meaning and action are consistent to improve
learnability and understanding
• consistent use of symbols to represent similar
concepts, leverages prior knowledge and makes
new things easier to use
• traffic always turns yellow before red
• cassette recorder control symbols used on a
Consistency
Internal
• consistency with other elements in the
system
• cultivates a sense of orientation and trust
• indicates system is well thought out and
planned
• eg. park and trail signage
Consistency
External
• consistent with other elements in the environment

8. • extends the benefit of internal consistencies across
multiple, independent systems
• more difficult to achieve because different systems rarely
observe the same design standards
Guidance:
1. Purpose - this is just what the document is for, you don't need
to modify this section in any way.
2. Goals and Philosophy - this is just what are the primary NFRs
that the architecture addresses. For example, if reliability is a
key concern you would say that the architecture addresses
reliability issues. Its not really a 'philosophy', it just what you
are trying to achieve with the architecture.
3. Assumptions and Dependencies - this is where you state some
of your key assumptions - things like that the warehouse has a
connection to the Internet, that the warehouse has a wireless
network to connect the cranes - that the cranes have an
independent processing node on them and aren't just a remote
screen (for example). That the WMS is a separate system.
Dependencies are things like the SOAP specification, the WAF
specs, access to a TCP/IP network - external factors that you
can't control and need to support/implement, or depend on.
4. Architecturally significant requirements - requirements that
affect the architecture - like supporting access as a web service,
the fact that the crane drivers consoles are mobile, if you have
any reliability recoverability or performance requirements.
Note : sections 2 through 4 are 'forward looking' - ie they spell
out requirements that your architecture has to address. The
following sections are 'backward looking' - ie they document
things that you decide and do in the other parts (B,C, D) of the
assignment. You should NOT get stuck trying to figure these
later sections out before you have actually decided on what your
architecture is going to be, and what software patterns you are

9. going to use. Come back and fill these sections in after you
have worked out your architecture and detailed design.
5. Decisions, constraints, and justifications. Here is where you
note down and explain/justify decisions you have made (note
past tense).
6. Architectural mechanisms. Mechanism is sort of a synonym
for 'pattern'. I relate it back to architectural 'tactics'. Tactics are
a specific approach you are going to take to address a particular
NFR. For example, we may have a reliability NFR, and we
decide we are going to address that NFR using a 'hot spare'.
'Hot spare' is an 'architectural mechanism' we are going to use
to address the reliability NFR. Refer to the lecture on
'Principles, Patterns, Tactics, and Views' for some idea of what
tactics are. Otherwise, get hold of 'Software Architecture in
Practice' (SWAiP) - or google 'software architecture tactics' and
look at the articles published by the Carnegie SEI. I have also
uploaded Chapter 5 from SWAiP into the Asg2 Resources
section of the website.
My take is - an 'architectural mechanism' is some software
pattern by which we are going to implement some architectural
tactic. IE a mechanism implements a tactic.
Just note down what tactic you are going to employ to address
some NFR, and then what pattern/arrangement of components
you are going to use to implement that tactic. Once again this is
best done after you have decided how you are going to address
those issues.
7. Key Abstractions - for abstraction, read 'representation' or
'concept'. This section wants to know about the key concepts
that are represented in the application - ie your domain model or
entity classes. Also, if there is some really dominant pattern
that helps explain how your whole system is going to function -
like 'event driven interaction between components', or 'data
access object encapsulate persistence system', then mention that
here.
8. Architectural Framework - this where you typify your
application by calling it 'basically a client-server model' (or

10. not) - or 'the architecture uses a layered style, separating user
interfaces from business logic and persistence mechanisms.
Also that it is partitioned into your functional components.
Basically, here is where you say how you divided the system up
into functional and technical components, and whether there is
some overarching 'architectural style' that you can relate it to.
9. Architectural Views. OK there is a mismatch here between
the template and what I really want - but you don't have to
include anything here anyway - you only have to refer to the
diagrams that are requested in other parts of the assignment.
What we are producing as 'architectural views' corresponds to
Kruchten's 4+1 Views as described in the Kruchten article in the
Asg2 resources, and also that FCGSS_US_WP pdf - which tells
you what UML 2 diagrams correspond with what views.
Essentially its like this:
Logical view - Class diagram - Asg2 Part B Section a. The
logical view basically shows the class collaboration necessary
to support the CCRD use case according to the architecture that
you have designed. Its a bit like the summary analysis class
diagram, except that it shows all the classes involved in
supporting the use case, including the user interface, controller,
and other 'infrastructure classes. The logical diagram shows
everything you would need to implement that single CCRD use
case according to your architecture - so it shows what would be
necessary to support the NFRs, as well as just the functional
requirements - so if there is some need to store things in a
database, the logical diagram would show the classes necessary
to support that. This is where any DAObjects start to show up.
Process View - Sequence diagram - Asg2 Part B Section b. This
is very similar to the sequence diagram we drew for Asg1, but it
shows the details of how the control class is going to support
the user interface you come up with for the crane driver in Part
C, and as in the logical view, it shows how the NFRs are
addressed as well as the functional requirements. So - as above ,
if you are going to store things in a database, we want to see
when those DAObjects are told to update and save as part of the

11. message sequence that supports the use case. Basically, the
message sequence we drew in Asg1 (that is provided to you for
'manual store pallet' in the Asg1
Solution
s) forms a skeleton, which we now flesh out with specific
information need to support the crane driver interface, and also
to conform with and support the NFRs addressed by the
architecture. The message sequence has to be consistent with
the architecture.
Implementation View - Component Diagram Asg2 Part A
Section b. This is a 'high level' view that shows your functional
and technical components. The other thing it has to do is
identify any 3rd party components your application is going to
rely on - like a database implementation, or a web server for
example. The component diagram is for 'implementation' so it
assumes you have actually identified the platform/language you
are going to implement in. In terms of development this is an
important diagram because it does things like identify what
versions of what libraries you are going to need - and that the
developers have to stick to.
Deployment View - Deployment Diagram Asg2 Part A Section
c. This is a complementary high level view that shows how your
high level components are laid out on the actual hardware of the

12. deployment environment - its a pretty straight derivative of the
component diagram with the addition of 'hardware nodes'. The
trick is that your components have to respect hardware
boundaries, and any 'inter-node' communication has to
incorporate some sort of network communication - so there's
another technical component you are going to need - probably
on every node in the system.
Use case View - not required for this assignment, but basically
its job is to provide a context for the other views.
Anyway the point here is that you don't have to duplicate all
these diagrams in the architecture notebook - you just have to
identify them, and reference the other parts of the assignment