Design

HCD Activity 3: Produce design solutions to meet user requirements


The HCD standard suggests that this has the following aspects:

  • Making design solutions more concrete (development of prototypes)
  • Altering the design solutions based on user-centred evaluation and feedback
  • Communication the design solution to those responsible for implementation

My recommendation for the techniques to be used follows.

3.1 Develop design proposals

This phase starts with abstract representations derived from the user conceptual model, through wire frame representations and eventually to worked-up interface designs. It can involve input from a number of professional disciplines including, information architecture, information design, technical authoring or copyrighting and graphic design. It may also require input from software developers to ensure what is proposed can eventually be realised. This phase is interleaved with the following three. The stages of this phase are described in the following sub-sections.

3.1.1 Produce Naive interface design

In a sense, the user conceptual model is already an abstract interface design; it references all of the data items and actions that are required to carry out the tasks it is derived from.  In principle it just needs to be put on one screen or animated in some other way.  However to make it practical, further refinement may be needed; it may contain too many details to fit on the available screen, or it may be overly complex with rarely used elements obscuring crucial and regularly used ones.  Also decisions must be made about how the data content and capabilities for interaction will actually be presented.

Working with the user conceptual model diagram does give you a starting point however.  The objects you have identified are likely to be presented and manipulated as units, possibly windows or tabs.  The printed diagram can be cut up and manipulated (perhaps using the sort of non-permanent glue found on Post-it® notes, alternatively it can be manipulated in drawing software.  Aggregation relationships can be represented by bordered areas (possibly independent windows).  Related sub-type objects should share common layouts.  Whilst the naive interface design produced will not look much like a finished screen design, it will give a good indication of the relative amount of space required to represent screen objects, and gives you something to run through scenarios with.

After rearranging the elements of the interface to meet initial constraints, the recorded scenarios should be run through against the design by the designers to ensure that nothing has been missed, and to begin to get a feel for how the interface will support the task.

3.1.2 Produce wire-frame design

Decisions must be made about the interface components that will be selected to present data and enable actions in the interface, i.e., formatting of data fields and use of buttons, menus, check boxes, etc.  If use of a corporate style guide has been mandated, then that will determine choices and options selected. Where new design decisions have to be made they should be documented, together with their rationale, to ensure consistency throughout the design.

The output from this step will be ‘pencil sketches’ of the design with place-holders for content and graphical elements (logos etc.).  There should be annotations on and around the sketch to record navigation and other animations of the interface, transition to other screens, etc.

At each iteration of the developing design, the designers should run through the collected task scenarios.  As the designs take on a more ‘conventional’ appearance it may also be possible to run through them with representative users.  If this is to be done then cleaned up wire-frames with the annotations removed should be produced and paper-prototyping sessions set up.

3.1.3 Produce finished design

The work involved in this will depend very much on the type of product being developed. If it is a customer facing application (e.g., a web site or a commercially distributed application) then corporate image may be crucial. The corporate style guide (which will have had considerable graphic designer input) may prescribe templates to follow, with appropriate colour pallet, fonts, layout, etc. Alternatively the services of a graphic designer may be required. The graphic design of an interface can profoundly affect its usability, both positively and negatively.

Where complex data must be presented then the skills of an information designer may be required.  This is particularly the case if graphs or charts are to be used, also diagrams and maps.  Whilst an aesthetically pleasing presentation may be desired, perhaps using colours and icons chosen to match the overall graphic design, this must not be at the expense of the clarity and appropriateness of the information displayed.

The output from this step will be a more finished presentation with graphical assets specified in detail.

3.2 Produce a Lo-Fi prototype

At the point when a plausibly complete and detailed design has been produced, it should be tried out with users. It is usually not appropriate to show the design sketches to users; the dynamic aspects of the design may not be clear and there will typically be confusing annotations to assist implementation that will not appear in the finished interface.

Initially a paper prototype can be produced. It should demonstrate the design, not merely describe it (as the design sketches do). The designs should be ‘cleaned up’ to remove annotations, and place-holders replaced with representative content. Demonstration of the dynamic aspect of the interface should be made possible by placing components that appear and disappear on separate pieces of paper or transparent sheet.

Whilst this may at first appear merely as a simple task of preparing a presentation, in actuality it is a continuation of the design process. It encourages focus on detail so aspects of the design that previously have been included in outline must be filled in. Also the act of making the design concrete will give rise to further insights that should be incorporated. Changes should be incorporated in the design sketches.

Depending on the type of project, the production of prototypes may be continued after the following two stages, perhaps increasing the fidelity through production of software prototypes, either in the eventual production environment (rapid-prototyping) or using simpler tools.

3.3 Carry out prototype testing sessions

Nothing useful is likely to be discovered merely by showing the prototype to users and asking for comments. It is important that they actually ‘use’ it to carry out a meaningful task. Then the real deficiencies will be uncovered and their comments will have some substance.

Prototype testing can be carried out very early on paper representations of the design (‘lo-fi prototyping’) and can progress to non-functional software representations (perhaps using ‘Wizard of Oz’ techniques) and perhaps functional designs realised in a prototyping development environment, or on the final delivery platform (incremental prototyping).

3.4 Modify the design to meet usability goals

The discoveries made during the prototyping sessions must be incorporated by changes in the design. However it is important that this is controlled so that a distinction is made between critical changes and more superficial improvements. Making too many changes can result in introducing more problems than are solved.

3.5 Manage the iteration of design solutions

The iterated process of design, prototype, test and redesign must be carefully managed to ensure that efficient progress is made towards satisfying the specified usability requirements.

As the design evolves and decisions about particular details are firmed up, it is important (particularly in a multi-designer project) that these are documented along with their rationale in an ‘Application Style-Guide’ to maintain consistency throughout the design. This can be considered an extension to the Corporate Style Guide, if one exists, or as the basis of one to be used in future projects.

4 References

Rettig, Marc, 1994, “Prototyping for Tiny Fingers”, Communications of the ACM, April 1994, Vol. 37, No. 4. [Available online in the ACM Digital Library.]

Advertisements

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s