Design Science and Information Systems

Last updated Sep 15, 2024 | Originally published Jan 19, 2024

Here, we explore the fundamental concepts and principles of design science, its application in information systems, and how it can be used to develop novel design theories. Design science is the combination of design (a discipline focused on using what we know to engage in effective, efficient, and ethical problem-solving) and science (a discipline focused on advancing what we know by iteratively and empirically solving problems). The interdiscipline of design science plays a crucial role in the development and implementation of information systems, helping organizations achieve their objectives efficiently and effectively.

When you hear that someone is a designer, what are your assumptions? What do you think they do? A common misconception about design is that design is about aesthetics. “Designer” fashion or furniture is a great example of this. So, often, when people talk about design, they are talking about the look of something. You might assume that a designer is a graphic designer, clothing designer, or product designer, and that their day-to-day work involves choosing colours, styles, layouts, and materials. Steve Jobs famously asserts that these assumptions are completely wrong:

Design is not just what it looks like and feels like. Design is how it works.

• Steve Jobs (1955–2011), co-founder and former CEO of Apple, as quoted by Walker, 2024

Designers don’t just think about what something looks or feels like. Designers decide what a thing does. The word “design” is, in fact, rooted in the Latin “de-signô”: “I mark.” A designer designates what is important about a thing, and what is not. Every person, in fact, engages in design work — whether they know it or not. You decide why you’re reading this reading: what is important about this experience for you? What is not? You decide what your goals are. In turn, you decide what your day should look like to help you achieve those goals. So, you are a designer, I am a designer, and we are all designers.

Of course, the designers developing information systems such as your employer’s Enterprise Resource Planning suite, the latest social media platform, or an e-commerce website must make different kinds of design decisions than the ones we all make every day. Designing information systems at this scale means appreciating that you are not the only stakeholder or user of the systems you’re designing. More crucially, it means understanding that the system you’re designing doesn’t really matter — those users and stakeholders do (Keil & Mark, 1994). Thus, most designers engage in an iterative design process that looks like this:

1. Work with users/stakeholders to deeply discover the problems that the design must solve (and who exactly it must solve them for);
2. Define the exact parameters, constraints, objectives, and success conditions for solutions for these problems for those users/stakeholders;
3. Use feedback from tests to develop possible solutions and improve upon them; and
4. Deliver, implement, scale, and sustain the new design.

That design process has variously been visualized as a “double diamond” (figure 1) or the “design squiggle” (figure 2).

Design decisions using this process range from major (“what does this policy do, and for whom?”) to minor (“do we make this function accessible via a menu or buttons?”) The iterative nature of this process is important. No design should ever be implemented without testing it, and using the feedback from that testing to improve the design. Repeatedly moving through this process — iterating — is how that feedback cycle drives progress.

