This document summarizes key concepts from the book "Design of Everyday Things" by Donald Norman including: 1) Norman doors which can be confusing to users as the affordance (what the door allows you to do) does not match the actual interaction required. 2) The importance of discoverability and understandability so that users can figure out possible actions and how to perform them. 3) Other principles of good design including affordances, signifiers, feedback, mapping, and conceptual models to ensure usability and intuitiveness. 4) Lessons for developers that designing APIs and code involves considering the user experience and making sure interactions are discoverable, understandable and follow good design principles.

1. Design of Everyday Things
Fundamental Principles of Interaction
Isaac

2. Learn how to code
2

3. The book and author
3

4. Chapters
● There are many other content
● Only one paragraph taught me A LOT!
4

5. Agenda
- Warm up
- Norman Doors
- Discoverability and Understanding
- Fundamental Principles of Interaction
- Affordances
- Signifier
- Mapping
- Feedback
- Conceptual Models
- What I learned as a developer
5

6. Warm up
● Norman Doors
● Discoverability and Understanding
How to drink a cup
of coffee….??
6

7. Have you ever...
●
● Got a requirement
● Just implement it
● Don’t know who is the user
● Don’t know how user use it
● Don’t care,
just resolve ticket anyway

8. Try to figure out
● Who is the user
● What is the user intention
● How user use it
Whom you fight for?
What you fight for?

9. Norman Doors
● Doors should be simple
● Norman Doors confuse people
● It seems you can pull
● But it want you push
● Sometimes is designed for
beautiful, but become invisible
and unusable
9

10. Norman Doors
● Sometimes is designed for beautiful, but become
invisible and unusable
10

11. Discoverability and Understanding
● It’s the most important characteristics of good design
● Discover-ability
○ Figure out what actions are possible
○ Where and how to perform them
● Understanding
○ What does it all mean?
○ How is the product supposed to be used?
○ What do all the different controllers and settings mean?
11

12. Discoverability and Understanding
Discoverability: can push only
Understanding: just push to open the door
Discoverability: Won’t notice there is a door
Understanding: Can’t understand how to
open, need try-and-error
12

13. Discoverability and Understanding
Buttons are visible, but unable to know the meaning
13

14. Discoverability and Understanding
● Large method
○ Discoverable
○ Can’t be understood
● @DoWhateverYouNeed
○ Can’t be discoverable
○ Can be understood
It’s easy to build another
kind of Norman Doors

15. Fundamental Principle of Interactions
In order to come out good design, need take care of following principles:
● Affordances
● Signifier
● Feedback
● Mapping
● Conceptual Models
15

16. Affordances
An affordance is a relationship between the properties of an object and the
capabilities of the agent that determine just how the object could possibly be used.
A chair affords support and sitting
16

17. Consider...
What device user use when designing software feature
● PC
● Mobile
○ Browser
○ Apps
● SMS
● Monitor system
○ Time series
○ Event based
● IOT

18. Signifier
● Affordance: it is a relationship
● Affordance determine what actions are possible.
● Signifiers communicate where the action should take place.
18

19. Signifier
Some doors unable to know how to open without a signifier
19

20. Signifier
Signifier is an important device for communication, whether or not communication
is intended
20

21. Signifier
The sink that would not drain
A door unable to push/pull
Signifier confuses people
21

22. Consider..
Based on feature and afaffordance
● How user find a signifier and understand how to use it
● How other developers find your code and understand it
○ Have you separate or decouple high cohesion code far far away?
■ Ex. An annotation to code pre/post action far away from core logic?
■ Ex. An annotation to commit a transaction based on internal counter, which is far away
from the place user persist data?
○ Have you use design pattern to decouple high cohesion logic to many many small pieces code
code?
● Visit oodesign.com to learn design pattern’s when to use
.

23. Mapping
● Mapping is the relationship between the elements of two sets of things
● Ex. Switch mapping Lights in office
● Mapping the layout of controls and displays
23

24. Mapping
Steeling a car, rotate the steering wheel clockwise to cause the car to turn right.
24

25. Mapping
Tank is different,its designed to control wheel speed because it uses track
25

26. Consider..
When designing a feature
● How you explain how will you implement to others?
● Is there same term in your code?
● Why you separate modules?
● When you separate modules, will other developers know where to find a
specific model?
● Is there a way for developers to map a feature/idea to modules/models?

27. Feedback
User can’t control things without feedback
27

28. Feedback
● Feedback must be immediate: even a delay of a tenth of a second can be
disconcerting. If the delay is too long, people often give up, going off to do
other activities.
28

29. Feedback
● Too much feedback become annoying.
29

30. Feedback
● Use one simple signal producer to reduce cost, let people not easy to
remember (Beep code)
● Beep code definition may be different in different machines. We'll be confused
when those machines beep together.
● Feedback has to be planned and prioritized.
● Feedback is essential, but it has to be done correctly. Appropriately.
30

31. Consider...
In order to build things easy to control, need to have good feedback
(“User” can be API/method client code)
● Does your code always response quickly?
● Sometimes may not have quick response, how user know it?
● Can user choose not to wait?
● What will happen when user choose not to wait and cancel?
Does it really stop or keep running under the scene?
● Does your code thread safe, so that status won’t become out of control?
● Provide a way for user to understand what’s going on.

32. Conceptual Models
● A conceptual model is an explanation, usually highly simplified, of how something
works.
● Ex. There are folders in screen, but it doesn't means there is really a folder in disk
● Ex. User browse data in PC and think it's a data in PC, but data is in cloud actually.
32

33. Conceptual Models
● Conceptual models are often inferred from the device itself. Some models are
passed on from person to person. Some come from manuals.
● Some conceptual models come from experience, so wrong conceptual
models let devices hard to use
● How things work come from user perceived structure
○ Signifier
○ Affordance
○ Mappings
33

34. Consider...
User may try by himself or study document before try.
● How user understand your system?
● How to understand your design?
○ Need a document
○ Introduce mental model
○ Design decisions
○ Introduce where to find code
○ How to troubleshoot
○ It will be great to provide ways to monitor

35. Learn from Spring
● Many abstraction layers, from documentation to code level.
● Need easy to read, discover and easy to understand
35

36. What I learned as a developer
● Developer design API to interact with Users/Developers
● Every RestAPI/Framework/library/method/lineOfCode are API
● When designing APIs, we need make sure design is good
● Good design is discoverable and easy to understand
● Good document is a must have for complex conceptual models
● How to come out a good design?
○ Affordance
○ Signifier
○ Mapping
○ Feedback
○ Conceptual Models
● Whenever you read Code Complete/Clean Code/Design Pattern/Effective
Java, masters want to share how to come out good design 36