Lawfulness by design – development and evaluation of lawful design patterns to consider legal requirements

Figures & data

Table 1. Research Background.

Study	Key Results
Smith and McKeen (2006)	Explores how new regulation rules change IT work and the resulting regulatory issues
Weick (2010)	Regulation rules are equivocal, must first be transformed, and made explicitly
Almeida et al. (2020)	Developed a framework to provide a lens for what about, when, and how the use of AI should be regulated
Vaujany et al. (2018)	IT-based regulation systems consist of rules, practices, and IT artefacts and their relationships as a trifecta
Blind et al. (2017)	In situation of high market uncertainty, regulation leads to lower innovation efficiency
Butler (2017) ↓	Identifies challenges of RegTech: regulation-interpretation problem, and absence of a common language
This study	Makes abstract regulation rules understandable and applicable for developers through design patterns
↑ Becker et al. (2014)	Meta-design for integrating regulations into the design of IS

Figure 1. Design science research approach adapted from Peffers et al. (2007).

Table 2. Lawful design pattern requirements.

	Requirements	Legal Relevance	Source
R1	Related information should rather be presented together to avoid split-attention effect and to reduce extraneous load resulting from complex legal knowledge.	Connecting legal and technical requirements to avoid split-attention effects.	Aljeraisy et al. (2021); Ayres and Sweller (2005)
R2	Information needs to be appropriately structured (e.g., through a clear subdivision of legal terms) so that different subjects are clearly perceptually distinguished and allow rapid retrieval of legal information.	Breaking down legal texts to make them accessible	Figl (2017); Kirschner et al. (2011); Malinova and Mendling (2013); Osterwalder and Pigneur (2013)
R3	A design pattern should communicate why it is useful to use it to clarify the importance to implement the legal requirement(s) and the related added value.	Communicating the added value to increase the perceived importance	Garud (1997); Ayala-Rivera and Pasquale (2018)
R4	Legal knowledge should be formulated compact and context-specifically adapted to its use case scenario to overcome technology neutrality of law.	Formulating compact and context-specific legal knowledge to overcome technology neutrality of law	Legner et al. (2020); Ayala-Rivera and Pasquale (2018)
R5	Include requirements, the relationship between constructs and domain objects, an explanation, and a justification of the requirements.	Providing information behind the legal requirements	Heinrich and Schwabe (2014); Hadar et al. (2018)
R6	A design pattern should provide additional domain-specific information and knowledge to support the application.	Supporting the transfer into practical implementation	Chandra Kruse and Seidel (2017)
R7	A design pattern should provide implementation guidance but should not restrict the pattern users in their creativity.	Legal requirements may be prioritised higher due to their relevance and the risk of penalties, possibly affecting the developer’s creativity	Ahrens and Sankar (1993)
R8	A design pattern should provide an overall understanding of the artefact to be designed to successfully integrate legal requirements.	Considering the overall artefact design during the implementation of legal requirements	van Aken (2005); Walls et al. (1992); Ayala-Rivera and Pasquale (2018)
R9	The design pattern should enable knowledge transfer, document it, and provide good repositories for legal knowledge dissemination.	Providing a legal design knowledge repository	Chandra Kruse and Seidel (2017); Huth et al. (2020)
R10	The codified design knowledge should be abstracted to make it usable for a class of artefacts.	Balancing legal requirement abstractions	Nonaka and Toyama (2003); Baxter et al. (2007)
R11	Besides a solution the design pattern should support the understanding of the legal problem context and the underlying legal requirements.	Understanding the underlying legal mechanism	Rothe et al. (2020); Vom Brocke et al. (2020); Compagna et al. (2009); focus group workshop

Figure 2. Cognitive load theory application.

Figure 3. Mapping of the requirements to the initial pattern elements.

Figure 4. Initial design pattern.

Table 3. Mapping of pattern elements and initial design pattern.

