Design Process and Evaluation

In our approach, we followed the design study methodology by Sedlmair et al. [SMM12]. Our design process was conducted in a two-years effort, comprising three iterations of design (DESI), implemen-tation (IMPL), and evaluation (EVAL) (see Figure4.7). The focus of each round was chosen in line with the suggestions provided by Munzner et al. [Mun09]. Based on thedomain characterization(cf.

Section4.3.1) and thedata and task abstraction(cf. Section4.3.2), we implemented an early prototype that was shown to selected expert users. In interviews with the experts we validated theproblem char-acterizationand thedata/operation abstraction design. In the second round, we focused on thevisual encodingand theinteraction design. Feedback on the usability of PolicyLine was collected. Finally, in the third round, we repeated the evaluation design of the second round to measure the progress made.

In the following, we briefly describe each of the evaluation stages and present the achieved results.

4.4. Design Process and Evaluation

Figure 4.5.:Process Creation Form.

4.4.1. Pre-Evaluation - Expert Interviews

Initial user feedback on the first version of PolicyLine was gathered in a pre-evaluation round which has been conducted in form of informal interviews with four selected expert users highly connected to political EU institutions. The purpose was to understand whether the design of our approach de facto addresses the experts’ problems. Feedback about the usefulness of PolicyLine helped us to extract re-quirements on a refined version. The main requirement was to improve and expand the functionalities regarding the manual creation of content. The experts preferred manually provided content instead of using automatic approaches for extracting policy processes and process steps from external sources like EUR-Lex. Also the manual classification of the documents’ author categories was preferred over au-tomatic approaches. This feedback further strengthened our vision of a collaborative system approach.

Still, the experts promoted the usage of automatic approaches to augment the policy processes and analyze its textual content. Moreover, the experts shared detailed perspectives on a refined structure of the timeline visualization. A clear separation of the high level author categories on the y-axis, a decoupled display of non-overlapping process steps on top of the timeline, and an intuitive zooming functionality were requested. The detailed feedback on creating policy processes, on adding manually curated documents, and on the timeline visualization enabled us to improve and refine the design of PolicyLine significantly.

Figure 4.6.:Document Creation Form.

4.4. Design Process and Evaluation

Figure 4.7.:Overall Evaluation Methodology.

4.4.2. Two Qualitative Evaluation Rounds

We tested the usefulness and the usability of PolicyLine in two consecutive evaluation rounds. We applied the same experiment design in both rounds which allowed us to (a) receive feedback and sug-gestions for improving the application (formative evaluation), and (b) to measure the progress between the first and the second version of PolicyLine (summative evaluation). The two rounds were conducted with fifteen and ten real-world users from the EU environment.

Evaluation Design.Both evaluation rounds were divided into four parts: (1) a personal information form, (2) a task completion test, (3) short usability questionnaires on the individual interfaces, and (4) a final questionnaire on the overall approach. Through the personal information form, we acquired information about the users’ IT expertise. The task completion test was designed to cover the main functionalities of PolicyLine. The users were asked to (a) create a policy process, (b) add documents to the process, (c) explore the process with the timeline visualization, and (d) explore the information provided about a single document (only applicable for the second round). After each task, they had to respond whether they were successful in completing the task. After the task completion test, the users had to answer separate questionnaires on the respective interfaces. For each visual interface we designed four open questions, and four (closed) statements, which had to be rated on a 5-level-Likert scale. For each interface, the open questions 1-3 were covered by the control questions 2-4, while the first control question covered the task completion test. These questions/statements concerned the intuitiveness, the organization, and missing information of the interfaces. The final questionnaire con-tained five open questions for sharing ideas and suggestions, followed by ten closed statements about the overall impression of our approach. The evaluation was conducted with an online tool developed by Nazemi et al. [NBH^∗15].

Results of First Round. Given the fact that future users of PolicyLine expect the system to be self-explanatory, the evaluation was conducted without introduction. In the first round, we recorded difficulties to grasp the general concept of a policy process and the process steps. As a result, we improved the introductory aspects of the system. Therefore, we designed an infographic that explains the overall concept of PolicyLine in a compact way. Another issue concerned the EUR-Lex

reposi-tory [Eur16], the main source for European legislative documents. While some experts appreciated the inclusion of a EUR-Lex link as source for automatic document crawling, others were not aware of this information source. They reported that they still use Google for searching relevant policy documents, which once more supports the idea of our approach to provide a “one stop shop decision making aid”

