Chapter One.
Approaching interaction design

Design is by nature both holistic and ruthlessly simplifying. A designed artifact, whether it is a piece of communications software or a city park, must address the complex mixture of human needs, embodied in a weave of physical and social interaction. But the design itself cannot embody all of the complexities if it is to be constructible and understandable. The design must embody a simplification, leaving room for the texture of the world to be filled in by the interpretation and practices of those who use it.
– Terry Winograd, Designing a New Foundation for Design (72)

Design and the act of design are often misunderstood and variously defined. Since they are key topics throughout this thesis, I will start with a discussion on what design is and what I mean by the act of design.

Put simply, everything made by humans has been designed. Every time something new is created, someone has made decisions about its function, content and medium of expression. Decisions to include, exclude, modify or to seek out new ideas are what make the something that has been created. These decisions – conscious or unconscious – are at the heart of the design process.

Design is often described in terms of problem solving – here is a problem, design a solution. This is a useful way of trying to understand the design process, especially as it takes the focus off the visual and aesthetic outcomes of design. However, it needs to be acknowledged that design problems can not ever be fully understood and that there is no single solution to a design problem. Design takes place within a complex context which the designer is continually exploring and seeking to further understand – a context which is always liable to change, if it is not already in continual flux. As designers work to create and refine solutions, their understanding of the problem and context is increased, allowing them to further refine their solutions, and so on. Under these circumstances it is not possible to establish if a solution is right or wrong – if it is a solution in the logical sense (Löwgren & Stolterman).

Additionally, designers must communicate their design solutions to others – to other designers so they can share, discuss and collaborate; and to their clients, users and the general population, in order to increase their understanding and evaluate the effectiveness of their solutions. Without effective communication the act of design becomes very difficult and can very quickly lose its value.

Design is an activity to be undertaken deliberately, knowingly and with eyes wide open. With the previous points in mind, we can say that to design is:

• to seek to understand a problem and its context;
• to seek and create solutions to the problem, or at least parts of the problem;
• to evaluate and decide on the effectiveness and appropriateness of the solutions; and,
• to communicate these design solutions to others.

These points are not linear nor definitive. They are repeated many times over, in many different orders. In this way, they make up the activity of designers: the act of design.

Figure 1. The design process moves from vision to specification, but the path is not straight and linear. Source: Löwgren & Stolterman (25)

I have included an illustration from Jonas Löwgren & Erik Stolterman (Figure 1) that beautifully illustrates the reality and lack of linearity in the design process. The diagram shows the designer moving through various levels of abstraction over time, from the initial vision to final specification. The dark diagonal line shows the general, or averaged progress, but as we can see from the lighter line the actual design process is in no way linear or straight forward.

Interaction Design

Interaction design… illuminates the relationship between people and the interactive products they use… its focus is on defining the complex dialogues that occur between people and interactive devices… Interaction design defines: the structure and behaviors of interactive products and services; user interactions with those products and services.
– Interaction Designers Association

Interaction design refers to the process that is arranged within existing resource constraints to create, shape, and decide all use-oriented qualities (structural, functional, ethical, and aesthetic) of a digital artifact for one or many clients.
– Jonas Löwgren & Erik Stolterman (5)

Interaction design is the art of facilitating interactions between humans through products and services. …interaction design isn’t about interaction with computers (that’s the discipline of human-computer interaction) or interaction with machines (that’s industrial design). It’s about making connections between people through these products, not connecting to the product itself.
– Dan Saffer (4, 6)

Interaction design is still a relatively new term and there are significant differences of opinion as to its exact definition. Older design disciplines, such as graphic design, fashion design, architecture and industrial design, are reasonably well defined and understood. This is perhaps because of the fairly tangible nature of their outputs when compared to interaction design – graphic design produces graphics, fashion design produces clothing, but interaction design does not produce interactions.

Interaction itself is a very broad term. Interaction takes place when any two things have a reciprocal effect on each other, these could be subatomic particles, weather systems or people. We can’t predictably influence all of these types of interactions, so we need to better define what types of interaction we are interested in.

