Chapter Two.
Designing a better way to record personal time use
Our actions can not be separated from the meanings we and others ascribe to them. Embodiment is about engaged action rather than disembodied cognition; it is about the particular rather than the abstract, practice rather than theory, directness rather than disconnection.
– Paul Dourish, Where the Action Is (189)
Any search for a methodology for interaction design needs to be balanced in both theoretical and empirical research. Despite the masses of theory surrounding interaction and design, both are founded in practice and any theoretical examination would benefit from an empirical perspective. On a more personal level, I was looking for methodologies and approaches that suited me – how could I know they suited me without at least trying to use them? In addition incorporating an empirical approach stimulated my research – had I not had the interest in applying these methodologies and approaches in a practical, real world context, a number of theories may not have been explored in as significant detail.
When looking for something to design, an activity which seemed likely to provide fertile ground for research was the recording of personal time use, or filling out time sheets. Many different types of workers have to record their time use on a regular basis. This information is used to help keep track of projects, to bill clients, to pay the workers, to track efficiency and for personal time management.
I felt that designing a digital artefact for recording personal time use would provide a good platform for empirical research into the methodologies and approaches to interaction design for a number of reasons:
- it is a relatively simple activity which is done everyday by a large number of people with a broad range of experience and backgrounds;
- it is an activity that was done before the introduction of computers into the workplace;
- it appears to be done poorly in many circumstances; and,
- even slightly improving it could have a very positive impact on many, if not all of the people who don’t like having to do it everyday.
Undertaking the design of an artefact in the context of this honours research project, required that I took on the roles of client, designer, user and to a limited, extent developer. In a more realistic environment all of these roles would be performed by separate people, and I would have had a team of designers to work with. Whilst this was not possible in the context of this research, there were a number of things I was able to do to help overcome this issue. As mentioned previously, the recording of personal time use is a common activity done in many and varied organisations. This provided the opportunity to find potential “clients” – individual organisations – with which to establish the artefact’s requirements. Each of these clients had a number of “users” – workers from within the organisations – from which to establish user requirements and conduct the various participatory processes and evaluations. Going out to the wider community removed the need for me to be client and user, and allowed me to focus on being a designer.
As I already had a good idea of the activity and tasks involved in recording time use through my own personal experience, my main goal in finding and selecting volunteers to participate in the research was to find individuals whose use of and experience with existing time recording systems varied from my own. In the end I was able to work with ten users, from a range of industries including marketing & public relations, financial & accounting services and software development, from both the private and public sectors. The users involved were a mix of managers, employees, contractors and freelance workers.
While many more people expressed interest and agreed to take part in the research, many of these were unable to make the time, about half an hour, to meet with me for an initial discussion. It was difficult in this context to offer anything of real value or to be able to encourage participation, and I expect this would be similar in a more realistic context. Educating potential volunteers to the personal benefits of participation needs to be a strong part of the recruiting process in order to try and increase the participation rate.
Another issue also arose at this point which I would expect to be just as relevant in a more realistic context. With two organisations I had to rely on other people to select potential volunteers for me. Despite explaining the user-focused nature of the research, and the need for me to speak with end users, the volunteers selected for me were from middle and senior management who were not required to use the time recording systems as frequently or as rigourously as more junior staff. In further exploration of this issue there appeared to be a general belief that there was no advantage in speaking to users further down the line as the managers understood everything. Again, educating clients and careful communication would be needed to overcome this issue in future.
User Research
Before going out to my participants to discover their needs, I had a number of goals for the artefact already in mind. It is common for designers to establish initial ideas for a design from the moment they learn of a project, but as the owner of the project I had more of a say than I might otherwise have had. For me the main goal of the artefact was to enable and assist workers to quickly generate accurate records of how they use their time. I also always intended that the artefact would require an active involvement from the worker and would not monitor or automatically collect information from the worker’s general activities. There were a number of reasons for this including the personal and privacy concerns of the workers, and the logistics of translating monitored data into useful and accurate records without significant user involvement. I also hoped that by actively involving users, it would increase their awareness of their time use, which could potentially provide benefits to their time management and productivity.
With this in mind, my objective for the first interview was to work through the Envision stage of LUCID with my participants, and to gather information on their work practices and requirements to complete the Discovery stage, as well as to start on building an understanding of the participants experiences as part of the Utrecht methodology. This may seem like a lot to achieve in a single meeting but, as recording time use is a common activity with which everyone involved was familiar, it seemed reasonable. Additionally, participants were sent a one page letter (Appendix A) explaining the subject and objectives of the research prior to the interview. As a result many came to the interviews with ideas and design concepts ready to talk about.
As an experienced designer, my client communication skills are one of my key assets, however the style of interview and degree of exploration were outside my typical experience. To this end Brenda Laurel’s Design Research proved to be an excellent reference, presenting a range of articles and experiences from a wide range of designers and researchers. In preparing for the initial interviews, the advice from Christopher Ireland on conducting one-on-one and dyad interviews, and from Stacey Purpura about talking to the right people and “feature-testing”, provided very useful in setting out to do this type of qualitative research.
I designed the initial interview worksheets (Appendix B) with a number of things in mind: I needed to ensure that I covered all the necessary topics and details; I wanted to avoid a linear line of questioning by allowing the conversations to follow their own course; and I wanted to have everything in one place on one page to avoid having to search for things during the interview. The resulting worksheets were based on a simple grid, with points for me to check off, and room for small notes if I wanted to return to a topic to cover more detail later. To free me up to focus on facilitating the interview, audio and video of all the interviews were recorded directly to a laptop computer for later review. This made my role much simpler, and the small size of the camera was unimposing.
Even though the interviews went well, after reviewing the interviews there were a couple of recurring issues which could have helped make the whole process a bit smoother and enhanced the level of feedback and participation I got from my volunteers. These are fairly common sense, but they are worth mentioning. I was very aware that my interview participants were volunteering their time, and as such I wanted to keep my imposition on their time to a minimum. To this end I was well organised and went straight to the point, trying to get through the interview quickly. Having done that, I think the participants would have felt their time was better used if I had taken longer, and spent more time educating them about the process and their value to the process. Also, as suggested by Christopher Ireland, interviews conducted in pairs were much more useful than the interviews conducted one-on-one. People felt more relaxed and would often draw each other out much more than I could on my own, although some care needs to be taken in pairing interviewees.
Going into the interviews I had a number of expectations of what I might find. Primarily I expected to see a very high level of dissatisfaction with the current systems and current methods of recording time use. This wasn’t as consistently present as I had expected, instead many participants seemed to have accepted this activity of recording time use as an annoying but necessary part of their work life.
From several discussions prior to the interviews I was also aware of a situation where some computer based recording systems would require all the details for an entry to be filled in for the system to save the entry. This meant you could not use these systems to record just the start time of an entry, you had to wait until you finished working on a project, and then record an entry. These systems discourage regular use throughout the day because of the level of detail and rigour required to record an entry. While this issue was not explicitly raised during the interviews, participants who worked with such systems had developed their own personal mini systems to work around the limitations of the main system. In these circumstances these participants only used the main system as required, either weekly, fortnightly or even monthly.
One issue that was a little more present than I had expected was workers who would regularly and deliberately enter false or inaccurate data into the system they used. These workers felt that they would be disadvantaged, penalised or attract unwanted attention if they entered the actual data into the system. This falsification ranged from reducing time spent on a project, to not entering data at all, to entering time against the wrong project. In some cases this was supported, and even encouraged, by their immediate managers. For me this was of concern for two reasons. Firstly, having false data going into the system means that anything done with that data was immediately problematic. Secondly, this represents an environment where workers don’t trust the system, or their managers, to the point they have to lie to them, which surely just perpetuates an ongoing cycle of mistrust.
It is unrealistic to expect that interaction design around a small system can solve this problem entirely as it is most likely rooted in the culture of the organisation. However, it is an issue which will have a significant effect on how the worker will use the time recording system – if they don’t feel they can trust it then they will be hesitant to use it, and will think before using it rather than using it automatically or habitually.
I was also very interested in seeing what personal mini systems the participants had developed to assist them in recording their time use. I hoped that these personal systems, which potentially had evolved over a long period of time, would provide insight into how participants were comfortable recording their time, and how much data they needed to record throughout their day to enable them to enter complete information into the main system at the end of the day. About half of the participants had some sort of methodical system they used as they worked. These were generally a set of notes in a diary or on a piece of paper which helped them remember what they had done during a day or week, or even a month. Where these notes were inadequate, or where participants did not have such a system, they reverted to relying on their memory and checking diaries, emails, and phone records to help them complete their entries. Those participants who had a personal system felt they had more accurate records than those people who didn’t, but most of those interviewed did not feel that their final entries were very accurate. However, they did feel that their data was adequate enough for their needs.
The defence of fairly obvious flaws in existing systems was something I didn’t expect from end users of the systems, and I was surprised by the degree to which participants defended systems, particularly those who had used them for a long time. I had anticipated this from the owners of the systems, or those responsible for maintaining them, but in reality those responsible for looking after the systems were more open to discussion of problems and issues, than those who used the systems. This defensiveness was partially a resistance to change, but more strongly it seemed to come from an unwillingness to admit that there were problems in a system that had been relied upon for so long. During one interview I was taken by surprise by this and I think my interview technique would be improved by looking out for this issue in future, and carefully working through it to ensure the participants stay onside.
Design Documentation
There were of course a range of other findings and details that came out of these interviews. Some of these will be discussed below, the rest have been included in the documentation found in Appendices C, D, and E. Appendix C, Design Documentation, follows the recommendations of Envision and Discovery stages of the LUCID methodology. Some key points from this documentation that are worth highlighting here include the High-Level Concept:
Time Pad will support workers who have to keep track of how they spend their time during the day for billing or project management purposes. It will provide simple tools for quickly and accurately tracking work done as it happens, as well as assisting users to complete their records at the end of the day.
This was the first time that the artefact was named. The name Time Pad was chosen to both represent the nature and flexibility of the artefact. My Time Pad was also considered for a short period to make the product more personal, but it was felt this cheapened the product in the eyes of some people. The name was eventually changed to Time Notepad which clarified the purpose and sounded more balanced.
A couple of other key points from this documentation are worth mentioning. Firstly, the system does not have to report on, or track, start and stop times for individual entries, just the amount of time spent. No individuals or organizations interviewed used or required this information to be tracked. This was a surprise, as I expected at least one organisation would want to track all the details of their employees work. I was sure some organisations might, and with a little further asking around I was only able to identify one organisation out of approximately twenty five which required its systems to track this much detail.
Secondly, the system will run on standard personal laptop and desktop computer systems. Other types of devices, such as mobile phones and PDA’s are not required to be supported. This was something that came out of the interview process, but it’s likely I would have made it a requirement anyway in order to keep the scale of the empirical research to a manageable level. It also kept open the possibility of a functional prototype if time allowed.
When it came time to create the user personas (Appendix D), I found it to be a relatively straightforward process. As I went through the two weeks of interviews the three different types of users became clear to me. Abbe Don & Jeff Petrick provided clear guidelines on what to include in the personas, as well as warning about common pitfalls encountered in the process. Their advice was valuable in keeping the personas clear and focused. In particular, the inclusion of a name and a picture was very useful in shaping the final personas and in keeping the personas in mind while I worked through the design process.
The creation of typical experiences (Appendix E), in line with the Utrecht methodology, was much more difficult and required a much higher level of personal involvement and creativity than the personas did. It was hard not to simply retell a participant’s story from an interview. Whereas the creation of personas required a breaking down and a simplification, the creation of experiences required finding a simplified core and then fleshing it out to make it personal, realistic and emotive.
What was useful here was Bonnie McDaniel Johnson’s article on informance. Informance is a process or a set of techniques which aims to give researchers and designers a greater understanding of potential users and their responses to new artefacts through the use of performance and role play. While I didn’t actually perform or role play a person or context, I found that these techniques helped me to better consider the user behind the experience, and to bring both my imagination and my analytical skills into play.
At one point while reviewing all the design documentation, notes and interviews, I considered not using the experiences, as I felt they were very close to the personas in the information they provided. In the end, I chose to keep them as they were more open to personal feelings and frustrations than the personas were and, as suggested by the Utrecht methodology, they made it easier to re-consider the experience of such a user going through the same situation with the Time Notepad as I reviewed various design concepts.
The Design Concept
Most of the ideas and concepts for the design were played out by sketching them out in several notebooks. Some of these pages can been seen in Appendix F. Once an idea had advanced past this stage, it was drawn up and refined further, using vector-based illustration software Adobe Illustrator. Beryl Plimmer & Mark Apperley tested an interface tool which allowed designers to sketch an interface idea, and then run it allowing them to better assess its effectiveness – kind of like very-rapid prototyping. The designers who used this tool produced significantly improved concepts to those who use more traditional methods. I didn’t have this tool, but was able to use some of the ideas from it to help with testing my ideas and concepts. Being an expert user of Adobe Illustrator allowed me to work very quickly within it to trial concepts. I was also able to use its very flexible layering capability to create and compare multiple versions, as well as create sequences showing different stages of users progress through activities and tasks. While probably not as fast as the tool put forward by Plimmer & Apperley, my methodology was most likely a great deal more flexible in the nature of the interface elements I could use, create and evaluate.
Early on in my research I devoted considerable effort to researching the psychological and cognitive nature of time and memory, hoping to find guidelines and tips to creating an interface that would help people to remember what they had done during their day. Most of what I was able to identify was either too specific or too general to be of use in helping people remember specific times, or recall the order of events more accurately (Hoerl & McCormack; Brown & Chater; Marcus). Interestingly, and in line with the discussion of approaches to interaction design earlier, many of the practical tips and clues to creating the interface for the Time Notepad came from talking with users and understanding the experiences they go through in trying to use their current systems.
In line with the Design Foundation stage of LUCID, a number of different ideas were explored in trying to come up with the basic conceptual design for the Time Notepad. Some ideas based around punch clocks and timers were explored, but these were too problematic. The usefulness of these concepts relied heavily on the worker using them on-time. If they forgot to start a timer, or remembered half an hour into a project, the times recorded would be inaccurate, and a complex or separate interface would be required to allow for changes and corrections.
The concept of a day in a diary was an early one that survived through to the current design. One of the big advantages of the diary concept was its highly visual nature, which provides a very quick view of the day showing what time has been allocated and what has not. This made it very simple to notice projects or entries that had been left out, much more so than a list of times in a table. The diary also made it easy to add entries quickly – you could add an entry by simply dragging from the start time to the stop time, and then typing some text into the entry to describe what you had done. Another advantage of the diary-style interface, in line with the theories of embodied interaction, is that it builds on a level of familiarity both from existing computer users who may already use such similar calendar systems on their computers, and from other workers who work with paper-based diaries.
Using a diary for the interface requires users to record start and stop times for entries, even though no one interviewed actually required or used this information. Not recording this information would reduce the amount of data collected, and it could be argued that this would improve the usability of the interface. However, from the user research and the experiences created, it is clear that workers use this information to help them remember what they have done during the day. Not including this information in the system significantly reduces the number of cues available to help trigger the worker’s memory, and would not provide a visual reference for the worker to check their whole day at a glance.
The main problem to be overcome with a diary-style interface was how make it able to be used regularly as the worker goes through their day. For example, to make an entry you need to click and drag from the time you started to the time you stopped, but at the start of working on a project you don’t know when you’ll stop. You could simply drag out an hour or two as a guess for how long it would take, but you would then have to remember that it was a guess and fix it later. My initial solutions to this were complex combinations of different types of entries with start and stop timers, none of which seemed to provide a good solution. When I revisited the personas and experiences I had worked on earlier, I realised all that was needed was simply a note on the diary at a single point in time. This note could then be used as a reference later in the day, or could be expanded to become a full entry when the user had finished that time period.
The concept of notes made the whole interface much cleaner and actually opened up the interface to much broader use than had been originally considered. For example, once someone is in the habit of making notes using Time Notepad, they can simply transfer this habit to a diary or piece of paper when they are mobile or away from their desk. This type of notes system could also be adapted to many existing mobile or portable devices beyond the laptop computer originally specified. While the full interface would be too complex to implement on such devices, a note-taking interface would be practical. For example, a mobile phone-based application could be written that would record a note at a point in time during the day. Users could use the small, annoying mobile keypads, or select from a simple short list of pre-written notes – “Started Work”, “Stopped Work”, “Started Break”, “Stopped Break”, “Started Travel”, “Stopped Travel”, etc. This type of simple note-taking could be done quickly with a range of existing portable interfaces on iPods, phones, PDAs, etc., and then synchronised to the worker’s main computer when they arrived back at work via wireless or wired connection. These notes would then appear in the Time Notepad and the worker could expand them to fill in their activities for the day.
In combination, the concepts of a day in a diary and being able to make quick notes in such a diary, provided a strong solution to the basic requirements of the Time Notepad. Together they formed the design concept on which I could design the rest of the system. Having come up with this basic design concept, if I was to follow LUCID strictly, I should have created and presented a key screen prototype to my research participants. Ideally this could have been done in one or two quick group meetings, but with my participants variously employed and geographically scattered this was difficult to organise. Instead I discussed the concept informally with colleagues which allowed me to confirm I was on the right track before proceeding to the Design Detail stage of LUCID.
Design Detail
At this point the basic design concept offers all that is required for the system to work as required – workers can make entries or notes in the diary and completely fill them in using a basic form on the right hand side. However, one of the things I noticed, even from my limited sample of workers, was the variation in the types of work they did and in how they recorded this into their time sheets. Some workers had one main project each day with a series of breaks. Other workers often worked on many more projects, or several projects at once. The system would work for these people as is, but some flexibility would improve the interaction.
One level of flexibility added to the basic concept is a feature called variations – referred to as “Vary time by” in the interface. The purpose of variations is to allow workers to record actual times in their diary, but make changes to this for whatever reasons they require. For example, a worker may have worked from 10:00 a.m. to 12:00 p.m. on a project, but felt that they had worked slowly and they didn’t feel it was worth charging the client for two hours work. They could then choose to vary the time down by one hour. This would mean that the client was only charged for an hour, but their diary would show two hours work on the project, accurately reflecting their work day. Variations can be made up or down as required, and show up visually in the diary. When a variation is made a new field becomes available for the worker to make a note of the reason for the variation.
As well as the flexibility of variations, there is a feature called interruptions which allows entries to interrupt other entries. Normally Time Notepad allows two different entries to overlap. This is not seen as an error, and may be necessary for rounding or various other reasons. The user can set one of these entries to “interrupt other entries”, which stops this overlapping of time. A common use for this might be a worker who works from 10:00 a.m. to 3:00 p.m. on a project, taking a lunch break from 12:00 a.m. to 12:30 p.m. They could make two separate entries from 10:00 a.m. to 12:00 p.m. and then 12:30 p.m. to 3:00 p.m., and then enter the same project details for each entry, but this is double entry and a waste of effort. By using an entry for their lunch break the user can interrupt the main project entry. The worker then has one main entry from 10:00 a.m. to 3:00 p.m. with all the project details in it. They then have a lunch break entry from 12:00 a.m. to 12:30 p.m. which is set to “interrupt other entries”. This then reduces the time on the main entry from 5 hours to 4.5 hours. Variations and interruptions can be used in combination as required.
Another significant feature of the system is the separation of recording and submitting data. The system is capable of recording a great deal of information about a worker’s day. This may be necessary for the organisation, but as discussed it is mostly in place to help users track their own time and see what they themselves have been doing. For example, no organisation interviewed needed to know that a worker worked on a project from 10:00 a.m. to 1:00 p.m., then again from 4:00 p.m. to 5:30 p.m. They simply wanted to know that the worker worked on that project for 4.5 hours on that day. Some needed a description of the work done, others didn’t. On the right side of the Time Notepad is a Report panel which provides this summarised data for the worker to see and check over. If they are happy with what they see they can submit or export the data to a larger system they are working with. The level of detail in these reports can be customised to suit the needs of the worker and the organisation, and can cover a day, week, fortnight or month as required.
This separation is in place for a few reasons. It helps to overcome some of the issues of trust and falsified data that came up during the user research. The collection of all this data is most useful to the individual worker, and they should feel comfortable about accurately recording their day, without worrying how it might appear to a manager or supervisor. With the separation of recording and reporting of data workers are able to work quickly and confidently with the Time Notepad without having to think twice before they use it. While this doesn’t remove the falsification of data issue entirely, it does leave a more accurate record for the worker of their day, allowing them to trust the system and work efficiently with it.
Additionally, not all of the various back-end systems will support the collection of all this data. Rather than limit the collection of data to what the various systems can cope with, the collected data can be summarised and customised to suit the back-end when exported. Some businesses will want all the details from the system, and this can be done as well, but it is rarely necessary and in such a case the resulting privacy and accuracy issues are a matter for employees and their managers to work out. The Time Notepad is not intended to force compliance, or enforce an organisation’s rules; it is intended to make a worker’s life easier, and increase the accuracy of recorded data. I am keen not to incorporate the rules of each individual organisation within the main interface of the system. Some organisations may not want to allow variations, or may require specific rules or notes to be made for them. Implementing this type of compliance into the main interface makes it more complicated and reduces the flexibility of the system. An organisation’s rules and compliance issues could be incorporated into the Reporting and Submission parts of the artefact as required. Keeping the main interface free of these types of rules allows workers to find their own patterns and rhythms of working with the Time Notepad.
Prototype Evaluation
Part of both the Design Detail stage of LUCID and the Utrecht methodology is evaluating various versions of the design with the potential users of the artefact. Having detailed the design to a point where a full range of activities could be demonstrated, it was time to show it to my participants to see what they thought. At this stage a non-working prototype would have worked well, but my attempts at low fidelity paper prototypes were not able to show enough detail with out being overly complex or messy. As I had already done some drawings of the interface in a vector illustration program I decided to flesh these out to show all the interface elements, and include a range of sample data for different activities.
As I had a variety of different participants with different levels of computing experience I chose not to use typically styled interface elements from either the Mac OS or Windows operating systems for fear of confusing or alienating participants unfamiliar with one or the other. Instead I drew interface elements that would appear functional and familiar to the full range of participants. Visually the Time Notepad was designed to look clean and somewhat physically like a paper diary, as I wanted to build on the familiarity of a diary, and appeal to the flexibility of taking notes on real paper. In doing this the Time Notepad follows the concepts of direct manipulation – where users operate directly on explicitly representative objects – and affordance – where an object affords an operation or action – and builds on the users’ existing experiences in the world to enable the creation of meaning, all in keeping with Dourish’s theory of embodied interaction.
The drawings of the Time Notepad were then pasted into presentation software, where notes and simple animations were added to the sequences in order to demonstrate how a worker might use the system in various ways (Appendix G). When creating these sequences I returned to the personas and experiences I had created earlier for evaluation and ideas. After a couple of sequences were tried out, I made several small revisions to the design to make some elements or meanings clearer.
In preparing the presentation sessions I was keen to make the sure that the sessions were comfortable and collaborative, and that the participants didn’t feel that they were being evaluated. The presentations were also structured to allow for the participant to uncover the interface slowly and to give them time to comment and ask questions (Burr & Bagger). The prototype was presented to the participants in the fashion of a paper-prototype, but rather than swapping paper pages around, I controlled a small laptop with the “pages” being presented on the screen. During the presentation the laptop also recorded the presentation session for later review in the same way as for the initial interviews.
For reasons of timing and availability the prototype was shown to half the original participants and all interviews were done one-on-one, rather than in groups of two. While this was not ideal it did allow the participant to view the Time Notepad in their own work space, and to have their existing systems and notes to hand as they reviewed the prototype (Bødker & Madsen). Those who did participate provided a good level of feedback which was relatively consistent across the group.
In the week before seeing the prototype the participants were sent a summary of the design documentation and user personas for them to review and comment on, as well as to refresh their minds and get them thinking about the process again. I went through this documentation with each participant at the beginning of each presentation and these were generally accepted with a few small questions or comments. These documents did prompt two new requirements that needed to be included: firstly to accommodate the new legislation which required all employers to track the start time and number of hours worked for each employee everyday; and secondly, a requirement for repeating events which would help to cover leave arrangements.
Upon being shown the prototype all the participants quickly worked out the basic operation of the software. In one case the sample data used in an example entry was confused for part of the interface as the terminology used in the entry was of a semi-technical nature. As a result I have been more careful and used very generic work terminology in the current examples.
There was also some confusion over the terminology and effect of the variations and interruptions features when people first saw the terms used in the interface, and the terminology has been revised in the current design to help avoid this. The concepts behind interruptions and variations were not familiar to the participants and it took a few examples for people to understand their value over the basic interface. Once understood most participants appreciated the flexibility and efficiency they offered.
All participants liked the idea of being able to enter notes into the diary, although some took a while to understand why you would bother waiting for an application to open just to make a note. Once they understood the system was intended to be always available from a single keystroke or mouse click, and the very quick time required to make a note, they considered that this may change the way they record their time use.
One participant, a manager, raised a concern that they would not get to see all the information that their staff entered into the Time Notepad, even though their current system did not provide this level of information. This participant felt that all information collected should be theirs to examine and review as required. I explained the trust and accuracy issues behind the separation in the system, and the participant agreed that many people who worked for them did falsify their time sheets, therefore the manager wanted to collect and review every possible detail to rectify this situation. Despite my opinion that this would have the opposite effect, I decided that this debate was not appropriate in this context, and explained that the system could submit every item of collected data if required, but that by default it would not, in order to encourage frequent use and accuracy from the workers who used it.
The presentation also prompted a few ideas from participants about other features that they would like to see in the system. Several suggested an option to import entries from their existing diaries. This was a feature I had considered, and had actually sketched at one point. In working through this concept, I found that as diary entries were usually forecasts, not actuals, most of the information imported (start, duration, description) would need to be changed, saving very little time. The other reason for using data from a diary was to trigger memory of a day’s events. While this is useful, it would be simple enough to have the diary open in one window and the Time Notepad open in a second window so that both where visible at the same time. This would achieve the same result without having to complicate the interface of the Time Notepad, so I chose not to include the feature.
The need to track the work day start and duration to match legislative requirements was obviously an important feature that was needed by the system. One way of doing this is to have the worker account for every minute they are at work by making an entry into the system. You can then use the start time for the first entry of the day, and the end time of the last entry to calculate the work day information. I felt that this was an onerous task for workers and one that is likely to reduce the accuracy of data as workers would likely just match up entries where they would otherwise leave time unaccounted for. After working through a few different concepts, I chose to include a separate set of times for each work day. These times have default values, and can be individually adjusted for each day as required. The interruptions feature now includes an extra option allowing for an entry to interrupt the work day as well as other entries, which allows for the entry of work day breaks, such as regulated lunch breaks, as required. The work day is shown by light and dark shading in the background of the diary.
Having to enter two weeks of daily leave activity entries also seemed to be a fairly onerous task that should be catered for. This was fairly simply integrated by allowing an entry to repeat itself either “Every Day” or “Every Work Day” until a certain date.
One participant wanted to be able to enter a number of hours for a project and have the Time Notepad automatically count down these hours as they were entered, allowing the worker to see how many hours they had left. I initially thought this could be of some value, but with a little exploration it proved highly problematic. My main concern was that without tight integration to the main project management system there was a good chance the count down figure could be wrong, and have dangerous consequences for all involved. With a separate and generic artefact like the proposed Time Notepad, I felt encouraging better communication between project managers and their workers would be a safer and more effective option.
There was also some discussion with participants as to how the project and activity fields were defined and populated. Participants wanted hierarchies and a high level of flexibility with these fields. I had given some consideration to this area, but it was not covered in any great level of detail for the prototype. My idea for both projects and activities was that they would be very flexible to suit the organisation and the individual workers. The name of each field would be variable, so ‘Project’ could be changed to ‘Department’ if it suited better. Both fields would have an associated hierarchical list of codes and names. If a project or activity did not already exist in the list, workers could add it by entering the new code or name into the field while filling in an entry. The colour of each entry would come from the activity assigned to it, and activities could also be set to interrupt by default.
The last request made by a participant was for free form entries – these are entries that have no start or stop times just a duration. The reason given for this was that some workers don’t want to have to worry about what time they did something, they just want to choose the project and enter some time against it. It was suggested that all the extra data entry would slow workers down who wanted to make such a quick entry. I’m going to admit to a bias here, in that I don’t like this idea at all, partly because I worked hard to ensure making entries was as easy as possible, partly because it breaks the diary concept, and finally I don’t believe this would be a real issue in practice. To make such a quick entry in the current design, a worker would click-and-drag an entry of the right length and then choose a project. Using a revised design that included free form entries, a worker would create a new free form entry somehow (most likely a small button click), type in a duration and then choose a project. It would be the same, if not more, work with free form entries, even excluding the extra cognitive load caused by having two different types of entries in the interface. If the worker does not care about the times then neither does the Time Notepad – it does not care if entries overlap, if times don’t line up nicely, or if they are on the wrong day. It is possible that such a worker may feel wrong making an entry that is at the wrong time. If this is the case then the user really does care about the times involved, and would probably benefit from making more accurate entries, which would take no longer to make anyway. All of that said, because of my bias I would ensure that this issue was specifically tested once a working prototype was built.
The Current Design
It was never intended to develop a fully functional artefact during the research, but to focus on key elements of the interaction design process. Originally I had hoped to be able to build and test a partially working prototype, however as my research continued this became less of a priority. Following on from the prototype presentations the design of the Time Notepad was revised in both significant and small ways, most of which have been mentioned or discussed above. While I feel that a working prototype could be built from this design, rather than present a detailed specification for this purpose, I have decided to present the design in the form of a Getting Started Guide. This guide has been reproduced in its full size on the inside front and inside back covers, a slightly reduced version is in Appendix H. While this format may not provide the level of detail of a full interface specification, it communicates a better idea of how the Time Notepad would work and what it might be like to work with.
While creating the Getting Started Guide, I was conscious of the work Suresh Bhavnani & Bonnie John presented in their article The Strategic Use of Complex Computer Systems. This article explores efficiencies use of artefacts, that seem to stem from an intermediate level of knowledge that is not present in the artefact itself or in the knowledge of the functions that artefact offers. Put simply, knowing how the artefact works and functions does not automatically lead to efficient use of that artefact. They provide a simple example of a hammer, which when used by inexperienced users often results in bent or crooked nails, or hit fingers. Efficient hammer users know how to drive the nails in straight by first tapping the nail in to ensure the proper angle, and then using heavier blows after removing fingers from the nail. This intermediate level of knowledge has to be learnt. This resonated with my experience of demonstrating the more advanced features of Time Notepad, which required several examples before participants understood the value of these features. Bhavnani & John suggest that one of the best methods of achieving this level of knowledge is through the strategic instruction of users in the efficient use of these artefacts.
Another way of looking at this level of knowledge is as experience gained using the artefacts. Going back to the hammer example, an apprentice would learn these skills through on-the-job experience with an experienced mentor. This form of instruction takes place in a workplace that appreciates the passing on of skills, however workplaces like this seem to becoming less and less common. Bringing an experience-based approach to design to this issue, it would be expected that the designer of an artefact would have considered and designed the artefact to allow for its efficient use, and that they would have considered or developed experiences in which this efficiency was demonstrated. However, as Bhavnani & John point out, these efficiencies are not always obvious in an understanding of the functioning of an artefact. This is the case with the variations, interruptions, and notes features of the Time Notepad. These features are fairly easy to explain and understand, but how they should be used to make the process of recording time use more efficient is not evident. To this end I have attempted to include experiences and situations in the Getting Started Guide which demonstrate the efficiencies to be gained by using these features. Doing this takes advantage of the designer’s processes, their work with user experiences, and helps to express the vision the designer had in mind when they created the artefact. This is consistent with the theories of semiotic engineering and embodied interaction discussed earlier, in that it assists the designer in communicating their vision and their expectations of how the artefact should be used. Additionally, following through with the creation of such a level of documentation at this early stage of development may help the designer to refine and find flaws in the artefact, and provides another way of obtaining feedback on the design from potential users before committing to the development of a functional prototype.
Review of Methodologies and Approaches
Without being able to fully evaluate and trial a functioning artefact it is difficult to report on how successful the design process was in delivering a good result. As the designer in the process, I felt very comfortable with the methodologies and approaches used and feel confident that the current design would work well as a finished artefact. Obviously, before committing to production of the artefact I would like to conduct further evaluations of the design and review the project, particularly in light of the limitations on the process imposed by being part of a honours research project.
The main difficulties that arose during the process seemed to be centred around a key part of the design process, communication. Both methodologies attempted to address this and did help, but this may be outside the bounds of methodological intervention. These difficulties can be summarised as: does the client know what they want?; client expectations and responses; and, how do you manage both of these without damaging the process and the relationship.
The question of ‘Does the client know what they want?’ is a common one in design, and is covered briefly by Jonas Löwgren & Erik Stolterman while discussing the questioning qualities of a designer (26-27). Clients usually approach designers and ask for a solution, a solution they think will fix a problem they have. Clients don’t normally communicate the problem and ask for a solution. Often clients do not have the distance, skills or knowledge to determine the right solution. Sometimes clients may not have considered the problem at all, but have decided the solution is what they need anyway. Designers need to be able to listen to and question the client to uncover the real problems the client is trying to solve, in order to assist the client in designing the right solution for them.
These difficulties did come up in the design of the Time Notepad, even though I was responsible for many of the bigger design questions in this project. Some participants had very fixed views on how time recording worked, and could not see them as being separated from particular office processes, even when they were already actually quite separate. Some participant discussions and suggestions had little to do with time recording and were quite specific to human resources management or project management issues. Under these circumstances trying to uncover a participant’s true intent was often difficult, and sometimes trying to move their focus away from their desired solution, towards what I understood as the key problem, was almost impossible without agitating or aggravating the participant. This meant that on occasion, certain issues were not fully explored and some questions were left unasked. Similarly, this is the first project in which I have encountered such strong defensiveness, possibly because I approached the clients rather then the other way round. Even so this was not consistent within each organisation, some people would see the current practices as highly flawed, while others would see them as working well. At times I was not sure how much of the disagreements had to do with the discussion at hand, or existing personal and political differences which ran much deeper.
These are areas where personal communication skills, experience and being able to successfully educate and communicate the design process to a client is essential. There is little that a specific methodology can do, as all clients and designers are individuals and require different styles of interaction and management to get them through the process successfully. Thankfully these experiences were only a very small part of my overall experience in this particular process.
Throughout the design of the Time Notepad, both the LUCID and the Utrecht methodologies clearly demonstrated their value, and I would be very comfortable using them on future projects of this kind. One of the key advantages of the LUCID methodology was the flexible way it allowed me to incorporate other methodologies and use a variety of approaches, including those which may be less familiar in the human-computer interaction universe such as phenomenology and embodied interaction.
At this point, it is useful to consider how some of the approaches to interaction design discussed in Chapter One have impacted on the design of the Time Notepad. It is difficult to bring these out in isolation, and the reality of the design process would be that they all (and others not discussed) had some impact on the design simply because I had spent so much time researching and reading about them.
Firstly, while there were no formal usability evaluations conducted on the design in this research project, the desire to create a highly usable artefact was a key driver in the design. As an artefact which is intended to integrate itself into worker’s everyday practices, conducting formal quantitative usability studies would only be of use in identifying problem areas within the design. Less formal and more qualitative approaches would be required to evaluate the design’s overall success over a longer period of time.
Secondly, the impact of cognitive and ergonomic approaches to the design were significant, even though no specific laws or formulas were applied to test various ideas and concepts. Certain options were evaluated on the basis of how many options or choices they would create for the user, and keeping the number of modes in the artefact to a minimum was also a key part of a couple of decisions. To some degree, these types of cognitive considerations arose through the use of the user experiences in evaluating various design options.
Thirdly, while the LUCID methodology used in this project is based on a user-centred approach, my actual design process was more user-focused than user-centred. The users were not the drivers of this process, rather they were well researched, considered in all decisions, and consulted at major points of the process. This process appeared to balance the advantages and disadvantages of the user-centred design, by carefully evaluating the users’ input into the project and through considering a broader range of users and activities than the sample group of users could represent.
Fourthly, I would like to be able to think of myself as a thoughtful designer in the sense of Löwgren & Stolterman, and I hope that this research project demonstrates this to some degree. With the amount of reading and research that went into this project, the design of the Time Notepad had little choice but to emerge from a thought-filled and considered approach. Beyond that, this thesis demonstrates an ongoing questioning and evaluation of both the design process and the role of design in the world.
Fifthly, the theory of semiotic engineering could be said to have had the least obvious impact on the Time Notepad of any of the approaches discussed. This may be because I have always considered that my own mental design processes follow a semiotic approach – it appears to be an integral part of my thinking to consider the various signs created by a design, and the various interpretations and meanings that these signs could create out in the wider world. For this reason I would like to explore and focus on semiotic approaches to design in more detail in future projects.
Finally, the use of phenomenology, experiences and embodied interaction in design was at times the most difficult to apply and then to get right. Yet they could also be said to be the most valuable approaches to this particular project. The use of experiences proved invaluable in understanding the specific needs of users while they were recording their time use, and in considering the value and appropriateness of various design options. The theory of embodied interaction provides strong support to many aspects of the current design, including the key concept of a diary-style interface. The intersection of embodied interaction and semiotic engineering also had a significant impact on this project. As Dourish suggests, ‘We act in a world that is suffused with social meaning, which both makes our activities meaningful and is itself transformed by them’ (189). Perhaps then it was actually the combination of a semiotic sensibility with an exploration and application of embodied interaction that has had the greatest effect on the design of the Time Notepad. The intersection of semiotics and phenomenology – the way they describe the process of interaction, explore the creation of meaning and can then be used to help design improved interactions – together with interaction design, is to me, the most interesting convergence to come from this research, and is worthy of detailed exploration in future research and design projects.