Requirements	Pattern Element (PE)	Implementation into Initial Design Pattern	Field in Design Pattern
R4 Legal knowledge should be formulated compact and context-specifically adapted to its use case scenario to overcome technology neutrality of law.	PE#1 Allow the user to acquire additional legal information to make the design pattern reusable and applicable to each knowledge level as well as for legal laymen.	Linking legal information to support each knowledge level, further information can be accessed via linkable explanations	Relevant legal requirements; Influences
R10 The codified design knowledge should be abstracted to make it usable for a class of artefacts.
R5 Include requirements, the relationship between constructs and domain objects, an explanation, and a justification of the requirements.	PE#2 Connect the legal requirements with the solution so that the understanding of the underlying legal facts is supported.	Each design pattern includes the laws behind it, ensuring a link between the design solution and the legal requirements	Relevant legal requirements
R11 Beside a solution the design pattern should support the understanding of the legal problem context and the underlying legal requirements.
R1 Related information should rather be presented together to avoid split-attention effect and to reduce extraneous load resulting from complex legal knowledge.	PE#3 Provide information units that reduce the user’s task complexity through a clear, uniform, and comprehensible presentation of complex legal information.	A clear presentation allows to quickly find the necessary information	Clear arrangements through separated areas; Spatial combination of related information; Current period of development process
R2 Information needs to be appropriately structured (e.g., through a clear subdivision of legal terms) so that different subjects are clearly perceptually distinguished and allow rapid retrieval of legal information.
R6 A design pattern should provide additional domain-specific information and knowledge to support the application.	PE#4 Provide information that transcends the solution to explain the problem, enable knowledge transfer, and document legal design knowledge.	Integration of additional information about the pattern’s goal, requirements, and influences to support the user’s understanding of the problem and enable knowledge transfer	Solution, Relevant legal requirements; Current period of development process
R7 A design pattern should provide implementation guidance but should not restrict the pattern users in their creativity.
R9 The design pattern should enable knowledge transfer, document it, and provide good repositories for legal knowledge dissemination.
R3 A design pattern should communicate why it is useful to use it to clarify the importance to implement the legal requirement(s) and the related added value.	PE#5 Convey the importance and relevance of the legal requirement.	Goal describes how the optimal target state looks like after considering the design pattern	Goal
R8 A design pattern should provide an overall understanding of the artefact to be designed to successfully integrate legal requirements.	PE#6 Integrate consequences that may arise from the implementation of the design patterns’ solution by taking legal requirements into account.	Integration of category “consequences”, in which both the possible positive and negative effects of the pattern’s implementation are listed.	Consequences

Figure 5. Classifying our evaluation approaches.

Figure 6. Formative evaluation process.

Table 4. Comparison between control and treatment groups’ prototypes.

			Groups	Rating (1–5)	p-Value
Expert Rating	Group	Support	N	Mean (SD)
	Control	No Support	21	2.1 (1.09)	P<.05
	Pattern	Design patterns (DP)	24	2.96 (1.41)

Figure 7. Design pattern after first revision.

Table 5. Documents collected from simulation study.

Relevant Documents from Simulation Study	Source	Scope
Filing of action of the case “passing personal data”	Exchange of pleadings	7 pages
Filing of the action of the case “omission of the use of the AI-based assistant”	Exchange of pleadings	4 pages
Statement of defence of the case “passing personal data”	Written hearing	5 pages
Statement of defence of the case “omission of the use of the AI-based assistant”	Written hearing	5 pages
Judgement of the case “passing personal data”	Written hearing	2 pages
Judgement of the case “omission of the use of the AI-based assistant”	Written hearing	3 pages
Video recording of case “storage duration of personal data”	Oral hearing	58 minutes
Video recording of case “right of data cancellation”	Oral hearing	46 minutes
Filing of action of the case “storage duration of personal data”	Exchange of pleadings	7 pages
Filing of action of the case “right of data cancellation”	Exchange of pleadings	6 pages
Statement of defence of the case “storage duration of personal data”	Oral hearing	5 pages
Statement of defence of the case “right of data cancellation”	Oral hearing	4 pages
E-learning charter of the university	Oral hearing	2 pages
Transcript of the case “storage duration of personal data”	Oral hearing	10 pages
Transcript of the case “right of data cancellation”	Oral hearing	8 pages
Interview transcript	Interview	5 pages

Figure 8. Legal simulation study.