Dan Saffer’s definition, quoted above, tries to draw a line between interaction design, human-computer interaction and industrial design. He limits interaction design to interactions between people through the use of artefacts. Someone programming a video cassette recorder to record a television show is outside this definition, as there is no connection between people involved. Someone using a digital video recorder with an electronic program guide is inside the definition, because they got the programme guide as a result of some sort of connection with the people who made the programme guide. As will be discussed later, it can be argued that someone using a video recorder is connecting with the designers of that video recorder and is therefore inside the definition after all. Although helping people make connections and communicate with each other is an important and integral part of interaction design, it does not help to define the discipline well.

Jonas Löwgren & Erik Stolterman’s definition of interaction design, quoted above, focuses on interactions with digital artefacts that can be used. This is a much more straightforward way of separating the interactions we are interested in. As there are many non-digital artefacts which have and could benefit from the application of good interaction design I would remove the digital part of their definition and look at interactions with artefacts that can be used.

The definition from the Interaction Design Association, above, is very similar to Löwgren & Stolterman’s definition, but perhaps not as concise and clear. It does use some slightly simpler and more accessible language though, which can be an advantage. To bring all of this together I would suggest the following definition: Interaction design is a process focused on improving the interaction between people and the artefacts they use. This process creates, shapes and decides the functional, behavioural, structural, aesthetic and ethical qualities of these artefacts.

Approaches to Designing Interactive Artefacts

In response to the difficulty many people have using interactive artefacts, a number of approaches to producing better products have evolved over recent decades. These include usability, humans’ cognitive and ergonomic abilities, and human-centred design.

Usability is the study of how usable an artefact is – the more usable the artefact the better it is to use. Nielsen & Loranger suggest that ‘Usability is a quality attribute relating to how easy something is to use. More specifically, it refers to how quickly people can learn to use something, how efficient they are while using it, how memorable it is, how error-prone it is, and how much users like using it. If people can’t or won’t use a feature, it might as well not exist’ (xvi). Usability metrics come from extensive qualitative studies of products, usually conducted in usability labs. They are useful for finding specific issues with a product, or for comparing the usability of different solutions. Over time general design guidelines have evolved from usability studies, but these need to be used carefully and with considerable attention to the contexts of the studies, and the components of the designs, that lead to these guidelines.

Another approach common in human-computer interaction, is to work from cognitive and ergonomic understandings of human ability. In The Humane Interface, Jef Raskin argues that by starting from an understanding of human cognition, striving for simplicity and focusing on uniformity among individuals, we can build completely modeless and monotonous interfaces that improve productivity and lead to less time spent doing a task. An interface is modeless if the interface responds consistently to a single gesture for the current state of the interface, and if the user is aware of the current state of the interface. Raskin suggests that a modeless interface provides greater consistency and trust, is less confusing to users, and allows them to work faster. A monotonous interface is one where any desired action can only be invoked via a single gesture. e.g. being able to perform an action via a menu or a keyboard shortcut is an example of a non-monotonous interface. Raskin suggests that non-monotonous interfaces provide increased choice for users, are therefore more confusing and will slow users down.

There are several laws and guidelines for interfaces that come from a similar cognitive and ergonomic understandings of humans’ abilities and limitations. These include:

• Hick’s Law, the time it takes someone to make a choice from a list increases exponentially with increases in the size of the list;
• Fitt’s Law, the time it takes to move to a target increases as the distance to the target increases and as the size of the target decreases; and
• memory chunking, people are generally only capable of accurately remembering between five and nine (7±2) chunks of information in short term memory.

An understanding of humans’ cognitive and ergonomic capacities is valuable in helping to decide between different interface options, and in attempting to understand why people have problems working with certain interfaces in certain contexts.

Human-centred design, or user-centred design, is widely accepted as the basic standard for developing and designing good interactive products. This approach was developed in response to a range of bad software designs, and focuses on the needs and abilities of the users of the software. Users drive the design process, and they are often involved in every stage, providing input and inspiration (Preece et al. 285-287; Norman “Human-centred”). Human-centred design has been very valuable in focusing the attention of developers and designers on the actual needs and limitations of the users, rather than on what developers and designers perceive their target users to want or to be capable of.

Even though these approaches have been around for many decades, and they have been very useful in improving the quality of interfaces and artefacts, there are still a lot of people who have considerable trouble using the artefacts being produced. When considered in the context of design and the act of design, an interesting pattern emerges from these approaches. All three seek consistent, definitive and quantifiable results from either quantifiable user testing, cognitive and ergonomic laws and limits, or from the users themselves. These results all come from outside the product development team. With such definitive results the product development team no longer needs to make a decision, thereby absolving itself from, or reducing its role in, the design process.

