Sketch Book of Dyson Engineer

This is a sketch book from a Dyson engineer showing the thinking process when designing the company’s revolutionary vacuum cleaner. The notebook is part of the exhibitions in Tokyo Designers Week 2011.

It’s very intriguing to see that how the designer used the sketch book to gather ideas and visual thinking with simple doodles. No worries about structure, fidelity, quality; all it matters is quick and free drawing, or even putting your coffee mug on the notebook and leave a mark. So analog, so beautifully human.

Post to Twitter Post to Facebook

Elevator Door Buttons

Here are some thoughts on elevator door buttons and design inspirations I got from the observation.

Common issues:

  1. Language – there’re thousands of words in different languages to communicate the “open” and “close” functions. English is [open/close], Chinese is [開/關] or [开/关] (simplified Chinese), Japanese is [開/閉],…etc.
  2. Icon – to solve the language problems stated above, it’d be better to use icons that is universally understandable regardless of the language barrier.
  3. Button location – Some elevators has the open/close buttons located at the top of the button panel. While one person is pressing the [open] button to keep the door open, other people sometimes has to squeeze under his/her armpit to press the floor buttons. That’s quite inconvenient and could be embarrassing.
  4. Mutual exclusive states – “open” and “close” are two mutually exclusive states of one object: the door. Logically, you only need one control to operate the door. Think about a light switch: one switch is connected to one lightbulb to turn it ON or OFF. However, perhaps when the engineer first designed the elevator, the two functions was identified as two separate tasks where each has to be implemented and engineered separately. Thus, the two buttons are mapped to control the two functions.
  5. Accessibility – what if the user is colour blind or unable to see? What if the light goes out and you can only rely on touch?

A good solution

  1. Language independence.
  2. Every control should have at least two or more ways to communicate its function.
    • Colour (green is open / black is close)
    • Icon (outside pointing arrows is open / inside pointing arrows is close)
    • Physical dimension (wider button is open / narrower button is close)

Real world example

Post to Twitter Post to Facebook

Sketch: Model-View-Controller

Model-view-controller is a well-known programming pattern that is used to organize software code. It suggests code separation within a software into three roles: input (model), process (controller), and output (view). When the software gets really big, such organization of business logic makes it manageable, as well as easier to maintain and extend in the future.

However, many new programmers and non-techy people find it difficult to understand the concept. Here is my attempt to visualize it by using the metaphor of supermarket:

Model – product info and price data retrieve from external source, such as the supermarket headquarter, supplier and so on.

View – shelf arrangement, decoration, poster, price tags, and things that could be affected by the data (product info and price). View is a passive element, which doesn’t automatically update by itself.

Controller – the staff in the store, who would constantly update and rearrange the shelves, decoration and so on base on the ever changing external data provided to them.

Post to Twitter Post to Facebook

About Calvin

Hello there, I’m Calvin Chun-yu Chan. Grew up in Hong Kong, studied and worked in Canada as web engineer+designer, now designing mobile apps in Tokyo. On my blog I would like to share my opinions on design, usability, culture and creativity.

Follow me on:
Twitter @calvincchan