Design is a problem-solving process whose objective is find a way to implement requirements, respecting constraints, and ensure good quality. According to the ISO standard 9241-210 (2008) [1], the design process of an interactive systems is iterative: design solutions are created, tested, revised, and improved until the development team produces a proper version of the fully fledge system. This process produces two types of results: a specification of the design solution to be implemented (the interactive system) and a set of design decisions that drive the evolution of the design along the iteration cycles. User interface prototypes are the most common type of artifacts used to specify design solutions for interactive systems. In early phases of the development process, drawings are acceptable as prototypes to support ideation of the product but as the process advances, drawings are replaced by interactive specifications and then by executable prototypes. It is interesting to notice that prototypes are useful and necessary but they are not sufficient to fully specify an interactive systems. On one hand, prototypes are not self-explicative, which is illustrated by the fact that annotations have to be used to explain for instance the use of icons in a design. On the other hand, prototypes cannot directly inform other important aspects of the interactive system, for that other artefacts such as task models [3], dialog models and interaction models [4] must be used.
Empirical observations have demonstrated that development teams often make an extensive use of annotations as a communication support [2]. It is a basic assumption that decisions made by the development team will create iteration along the process and affect the way artefacts must evolve. Indeed, prototypes and artefacts evolve along the development process and many of the design decisions might be described in the form of annotations. The dangling question is: What happens with annotations in a UCD development process? This paper presents a micro-development process that is aimed to describe the life cycle of annotations and how annotations co-evolve with artifacts along the development process of interactive system. Moreover, we discuss how stakeholders might make better use of annotations for improving the communication in a UCD process.
The first studies about annotations started with the identification of common practices by university students on their paper textbooks [5]. Paper-based annotations work as a conceptual model for electronic documents. Therefore, common definitions of annotation often refer to text documents [6]. Kahn & Koivunen [7] define annotations as "user made statements", consisting in a body (i.e. text note or graphical content), a link (the so-called anchor) to the target which include a location within the document as well as other metadata. As we shall see, these three elements (body, target and link) are core concepts not only for paper-based or electronic documents but they are essential to understand how annotations applies to the many artefacts used to build interactive system as well.
In [8], Li et al. have defined a classification of annotation approach for Computeraided Design. This classification identify the following categories of attributes that complete the specification of annotation: targeted media, audience, rendering system, usage and function, representation, and storage location. This classification of annotations bring another complementary view of annotations. Based on the literature on text and electronic documents [5][6][7][8][9][10][11][12], we can summarize three main functions played by annotations: to enrich a document, to support communication and to support an intention/activity carried out by the author of the annotation. Whilst most of the literature in the matter refers to text documents, that classification is relevant for the development of interactive systems.
More and more prototyping and IDE environments at least some basic mechanisms for annotating artifacts [13]. Very recently, the W3C proposed a standard called Web Annotation Data Model which was created for specifying a model and a format to ensure the sharing and reuse of annotations across different hardware and platform. All these tools testimony of the increasing importance of annotation for building interactive systems.
Very few studies have investigated how annotations could affect the development of interactive systems in a UCD process. The study performed by Gutierrez et al. [2] pointed out that annotations are used by members of development teams to: record the results of discussion including decisions and upcoming tasks, communicate and inform other team members of the work done, gather internal and external feedback on artefacts stored in the workspace, conduct usability evaluations by documenting information and by recording conversation between design teams and UX experts, justify design choices, and document the design choices by describing them retrospectively. The work of Gutierrez et al. [2] does not make any distinction between types of stakeholders. It is worthy of recalling the classification of Winckler et al. [16] who identify two groups of stakeholders taking part in a UCD process: the development team (which encompass roles having responsibility with respect to the production of artefacts) and external members (such as clients and end-users) who provide opinions, requirements, and/or constraints for the design. Interesting to notice that these two groups of stakeholders collaborate along the development process in iterative cycle.
Thus, regarding the use of annotations, it is possible to identify two main roles: the writer of the annotation and the readers. More generally, annotations is a mean to convey a large variate of intentions to the reader. Naghash et al [12] suggest 6 different usages of annotations: i) clarifying and explaining the design; ii) verifying and requesting a verification from other designers or users; iii) exploring by asking questions to obtain more details on end users' needs; iv) altering or requesting an alteration proposed by the end users; v) confirming and giving feedback on a design; and vi) asking questions to the designers.
Whilst the development team are responsible for creating artefacts and make use of annotation to coordinate their activities, external member might use annotations to express opinions and comment on what is being developed. In the rest of this paper, we assume that annotations are suitable communication tools that must be available to the diverse stakeholder (readers/writers) that take part in the development process of interactive systems.
The Figure 1 represent the lifecycle of a design artefact within a UCD process. This process acknowledges that the creation artefacts are a starting point for the work. Nonetheless, it does not impose any artefact to be created, which might be dependent on project needs. After creation, the design team should be able to perform following tasks:
• Edit the artefact, either for enriching it, for correcting it, or for making to match new requirements.
• Archive the artefact within a workspace for future use.
• Submit the artefact for evaluation, which leads to the creation of a new artefacts such as an "evaluation report". The results of an evaluation have their own lifecycle within the design process and might lead to the creation/updating of other artefact (ex. new user interface design is created following recommendations of a usability evaluation). These outcomes are represented by the red arrow labelled "External influence".
• Dispose the artefact, when it is no longer useful. Artefacts might pre-exist, for that, the process includes an "existing" state represented by the grey rectangle in Figure 1. Depending on the collaborative tools used by the design team, a distinction can be made between a local copy and a shared copy of the artefact. This duplication of artefacts require an effort of synchronization for the design team who have to manage the consistency between the local copies of each contributor with the shared copy.
It is interesting to notice that annotations are, at some extension, a special case of artefact. Annotations depends on the artefact they are attached to, but they possess their own lifecycle which can be evolving independently from the design artefact. One particular aspect of the annotations in a UCD process is that annotations can be related to certain versions of the artefact but not each of its version (e.g. an annotation indicating to fix an error).
The life cycle of an annotation shown by Figure 2 starts with a decision. The creation might be motivated by a variety of reasons and influenced by external influences (e.g. in reaction of other annotations, of the content of an artefact). This creation can occurs when the artefact is being consulted, edited or evaluated. After its creation, the annotation is in a private state and only visible to its author. In this state, the annotation can be updated and reviewed anytime by its author. Depending on the annotation, its author can decide to publish it to make it visible to other members of the design team.
Published annotations are presented to the different actors of the design process who can argue with the information contained in the annotation (which can lead to the creation of an annotation as a response) or who can validate the annotation to ensure its relevance toward the artefact and to assess its content.
When validated by stakeholders, annotations are kept as a reference about activities taking place along the design process (e.g. information on the requirements, appreciation marks of the design, highlight of problems). These information can have an impact on other design artefacts which is represented by the red arrow. For instance, a problem on a prototype identified with an annotation can motivate and justify a decision to edit the prototype in order to fix it. After that, annotations can be managed by indicating that it has been processed.
If the annotation is not validated, the annotation will not have an impact on other artefacts or for future uses in its current state. Similarly to artefacts, annotations can be archived for keeping the annotation in its current state or disposed when it is no longer useful.
Annotations can also affect the evolution but are also be affected by the evolution of the artefact itself. Thus, while annotation have their own lifecycle, this lifecycle is interweaved by the life cycle of annotated artefacts. An annotation is created or updated on an artefact in reaction to the content of the artefact as illustrated by the red arrow "Induce the creation of annotations" in the Figure 3. After the creation of the annotation, the annotation can be attached or detached to any artefact or fragment of artefact to include it to its target list represented with orange arrows. In return, the annotation can have an impact on the artefacts it is attached to. Indeed, annotation can be used a medium of communication for discussing, for contributing to the elaboration of an artefact, to point out modifications to make on the artefact. The content annotations can be varied from the topic discussed, the intentions of the persons involved in the annotations, the precision of the information, and the quantity of information contained. Depending on this content, several type of impact can be identified: no modification required (e.g. for informative annotations), localized modification restricted to the artefact (e.g. correcting a typo, adding a precision) or global modification that can impact other artefacts (e.g. appearance of new requirements or adjustment of existing requirements). While annotations may have an impact on design artefacts, they are not always factual and can reflect opinions that should be nuanced and cross-referenced with others opinions or concrete facts prior to taking decisions. Thus, annotations can be used to motivate or support a decision regarding the artefact as illustrated by the red arrow "Induce or support a decision".
Regarding the impacts of an annotation to the update of an artefact, their weight can depends on several factors. Indeed, annotations can point out problems directly, reflect an opinion or unverified data from different sources and thus, the information conveyed needs to be validated. This can be done by several means such as checking the person involved in the discussion, analyzing the relevance or the trustworthiness of the information. After the validation, another aspect can be taken into account that can influence the impact on targeted artefacts. Indeed, a decision process can be integrated prior to the editing of the artefact. This decision process can assess the cost of the editing and its planning if the editing has been adopted by the design team.
Another interaction between the artefact and the annotation is the mutual update they can trigger. When updating an artefact, the content of each annotations attached to the artefact may be questioned or the state of the annotation can be updated to match it with the new state of the artefact.
Annotations are a versatile tool for documenting the design by associating documents or by explaining. They can be used for communication, for planning tasks, for reviewing the design and by allowing stakeholders to highlight problems, to question the design or to give opinion.
This presented the connections between annotations and artefacts along the development process of interactive systems. This work is an attempt to promote annotations as a first class artefact that could be used for tracking design decisions along the development process of interactive.
Currently, we have implemented tools that allows to connect annotations to multiple artefacts. Our ultimate goal is to develop tools that could help the development tool to make a better use of annotations to communicate, trace design decisions and follow the evolution of artefacts along the development process. These tools are suitable for a demonstration and future work will encompass the evaluation of them with real users. In a long run, we expect that our tools would be able to collect design decisions along many projects. The analyses of design decisions and their association with the evolution of artefacts, might provide useful data for have a better understanding on the real practice of UCD process.