The evolution of these approaches in an engineering or business environment is perhaps understandable. As we have already discussed, design is a very flexible activity, and the results of design can rarely be classified as right or wrong. Within a scientific and engineering environment, like most software and technology companies, this must be a difficult concept to fully accept. Within a business or corporate environment, it must sound very risky, if not potentially suicidal. In this context it makes sense that such approaches have evolved in order to try and reduce the perceived risk, and seemingly avoiding the whole design issue.

The problem with not being actively involved in the decision making or design process and simply relying on the results of these approaches, is that it is impossible to know if the results are accurate, or if they point to a successful outcome, or not. This lack of engagement and simple acceptance of results is likely to lead to small refinements to the current design concept. It does not encourage creativity, or the development of new design concepts that may be better suited to the activity or context. Additionally there is a strong risk that the results of these approaches will become concrete limitations or boundaries in the minds of the developers, rather then being considered desirable or probable in the context from which they were derived. These types of approaches are simply not sufficient to fulfil or to replace the act of design in the development of interactive artefacts – they are not bad or wrong, but they need the benefit and application of experienced designers in a good design process.

Figure 2. The status quo in software development today. Source: Buxton “Performance” (6)

Figure 3. Inserting a design phase at the start of the process. Source: Buxton “Performance” (8)

Figure 4. Removing the boundaries to demonstrate ongoing responsibility. Source: Buxton “Performance” (11)

This apparent avoidance of the act of design is raised by William Buxton as a key factor in the failure of software companies to deliver successful products. In Performance by Design: The Role of Design in Software Product Development he compares the software development industry to the film production and industrial design industries, and laments the lack of any design in the upfront processes of the software industry. A key point made by Buxton is that the software industry will typically approve the engineering and production of a product before they fully understand the product they are setting out to build (Figure 2). By comparison, the film industry typically spends a considerable amount of time in preproduction (writing, scripting, gathering key production staff and cast members, budgeting, release plans etc.) before a product is to be considered for production. A similar process takes place in the automotive industry – full production of a vehicle will be considered only after a full scale model has been built, and detailed plans for the manufacture and marketing of the vehicle have been completed (Figure 3). In the software industry, without the proper design processes in place, the products that ship, if they do ship, are often very different from the product intended at the start of the engineering process and may not end up meeting any real needs or goals of the market place.

Buxton goes on to point out that simply adding designers to the beginning of the process is not going to result in better products at the end. A more ideal situation is for all interested parties and stake-holders to be involved in the development process on an ongoing basis (Figure 4). Susanne Bødker & Jacob Buur’s Design Collaboratorium provides an interesting starting point for integrating development teams. The Design Collaboratorium is a place and a way of working in which all parties involved in the design and development of a product can work, or at the very least come together. Designers, engineers, marketers, users and other stake-holders can work and share the same time and place in order to facilitate an improved design process.

Including designers in the development of interactive products, and providing for suitable design practices will improve our interactive artefacts, but designers will need to use more appropriate approaches than those previously outlined. In Designing Interaction, Not Interfaces, Michel Beaudouin-Lafon compares the 1984 Macintosh computer with the 2003 model iMac. Somewhat surprisingly, even with the massive growth in computing capability, the basic interaction is still the same. In this time, new methods of interaction have been developed and proven in testing, but they have rarely been adopted. To improve this situation Beaudouin-Lafon argues that we need to move away from task analysis and interface designs, to a more holistic approach, considering the broader implications of interaction beyond just that of the user and the computer. By arguing for a better understanding of the context of use, and the development of stronger theories around the phenomenon of interaction, Beaudouin-Lafon is in essence arguing for a shift from human-computer interaction and the design of interfaces toward interaction design as defined earlier. That is, improving the interaction between people and the artefacts they use, not just designing the interfaces of these artefacts.

In line with Beaudouin-Lafon’s argument for less focus on tasks, and for an understanding of the broader context in which interaction takes place, Ben Shneiderman wants to see a move away from machine-centred automation, which aims to replicate or replace human tasks, towards user-centred tools, which aim to assist humans to do their tasks better, faster and more accurately. This is Shneiderman’s second shift towards what he calls the new computing. The first, and most important shift, is in the way users perceive and value the experience of using computers. Instead of being concerned with gigahertz, bandwidth, and megabytes, Shneiderman wants users to value how much work they got done, how creative they were, what their computer usage allowed them to contribute to themselves and to their various broader communities. This shift in value by users, and therefore consumers, should put increased pressure on developers and designers to improve their artefacts to meet the desires of these consumers.