Design science is a discipline combining design with the scientific method. As described by Hevner et al. (2004, it is a paradigm that harnesses our instinctive designing ability and formalizes it with scientific rigor. With roots in engineering and the sciences, design science adds structure to the discipline of design. As we will discuss, for instance, design science separates the ideas behind a design (its design principles and theory) from the ways in which we use those ideas (the designed tool itself, usually called “artifacts” or “instantiations.”) Design science further applies empirical methods to design processes and challenges, with the goal of producing reliable, reproducible, and valid designs as outcomes of the design science process.

Design science plays a significant role in Management Information Systems (MIS). It offers a structured method to create innovative IT artifacts — products and processes — that are intended to meet specific organizational or business goals (Gregor & Hevner, 2013). Given the dynamic nature of MIS – marked by rapid technological advancements, diverse user requirements, and shifting business environments – the need for constant design and redesign is paramount. Thus, design science provides an essential framework for developing and refining MIS models, tools, and theories.

This section introduces the fundamental building-block of design science: the design principle. Effectively designing, defining, developing, testing, and applying design principles is fundamental to any successful design. This section will help you understand what design principles are, their significance, how they can be identified across various domains, and the role they play in enhancing system performance.

Design principles can be thought of as the guidelines or rules followed in the creation or modification of a design artifact. They are prescriptive statements that indicate how to do something to achieve a goal (Gregor et al., 2020). Design principles provide guidance to people developing solutions to particular classes of problems, providing detailed behavioral prescriptions that establish how the related artifacts should be constructed or used (Gregor & Jones, 2007). For example, in visual design, principles like balance, contrast, and unity guide aesthetic decisions. For a trivial example, “do not make the date or location of the event small or hard to see” is a very important design principle in the design of an event poster. An example from designing information systems might be “Provide user interfaces that allow the user to precisely control the system.” This design principle would guide a designer away from counterintuitive designs, such as a volume controller on a slide that requires the user to tilt the controller and wait for the slider to fall “down” to the appropriate volume level (figure 3), or a volume controller that does not give the user exact feedback about the level of volume of the device (e.g., Apple’s iOS Control Center volume control, introduced in iOS 7; figure 4).

The identification and definition of design principles provides an important middle ground between understanding a problem and its potential solutions and actually delivering and implementing a solution to the problem. Imagine a company aiming to develop an innovative online learning platform to address the problem of access to quality education in rural areas. In this scenario, the identified problem is the inadequacy of current solutions in delivering high-quality education to the remote regions. There are barriers such as inconsistent internet connectivity, limited resources, diverse learner profiles, and varied learning environments to consider. We might assume the company understands this problem and potential solutions thoroughly. Nonetheless, developing the platform without clearly defining design principles that address the key challenges of the platform’s users would be like trying to travel through uncharted terrain without a map. Just like you might head in the right direction through sheer luck, the company might invent a design that solves all of its users’ problems immediately. More likely, though, the company will get more things wrong than it gets right when it first begins. To navigate this uncharted terrain effectively, designers at the company need to map their understanding of the problem and their users to testable design principles, and then test and use those principles as guidelines to steer the design process. These principles could include:

• Inclusivity: design the platform so that users with limited resources and abilities are not disadvantaged.
• Simplicity: Ensure the platform is easy to use such that any major action taken requires a maximum of four steps after logging in.
• Flexibility: Allow users to follow adaptive learning paths, engaging in content and assessment in the order that best suits their needs and abilities.
• Resource Efficiency: Optimize the technical requirements of using the platform so that it remains performant even when users networks have low Internet bandwidth and their devices have limited processing power and memory.

These principles provide direction and useful constraints for the platform designers, encouraging them towards solutions that will be celebrated by their users while preventing them from implementing ideas that disparage their needs. Design principles provide wayfinding and guardrails for designers on the road between finding a problem and solving it effectively, efficiently, and ethically.

Understanding design principles is a core aspect of leveraging design science, particularly in the development and management of information systems. The itemized, atomic nature of design principles is particularly important in design science. This allows designers to decompose a design into its component principles. This, in turn, allows designers to manipulate only some of these parts at once, facilitating the evaluation of specific aspects of the design while controlling the rest. The itemized, atomic nature of design principles is particularly important in design science. This means that each principle can exist independently and is defined distinctly. Such a modular approach to principles allows for decomposing or breaking down a complex design into its constituent principles, much like dismantling a complex machine into its individual components.

In conclusion, design principles offer crucial prescriptions for the design process. They provide clear, actionable, and theoretically grounded advice that direct designers towards the outcomes of their design goals. Further, they help break down the complexity of designs into testable components, facilitating the design science process.

At this point, you may be noticing the difference between a design and the objects we make with designs. This represents the essential duality of design science, and an important distinction: we use designs to make things. Designs themselves are fundamentally theories of the best way to do or make something. Designs are therefore fully represented by design theories: design principles and a number of other supporting ideas about those design principles (Gregor & Jones, 2007). Objects are design artifacts (or “instantiations”), the result of applying those design ideas to create or do tangible or intangible things (Hevner et al., 2004).

We can make this idea obvious with a simple example. Consider the following design principles for a chair:

1. Use ultralightweight materials to make the chair easy to lift.
2. Allow the chair to nest on top of other chairs so that they may be stacked.
3. Provide a wide seat and movable arms so that the chair is comfortable for people of different shapes and sizes.

Now, imagine the chair that would result from applying those design principles. Easy, right? Yet, the chair you imagine and the chair that I imagine are undoubtedly different. Each person applying these design principles will instantiate the design in different ways. (Instantiation validity is the degree to which a given artifact stays true to its design; Lukyanenko & Parsons, 2013)

This distinction between design theory and designed object facilitates several things. First, designs are more than just their design principles. A design theory provides the purpose of a design, all of the principles that guide its creation/manifestation/implementation/application, the basis of those principles, tests of the effectiveness of the resulting artifacts, and more. Design theories are therefore amalgamations of knowledge, principles, and other information that guide how to go about creating the artifact to solve a recurrent class of problems (Gregor & Jones, 2007). Second, design artifacts or instantiations serve as physical proofs of concept for the design theories. These objects translate abstract design theories into actionable frameworks. By interacting with these objects in the real world, users can verify the efficacy of the design, giving credibility to the design theory. Third, not all designs work as intended. Design artifacts are therefore not only proofs of concept, but feedback mechanisms. This allows for the examination and modification of a design without necessarily impacting the existing artifacts or instantiations. Just as an architect may amend a building plan for future buildings without physically altering the construction of the existing one, designers can revise their design theories to optimize future outcomes without directly changing the objects already produced. We can consider each instantiation as a tangible case study, offering insights into the design’s effectiveness. The successes or shortcomings observed in existing objects can feedback into the redesigning of the theories, leading to continual improvement in the designs themselves. This cycle is the design science research cycle, and we will discuss it further in a later section.

As explained in the preceding section, a design theory is a complete articulation of a design (Gregor & Jones, 2007). A simplification of Gregor and Jones’s (2007) anatomy of an ISDT is provided below consisting of eight components:

• Purpose or problem: the exact issue the design aims to address/improve upon
  • Success conditions: the conditions that must be true for us to know that this problem is “solved”
• Context: the domain of the problem at hand
• Users: who will be working with the results of the design, and what they’re trying to do
• Basis: the argument for the design; the evidence the designer draws from to assert that their design can and will work to achieve the purpose or problem for the users in this context
• Principles: the core, basic ideas that the design is leveraging for its solution, composed of constructs, affordances, and tests
  • Constructs: the features, mechanisms, tools, and other artifacts that are the objects of the design
  • Affordances: what use of the artifacts does for the user to implement the principles and address the purpose/problem
  • Success conditions: what conditions must be true if the constructs successfully fulfill the affordances
  • Tests: evaluations that the designer and/or user can carry out to assess if the success conditions are met

To develop a novel design theory for a given problem, start from the first component, and then work through the rest in sequence. Note that design principles are therefore derived from some basis: the justificatory kernel theories drawn from experience or expertise that indicates the potential of the design principles. It can be helpful to present design principles in tables of the following form:

Table 1. Presenting design principles.

In this section, we will demonstrate the development of a design theory by adapting the Technology Acceptance Model (TAM) developed by Davis (1989) into the components described above. TAM is a widely-cited design theory in Management Information Systems that explains users’ acceptance and usage behavior towards technology.

• Purpose or Problem: TAM was developed to understand why users accept or reject information technology and what factors influence users’ technology acceptance.
• Success Conditions: TAM is successful when it accurately predicts or explains an individual’s acceptance of an information technology or system. It should be able to guide system design such that it appeals to user acceptance factors.
• Context: TAM is applicable in various contexts where individuals interact with technology or are introduced to new technological systems or tools.
• Users: Typically, the users of TAM as a design theory are IS designers, system analysts, organizations introducing new technologies, and researchers examining technology adoption and usage behavior.
• Basis: TAM is grounded in Fishbein and Azjen’s (1975) theory of reasoned action and extended to accommodate the acceptance of information systems (Fishbein & Azjen, 1975). The theory of reasoned action is supported by numerous empirical validations and serves as a theoretical foundation for subsequent research proposing extended and modified versions.
• Principles: TAM suggests that Perceived Usefulness (PU) and Perceived Ease of Use (PEU) determine an individual’s intention to use a system. These principles are developed into constructs, affordances, success conditions, and tests in the table below.

Table 2. Design principles for the Technology Acceptance Model (Davis, 1989)

In essence, TAM posits that a system is more likely to be accepted and used by individuals if they perceive it to be useful and easy to use.

Now that we have a deep understanding of how we develop design theory, let’s explore how we combine design with science to study what we make. In this section, you will learn how the scientific method is applied to test designs, review the design science research process, and see how this is put into practice via a hypothetical example.

If you’re familiar with the philosophy, processes, and practices of science, the “science” of design science is actually quite straightforward. Design science simply employs the scientific method to validate design theory. In other words, it essentially follows the scientific cycle of making an observation, developing a hypothesis that explains that observation, empirically testing that hypothesis, then making more observations based on our tests. This is the fundamental rigorous cycle of scientific knowledge. What makes design science unique from the other sciences, however, is that it involves two additional cycles: a design cycle and a relevance cycle (figure 5). For our current purposes, the details of these cycles do not matter. Simply note that these interlocking cycles drive advancement in three places at once:

1. Through the rigour cycle, we develop a better understanding of the world, particularly about the effects and natures of technology.
2. Through the design cycle, we build better products, processes, and programs (design artifacts) and improve our ability to evaluate their efficacy.
3. Through the relevance cycle, we improve our understanding of problems and opportunities and help to make progress on both.

To conduct design science, Peffers et al. (2007) offer a robust Design Science Research Methodology (DSRM; figure 6). The DSRM is a commonly used structure for creating and evaluating constructs and artifacts within the Information Systems discipline. It consists of six key activities, which can be executed in a largely sequential fashion but also allows iterative feedback loops:

1. Problem Identification and Motivation: Define the research problem and substantiate the relevance of the solution. A comprehensive understanding of the problem is developed through landscape review, gap identification, and insight into why and how an existing problem affects stakeholders. (This is where a design theory’s problem/purpose, context, and users might be defined.)
2. Objectives Definition for a Solution: Infer the objectives of a solution based on the identified problem. The solution’s requirements and effects are established, clarifying the success conditions for the resulting designed artifacts.
3. Design and Development: Create an artifact for a specific problem. This is where design principles and their constructs, affordances, success conditions, and tests would be defined.
4. Demonstration: Demonstrate the use of the artifact in a suitable context. This phase involves use-case scenarios, simulations, or detailed examples to explain how the designed artifact can be applied to solve the stated problem. This stage is our opportunity to see if our design results in artifacts that satisfy the success conditions using evaluation (the next step in the DSRM).
5. Evaluation: Evaluate the artifact. The artifact’s performance in solving the problem is evaluated using suitable methods as specified in the design theory and principles, which may be observational, experimental, analytical, testing, or descriptive, depending upon the research context and the artifact itself.
6. Communication: Communicate the problem, the artifact, the novelty, the usefulness, and the effectiveness to audiences. This involves consolidating and disseminating research outcomes for its intended audience— it could include academic peers, as well as industry practitioners.

Peffers et al. (2007) suggest that researchers may enter this process at different stages depending on the nature of the research, using what they call “entry points”. The research activities are not strictly sequential but typically recur iteratively as the research progresses, allowing the researcher to loop back to previous stages based on the findings at a current stage.

Here we explore a example of the DSRM. Consider the following hypothetical example focused on a manufacturing company..

1. Problem Identification and Motivation: Suppose that inefficiencies in resource allocation within a manufacturing company are causing increased costs, production delays, and waste. Changes to production plans and simple errors both cause schedules to shift unpredictably in mid-production. This means that the company must become better at dynamically adapting the manufacturing schedule.
2. Objectives Definition for a Solution: The company needs to become better at adapting the manufacturing schedule in realtime to keep up with changes and unexpected issues. A new design will be successful if changes can be made to the schedule in the middle of operations such that those changes and their consequences are appropriately propogated downstream to all aspects of production affected by the change.
3. Design and Development: Given the above problem and objectives, the design team begins by exploring the basis for potential solutions to this challenge. They know that recent advancements in data analytics, machine learning, and AI have led to algorithms that are effective at modelling complex problems and, given new input data, can adapt the model to suit. So, the team develops design principles focused on a model-based adaptive scheduling algorithm that can draw on realtime data to maintain a model of the production schedule and adapt it to inputted changes, dynamically scheduling resources to minimize costs and delays.
4. Demonstration: The AI-based scheduling tool is put to use in a simulated environment reflecting real-world conditions and constraints of a production factory. Various scenarios are run to assess the performance of the AI tool across a range of situations, including both regular and high-stress (rush orders, limited resource availability, etc.) production cycles.
5. Evaluation: Using a test dataset reflecting both regular and outlier conditions, the performance of the AI tool is evaluated by comparing it against manual scheduling outcomes and outputs from traditional non-AI scheduling software. Common evaluation metrics could include fulfillment timeline, cost efficiency, and resource utilization rate. The results of these evaluations are used to validate our initial hypotheses.
6. Communication: If the AI scheduling tool is successful in significantly improving resource allocation efficiency, the results would be disseminated in a stream of research papers. These would detail the problem, the tool design, the tests performed, the evaluation methodologies, and the resulting impact of the AI tool. This information would be invaluable to both academics studying AI applications and industry practitioners in manufacturing.

This hypothetical project demonstrates how the development of a design theory follows DSRM process, thus ensuring a comprehensive and methodical approach to problem-solving that contributes to rigour, design, and relevance.

There are professions more harmful than industrial design, but only a very few of them

• Victor Papanek (1923-1998), advocate for socially and ecologically responsible design (Papanek, 1997)

Imagine a company developing an MIS to optimize its hiring processes. The system incorporates algorithms intended to screen candidates rapidly. However, the algorithm is inadvertently biased against candidates from certain demographics, leading to discriminatory hiring practices. This scenario unfolds silently, masked by the perceived impartiality of technology. The repercussions extend beyond individual missed opportunities; they perpetuate systemic inequalities and erode trust in technology as a tool for fairness. This hypothetical example illustrates the potential consequences of neglecting ethical considerations in MIS design—a failure that can reinforce societal disparities and undermine ethical standards.

At this point, it is worth underscoring that every decision is a design decision. In Management Information Systems, that means that every decision should be guided by design to encourage the usability, accessibility, efficiency, and functionality of our information systems. The issue with this is that for many kinds of decisions, our design theories are implicit. That means that we have not put in the work to understand, articulate, and make tangible the problems we’re solving, who we’re solving them for, the context we’re working within, what success looks like, or what ideas underpin the success of our designs — let alone how we know if those ideas are being properly implemented. Unfortunately, the consequences of bad design are like an iceberg. Some of the challenges caused by bad design (for instance, a poorly-performing system that is hard to use) will be easy to see. However, as technology is increasingly and intractably woven into the fabric of business and society, some of the most significant ramifications of poorly-designed systems are now hidden beneath the surface of these tools. These decisions dictate how systems interact with users, influence organizational processes, and potentially affect broader societal norms. Given the ubiquitous integration of MIS in daily operations and personal lives, these systems can shape behaviors, protect or endanger privacy, and foster or hinder inclusivity. The weight of these decisions places a moral imperative on designers and developers to recognize and wield their power responsibly. As a result, good design is not only paramount for making effective and efficient systems — it is also essential for making ethical systems.

In the book Ruined by Design, Monteiro (2019) argues that designers are not neutral parties in the creation of technology; they are gatekeepers of ethics and morality. Design in MIS is not merely about creating efficient systems; it’s about making decisions that affect users’ lives, data privacy, and societal norms. Monteiro emphasizes that every design choice wields power and influence, embedding within it the potential for significant societal impact. This underscores a multifold responsibility: To not only fulfill business objectives, but also to safeguard user rights, to anticipate long-term systemic effects of changes to technology, and to advocate for positive change. Remember the key lesson at the beginning of this module: we are all designers. Thus, as professionals working with MIS, we must extend our purview beyond using data and systems to consider the ethical implications of our work. This includes respecting user privacy, ensuring data security, and actively resisting features that could exploit or harm users or other stakeholders.

To navigate the ethical complexity of design, adopting a structured framework is essential. Monteiro (2019, chapter 1) advocates adopting the following designer’s code of ethics:

• A designer is first and foremost a human being.
• A designer is responsible for the work they put into the world.
• A designer values impact over form.
• A designer owes the people who hire them not just their labor, but their counsel.
• A designer welcomes criticism.
• A designer strives to know their audience.
• A designer does not believe in edge cases.
• A designer is part of a professional community.
• A designer welcomes a diverse and competitive field.
• A designer takes time for self-reflection.

By adopting such a code of ethics, we are challenged to consider the potential ramifications of our designs, making decisions that stretch beyond functionality or aesthetics, but also addressing issues of privacy, accessibility, sustainability and safety. By encouraging criticism, user-centeredness, professionalism, diversity, and self-reflection, the code of ethics also gives us mechanisms and behaviours to ensure we can support and protect this ethical orientation.

Nonetheless, the challenge of implementing these ethical foundations in the real world is significant. It requires:

• Education and Awareness: Professionals must be educated on the ethical implications of MIS design, including ongoing training and development.
• Ethical Leadership: Organizations need leaders who prioritize ethical considerations in strategic decisions and who can serve as ethical role models.
• Policies and Governance: Robust policies and governance structures should be established to enforce ethical practices in design of MIS.
• User and Stakeholder Advocacy: Establishing roles or teams dedicated to human rights and ethical design should ensure that user and stakeholder welfare is a priority in system design and implementation.

In an era where technology shapes almost every aspect of our lives, the ethical considerations of MIS design are paramount. It is clear that the task of creating ethical systems is complex but critically important We, as professionals and designers in this field, have a profound responsibility. We are not only designing systems; we are designing the future experiences of everyone who interacts with or is affected by those systems.

In this note, you explored the design of information systems, learning to develop design principles and design theories, to separate design from designed artifact, and to study the effectiveness of our designs via design science research methods.

Design is fundamentally a process of decision-making, a means of knowing what holds importance and what does not. It is through the act of ‘designation’ that we make design decisions which lead to the creation of valuable artifacts. To design is an act of ‘deciding’ what matters. This point underscores the significance of MIS design decisions in shaping systems. Remember that every tool has an implicit design theory, and being explicit about these theories allows us to build, adopt, and use these tools more effectively, efficiently, and ethically.

Design science builds on the idea of applying scientific methods to the realm of design, fostering a rigorous, evaluative, and iterative approach towards developing design theories and principles. The frameworks developed from exiting theories guide the formation of novel and useful artifacts, solutions to recurrent problems within their specific domains.

Do not forget about the importance of ethical considerations in design. Design is not just about determining how to make the most performant systems. Design is also about appreciating the complex ramifications of the choices we make during the design process. Design ethics challenge us to be accountable for our design decisions and to anticipate their consequences.

1. To design is to designate; to mark. Design is about deciding what is important (and what is not).
2. Design science is the application of the scientific method to design theories, principles, and artifacts.
3. All tools have design theories, though they may be implicit.
4. You have and use design theories, though they may be implicit.
5. Being explicit about our design theories helps us to build, adopt, and use tools more effectively.

Davis, F. D. (1989). Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Quarterly, 13(3), 319–340. https://doi.org/10.2307/249008

Dresch, A., Lacerda, D. P., & Antunes, J. A. V. (2015). Design science research. In A. Dresch, D. P. Lacerda, & J. A. V. Antunes Jr (Eds.), Design science research: A method for science and technology advancement (pp. 67–102). Springer International Publishing. https://doi.org/10.1007/978-3-319-07374-3_4

Fishbein, M., & Azjen, I. (1975). Belief, attitude, intention, and behavior: An introduction to theory and research. Addison-Wesley.

Gregor, S., & Hevner, A. R. (2013). Positioning and presenting design science research for maximum impact. MIS Quarterly, 37(2), 337–A6. https://www.jstor.org/stable/43825912

Gregor, S., & Jones, D. (2007). The anatomy of a design theory. Journal of the Association for Information Systems, 8(5), 25. https://aisel.aisnet.org/jais/vol8/iss5/19/

Gregor, S., Kruse, L., & Seidel, S. (2020). Research perspectives: The anatomy of a design principle. Journal of the Association for Information Systems JAIS, 21, 1622–1652. https://doi.org/10.17705/1jais.00649

Hevner, A. R. (2007). A three cycle view of design science research. Scandinavian Journal of Information Systems, 19(2), 87–92.

Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design science in information systems research. MIS Quarterly, 28(1), 75–105. https://www.jstor.org/stable/25148625#metadata_info_tab_contents

Keil, M. L. M., & Mark. (1994). If we build it, they will come: Designing information systems that people want to use. MIT Sloan Management Review, 35(4), 11–25. https://sloanreview.mit.edu/article/if-we-build-it-they-will-come-designing-information-systems-that-people-want-to-use

Lukyanenko, R., & Parsons, J. (2013). Reconciling theories with design choices in design science research (pp. 165–180). Springer, Berlin, Heidelberg. https://link.springer.com/chapter/10.1007/978-3-642-38827-9_12

Monteiro, M. (2019). Ruined by design: How designers destroyed the world, and what we can do to fix it (p. 221). Independently published.

Papanek, V. J. (1997). Design for human scale. Van Nostrand Reinhold.

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://www.tandfonline.com/doi/abs/10.2753/MIS0742-1222240302

Walker, R. (2024). The guts of a new machine. The New York Times, 78. https://web.archive.org/web/20240204042142/https://www.nytimes.com/2003/11/30/magazine/the-guts-of-a-new-machine.html