as one participant stated. The general intuitiveness and usability of all interfaces was described very positive. Moreover, the participants welcomed our collaborative approach by requesting further man-ual content creation facilities, like providing the owner/initiator of a process, enabling longer textman-ual descriptions for documents and processes, etc. Moreover, they proposed the augmentation of the policy process with events. Several participants requested refinements on the author categories, e.g., a cate-gory to identify peer-reviewed research papers was requested. As an overall feedback, most of the users stated that our approach is very innovative, and would help them in their daily work. They also pro-vided high ratings for the learnability of PolicyLine. Surprisingly, some participants also commented on the aesthetics of the interface. While we were focusing on the functionality of the interfaces in the first implementation round, they demanded to improve the look and feel of the application in order to attract more users.

Results of Second Round. In the second evaluation round, experts identified several improvements on the process creation form. Still, most of them commented that this is a very important task that should be carefully executed by expert users only. The success of our approach would heavily depend on the quality of the curation process. Hence, once more the separation of expert users curating pro-cesses and associated documents, and general users with the intent of getting an overview of ongoing policy processes was emphasized. The refined author categories were widely accepted. The linguistics component at the document page was not well understood by the experts and required more expla-nations. The timeline was appreciated by most experts. Still, some participants stated that it looks

“busy”. This obvious trade-off between the visual information density and the subjective usability will be subject to possible future work. As a final remark, we want to emphasize the dissent between some users having problems in handling simple visualization techniques and others requesting more innovative visualization techniques. Exemplary statements on our overall approach were: the tool is

“multi-stakeholder and multi-purpose”, “a useful decision making tool that creates better set of op-tions”, “practically no training needed”, “the timeline is useful once it is well created and all relevant documents have been uploaded”, “a dynamic information channel”.

4.4.3. Collaborative Usage Scenario

PolicyLine’s overarching goal is to increase the transparency of the policy process among all stake-holders involved. To illustrate its power, we demonstrate a collaborative usage scenario. Policy analyst Aliceis engaged by the European Commission (EC) to initiate and analyze the public discussion on TTIP. Using PolicyLine, Alice simply creates a new process, enters a few details and starts adding the relevant institutional documents (like white papers or policy proposals) written by the European Commission and published via the online portal EUR-Lex. Then, she shares the PolicyLine process to initiate a public discussion and becomes an observer monitoring the process. Multiple stakeholders start

4.4. Design Process and Evaluation

to contribute to the process. One of them is lobbyistLawrence, who works for a large multi-national corporation. He is interested in influencing the legislative decision in the direction of his employers’

favor. For this, he adds documents that argue pro TTIP. Finally, he rates existing documents in line with the vision of his employer. Alice also reachedChloewho works for an Anti-TTIP NGO. Chloe adds documents to the process, rates further documents against TTIP, and also adds her own proposal.

As this flow is repeated by different stakeholders, the public discussion intensifies. Alice monitors the evolution closely and observes that the Anti-TTIP proposal by Chloe has a high support from many credible experts in the topic. Therefore, she puts that proposal on the agenda for one of her next meet-ings at the EC in order to evaluate the raised key issues. Obviously, she uses PolicyLine as a visual means to communicate the evolution of the process.

4.4.4. Lessons Learned

Providing a policy process visualization system to political stakeholders was appreciated by experts from the domain. There was an obvious lack of such a system. The content creation functionality was well accepted by most of the experts, although there was a discussion, who should be able to curate policy processes. They emphasized that the process creation cannot be automated due to the absence of standardized structures. Still, the automatic augmentation of official documents from existing repos-itories (e.g., EUR-Lex) was appreciated. Further automatic techniques like linguistic analysis methods were initially requested by the domain experts. However, the functioning of such techniques needs to be carefully explained to the users to increase the acceptance of text analysis results. From this, we learned thattrustand theawareness of uncertaintyin the data needs to be carefully considered during the design of visualization systems for policy domain users.

From the visualization perspective, we learned that a visualization system supporting the derived tasks needs to be carefully designed. We learned that the attempt to structure policy processes that are not necessarily structured and providing an intuitive access to the derived structure are difficult tasks. Meeting the expectations of different stakeholder types is cumbersome. However, the involved stakeholders are very enthusiastic about the benefits of such an approach. Seeing the whole process lifespan including the most relevant documents at a glance was a requested key feature. However, the definition of relevance is difficult due to conflicting user expectations. Therefore, drill-down (by zooming), and search functionality to explore less relevant documents is an essential functionality for knowledge acquisition.

Finally, our initial design process plan consisted of two cycles including design, implementation, and evaluation within each cycle. During the first design phase, we realized the need for an intermediate evaluation to validate whether the user expectations were met. From this, we learned that the policy domain varies from other application domains. First, computer expertise strongly varies in this field.

Both highly skilled technicians and seniors with little to no computer expertise collaborate in this domain, which makes it difficult to derive clear requirements from the users. Second, due to time pressure, political stakeholders are difficult to reach. Hence, it was of key importance to collaborate with partners that had close connections to EU stakeholders.