Both Shneiderman and Beaudouin-Lafon argue that the increasing creative workload of most modern computer users is not well supported by the interfaces currently in place. Given that artefact design and engineering can be considered as a creative activity, it would make sense to build interfaces and artefacts for designers, developers and engineers that better support their creative work. This would then hopefully provide positive flow-on effects as these workers build the interfaces and artefacts for the rest of the world to use.

In comparison to usability, cognitive and ergonomic understandings, and human-centred design, the approaches of both Shneiderman and Beaudouin-Lafon promote a broader understanding of the development, purpose and use of interactive artefacts. These approaches ask us to step back, to examine and to question even the motivation and purpose of the artefact being developed. Jonas Löwgren & Erik Stolterman take this even further, arguing that the design of interactive artefacts is so complex, so constantly changing, and so fraught with contradictions that it requires something more than new methods and approaches to design, it requires a thoughtful designer. This is a designer who not only understands design and can design, but a designer who consistently examines the role of design, their own role in the design process and the benefits and pitfalls of the different methods and tools available to them.  ‘A thoughtful designer is someone who takes on design as a serious and important task and who tries to become a designer with the ability to create fascinating, authentic, and useful digital artifacts’ (2).

In his book Shaping Things, Bruce Stirling presents designers with an even greater challenge – design with everything in mind, because your users (collectively) will have everything in mind when it comes to using (or choosing to use) the artefacts you design. This type of collective knowledge is already in existence through Amazon and various other online stores, and the world wide web in general. You can easily find many different reviews of a product you may be interested in purchasing. If you look a bit harder, you can find other people who have used the product talking about the problems they have had, or how great the product is. This level of knowledge is only going to increase until the collective users know more about an artefact and how it works than the designers, engineers and marketers who made it in the first place. With this level of knowledge it is going to be much harder to sell products that are of a poor or substandard quality, and that is going to be a major challenge for many companies over the next few decades.

In addition to these arguments for broader thinking in the design process there are a number of more specific approaches designers may choose to use in examining and understanding the interactions that take place around an artefact. In The Semiotic Engineering of Human-Computer Interaction, Clarisse Sieckenius de Souza presents a model for interaction design which brings the designers of artefacts up to the same level of recognition and importance as the users of these artefacts. Following general semiotic principals, the theory of semiotic engineering explores the communication between designers and users which takes place through the built artefact. Semiotics is the study of signs, exploring how signs are created, how they are interpreted and how they participate in communication. Following the theory of semiotic engineering, designers examine the users, the role of the user and the context in which the user operates. The designers must then put forward a design for the artefact which responds to the users desire for change, and communicates the designer’s vision for how this change might occur. Through interacting with the designed artefact, the users explore the designer’s vision until they fully understand it and are capable of making use of the design within their own context. This is a significant change from the separate design model, system model and user’s model often found in human-centred design methods (Figure 5). Semiotic engineering places a greater burden on the designer to better understand users and communicate with them, effectively bringing the different models together into a shared vision.

Figure 5. Human-centred design compared to semiotic engineering. Source: de Souza (8)

My early research led me to a methodology for interaction design from the Utrecht School of Art based around the philosophy of phenomenology. Phenomenology considers experience and embodiment – being in the world – central to the creation of meaning, rather than meaning being created by objective abstract thought. The methodology, which I’ll explain in more detail shortly, uses phenomenology to help designers to understand the user, the experience of the user, and the context they are designing for (Barfield et. al.). The idea of phenomenology as a design tool made considerable sense to me, so I followed this further in the work of Paul Dourish and his book Where the Action Is: The Foundations of Embodied Interaction. Dourish builds on the work of philosophers Martin Heidegger, Alfred Schutz, Maurice Merleau-Ponty and others to establish a theory of embodied interaction, a perspective on the relationship between people and systems. According to Dourish, ‘Embodied Interaction is the creation, manipulation, and sharing of meaning through engaged interaction with artifacts’ (126).

