Automating the Design and Development of Usable, GDPR-Aware Web Forms

ORIGINAL RESEARCH SN Computer Science SN Computer Science (2026) 7:639 https://doi.org/10.1007/s42979-026-05219-7 Evangelia Vanezi vanezi.evangelia@ucy.ac.cy Anna Vasileiou vasiliou.anna@ucy.ac.cy George A. Papadopoulos george@ucy.ac.cy 1 Department of Computer Science, University of Cyprus, University Avenue 1, 2109 Nicosia, Cyprus Abstract Personal data collection in web applications should follow mandated legislative frameworks such as the EU General Data Protection Regulation (GDPR) principles. Among others, web data collection forms should provide clear and transparent explanations regarding the purposes of the collection. At the same time, for users’ ease, such forms should follow standard usability principles. There have been works studying the merging of usability principles and privacy standards. Building on this line of work, we exploit the usable privacy heuristics, in combination with a set of relevant GDPR principles and the current website landscape, to create a user-centred design for transparent, usable, and GDPR-aware web forms through high-fidelity prototypes. We developed and validated a purposes dataset, both in human-readable and machine- readable formats. Finally, we developed a tool to assist web engineers in creating such forms and integrating them into their websites. We present an evaluation of the tool, demonstrating overall positive results and highlighting the potential of our approach to improve transparency at the point of data collection. Keywords GDPR · Usability · Transparency · Purpose limitation · Web forms · Personal data Received: 15 January 2026 / Accepted: 2 July 2026 © The Author(s) 2026 Automating the Design and Development of Usable, GDPR-Aware Web Forms Evangelia Vanezi 1 · Anna Vasileiou 1 · George A. Papadopoulos 1 communicate to users why data are being collected and how they are to be used, i.e., the processing purposes. The regulation also dictates that such purposes should be con - cise, easily accessible, and easy to understand, according to Transparency (GDPR Recital 58). Nevertheless, at present, most systems tend to provide such purposes through privacy policy texts, which are often lengthy, full of legal jargon, and difficult to interpret [ 2 ]. This creates a gap between compliance requirements and users’ ability to make informed privacy decisions [ 3 ]. It is also evident that developers are not fully familiar with legal obligations and require solutions that are quick to imple - ment, user-friendly, and do not disrupt the overall design of data collection forms [ 4 ]. In this work, with the aim of assisting web users in under - standing the processing purposes of their personal data dur - ing collection, and supporting web developers in integrating these purpose explanations correctly and transparently into their forms, we design and develop a research-based tool that automates the creation of such forms, following a user- centred design approach for forms that are usable, trans - parent, and GDPR-aware. To do so, we exploit the usable privacy heuristics [ 4 ], a set of guidelines on how to effec - tively make privacy user interfaces (UIs) usable. Moreover, Introduction Users share personal data continuously over the web in order to use online services and platforms. 1 The protection of these personal data, and hence users’ privacy, is man - dated by regulations such as the European Union General Data Protection Regulation (GDPR) [ 1 ], applied since 2018, imposing rights for data subjects and liabilities for data pro - cessors and controllers. One such principle is Purpose Limi - tation (GDPR Article 5-1b), requiring systems to explicitly 1 According to Statista ( https: //w ww.stati sta .co m/stat i stics / 61713 6/ di gital-po pulation-worldwide/ ), as of 2025, over 6 billion individu - als worldwide were internet users, representing more than 73% of the global population. SN Computer Science 639 Page 2 of 17 SN Computer Science (2026) 7:639 towards GDPR awareness, beyond Purpose Limitation and Transparency, we address the principles of Data Minimisa - tion (GDPR Article 5-1c), and Storage Limitation (GDPR Article 5-1e). As a first step, aiming to understand the current land - scape of how web forms communicate processing purposes to users, we conducted a manual data collection and review across eight major web sectors, examining a total of 160 websites and 320 pages (registration and account pages were reviewed in all websites as the main common points of data collection). This revealed common problems, such as missing or unclear explanations about how user data will be used. From our audit, we were able to identify four different types of purpose communication (A–D), as well as five representative design approaches (A1–A5) used to implement such communication. Following that, through a user-centred methodology, we conducted a user survey to identify users’ preferred approaches. In parallel, we devel - oped a design framework grounded in GDPR principles and usable privacy heuristics. The two top-voted approaches in combination with the framework were used to develop high-fidelity prototypes for usable and transparent forms. We then developed a dataset of processing purposes for the 20 most commonly collected personal data fields, which we subsequently validated with legal and technical experts. The dataset was also translated into machine-readable for - mats (XML, JSON). Following this, a tool was developed that is informed by the dataset and adopts the design and guidelines from the previous steps, aiming to automate the process of creating and embedding usable and GDPR-aware forms in existing websites. We evaluated our tool using a mixed methodology, employing a user survey and indi - vidual interviews with software engineers, and analysed the results through quantitative and qualitative means, observ - ing positive results and opportunities for future directions. Methodology Figure 1 demonstrates the methodology followed in this study. Initially, we conducted a literature review to explore the current status of research on usabil - ity and readability of privacy policies on websites, with particular focus on the point of personal data collection. In parallel, we examined relevant GDPR principles, such as purpose limitation , as well as the usable privacy heuristics . Drawing on this background, we identified that, while many works address purpose communication within pri - vacy policy pages, limited attention has been given to the point of data collection itself. Existing approaches largely focus on analysing or presenting privacy information within policy documents, without providing actionable guidance on how such information can be effectively integrated into user interfaces at the point of interaction. At the same time, developers are required to comply with the GDPR and incorporate legal requirements into their UI design, high - lighting the need for practical, design-oriented tools that support the implementation of transparency and usability principles directly within data collection forms. Motivated by this gap, and with the aim of developing a tool to support users’ understanding of data collection pur - poses directly at the point of interaction, we proceeded with an investigation of the current web landscape. Specifically, we conducted a manual audit of 160 web - sites to analyse how processing purposes are communicated and categorised these approaches into four main types. Building on these findings, we derived a set of five repre - sentative design approaches, and conducted a user survey to identify those that users prefer as they best support their understanding and usability. In parallel, we developed a design framework. We then developed high-fidelity proto - types by combining the selected approaches with our design framework, incorporating GDPR principles and usable pri - vacy heuristics. Following the prototypes, we developed the functionality of the proposed tool. Finally, we conducted an Fig. 1 Overview of the research methodology and design process SN Computer Science Page 3 of 17 639 SN Computer Science (2026) 7:639 evaluation of the tool with users, combining quantitative and qualitative methods. This multi-stage process follows a user-centred, design- oriented approach, where empirical insights, theoretical grounding, and user involvement inform the development of the final artifact. Contributions 1. An empirical audit of 160 websites, revealing systematic transparency gaps at data collection points. 2. A user survey on design approaches for GDPR-aware forms. 3. A conceptual design framework for form-level transpar - ency, integrating GDPR principles and usable privacy heuristics. 4. High-fidelity prototype designs informed by the user-pre - ferred approaches and the conceptual design framework. 5. A validated dataset of processing purposes in human- and machine-readable formats (XML, JSON). 6. A tool operationalising usable privacy and transparency- by-design at the data collection interface level, into developer workflows. Structure. The rest of the paper unfolds as follows: “ Related Work and Background ” provides insights into related work and presents back - ground information about the GDPR and the usable pri - vacy heuristics. “ The Current Landscape of Web Forms ” presents our manual data collection and analysis of the current landscape of web forms, “ Designing Usable and GDPR-Aware Web Forms ” demonstrates our user- centred design process, while “ A Dataset of Processing Purposes ” presents our dataset creation, validation, and formats. The tool is presented in “ A Tool for Automating the Creation of Usable and GDPR-Aware Web Forms ”, followed by its evaluation in “ Tool Evaluation ”. We con - clude our work in “ Conclusions ”. Related Work and Background Related Work There have been several tools developed for improving pri - vacy policies readability and comprehension by end users. PriX [ 5 ] is a tool aiming to address the issue of overly com - plex privacy policies and enhance privacy transparency by automatically analysing privacy policies and providing visual explanations to make key privacy information more accessible. Moreover, other approaches have been explored to improve privacy transparency, including privacy icons and labels through efforts to develop standardized icons that visually represent key privacy terms, similar to nutri - tion labels for food packaging [ 6 ], as well as machine learning-based privacy policy analysis via tools such as Polisis [ 7 ] and PriBot [ 8 ], which use natural language pro - cessing to summarize and answer questions about privacy policies. PRISMe [ 9 ], is an interactive browser extension that combines LLM-based policy assessment with a dash - board and customizable chat interface, enabling users to skim quick overviews or explore policy details in depth while browsing. Similarly, another chatbot-based tool pro - viding assistance to users to understand and use their pri - vacy rights is the chatbot-based privacy assistant introduced in [ 10 ], providing users with a conversational interface to navigate privacy policies, manage personal data, and exer - cise their GDPR-defined rights. Although there are works on combining usability and privacy, providing either visuals of privacy policies, ana - lysing and summarising privacy policies, or adding icons and labels, to the best of our knowledge, there is no study addressing the communication of processing purposes via usable and transparent online forms directly at the level of data collection, nor explicitly addressing specific GDPR principles at the point of data collection. GDPR Principles The EU GDPR was voted in 2016 and has been applied since May 2018, affecting all systems collecting, storing, and handling personal data of individuals residing within the European Union. According to the GDPR Article 4, Per - sonal Data means any information relating to an identified or identifiable natural person (‘data subject’). The GDPR defines a set of rights for data subjects and obligations for data controllers and data processors. Among others, a set of principles relating to the processing of personal data is defined in GDPR Article 5. In this work, we aim to align web design and develop - ment, and more specifically data collection points, i.e., data collection forms, with the following main GDPR principles: ● Purpose Limitation (GDPR Article 5-1b): according to this principle data should be “collected for specified, ex - plicit and legitimate purposes[...]”; therefore, process - ing purposes should be presented explicitly to the users and be specific. ● Data minimisation (GDPR Article 5-1c): this principle dictates that personal data collection should be “limit - ed to what is necessary in relation to the purposes for which they are processed”, and as such users should not be forced to provide more information than what is necessary. ● Storage Limitation (GDPR Article 5-1e): defining that personal data should be “kept [...] for no longer than is necessary for the purposes for which the personal data SN Computer Science 639 Page 4 of 17 SN Computer Science (2026) 7:639 are processed”, with users being clearly informed about this processing period. ● Transparency (GDPR Recital 58): according to this, “[...]any information addressed to the public or to the data subject be concise, easily accessible, and easy to understand, and that clear and plain language and, ad - ditionally, where appropriate, visualisation be used.” Usable Privacy Heuristics To design usable forms, we exploit the work of [ 4 ], which proposes a set of six usable privacy heuristics, as follows: 1. Readability of Privacy Policies : Privacy policies should be clear and easy to understand, allowing users to make informed decisions about their data. 2. Users’ Doubt and Precaution : Users should be able to assess risks and consequences related to their privacy choices, encouraging careful decision-making. 3. Provide Help and Avoid Jargon : Privacy interfaces should offer guidance and avoid technical terms, ensur - ing accessibility for all users. 4. Discretionary Access Control : Users should be informed about who has access to their data and be able to manage permissions accordingly. 5. Fast Interaction and Human Error Vulnerabilities : Privacy settings should be designed for quick interac - tions while minimizing the likelihood of mistakes. 6. Unstable Choices and Appropriate Symbols : Privacy settings should accommodate changes over time, and symbols should be intuitive to help users easily interpret their choices. These heuristics, extending Nielsen’s usability heuris - tics [ 11 ], help address common usability issues, and enhance user control over privacy settings. They are aimed at improving privacy interfaces, particularly for non-technical users. The heuristics were designed to address the gap iden - tified by the study in [ 12 ], which designed and tested a UI aimed at giving users more control over their personal data by helping them understand and manage who can access their data and for what purposes. It showed that while the UI enabled users to define access policies, it was not user- friendly and many users struggled to navigate the interface. The Current Landscape of Web Forms In order to explore the current landscape of data collection web forms and the ways they communicate the process - ing purposes for collected personal data, we conducted a manual audit, reviewing 160 websites with a total of 320 pages (registration and account pages) across eight web sec - tors (S1–S8): (S1) E-commerce; (S2) Health and fitness; (S3) Education; (S4) Social media; (S5) Travel and accom - modation; (S6) Online banking and payment services; (S7) Financial services and financial technology; and (S8) Job and recruitment services. These sectors were selected by considering a combination of factors, such as the popular - ity of each domain and its relevance to how personal data is collected and managed. For each sector, we audited the 20 most popular websites based on rankings from various sources. We studied these 160 websites through a manual data collection process and gathered all data in an MS Excel file, through which we were able to analyse the data and sum - marise the results in tables and graphs, as presented in this section. For each website, we specifically audited the Reg - istration Page and the Account Settings/Edit Profile Page, as it was observed that all these websites share these two com - mon main pages for collecting personal data. While the ini - tial dataset comprised 160 websites, the final set of analysed pages included 147 Registration Pages and 114 Account Settings/Edit Profile Pages. This reduction was due to exter - nal reasons that did not allow us to access specific pages; for example, in some cases account creation required payment. We next present our detailed data collection, analysis, and results, aiming to provide insights into the ways processing purposes are currently presented to users on the web. All our collected data, categorizations, analyses, and raw results can be found online. 2 Initial Data Collection For each of the 160 websites, we initially collected and tabulated the following data: (1) the website sector (one of the eight predefined sectors); (2) the website domain name (URL); and (3) and (4), for the registration and account pages respectively, textual descriptions of the ways the form communicates the processing purposes for each field to the user, including the actual description for each field and any other links provided, e.g., a link to the privacy policy of the website. Analysis By analysing data (3) and (4), we were able to identify four different ways which processing purposes are communi - cated from the form to the user: 2 Link will be published upon acceptance. SN Computer Science Page 5 of 17 639 SN Computer Science (2026) 7:639 ● A: The website does not provide any information (nei - ther a link nor text) about how or why personal data is collected. ● B: The website provides a link to its Privacy Policy or Terms of Use. ● C: The website explicitly describes the usage of at least some fields that require personal data. ● D: The website explicitly describes the usage of all fields that require personal data. We then marked each website with the category to which it belongs, with some websites belonging to more than one category. For example, a website may provide a privacy policy link and at the same time explicitly describe some of the fields. We defined a scoring system to assess websites in terms of the overall level of transparency they provide based on the categories to which they belong, as follows: 0 points for Category A, 1 point for Category B, 2 points for Category C, and 3 points for Category D. The scores were calculated and assigned to each registration and account form. For websites belonging to more than one categories, the points were summed across all the categories. Additionally, we identified five communication approaches used across the websites as follows: (A1) Icon pop-up messages next to each field; (A2) Short explana - tion next to each field; (A3) One general explanation for all fields; (A4) One clickable link to more information for all fields; (A5) One pop-up from a clickable link for all fields. For each website belonging to types C or D, i.e., providing information directly on the form, we assigned a number to its two forms, relating each to the approach it follows based on qualitative analysis of data (3) and (4). Results Table 1 presents the distribution of pages across the defined categories (A, B, C, D) for each sector. Overall totals may exceed the total page number, due to pages belonging to multiple categories. Overall Across all sectors, from a total of 147 registration pages, we observe that the majority (n = 134, 90%) belong to type B, i.e., they provide a link to a privacy policy or terms of use. We also observe that n = 40 websites (27%) explicitly describe the purposes for at least some fields, while n = 5 websites (3%) do so for all fields. A percentage of 8% of the websites does not provide any information at all (type A). Respectively, from a total of 114 account pages, we observe that the majority (n = 50, 44%) does not provide any information about the collection purposes, while only n = 36 websites (31%) provide a link to a privacy policy. These discrepancies from the registration pages can be attributed to the assumption that, as users have already encountered privacy-related information during registration, websites do not find it necessary to reiterate this information on Account Settings pages, even though these pages often involve data modifications and management. We additionally observe that n = 33 websites (29%) explicitly describe some fields and n = 8 websites (7%) explicitly describe all fields. Per Sector We observe that the largest number of reg - istration pages not offering any information at all (n = 8) belong to the Health and fitness sector (S2), while in sectors S6-S8 no such registration pages exist. On the other hand, all sectors include a number of account pages that do not offer any information. At the same time, most registration pages explicitly describing all fields (n = 3) belong to the Online banking sector (S6), while for account pages most such pages (n = 4) belong to the Social media sector (S3). Transparency Scores As mentioned, pages were assigned transparency scores based on the categories to which they belong, as follows: 0 points for Category A, 1 point for Category B, 2 points for Category C, and 3 points for Category D. In the case of a page belonging to more than one category, the total score was assigned to the page. Figure 2 presents the Average Transparency Scores (ts) for each sector (registration pages in comparison to account settings pages). We observe the highest average transpar - ency score in the Online banking sector registration pages Table 1 Distribution of registration and account pages across transparency categories (A–D) per sector Registration pages Cat. S1 S2 S3 S4 S5 S6 S7 S8 Total A 1/20 8/20 1/20 1/20 1/20 0/15 0/16 0/16 12/147 (8%) B 18/20 12/20 19/20 19/20 19/20 15/15 16/16 16/16 134/147 (90%) C 2/20 2/20 7/20 2/20 7/20 7/15 6/16 7/16 40/147 (27%) D 1/20 0/20 0/20 0/20 0/20 3/15 0/16 1/16 5/147 (3%) Account pages Cat. S1 S2 S3 S4 S5 S6 S7 S8 Total A 13/16 7/9 5/19 7/20 10/20 4/8 3/10 1/12 50/114 (44%) B 1/16 0/9 3/19 5/20 6/20 3/8 7/10 11/12 36/114 (31%) C 2/16 2/9 8/19 12/20 6/20 0/8 0/10 3/12 33/114 (29%) D 0/16 0/9 4/19 0/20 0/20 1/8 3/10 0/12 8/114 (8%) SN Computer Science 639 Page 6 of 17 SN Computer Science (2026) 7:639 (ts = 2.53), followed by the Job and recruitment sector reg - istration pages (ts = 2.06), while the lowest scores belong to the Online shopping sector (ts = 0.23), followed by the Health and fitness sector (ts = 0.44). Transparency Communication Approaches For all reg - istration pages (n = 45) and account pages (n = 41) belong - ing to categories C and D, i.e., explicitly describing the purposes for at least some or all of the fields, Table 2 shows the communication approaches (A1–A3) used per sector for both registration and account pages. We observe that the majority of pages (registration pages n = 40, account pages n = 34) use A2, displaying text next to the field. Designing Usable and GDPR-Aware Web Forms Drawing from the insights of the manual audit (“ The Cur - rent Landscape of Web Forms ”), which identified five representative design approaches (A1–A5), we followed a user-centred approach to identify the two preferred approaches for communicating processing purposes on web collection forms. In parallel, we developed a concep - tual design framework combining the GDPR principles and the Usable Privacy Heuristics. Finally, we combined the selected approaches with the proposed design framework to develop high-fidelity UI prototypes. User Survey on Design Approaches Users were presented with one real-life example for each of the five different approaches (with identifying elements removed), followed by a 1–5 star rating scale, which they were asked to complete, as shown in Fig. 3 . At the end, users were asked to respond to a final over - all design selection question to indicate which approach communicates the purpose of data collection more clearly and effectively to them (Fig. 4 ). The survey also included a demographic section in which participants were asked to indicate: (a) their age group (Under 18, 18–34, 35–54, or 55+); (b) their sex; and (c) whether their occupation was related to Computer Science/IT, Law/Legal professions, or neither. Table 2 Communication approaches (A1–A5) used in registration and account pages across sectors Registration pages Account pages A1 A2 A3 A1 A2 A3 S1 (total = 3) 3 S1 (total = 2) 2 S2 (total = 2) 2 S2 (total = 2) 2 S3 (total = 7) 2 5 S3 (total = 12) 9 3 S4 (total = 2) 2 S4 (total = 12) 10 2 S5 (total = 7) 6 1 S5 (total = 6) 5 1 S6 (total = 10) 10 1 S6 (total = 1) 1 S7 (total = 6) 5 1 S7 (total = 3) 1 2 S8 (total = 8) 7 1 S8 (total = 3) 3 Total 2 40 3 Total 1 34 6 Fig. 2 Average transparency scores (ts) per sector for registration and account settings pages SN Computer Science Page 7 of 17 639 SN Computer Science (2026) 7:639 Results We collected and analysed a total of n = 91 responses, with demographic diversity across age, gender, and occupational backgrounds. A total of 52.7% of partici - pants identified as female, 46.2% as male, and 1.1% pre - ferred not to say. A significant majority (83.5%) were in the age group of 18–34, followed by 13.2% in the group 35–54, and small percentages in the age groups Under 18 and 55+. Additionally, 46.2% of the participants reported being in occupations related to Computer Science/IT, 4.4% in occu - pation related to Law/Legal professions, and the remaining 49.5% in unrelated fields. The design approach with the highest average rating (avg r) was A2 (Short Explanation Next to each Field) (avg r = 4.44), followed by A1 (Icon Pop-Up Messages next to each field) (avg r = 3.88). Table 3 shows the sorted results for all five approaches. In the overall design selection question, 46.7% of the participants selected the “Short Explanation Next to each Field” approach (A2), 22.2% the “Icon Pop-Up Messages next to each field” approach (A1), 13.3% selected the “One General Explanation for All Fields” approach (A3), 10% selected the “One Pop-Up from a Clickable Link for all fields” approach (A5), and 7.8% the “One Clickable Link to More Information for all fields” approach (A4). Based on these results, approaches A2 and A1 were selected as the preferred approaches and are used in the pro - totype development presented in “ 4.3 ”. Design Framework The audit results (“ The Current Landscape of Web Forms ”) revealed that most websites rely on privacy policy links for communicating data collection purposes, while the litera - ture review highlighted a lack of design guidance for trans - parent data collection interfaces. Based on these findings, we present a conceptual frame - work for designing data collection interfaces that commu - nicate purposes, incorporating both GDPR principles and the usable privacy heuristics (“ Related Work and Back - ground ”), as follows: ● GDPR-based Design Guidelines (What to communicate) 1. Purpose Limitation and Transparency: purpose descriptions should be added to the form next to each field in a simple, clear, and straightforward way. 2. Data Minimisation: to assist users in providing as little personal data as possible, a message should be added to the forms, on a field-level, warning the user when a field is optional, prompting them to be scepti - cal and not provide the data if they do not wish to, as it is not necessary to proceed. 3. Storage Limitation: an additional message should appear on the form next to each field, informing the user about the period for which the system will store and use their personal data (as specified by the sys - tem developer). Table 3 Average ratings (1–5 Likert scale) of the five design approaches from the user survey (highest to lowest) Design category approach Aver - age rating A2. Short explanation next to each field 4.44 A1. Icon pop-up messages next to each field 3.88 A5. One pop-up from a clickable link for all fields 3.68 A3. One general explanation for all fields 3.64 A4. One clickable link to more information for all fields 3.27 Fig. 4 Overall design selection question asking participants to identify the most clear and effective approach Fig. 3 Example survey question presenting one of the five communica - tion approaches with a 1–5 star rating scale SN Computer Science 639 Page 8 of 17 SN Computer Science (2026) 7:639 ● Usable Privacy Heuristics (How to communicate such information) – Readability: data purpose descriptions and other GDPR-related messages to be added to the fields should be simple, easy to read, taking into consid - eration the font style, font size, and font colour con - trast. Basic relevant usability principles should be applied. – Users’ Precaution, Discretionary Access Control: the text next to each field should include all neces - sary information relating to the usage of the specific piece of personal data. – Avoiding jargon: legal jargon, which is usual for pri - vacy policies and legislation related text, should be completely avoided in these messages. – Providing Fast Interaction, Avoiding Human Error: the UI should be designed as for users to be able to quickly interact, but at the same time minimise the mistakes. A simple and widely used form struc - ture should be used. Informative messages should directly communicate to the users what they want to convey, without needing additional clicks or actions from the users. – Adapting Choices and Using Appropriate Symbols: users should be able to change their mind quickly by having all the fields on one page and by allowing them to remove or add text easily, and at the same time the symbols used on the UI should be appropri - ate and relevant to their meaning. High Fidelity UI Prototypes Combining the user survey results (“ User Survey on Design Approaches ”) and the design framework guide - lines (“ Design Framework ”), we developed high-fidelity UI prototypes for the two top-voted design approaches: (i) A2 “Short Explanation Next to each Field” and (ii) A1 “Icon Pop-Up Messages Next to each Field”. High-fidelity proto - types were developed using the Figma software. 3 Interactive behaviours were simulated in the prototypes to reflect real - istic user interactions, such as pop-up messages triggered by hovering over or clicking on icons. Additionally, layouts were designed with responsiveness in mind, allowing the forms to adapt effectively across both desktop and mobile screen sizes. Figure 5 shows the prototypes developed for the two design approaches. A Dataset of Processing Purposes To support the creation of such forms, we created a proto - type dataset gathering the 20 most commonly collected per - sonal data fields: Full name, Email Address, Phone Number, 3 https://www.figma.com/ . Fig. 5 High-fidelity prototype of the “Short Explanation Next to Each Field” approach (A2) and “Icon pop-up messages next to each field” approach (A1) illustrat - ing field-level purpose, data mini - misation, and storage limitation annotations SN Computer Science Page 9 of 17 639 SN Computer Science (2026) 7:639 Username, Password, Date of Birth, Gender, Address, City, State/Province, Postal code, Country, Profile picture, Security question, Company name, Job title, Website URL, Social media links, Newsletter subscription, and Payment information. We mapped each of them to three processing purposes in the form of short, human-readable text descriptions, to facilitate their addition to web forms. One example is shown below: ● Personal Data Field : “Full Name” ● Purpose Descriptions Set : {“Used to personalize your account”; “Required for identification purposes”; “Helps verify identity for legal purposes”}. The creation of the dataset was grounded in our research and findings from the GDPR, our prior manual audit of cur - rent websites (as presented in “ The Current Landscape of Web Forms ”), and common industry practices. Following its creation, we validated our dataset with experts in both software engineering and legal matters, as presented next. This dataset constitutes an important part of the tool devel - oped and presented later on in “ A Tool for Automating the Creation of Usable and GDPR-Aware Web Forms ”. Dataset Validation Methodology To validate our dataset, we conducted a mixed-methods survey aiming to assess three aspects of the proposed processing purpose descriptions: (1) Clarity, (2) Appropriateness, and (3) Relevance. The survey was dis - tributed to two key expert groups: technical experts, such as web developers and software engineers, and legal experts - groups with practical experience and theoretical under - standing in either web design and development or data pro - tection regulations and privacy. The experts were presented with the dataset and were asked to rate each set of purpose descriptions according to three specific questions related to the three aspects, using a 5-point Likert scale (1: Poor, 5: Excellent). Participants were also prompted to provide open-ended feedback after each field, allowing for qualita - tive insights and suggestions for improvement. Table 4 pres - ents the questions and their mapped aspect. Results A total of n = 14 individuals completed the sur - vey, representing a balanced mix of technical and legal backgrounds: n = 6 respondents (42.9%) with a legal back - ground (law students or professionals) and n = 8 respondents (57.1%) from technical fields (web developers or software engineers). Most participants reported at least some famil - iarity with data privacy and consent practices: 35.7% identi - fied as “very familiar”, 50% as “somewhat familiar”, while 14.3% reported being “not familiar”. All three aspects received positive scores, with Clarity having the highest average score (avg c = 4.48), followed by Relevance (avg r = 4.20) and Appropriateness (avg a = 4.15). Figure 6 presents all aspects for all fields, includ - ing their average values. Regarding Clarity, Username, Password, and Payment Information received the higher Table 4 Validation survey questions mapped to the evaluated aspects Question Aspect covered Q1 “How clearly are the purposes stated?” Clarity Q2 “Do the purposes align with legal/ethical expectations for this data type?” Appropriate - ness Q3 “Are the purposes directly related to the way such data are used in web platforms?” Relevance Fig. 6 Clarity, relevance, and appropriateness scores for each personal data field from the valida - tion survey SN Computer Science 639 Page 10 of 17 SN Computer Science (2026) 7:639 scores in this aspect (c = 4.78), while Gender received the lowest score (c = 4.07). Regarding Relevance, Username (r = 4.78) and Password (n= 4.64) received the highest scores, while Profile Picture (r=3.5) and Gender (r=3.64) received the lowest scores. Finally, regarding Appropriate - ness, Email Address (a = 4.71) received the highest score, while Gender (a = 3.43) received the lowest score. Observ - ing the average results for each field across all three aspects, we note that Username received the highest overall aver - age rating (avg overall = 4.69), followed by Password (avg overall = 4.64). The lowest overall score was observed for Gender (avg overall = 3.71). Regarding the open-ended comments, some respondents expressed uncertainty about the legal appropriateness of certain annotations (e.g., for phone number and email), with comments such as: “I am not sure about appropriateness.” On the other hand, participants affirmed the usefulness of the annotations, commenting: “Relevant for personaliza - tion and vital for identification” and “If there is need for communication with the user it is needed”, while also appreciating the simplicity and clarity of the suggestions, with one comment noting: “It’s best to show uses of the col - lected data briefly on the form rather than in the privacy policy page”. Following the validation, modifications were made to the original dataset to accommodate the results and suggestions. The full, finalised dataset can be found online. 4 Machine-Readable Formats: JSON and XML To improve reuse and integration with development tools, we created machine-readable JSON and XML versions of the finalised dataset, where each input field is associated with a set of possible purpose descriptions. These repre - sentations support automated import, validation, and exten - sion within developer workflows. As illustrative examples, we demonstrate the structure of the “Email” field in both formats. 4 Link to be published upon acceptance. Fig. 8 Tool interface showing the form preview and design approach selection buttons Fig. 7 Tool upload interface allowing users to import an HTML project as a ZIP file SN Computer Science Page 11 of 17 639 SN Computer Science (2026) 7:639 (JSON) (XML) the software engineering (SE) process, with the objective of benefiting websites end users in the long run. Development. The tool was developed using HTML and CSS (with Bootstrap), JavaScript (JS), and client-side ZIP handling libraries (JSZip, FileReader API, Blob API). The source code is available, 6 and can be run in the browser with no further setup required. Functionality. Users begin by uploading a.zip file con - taining a complete HTML, CSS, and JS web project. The upload interface (Fig. 7 ) includes a simple file input field accompanied by an “Upload ZIP” button. Once the file is uploaded, the tool extracts the contents using JSZip and identifies the main HTML file to dis - play. The form is then rendered live within a sandboxed iframe, preserving the original layout and functionality 6 Link to be published upon acceptance. The complete JSON and XML versions can be found online. 5 A Tool for Automating the Creation of Usable and GDPR-Aware Web Forms This section presents the browser-based tool developed to assist in generating transparent, usable, and GDPR-aware data collection web forms for websites. The tool is informed by the dataset presented in “ A Dataset of Processing Pur - poses ”, and adopts the design and guidelines of “ Designing Usable and GDPR-Aware Web Forms ”. It aims to automate the process of enhancing existing web forms, transforming them into usable, and GDPR-aware versions. It can be used by web developers, designers, and legal experts working in 5 Link to be published upon acceptance. SN Computer Science 639 Page 12 of 17 SN Computer Science (2026) 7:639 while conforming to the guidelines defined in our design (“ Designing Usable and GDPR-Aware Web Forms ”). Users are prompted to select their preferred design approach (Short Description—a brief explanation displayed under the input field, or Info Icon Pop-up—an info icon next to the label that shows a tooltip on hover). This toggle is implemented using two buttons, with the selected design approach highlighted and the form preview adjusted. The style selection affects how annotations are injected during rendering. Figure 8 presents an example of the website form preview with the approach selection buttons. The annotation engine automatically detects personal data form fields (e.g., name, email, password) based on our dataset (“ A Dataset of Processing Purposes ”) and injects either inline descriptions for the short description approach or tooltip icons for the info pop-up approach. Subsequently, the user can modify the form by click - ing the “Customize” button, after which an editing panel becomes visible. The panel contains two tables both list - ing all detected personal data fields along with additional options: 1. The first table presents, for each field, a drop-down list with predefined purpose suggestions (as per the dataset), options to manually input custom text and to reset to the default value, and a checkbox stating whether the field is mandatory. The checkbox is automatically completed based on the code, but the user has the option to modify it. 2. The second table presents, for each field, a drop-down list with predefined suggestions for the storage limitation text, with options to manually input custom text and to reset to the default value. Any modifications to the annotation styles or the editing panel are reflected immediately in the form preview. Once the annotations are customised, the user can press “Save All Changes” to store their edits and then click “Down - load Updated HTML” to export a fully enhanced version of the form in its original code and style. The updated file includes all injected modifications and is generated locally using the Blob API. Figure 9 presents the editing panel and the buttons to save and download the code. Tool Evaluation Methodology We evaluated our tool using a two-fold mixed-methods approach: (i) User Survey: We conducted a quantitative user sur - vey using a structured questionnaire based on the User Experience Questionnaire (UEQ), 7 to measure perceived user experience. The UEQ is designed to capture immedi - ate user impressions of an interactive system based on six key dimensions: (1) Attractiveness, describing the overall impression of the tool and reflecting user enjoyment and appeal; (2) Perspicuity, evaluating the ease of learning and 7 https://www.ueq-online.org/ . Fig. 9 Editing panel of the tool showing purpose and storage limitation customization options and export controls SN Computer Science Page 13 of 17 639 SN Computer Science (2026) 7:639 understanding the tool’s functionality; (3) Efficiency, exam - ining users’ perception of task completion speed and perfor - mance; (4) Dependability, describing the users’ trust in the tool’s functionality and reliability; (5) Stimulation, evaluat - ing user engagement and motivation when using the tool; and (6) Novelty, assessing users’ perception of the tool’s innovation and uniqueness [ 13 ]. It includes 26 pairs of con - trasting attributes rated on a 7-point Likert scale. Additionally, we included three related biographical questions: (1) “How familiar are you with the General Data Protection Regulation (GDPR)?”; (2) “How interested are you in developing usable web user interfaces (UIs)?”; and (3) “How interested are you in developing GDPR-compliant and privacy-friendly user interfaces (UIs)?”. To respond to the questionnaire, participants were asked to watch a brief demo video of the tool, demonstrating its features and usage. We collected and analysed 43 responses, mostly from soft - ware engineers. The results are presented in “ User Survey Results ”. (ii) Individual Interviews: We conducted one-to-one, in-depth, semi-structured interviews with five software engineers (SE1–SE5) with experience in web development and data collection systems, collecting qualitative feedback. Initially, the engineers were asked to respond to three bio - graphical questions: (1) “How many years of experience do you have as a software engineer?”; (2) “How often do you work with web apps and systems development? (1–5 Lik - ert scale)”; and (3) “How familiar are you with the GDPR? (1–5 Likert scale)”. They were then presented with our work, methodology, and a demo of the tool, and subsequently asked to respond to eight questions as mandated by our interview protocol. Responses were transcribed. The interview protocol and initial coding framework were designed around five predefined evaluation aspects (A1–A5), derived from our research objectives and tool design goals: (A1) perceived usefulness and professional value; (A2) transparency and purpose-annotation clarity; (A3) workflow integration; (A4) Annotation design feed - back, and (A5) Developer pain points and adoption factors. These aspects were operationalised through one or more semi-structured interview questions, as shown in Table 5 . We conducted a lightweight code-based thematic analy - sis [ 14 , 15 ] following a hybrid approach, starting with the - ory-informed pre-defined codes (deductive) and then adding new ones during analysis (inductive), in order to identify recurring patterns across responses and map them to the five aspects. The pre-defined coding scheme included: Professional usefulness (A1.1), examining whether developers see the approach and tool as valuable in their work; Usefulness of purpose suggestions (A1.2), assessing the perceived value of having pre-defined purpose texts; Transparency improve - ment (A2.1), evaluating whether annotations improve clarity compared to current practice; Purpose clarity and appropri - ateness (A2.2), assessing whether texts are clear and appro - priate for real system; Workflow fit (A3.1), examining if the tool fits with existing development processes; Integration and maintenance effort (A3.2), capturing perceived effort, constraints, and upkeep of workflow integration; Annota - tion style preference (A4.1), capturing the engineers’ pref - erence between annotation styles; Visibility versus clutter trade-off (A4.2), capturing the tension between clarity and UI complexity; Risks and limitations (A5.1), capturing per - ceived risks and edge cases; and Adoption requirements (A5.2), examining the conditions required for adoption. The mapping of codes to questions and aspects is shown in Table 5 . The thematic analysis results are presented in “ Individual Interview Results ”. User Survey Results The survey was completed by n = 43 participants. The results are presented below. Demographics GDPR familiarity : 45% of the participants reported being somewhat familiar with the GDPR, 12.5% indicated being very familiar, while 42.5% reported not being familiar at all. Interest in usable UIs : 53.5% of the participants reported being somewhat interested in developing usable web user interfaces (UIs), 37.2% indicated being very interested, Table 5 Interview questions and mapping to evaluation aspects (E) and codes (C) used in the thematic analysis Question E C Q1 “From a developer’s perspective, how valuable is the idea of annotating each form field with a clear explanation of its data processing purpose?” A1 A1.1 Q2 “In your experience, how are data processing purposes usually communicated to users, and how does this approach compare to how you currently communicate data processing purposes to users in your projects?” A2 A2.1, A2.2 Q3 “How well would this tool fit into your current development workflow?” A3 A3.1, A3.2 Q4 “As a developer, which annotation style would you be more likely to adopt in a real project, and why?” A4 A4.1, A4.2 Q5 (a) “Do the suggested purpose descriptions seem appropriate and defensible for use in real GDPR- compliant systems?” A2 A2.2 Q5 (b) “Do you find it useful having purpose annota - tion suggestions given to you?” A1 A1.2 Q6 “Do you see any risks, limitations, or cases where this approach might not work well?” A5 A5.1 Q7 “What changes or additional features would make you more likely to adopt this tool in practice?” A5 A5.2 SN Computer Science 639 Page 14 of 17 SN Computer Science (2026) 7:639 while 9.3% reported not being interested at all. Interest in GDPR-friendly UIs : 47.5% of the participants reported being very interested in developing GDPR-compliant and privacy-friendly web user interfaces, 40% reported being somewhat interested, while 12.5% reported not being inter - ested at all. Perceived User Experience Figure 10 presents the mean values for all 26 item pairs from the questionnaire, reflecting direct user responses to each individual attribute pair (e.g., “annoying/enjoyable”, “efficient/inefficient”), with values transformed onto a scale from -3 (most negative) to +3 (most positive). We observe that most participants rated the tool positively across key dimensions. Overall, the highest ratings were recorded for not understandable/understandable (2.3); bad/good (2.3); unfriendly/friendly (2.3); inefficient/efficient (2.3); clut - tered/organized (2.3), while the lowest scores were observed for dull/creative (1.1); conservative/innovative (1.1). The 26 UEQ items were then grouped into the six key dimensions to allow benchmark-based interpretation, as visualised in Fig. 11 . We observe that Attractiveness (2.1), Efficiency (2.3), and Perspicuity (2.0) were rated as Excel - lent, placing them in the top 10% of all benchmarked tools. Stimulation (2.0) and Dependability (1.7) were considered Good, suggesting above-average perceived quality, while Novelty (1.1) was rated as Above Average, indicating that users perceived the tool as somewhat innovative, though with potential for a more distinctive design. Individual Interview Results Demographics Five individuals participated in the interviews (S1–S5), with an average of 2.8 years of experience as software engineers (S1 = 6; S2 = 1; S3 = 3; S4 = 2; S5 = 2). Four participants Fig. 11 UEQ benchmark results across the six user experience dimensions Fig. 10 Mean scores for the 26 User Experience Questionnaire (UEQ) item pairs SN Computer Science Page 15 of 17 639 SN Computer Science (2026) 7:639 reported working “5—very often” with web apps and sys - tems development, while one participant (S4) reported “4— often”. Finally, regarding their familiarity with the GDPR, an average score of 3 was noted (S1 = 3; S2 = 3; S3 = 4; S4 = 3; S5 = 2). Thematic Analysis Five main themes emerged across participants, as follows: Theme 1: Strong Perceived Professional Value of Field-Level Purpose Annotations. All participants considered the idea of annotating each form field with its data processing purpose to be valuable from a developer perspective. Developers emphasized that such annotations address a well-known gap in current prac - tice, where transparency is often treated as a compliance formality rather than a meaningful design concern. Several participants highlighted that the tool provides ready-made purpose texts covering most real-world cases, reducing effort and uncertainty. The availability of predefined word - ing was repeatedly mentioned as a key benefit, especially given developers’ limited time and varying familiarity with GDPR requirements. Representative quote : “I consider it very important; it gives me options that cover most use cases and enables transparency, which is very reassuring for users.” (SE1) Theme 2: Improved Transparency Compared to Cur - rent Privacy Practices. Participants consistently described current practice as relying almost exclusively on generic privacy policies, often linked as long legal documents that users rarely read. Sev - eral developers openly acknowledged that these documents are included mainly for formal compliance, not for effective user communication. In contrast, the proposed approach was seen as significantly improving transparency by mak - ing purposes visible at the point of data collection. Develop - ers believe that short, field-level explanations increase the likelihood that users will actually read and understand why their data is collected. Representative quote : “We just place a link to a huge pri - vacy policy, and we know users will not read it. This tool shows the information clearly and directly.” (SE2) Theme 3: Conditional Fit with Existing Development Workflows. Developers generally viewed the tool as fitting reason - ably well into their workflows, particularly as a design-time aid rather than a runtime dependency. Exportable HTML and the ability to reuse suggestions without enforcing auto - matic code generation were seen as important. However, multiple participants expressed concerns about direct inte - gration into modern development environments that rely heavily on frameworks, templates, or CMSs. As a result, several developers described using the tool as a reference or first draft, followed by manual integration into their own codebases. Representative quote : “I would use it as a first draft, get the suggestions, and then replicate it in my framework.” (SE2) Theme 4: Trade-off Between Annotation Styles (Vis - ibility vs. Visual Simplicity). Preferences regarding annotation style were mixed, revealing a clear trade-off between visibility and visual sim - plicity. Most participants favoured icon-based annotations, arguing that they keep forms concise and visually appeal - ing, while allowing interested users to access information on demand. At the same time, one participant preferred inline text, noting that immediately visible explanations may be more effective for ensuring user awareness. Oth - ers suggested that the choice should depend on the overall design language of the website. Representative quote : “With icons it looks cleaner, and the information is there if you need it. Too much text can be overwhelming.” (SE1) Theme 5: Adoption Depends on Flexibility, Coverage, and Integration Support. When discussing risks and adoption conditions, partici - pants emphasized that successful uptake depends on flex - ibility rather than strict automation. Developers expressed concerns about edge cases with uncommon personal data collection, or where purposes may be more complex than those suggested. Across interviews, participants suggested several improvements that would increase adoption: sup - port for additional programming frameworks, CMS plugins (e.g., WordPress), better parser flexibility, the ability to manually add or correct fields, multilingual support, and customizable icon styles. Representative quote : “The dataset is very useful, but I would like to add fields that the parser does not recognize and connect them myself.” (SE3) Discussion The UEQ-based usability study captured general user expe - rience, while the qualitative evaluation complemented it by providing in-depth insights from software engineers. Over - all, the interviews indicate strong developer support for the concept of field-level purpose annotations. Developers see clear benefits in transparency, efficiency, and standardisa - tion, while also highlighting practical constraints related to workflow integration and design flexibility. Rather than expecting full automation, participants positioned the tool as a supportive design resource that can guide developers toward more transparent and GDPR-aligned data collection practices. SN Computer Science 639 Page 16 of 17 SN Computer Science (2026) 7:639 Practical Implications The tool seems to be well-suited for teams and developers that are required to implement GDPR-compliant web inter - faces. It can serve as a practical aid by providing ready- made purpose descriptions and design patterns that reduce uncertainty and effort. However, in highly regulated envi - ronments such as financial institutions or large enterprises with established legal teams, the tool may serve more as a supporting design guideline rather than the main solution, as purpose definitions and compliance processes are often centrally managed, while more complex software engineer - ing processes are in place. The findings from the interviews suggest that the tool is best positioned as a design-time support mechanism within broader engineering workflows. Rather than replacing exist - ing tools, it can complement them by assisting developers during the UI design and implementation phases, particu - larly when translating legal requirements into interface- level design elements. In practice, developers may use the tool to generate initial annotations and purpose descriptions, which are then refined and integrated into their existing frameworks or code. This aligns with modern development practices where reusable components and templates are adapted rather than directly generated and used. We can also recognise trade-offs when adopting the pro - posed approach. On the one hand, field-level purpose anno - tations improve transparency and user understanding, as also reflected in the evaluation results. On the other hand, such design may introduce UI complexity or visual clutter, particularly when using inline text annotations. Addition - ally, while the provided dataset reduces developer effort, it may not fully cover all domain-specific or complex data processing scenarios, requiring manual adjustments. Inte - gration effort is another consideration, as developers may need to adapt the generated output to fit within modern frameworks or CMS-based systems. Conclusions In this work, we have presented our study on automating the design and development of usable, transparent, and GDPR- aware web data collection forms. We provided an empirical analysis of the current landscape of web forms by auditing 160 websites revealing transparency gaps at data collection points. We then presented our user-centred design includ - ing a user-survey for selecting the top two user preferred design approaches for communicating purposes, a proposed design framework for form-level transparency integrating GDPR principles and usable privacy heuristics, and high fidelity prototypes informed by them. We then generated a purposes dataset validated by legal and technical experts, and we developed a tool operationalising the design to assist engineers in creating and embedding such forms in their websites. Our tool was evaluated with positive results, highlighting practical implications, and indicating promis - ing directions for future improvements. Limitations and Future Work Our tool can be enhanced in several ways in future work, including: (i) adding more flexibility with regard to the recognition of personal data, for example by expanding the dataset, allowing users to add new fields, or incorporating AI-based recognition; (ii) add - ing support for a broader range of programming environ - ments and frameworks or CMSs; (iii) translating the UI and the dataset into additional languages; and (iv) adding smart AI-based suggestions for purpose texts. Furthermore, our tool evaluation can be repeated with a larger sample size. Beyond these tool-related extensions, future work can also be oriented towards several research directions. First, the impact of field-level purpose annotations on end users can be investigated, examining whether such designs improve users’ understanding, trust, and decision-making during data disclosure, and whether they influence actual data-sharing behaviour. It is also important to study, how such tools are adopted within different software engineering settings, how they interact with legal teams, and what chal - lenges arise when integrating them into established software engineering workflows in practice. Finally, future work may explore how this approach can be extended beyond web forms to other data collection contexts (e.g., mobile applica - tions), contributing to a broader ecosystem of transparency- by-design solutions. Author Contributions All authors whose names appear on the submis - sion made substantial contributions to the study conception and de - sign, approved the version to be published, and agree to be accountable for all aspects of the work. Funding Open access funding provided by the Cyprus Libraries Con - sortium (CLC). Data Availability Data available on request. Declarations Conflict of interest Not applicable. Ethical approval Not applicable. Informed consent Not applicable. Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this SN Computer Science Page 17 of 17 639 SN Computer Science (2026) 7:639 article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit h t t p : / / c r e a t i v e c o m m o n s . o r g / l i c e n s e s / b y / 4 . 0 / . References 1. Parliament E, European Union C. General Data Protection Regu - lation. Off J Eur Union. 2015. 2. Reidenberg JR, Russell NC, Callen AJ, Qasir S, Norton TB. Pri - vacy harms and the effectiveness of the notice and choice frame - work. ISJLP. 2015;11:485. 3. Brunotte W, Specht A, Chazette L, Schneider K. Privacy explana - tions—a means to end-user trust. J Syst Softw. 2023;195:111545. 4. Salgado ADL, Hung PC, Fortes RP. Six usable privacy heuristics. In: Proceedings of the XXII Brazilian symposium on human fac - tors in computing systems. 2023. p. 1–11. 5. Brunotte W, Chazette L, Kohler L, Klunder J, Schneider K. What about my privacy? Helping users understand online privacy poli - cies. In: Proceedings of the international conference on software and system processes and international conference on global soft - ware engineering. 2022. p. 56–65. 6. Schaub F, Balebako R, Cranor LF. Designing effective privacy notices and controls. IEEE Internet Comput. 2017;21(3):70–7. 7. Harkous H, Fawaz K, Lebret R, Schaub F, Shin KG, Aberer K. Polisis: automated analysis and presentation of privacy policies using deep learning. In: 27th USENIX security symposium (USENIX Security 18). 2018. p. 531–48. 8. Harkous H, Fawaz K, Shin KG, Aberer K. { PriBots } : Conver - sational privacy with chatbots. In: Twelfth symposium on usable privacy and security (SOUPS 2016). 2016. 9. Freiberger V, Fleig A, Buchmann E. Helping Johnny make sense of privacy policies with LLMs. In: Proceedings of the 2026 CHI conference on human factors in computing systems. 2026. p. 1–21. 10. Vanezi E, Kallenou A, Papadopoulos GA. Saving the day for users in web platforms: a chatbot-based solution for privacy. In: 2023 10th International conference on behavioural and social computing (BESC). IEEE; 2023. p. 1–7. 11. Nielsen J. Enhancing the explanatory power of usability heuris - tics. In: Proceedings of the SIGCHI conference on human factors in computing systems. 1994. p. 152–8. 12. Bailly H, Papanna A, Brennan R. Prototyping an end-user user interface for the solid application interoperability specification under GDPR. In: European semantic web conference. Springer; 2023. p. 557–73. 13. Schrepp M, Hinderks A, Thomaschewski J. Construction of a benchmark for the user experience questionnaire (UEQ). Int J Interact Multimedia Artif Intell. 2017;4(4):40–4. 14. Braun V, Clarke V. Using thematic analysis in psychology. Qual Res Psychol. 2006;3(2):77–101. 15. Braun V, Clarke V. Thematic analysis: a practical guide. 2021. Publisher's Note Springer Nature remains neutral with regard to juris - dictional claims in published maps and institutional affiliations.