Diary study

Diary studies are carried out in the early phase of the audience research. They provide information about the type and chronology of users’ activities on a day-to-day basis. Similar to Twitter status updates, users submit statements about what they currently do (or try to do) in order to carry out their job. An aggregated and structured view of these statements helps to establish tasks, priorities, and the level of satisfaction with current systems and tools.

Benefits in a nutshell

  • A diary study is a quick and inexpensive way to find out about users actual tasks and activities
  • It provide insight into users’ actual needs and context
  • It allows a large number of participants to contribute synchronously

Conceptual Model

A conceptual model is a structured and coherent outline of ideas about how a web site or application will work. It is based on the requirements table and findings from audience and stakeholder research. It can include a model for the content (site map), high level wireframes, user journeys, technical architecture diagrams, and high level style guides.

Benefits in a nutshell

  • explains strategy and core ideas of the envisioned Web site or application
  • helps communicating the ‘big picture’ throughout the development process

IA heuristics

IA heuristics (comes handy for review)

  1. Does the site structure match the tasks to be performed by the user?
  2. Does the apparent site complexity and functionality match the intended user need?
  3. Is the structure designed so as reduce the total number of navigational steps needed to reach the desired page?
  4. Are frequently needed and critical pages located near the top of the site structure, requiring a small number of clicks from the homepage?
  5. Does the structure convey an appropriate metaphor that facilitates user’s understanding of the site?
  6. Do the navigational labels provide meaningful, unambiguous summary of the pages?
  7. Do the labels use familiar and consistent terminology?
  8. Are the labels distinct from one another?
  9. Do important keywords stand out in the labels?
  10. Does the site promote learning of the location of pages in the site structure?
  11. Does site design build on our prior learning and experience of the intended users?
  12. Does the layout of the navigation facilitate visual scanning by the user?
  13. Do the number of pages per navigation level and the number of levels in the site structure optimise navigation time?
  14. Has random or arbitrary ordering of pages on a particular level in the site structure been avoided?
  15. Are pages on a particular level presented in a logical order to facilitate scanning?
  16. Are pages on a particular level ordered to reveal structure and relationships among them?
  17. Does the order of pages agree with the user’s expected ordering?

From Volkside: 17 guidelines for better information architecture…from 1991

Direct touch

Direct touch bypasses abstraction and creates a strong connection with the touched object. This is particularly true when the object itself triggers associations in our minds. Due to its very size and weight and display area, the iPad triggers powerful associations with:

* Printed documents
* Notepads of paper
* File-folders from the filing cabinet
* Clipboards
* Books

There is something intrinsically “right” about seeing the iPad as a technological successor to, or version of, these physical objects. We’re immediately ready to accept the one as a substitute or enhancement for the other. This is a powerful, and novel, position for the iPad software developer.

Matt Legend Gennel: iPad application design

ipad UX

Differences between ipad and iphone

  1. The display is much larger; 1024×768 pixels. Apps with more demanding presentation requirements will be at home here.
  2. The virtual keyboard is larger, and external physical keyboards are supported via Bluetooth or the dock. Apps which focus on typing are now much more feasible.
  3. The iPhone supports multi-touch, but only the iPad can credibly claim to support two hands. We’ll talk more about this later.


    Two-pane and three-pane interfaces are once again worthy of consideration on this class of device.

  • Master-Detail is feasible and acceptable on iPad.
  • In landscape, both Master and Detail are visible.
  • In portrait, the Master is shown in a transient pop-over.
    Editing/viewing: Look like a viewer, and behave like an editor

  • Hide configuration UI until needed.
  • Edit object properties in place.
  • Attach the editing UI to the object. Show/hide/move as necessary
  • Inspectors should present context-relevant UI.
  • Hide controls which don’t apply to the selection or focus.
  • Modes (do one thin at a time) are preferable to clutter; removing a feature might be preferable to adding a mode for it;
  • Offer only the most-used/needed features. If in any doubt, remove a feature.
  • Discard optional/niche or highly configurable functionality.

  • Dual-handed input is acceptable.
  • Be usable with one hand. Don’t require two hands for essential features.
  • But don’t be afraid to offer time-saving, discoverable dual-handed functionality.

Extracted from Matt Legend Gennel: iPad application design