Through the theory of embodied interaction Dourish defines interaction design as needing to encompass three qualities of an artefact: its holistic qualities – an artefact is part of an environment and must be designed as such; its expressive qualities – artefacts express values and meanings and this expression needs to be considered as part of the design; and, its aesthetic qualities. Though it may appear that the theories of Dourish and de Souza are irreconcilable – phenomenology places embodiment at the origin of meaning, while semiology holds signs and texts as primary – Dourish and de Souza reach similar conclusions. The following quote from Dourish, could almost be word-for-word from de Souza: ‘The designer must somehow communicate to a user a set of constraints and expectations about how the design should be used. The system can be thought of as the medium through which a designer and a user communicate’ (132).

That both Dourish and de Souza have reached similar conclusions from different points is both exciting and broadly beneficial. Semiotics and phenomenology can be seen to appeal to very different types of thinking, and rather than take one as better than the other, designers, developers and engineers can work from the perspective that best suits them, or draw from both as the situation requires.

Design Methodologies

As this point, I would like to move on from approaches to interaction design and discuss the design methodologies I chose to work with for the empirical part of my research. As I have already suggested, design is a broad and flexible process. This in itself seems opposed to the application of a specific methodology to design. Some people see methods as being a set of instructions to be followed, and at the end of following the instructions you will get your result. In design this specificity of process is not what makes methodologies useful. Designers need to understand, adapt and mix methodologies to best suit the projects they work on.

The successful understanding and adaptation of methodologies is a key part of the success of any design process. It is rare that a designer can successfully design anything without following some sort of methodology – usually, successful practice uses a mix of several they have found and modified to suit their personal strengths and weaknesses over time. In this sense design methodologies can be seen to support designers in their internal processes: they help to ensure designers have researched and thought through all aspects of the design; they help designers to avoid common pitfalls; and, they direct designers to greater levels of understanding and research.

Design methodologies also provide significant value in enabling designers to work together with engineers, clients and other participants on a project. Many people don’t understand design or the act of design. Some think it is all just made-up, creative mumbo-jumbo. Some think it is purely interested in surface and aesthetic qualities. Others simply see design as a black box where you send something in one end and it comes out the other end as a finished product (Löwgren & Stolterman 64). Design methodologies can help designers explain how they work, why they ask the questions they do, and the potential value in following through with a full design process.

For the empirical part of my research I worked from two methodologies for interaction design, the LUCID methodology and the Utrecht methodology, both of which are described in more detail below. At the start of this research, my decision to use these methodologies was as much based on intuition and experience as it was from academic rigour. Now, having had the experience of using them throughout a design process and having completed significantly more research into interaction design, I feel that the decision to use these two methodologies was the right one for this project. Further, I believe they would provide a good base for a wide range of interaction design projects.

The Logical User Centred Interactive Design methodology, or the LUCID methodology, was developed by Charles Kreitzburg and Cognetics Corporation. It was originally called the Cognetics Quality Usability Engineering Design Methodology and was developed to integrate usability engineering practices into existing software development methods and procedures (71). The version outlined here is from Ben Shneiderman & Catherine Plaisant who describe it as a widely used and well tested methodology (119-122).

The LUCID methodology has six phases – Envision, Discovery, Design Foundation, Design Detail, Build, and Release (Figure 6). The first stage, Envision, is probably the most important stage of the process. It aims to reach agreement between all of the projects stake-holders on what the artefact is going to do or going to be for. Without all parties agreeing to clear and well defined goals, the project is almost certain to fail as different people and groups head off in different directions, or unknowingly change direction as problems or new opportunities arise.

Stage two, Discovery, is focused on researching and understanding all the different users of the artefact, the tasks they perform and what they need the artefact to provide. This information is then used to create a user requirements document for the artefact.

Stage three, Design Foundation, takes the information gathered from the previous stages and uses it to form the basis of the artefact design. Key to the LUCID methodology is the development of key visuals and a key prototype. Presenting users and stake-holders with the key visuals of the artefact generates significant interest in the design, and encourages significant levels of feedback from many different people.

Stage four, Design Detail, builds the design concepts and policies into a fully detailed specification. At this stage the detailed visuals and work-flows can start to be taken through a full usability evaluation process with users, making use of either paper-based, or simple computer-based, prototyping methods.