Figure 9. Design pattern revisions.

Figure 10. Final design pattern.

Table A1. Focus Group Participants.

Participant	Education	Work experience	Practical design pattern experience
#1	PhD in IS	IT consultant	yes
#2	PhD in Law	Lawyer	no
#3	Computer science student	Developer	no
#4	Computer science student	-	no
#5	PhD student in IS	UX consultant	yes
#6	Postdoctoral researcher in IS	Project manager	no
#7	Postdoctoral researcher in computer science	IT consultant	no
#8	Postdoctoral researcher in computer science	Developer	yes

Figure B1. Exemplary Prototypes as Result from the Experiment. Left Prototype Shows Results from the Treatment Condition. Right Prototype Shows Results from the Control Condition (translated into English).

Figure C1. Statement of Claim.

Figure C2. Statement of Defence.

Figure C3. Replication (reply of the plaintiff in civil proceedings to the defendant’s statement of defence).

Smith, H. A., & McKeen, J. D. 2006. Developments in Practice XXI: IT in the New World of Corporate Governance Reforms. Communications of the Association for Information Systems, 17. https://doi.org/10.17705/1CAIS.01732.

 Google Scholar

Weick, K. E. (2010). Sensemaking in organizations [Nachdr.]. foundations for organizational science. Sage Publ.

 Google Scholar

Almeida, P. G. R. D., Denner dos Santos, C., & Silva Farias, J. (2020). Artificial intelligence regulation: A meta-framework for formulation and governance. Proceedings of the 53rd Hawaii International Conference on System Sciences, Maui.

 Google Scholar

Vaujany, F. -X.D., Fomin, V. V., Haefliger, S., & Lyytinen, K. (2018). Rules, practices, and information technology: A Trifecta of organizational regulation. Information Systems Research, 29(3), 755–773. https://doi.org/10.1287/isre.2017.0771

 Web of Science ®Google Scholar

Blind, K., Petersen, S. S., & Riillo, C. A. F. (2017). The impact of standards and regulation on innovation in uncertain markets. Research Policy, 46(1), 249–264. https://doi.org/10.1016/j.respol.2016.11.003

 Web of Science ®Google Scholar

Butler, T. (2017). Towards a standards-based technology architecture for RegTech. Journal of Financial Transformation, 45(1), 49–59. https://files.openpdfs.org/je1d4gbz5ob.pdf#page=49

 Google Scholar

Becker, J., Heddier, M., Braeuer, S., & Knackstedt, R. (2014). Integrating regulatory requirements into information systems design and implementation. Thirty Fifth International Conference on Information Systems, Auckland 2014.

 Google Scholar

Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A design science research methodology for information systems research. Journal of Management Information Systems, 24(3), 45–77. https://doi.org/10.2753/MIS0742-1222240302

 Web of Science ®Google Scholar

Aljeraisy, A., Barati, M., Rana, O., & Perera, C. (2021). Privacy laws and privacy by design schemes for the internet of things. ACM Computing Surveys, 54(5), 1–38. https://doi.org/10.1145/3450965

 Web of Science ®Google Scholar

Ayres, P., & Sweller, J. (2005). The split-attention principle in multimedia learning. The Cambridge Handbook of Multimedia Learning, 2, 135–146.

 Google Scholar

Figl, K. (2017). Comprehension of procedural visual business process models - a literature review. Business & Information Systems Engineering, 59(1), 41–67. https://doi.org/10.1007/s12599-016-0460-2

 Web of Science ®Google Scholar

Kirschner, P. A., Ayres, P., & Chandler, P. (2011). Contemporary cognitive load theory research: The good, the bad and the ugly. Computers in Human Behavior, 27(1), 99–105. https://doi.org/10.1016/j.chb.2010.06.025

 Web of Science ®Google Scholar

Malinova, M., & Mendling, J. (2013). The effect of process map design quality on process management success. ECIS. https://aisel.aisnet.org/ecis2013_cr/160

 Google Scholar

Osterwalder, A., & Pigneur, Y. (2013). Designing business models and similar strategic objects: The Contribution of IS. Journal of the Association for Information Systems, 14(5), 237–244. https://doi.org/10.17705/1jais.00333

 Web of Science ®Google Scholar

