Showing posts tagged with:

Interaction Design

Interaction Design

Some 18 years ago I attended a Microsoft developer academy event in Cambridge (UK) – one of the sessions I attended was delivered by Alan Cooper and addressed the topic of interaction design. This session had a fundamental impact on how I viewed software development – and still influences my thinking today. I can’t recommend Alan Cooper’s book About Face strongly enough for anyone interested in building great software products, regardless of technology or platform. My personal learning was this – software products exist to help people complete a task they’d rather not being doing – so the best solution is intuitive, unobtrusive, supportive and abstracted from the implementation mechanics. A bit wordy perhaps, this is best illustrated by Cooper’s optimal solution design, the big red button with the label ‘Just Do It’!

Rarely do great user experience occur by accident. The best experiences feel natural and so tuned to the task in hand that the interaction is effortless and predictable.

Such user experiences are of course far from effortless to deliver, instead they are the product of careful thought and the expert application of interaction design techniques. Replace my use of the term interaction design with usability, user-centric design, HCI or whatever term you’re familiar with that relates to designing interactions starting with the user.

In developing a number of commercial and non-commercial software products over the years I’ve tried to rationalise the process element of applying interaction design to a project, i.e. how to integrate the outputs into a viable development process. The framework outlined below provides one approach to this. Of course the real value of any interaction, or user, centric design is the translation of the understanding of the user plus functional, technical and corporate brand constraints into a cohesive set of simplified interactions. The approach to this varies greatly between projects.

A simple but useful framework to consider.

— Interaction Pattern Catalogue
An abstract set of well-defined and robust patterns for the typical UI interactions required within the context. For example, how is a List page structured, how does the primary user interaction and any related actions work. My interaction pattern catalogue would typically cover List, Detail, Edit, Report, Dashboard, Search pages – providing an absolute and detailed definition of the composition and operation of each pattern. In the ideal case every page of the application would be covered by the patterns, however this is unlikely and a number of exception patterns would be typical – added to the catalogue and described in the same detail just in case a second instance occurs.

— Process Diagram
A concrete decomposition of the user-interface of an application into a block for each page and arrows to denote the transition paths between pages. Each block is coloured or annotated to indicate the interaction pattern (or exception pattern) defined in the interaction pattern catalogue. From experience, drawing out an approximation of the full user-interface early in the process, really helps focus the development effort, as well as ensuring all the interaction patterns are identified. I typically print this diagram out and place it prominently within the development area – I have also used this to highlight progress by changing the colour on completed areas. This may sound like a BDUF approach, however even agile projects can benefit from this exercise as long as the right caveats are in place.

— User Interface Policies
An abstract set of policies, well-defined and absolute, which specify the use of fonts, the colour palette, iconisation, indication of mandatory state, error condition presentation, field highlighting behaviour, dimensionality (gaps between components etc.), alignment, tone of language, label terminators, accessibility behaviour etc.. In short the user interface policies provide definition to key characteristics of the UI applicable across interaction patterns. Policies are typically documented in lightweight form and provide a handy and concise reference which enforces uniformity across the application.

— Interaction Storyboards
A concrete set of storyboards which extend the interaction patterns defining the specific behaviour of certain interactions, typically in the context of a persona and a scenario.