Stage five, Build, occurs when the design for the artefact is completed and can be handed over to the development and engineering teams. However this handover is not the end of the designer’s involvement in the artefact. To ensure the artefact continues to meet its goals and requirements the designers need to assist development teams to work through problems as they come up, and to be involved in further and more detailed user testing as the artefact progresses towards release.

Stage six, Release, sees a managed release of the artefact to the market or to the customer’s site, ensuring a positive reception from users and customers.

From my own experience, and research, the LUCID methodology appears to have been developed to address many of the common design issues that arise when working on larger projects in a commercial environment. One of the key appeals of this methodology for me is the establishment of a shared vision, which is built on, returned to, and revised as required. This one key point of ensuring that everyone is talking about and working towards a clearly defined and documented objective is something that many methods, and projects, simply assume to be the case, often to their detriment.

The LUCID methodology should be familiar to many designers, as it reflects the way many designers work, through creating a cycle of research, design, and evaluation. At the same time, it is a methodology which reads well and should appeal to non-designers, engineers and business minded people through its well structured and staged approach.

The last important factor in the appeal of the LUCID methodology is its flexibility. There is plenty of room to absorb other methodologies, techniques and approaches within it. LUCID provides a firm foundation which can be modified, built on, and built into to suit a variety of projects and situations.

Stage 1: Envision

• Align the agendas of all stake-holders, balancing the needs to meet business objectives, manage technical constraints and support users’ needs for a highly usable product.
• Develop a clear, shared product vision among the stake-holders.
• Identify and deal with potential problems that could impair the development team ability to collaborate e?ectively.
• Begin the design process at a concept sketch level.

Stage 2: Discovery

• Develop a clear understanding of the characteristics of each distinct segment of the product’s users.
• Understand the tasks users perform, the information they need, the terminology they use, their priorities and their mental models.
• Analyse the data gathered and create the products user requirements.

Stage 3: Design Foundation

• Develop and validate the basic conceptual design of the product.
• Develop a visual look for the product.
• Present the completed design as a key screen prototype.

Stage 4: Design Detail

• Complete a style guide containing the graphic design and UI policy decision.
• Flesh out the high-level design into a complete speci?cation.
• Conduct usability evaluations of speci?c screens or work-?ows.
• Create detailed layouts for each screen and detailed speci?cations for each element of each screen.

Stage 5: Build

• Answer questions and support developers, redesigning screens if needed.
• Conduct usability evaluation of critical screens, if necessary.
• Support the build process through review and late-stage change management.

Stage 6: Release

• Develop a rollout plan to support the new product
• Conduct usability evaluation of the “out of the box” or installation experience.
• Measure user satisfaction

Figure 6. Logical User-Centred Interaction Design Methodology. Source: Shneiderman & Plaisant (120)

To compliment the structure of the LUCID methodology, and to build on its user-centred base, I decided to incorporate a second more intuitive and analytical methodology which I’ll refer to as the Utrecht methodology, as it was developed at the Utrecht School of the Arts . The Utrecht methodology is based on an approach to design by architect Christopher Alexander, and the theories of phenomenology from the work of Edmund Husserl and Maurice Merleau-Ponty (Barfield et al. 70-79). The Utrecht methodology is an interactive methodology with five stages (Figure 7).

When working with the methodology, the designer cycles through the five stages as follows:

• the designer describes the experiences of the users, attempting to set aside, or at least make explicit, any prejudices they may have;
• using intuitive judgements the designer attempts to identify the good experiences from the bad experiences, and to then identify the invariant elements that make them good or bad;
• using patterns the designer represents their analysis as a system of constant forces, a context, and which elements resolve the forces in the context;
• using imagination and the awareness of the forces from the pattern, the designer outlines an illusion to function as a design concept;
• the designer then expresses these ideas as a form or prototype that can be experienced by the users, and these experiences can then be used to restart the process.

Figure 7. A method for experienced-based design. Source: Barfield et al. (75)

The use of phenomenological analysis to understand the essential experiences of the users performing the tasks brings the designer much closer to the users. This has the potential to provide the designer with a much larger level of understanding of the users’ tasks, context and interpretation, than more typical approaches to user-centred design or task-based analysis would.

The following chapter describes how I used the LUCID and Utrecht methodologies, and the range of approaches to interaction design previously discussed, in the context of the design of a new artefact for the recording of personal time use.

Now read Chapter Two. Designing a better way to record personal time use…