Garud, R. (1997). On the distinction between know-how, know-why, and know-what. Advances in Strategic Management, 14(14), 81–101.

 Google Scholar

Ayala-Rivera, V., & Pasquale, L. (2018). The grace period has ended: An approach to operationalize GDPR requirements. Proceedings - 2018 IEEE 26th International Requirements Engineering Conference, 136–146. https://doi.org/10.1109/re.2018.00023

 Google Scholar

Legner, C., Pentek, T., & Otto, B. (2020). Accumulating design knowledge with reference models: Insights from 12 years’ research into data management. Journal of the Association for Information Systems (JAIS), 21(3), 735–770. https://doi.org/10.17705/1jais.00618

 Web of Science ®Google Scholar

Heinrich, P., & Schwabe, G. (2014). Communicating nascent design theories on innovative information systems through multi-grounded design principles, Miami, FL, USA,148–163.

 Google Scholar

Hadar, I., Hasson, T., Ayalon, O., Toch, E., Birnhack, M., Sherman, S., & Balissa, A. (2018). Privacy by designers: Software developers’ privacy mindset. Empirical Software Engineering, 23(1), 259–289. https://doi.org/10.1007/s10664-017-9517-1

 Web of Science ®Google Scholar

Chandra Kruse, L., & Seidel, S. (2017). Tensions in design principle formulation and reuse. Designing the Digital Transformation DESRIST Research in Progress Proceedings of the 12th International Conference on Design Science Research in Information Systems and Technology, Karlsruhe, Germany, 180–188.

 Google Scholar

Ahrens, J., & Sankar, C. (1993). Tailoring database training for end users. MIS Quarterly, 17(4), 419–439. https://doi.org/10.2307/249586

 Web of Science ®Google Scholar

van Aken, J. E. (2005). Valid knowledge for the professional design of large and complex design processes. Design Studies, 26(4), 379–404. https://doi.org/10.1016/j.destud.2004.11.004

 Web of Science ®Google Scholar

Walls, J. G., Widmeyer, G. R., & El Sawy, O. A. (1992). Building an information system design theory for vigilant EIS. Information Systems Research, 3(1), 36–59. https://doi.org/10.1287/isre.3.1.36

 Web of Science ®Google Scholar

Huth, D., Both, A., Ahmad, J., Sauer, G., Yilmaz, F., & Matthes, F. (2020). Process and tool support for integration of privacy aspects in agile software engineering. Americas Conference on Information Systems (AMCIS) Proceedings, Utah, USA.

 Google Scholar

Nonaka, I., & Toyama, R. (2003). The knowledge-creating theory revisited: Knowledge creation as a synthesizing process. Knowledge Management Research & Practice, 1(1), 2–10. https://doi.org/10.1057/palgrave.kmrp.8500001

 Google Scholar

Baxter, D., Gao, J., Case, K., Harding, J., Young, B., Cochrane, S., & Dani, S. (2007). An engineering design knowledge reuse methodology using process modelling. Research in Engineering Design, 18(1), 37–48. https://doi.org/10.1007/s00163-007-0028-8

 Web of Science ®Google Scholar

Rothe, H., Wessel, L., & Barquet, A. P. (2020). Accumulating design knowledge: A mechanisms-based approach. Journal of the Association for Information Systems, 21(3), 771–810. https://doi.org/10.17705/1jais.00619

 Web of Science ®Google Scholar

Vom Brocke, J., Winter, R., Hevner, A., & Maedche, A. (2020). Special issue editorial –accumulation and evolution of design knowledge in design science research: A journey through time and space. Journal of the Association for Information Systems, 23(3), 9–49. https://doi.org/10.17705/1jais.00611

 Google Scholar

Compagna, L., El Khoury, P., Krausová, A., Massacci, F., & Zannone, N. (2009). How to integrate legal requirements into a requirements engineering methodology for the development of security and privacy patterns. Artificial Intelligence and Law, 17(1), 1–30. https://doi.org/10.1007/s10506-008-9067-3

 Google Scholar