Norman’s Design Principles

13 Jan

Here I will explain how I have implemented each of Don Norman’s design principles:

Visibility

Extensive use of icons rather than plain text makes it very easy and quick for users to know what functions are available to them. Additionally, important features like going to the map-interface for changing selected cities is very visible on the main screen and not hidden away behind the menu-button.

Feedback

All button presses should give instant feedback. Extensive testing was done to ensure that this was the case. The refresh button activates a background process so must give instant verbal feedback; in this case a Toast pops up to inform them that the update has been initialised – important because this can take a long time on slow mobile networks. At the other end of the scale, it is important to prevent excessive feedback which then overwhelms the user- to this end I ensured that Toasts never build up by coding a locking mechanism.

device-2013-01-21-193118

Mapping

All icons for buttons were carefully selected and/or designed so that they mapped to the action that pressing them caused. Some were easy as conventions exist – a gear icon for settings, question mark for help, pin-marker for the map screen, thermometer for temperature-view; others were harder and required testing with multiple real world users – a raindrop with a percent symbol overlayed for the relative humidity view, leaves swirled about for the wind view etc. See screen capture:

bars

Affordance

I carefully checked each screen to ensure that nothing which looked click-able had no action. This is the essence of affordance in a software perspective. Although I do provide user documentation, by testing with users I made sure that this was not required in order to use the interface. Basically, buttons, tabs and hyper-links all do what users expect them to do.

Consistency

Part of this means not re-programming the Android hardware buttons – especially the back button which is an important and well-used feature. Apps which do reprogram this, in my opinion and supported by Google’s own documentation, are poorly designed. With my design, I have ensure consistent colour-coding of the weather values across different functions (main screen, detail screen, ranking view). When using external designs I ensured that they were from well known sources so users are familiar with them – e.g. using Google Maps not Bing or Open, sticking with Android’s preferences design rather than making up my own one.

device-2013-01-21-192237   device-2013-01-21-192003

Constraints

These reduce errors and focus the user. My mechanism for changing the selected cities was heavily influenced by this:

  • The map interface constrains the user to select one of the marked cities
  • Currently selected cities are coloured separately so users are clear of their options
  • On clicking a marker they are given the city name and confirm they want to use this city
  • They are constrained to remove one of the currently selected cities in a simple list view.
  • The lack of textual input is a very important constraining principle for ease-of-use.

The settings were also carefully designed to limit options to the most widely-used ones. e.g. the temperature can only be set as degrees F or C; Kelvin was constrained out as it is not a widely used unit in the filed of meteorology.

In all, following these principles has helped me design an app that already meets the design guidelines for publishing to the App store, and has heavily influenced the decisions I made on the way.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: