How to successfully fail a design case study

2.1 Data work and information infrastructures in SMEs

Over the last years trade journals, papers, and public discourse often referred to the metaphor that data is the “new oil.” As this data can be used to better understand operational processes, customer profiles, and market changes and thus increase performance. ⁷ For small and medium-sized enterprises (SMEs), this means converting data into knowledge, acting in a more targeted manner, and strengthening their market position. ⁸ The increasing availability of data makes it necessary to consciously and actively engage with it in order to derive viable decisions. ⁹ With the increasing spread of digital technologies and the accompanying rise in information flows, more and more people are involved in the creation and processing of data. ¹⁰ Employees collect, manage, analyze, and interpret data in their areas of work. ¹¹ These activities are referred to in research as data work. ^{10 , 11} Although data scientists and analysts often come to mind first, ¹² data work affects a wide range of other professions. These include teachers and doctors, as well as administrative and office workers, who all enter data. It is precisely in these areas that this work often remains invisible and its importance is underestimated. ¹¹ The importance of data work becomes particularly clear when it comes to ensuring data quality, as only high-quality data enables integrated tools (or AI tools) to deliver their full benefits within the organization. ¹³ The principle of “garbage in, garbage out” and the associated approaches to improving data quality have been the subject of numerous other studies (e.g. ^{14 , 15} ). Sambasivan et al. ¹⁶ show that problems in data quality link directly to data work practices and can lead to inadequate results in AI systems. In addition to data work and data quality, HCI research also focuses on the use of data-driven systems in organizations. Sun et al. ¹⁷ use long-term care as an example to show that nursing assistants play an important role in data-driven healthcare systems. They perform invisible data work, for example by recording, correcting, and interpreting information. Pedersen and Bossen ¹⁸ demonstrate that the establishment of data-driven practices in organizations does not depend solely on technical solutions, but in particular on employees being empowered through targeted skills development to integrate data into their respective work processes. Kristiansen et al. ¹⁹ show that the use of data-driven systems has changed the way electricians work in such a way that data collection and use have become part of their everyday routine and, at the same time, they have had to redefine who is responsible for what and how the work is organized.

In addition to the focus on data work, an information infrastructure is required to enable the transfer and availability of information in the first place. As emphasized by Bietz et al. ²⁰ and Lee et al, ²¹ infrastructures are shaped not only by technical factors, but also by collaborative and organizational arrangements. ²² A functioning infrastructure is essential to ensure an efficient internal process. This ensures that information is passed on from one department or actor to the next. Studies highlight that SMEs often have inadequate information infrastructures and therefore have difficulty accessing relevant information. ²³ The lack of interfaces between systems within an organization also represents a key gap, as it hinders the smooth flow of information. ²⁴ The lack of interoperability between different IT systems also makes information exchange considerably more difficult and prevents existing data from being used efficiently. ²⁵ In addition, IT and R&D skills and a mature infrastructure strengthen the supply chain capabilities of SMEs. ²⁶ All studies thus demonstrate that a robust information infrastructure forms the basis for knowledge exchange, cooperation, and the further development of processes and is considered an important cornerstone of the organizational performance of SMEs. ²²

2.2 Data management and knowledge sharing

Working with data and the existing infrastructure are prerequisites for sharing information and knowledge within an organization. In their study, Oleksik, Milic-Frayling, and Jones ²⁷ highlight that effective data sharing depends largely on how social and technical conditions are understood. Particularly in connection with data exchange and reuse, contextual information on the origin and collection of data is often missing. ^{28 , 29} Without this context, it becomes unclear how central variables were derived and what they signify in practice. ³⁰ In addition, the quality and usability of the data is often called into question. ³¹ To ensure flawless exchange, data must be subject to a certain degree of standardization, especially when it comes to formats or data types. ^{32 , 33}

In addition to exchanging data within organizations and contextualizing it, it is equally important to generate added value from these data. This added value is used to derive knowledge that can be passed on within the organizations. Blair describes this difference as follows: ”A computer can have data (e.g., facts and figures stored in a database). A report can have information; that is, a report can be informative. But only a person can be knowledgeable, that is, only a person can have and exercise knowledge.” [ ³⁴ , p. 1021]. For SMEs, which have limited resources and technological and organizational barriers, ³⁵ it is all the more important to understand data in its context and generate knowledge in order to secure competitive advantages and make sustainable decisions. Ackerman et al. ³⁶ emphasize that knowledge and expertise can only be effectively distributed through social embedding, which is particularly crucial for SMEs with limited expert resources. ³⁵ Further studies show that knowledge systems only enable effective cross-departmental exchange through maintenance and social embedding. ³⁷ Similarly, Rutz ³⁸ shows that enterprise resource planning (ERP) systems in SMEs are only used sustainably if training and knowledge transfer are integrated into everyday work practices.

While data management (DM) primarily aims at structuring, standardizing, and reusing data, knowledge management (KM) focuses on social practices and the exchange of expertise. ³⁶ Durst ³⁹ observes that knowledge management in SMEs has evolved and now also encompasses topics such as organizational learning, digital transformation, and innovation capabilities. In contrast, data management refers to the structured management, storage, processing, and retrieval of data – usually mediated by information systems and guided by formalized guidelines. Despite their conceptual differences – implicit versus explicit knowledge, informal exchange versus structured records – KM and DM increasingly overlap in digital environments. Business intelligence tools, enterprise resource planning systems, and collaborative platforms blur the lines between knowledge as experiential value and data as formal records. Recognizing this convergence is essential to understand how SMEs holistically manage their information and cognitive resources.

2.3 Designing artifacts for knowledge

Design processes in rural-oriented and resource-limited organizations often demonstrate their value even before an IT artifact is implemented. The key factor is the joint examination of problems and possible solutions. Success is measured by the visualization, negotiation, and restructuring of practices and responsibilities, especially in fragmented rural contexts. ⁴⁰ We adopt a design case study stance ⁶ and elaborate this approach in Section 3.2. Against this backdrop, the joint development of a prototype can act as a boundary object, ⁴¹ an artifact that brings together different perspectives, establishes shared points of reference, and promotes mutual understanding. Systematic reviews show that such boundary objects support knowledge integration, coordination, and innovation. ⁴²

In design-oriented CSCW research, prototyping does not primarily serve to develop a technical solution. Rather, it enables assumptions to be visualized, tensions to be made visible, and organizational learning to be initiated. ^{43 , 44} In the study, too, the prototype developed fulfilled an analytical and mediating function. It made existing tensions visible, opened up new discussions with employees, and prepared the ground for strategic decisions. ⁴⁵ Design may thus be conceptualized as a distinct modality of knowledge work whose significance transcends conventional performance metrics.

3.1 Research context

As part of a federal initiative, a medium-sized company in Germany was supported via a design case study (see below) in overcoming a challenge in the area of data management. The initiative aims to promote the digital maturity of SMEs that often do not have their own research and development department. The industrial company in question, which employs approximately 50 people, specializes in the production for sale or rental of its products. The study is based on a total of five interviews, one observation of actual work practices in the sales department (one observer in the same room, two researchers via video call) and field notes conducted between February 2024 and September 2024. A total of six people were surveyed on site at the company. The interviews were semi-structured and the work practice observation of the internal sales process helped visually contextualize the processes and terms of the interviews to better understand the internal processes. The interviews comprise 27 questions on the topics of data management, the value of data, knowledge sharing, organization and communication within and outside the department. The average duration of the interviews is between 60 and 120 min. The observation triad consisting of one on-site observer and two remote participants surveilling the actual work practice took 38 min. The study participants were almost exclusively individuals in managerial roles within the company, with a tenure of more than five years. By selecting experienced managers, both established routines as well as current challenges in data organization could be made visible. Before interviews, a declaration of consent was given that we could use spoken content for research purposes.

3.2 Research framework and prototype development

The research framework follows the design case study approach. ⁶ Within CSCW, a design case study is a participatory approach in which design is used to examine and shape situated work practices. We used this approach to identify recurrent coordination and data-flow issues and to co-create solutions. To do this, we used an evolving prototype as a boundary object ⁴¹ to elicit requirements, align assumptions, and make implicit practices explicit. The company’s decision to opt for an external provider, rather than continue the cooperation with our research team, ended the prototypical work prior to appropriation. As these issues became visible, employees raised them with management and emphasized the priority of data and information for future decisions. The empirical surveys served as a basis for understanding the practices within the company and mapping them into a prototype. A participatory approach ensured that employees were involved in the design process (through interviews and discussions with the management assistant). Accordingly, we report the pre-appropriation phase.

The prototype was designed as a connector between the company’s existing software systems. At the time of the study, employees had to manually switch to Microsoft Teams when documents were created in the two ERP systems and the document management system. The prototype aimed to automate this step by linking the tools more directly, reducing manual effort and the risk of errors. Although the prototype was not fully developed and therefore could not be implemented during the study, it functioned as a boundary object that aligned assumptions across roles and clarified requirements for the subsequent procurement decision. However, the company decided against the simplified prototype solution and turned to a professional provider instead (Figure 1). The provider supplied a comprehensive system that replaced the existing applications, including the two ERP systems, document management, knowledge management, and new customer entry, with an integrated solution. Even though the prototype was not implemented, it provided important impetus together with our research approach. It initiated discussions about digital transformation and helped employees to better understand the problems as well as the opportunities and their own role. This then paved the way for the decision to opt for a more sustainable, holistic solution, as explained in more detail in the following chapter.

Figure 1:

Progress of the design case study (Author’s own illustration).

3.3 Data collection and analysis

The interviews were conducted in a medium-sized German industrial company. The following table provides an overview of the interviews (Table 1). Three interviews were held with the deputy management (Interview Int-1, Int-2 and Int-3). However, during the third interview, the person had to leave the meeting prematurely. The analysis was carried out in close collaboration with the research team and was based on several phases of joint reflection. Shortly after the interviews, we met to reflect on the discussions together and share our first impressions while the experiences were still fresh in our minds. In the further course of the analysis, the transcripts were read several times and discussed in the team. The aim was to identify central topics, tensions, and contexts of meaning as they emerged in the course of the discussions. Our approach is based on interpretive approaches within CSCW research (see ⁴⁶ ), which focus on the situated emergence of meaning and the embedding of statements in concrete work contexts. This enabled us to identify patterns that go beyond individual utterances and point to broader contexts in the organization. Our data analysis was conducted in an iterative team process that was guided by a reflexive, interpretative approach. The researchers’ perspective was deliberately included in the analysis process and understood as significant for the generation of knowledge. First, we coded all statements along two orthogonal dimensions. On the technical dimension, we distinguished process and task flow, data capture and maintenance, information distribution, and access rights. On the social dimension, we distinguished knowledge generation, knowledge sharing, knowledge use, and continuous improvement. We then categorized the material by interaction context, separating intra-departmental issues, inter-departmental exchanges, and interactions with external partners and the research institute. Selected interview quotes substantiate these categories and highlight the specific difficulties employees face in practice. Throughout the analysis, we worked reflexively as a team. After each interview we wrote analytic memos, re-read the transcripts together, and discussed alternative readings until we reached a shared interpretation. Quotations in the findings illustrate patterns that recurred across interviews and departments.

4.1 From practice analysis to prototype development

The organizational setting under investigation revealed a complex landscape of historically evolved software ecosystems. Two distinct ERP systems were employed to support different business processes – one dedicated to product sales, the other to equipment rental. These systems emerged from context-specific requirements and evolved in relative isolation, reflecting a path-dependent trajectory of their development.

Operationally, the ERP systems serve as the backbone for documentation workflows: they generate formal documents that are subsequently transferred to a Document Management System (DMS). However, the DMS lacks direct integration with Microsoft Teams, which is utilized informally as a project-oriented document repository. This absence of a programmatic interface necessitates manual transfer of documents (e.g., offers, invoices, delivery slips), resulting in procedural inefficiencies and redundant work practices.

Furthermore, an in-depth analysis of the customer onboarding process highlighted a fragmented data flow across departmental boundaries. Initial data capture occurs within the sales department through an online intake form. This data is then manually transcribed into the financial department’s software environment, where a customer identifier is generated and relayed manually back to sales. This process exemplifies a non-integrated pipeline characterized by duplicate data entry and heightened susceptibility to transcription errors, pointing to a lack of system interoperability.

Another noteworthy practice pertains to data collection in production environments. Workers complete analog timesheets to log work hours, machine usage, and project affiliations. Despite the richness of this data, it remains unused in digital analytics or operational feedback loops. These forms are archived physically and are not subject of systematic evaluation. Interestingly, the persistence of this practice is primarily symbolic – serving to communicate procedural diligence and to reinforce the perceived accountability of production tasks, even though the data itself remains inert.

Collectively, these empirical observations informed the development of a prototype (Figure 2) aimed at supporting context-specific integration, reducing manual overhead, and unlocking the latent value of underutilized data. The subsequent design process was guided by principles of grounded design ⁴⁷ and ethnographic sensitivity to local work practices, in line with the socio-informatics approach to IT artifact development. ⁴⁸

Figure 2:

Comparison of data processes with and without prototype connector (Author’s own illustration).

4.2 Data management and knowledge practices within departments

Our analysis revealed several challenges of employees to share information within their department, which were mainly related to individual work practices and information handling. In particular, the subjective burden of fragmented systems and manual workflows became clear. Employees use several systems simultaneously that are not directly linked (Int-2, P-3). This means that a large part of their working hours is spent on data entry. This manual data entry into multiple systems leads to transposed digits, redundancies, and inefficiency.

When accessing, I would say that only the mass of systems is a problem. So you have a lot of platforms, if you want to see that as a problem, a lot of login data, a lot of open windows. So not one system that I work with, but always several systems open. Yes, the source of error when transferring data. […] So I want to deliver something and the item is physically here, and at the moment when I want to generate the delivery note, the system says it can’t be done because the item is already somewhere else. […] There are just so many errors in the data. (Int-2, P-3)

The increased administrative workload and parallel and redundant work in several systems lead to higher stress levels and more frustration among employees. Furthermore, the fragmentation of systems not only impairs administrative workflows, but also reduces process efficiency to share knowledge effectively because information is distributed across different platforms. Knowledge sharing across departments is done through teams, wikis and PDF forms, with important data such as product or customer information scattered across several departments. We found that managers would like to share more knowledge within their department, but due to a lack of IT skills and scattered information, only direct knowledge sharing in written or interpersonal form is possible.

I still work with paper a lot, I have to say. Yes, it’s all my fault. Yes, but I have to leave soon. There’s too much paper. […] as I said, I’m still too much of a foreman instead of a plant manager. I still walk around the hall too much, explaining, assigning. (Int-4, P-5)

The CEO is promoting digitalization topics in internal training courses and incorporating them into the corporate strategy, while the internal departments’ superiors are trying to integrate them into departmental processes using digital tools. The lack of centralized documentation of critical production related knowledge means that employees are dependent on the knowledge of their foreman even in his absence. This means that he has to be available 24/7, even during his vacation. Generally, the absence of centralized documentation combined with insufficient training programs exacerbates the issue, making the transfer of domain-specific expertise even more difficult.

4.3 Data silos and cross-departmental conflicts

Coordination between departments and organizations is hampered by fragmented data storage and the lack of a unified ERP system. Two ERP systems are used in parallel to sell and rent goods. These have grown historically and have been maintained in parallel ever since.

We now have two ERP systems, which is a hangover from the past, because we used to also have two companies. Rental and production of products. And we would like to combine that into one system now. (Int-1, P-2)

The fact that different systems are running for two processes makes data maintenance, the flow of information between departments, and the consistent evaluation and use of company data more difficult. The existing data silos are spread across different departments and systems within the organization. Each department relies on its own tools and data sources, which are often maintained independently of others. There are hardly any overarching workflows to ensure information is consistently synchronized or updated between systems.

I currently have two projects that are already on site at the customer. But I can’t capture all this data because the products haven’t been created. And until they’re created, captured and stored manually, basically neither delivery notes nor consignment notes nor invoices can be created, none of it can be generated because I need the serial numbers. (Int-2, P-3)

As described by P-3, challenges arise in the interaction between production, delivery and documentation. In some cases, the goods had already been delivered to the customer even though the relevant documents such as delivery notes or accompanying papers were not yet available. Although the order was documented in the project file and carried out in practice, it was not recorded in the corresponding ERP system. This led to a delay in traceability and coordination between the operational business and the systemic representation. P-3 describes another example that illustrates the far-reaching challenges of isolated data storage and a lack of system integration. During the course of sending reminders, incorrect customer master data was discovered by chance. Several customer entries had been merged under the same customer number. This incident reveals a fundamental problem of insufficient data consistency and a lack of cross-departmental synchronization within the company.

We often only found out that we had master data when reminders were sent in the accounting department. The customers got in touch and said that the project didn’t belong to me. Yes, then it was discovered that several customers had been created under this customer master number. (Int-2, P-3)

Another example from P-6 illustrates the consequences of inconsistent data collection. Due to inconsistent spelling, several data records were created in the system for one and the same company. Slight differences such as full stops, spaces or different company names led to different entries existing for one and the same customer. Relevant information and associated documents were thus distributed across different data records, which made it considerably more difficult to find and process them.

The same company was entered into the system multiple times – sometimes as U. E., sometimes as U. E. GmbH”, then “U. E. GmbH & Co. and so on. Small differences such as periods, spaces or spelling mistakes resulted in up to six different data sets for the same company. This meant that relevant information and documents were scattered across multiple entries and difficult to find. (Int-5, P-6)

To counteract such redundancies, an internal workflow for the creation of new customer data has been established. The information is first recorded in the sales department and then forwarded to the accounting department via a standardized form, where it is centrally maintained in the relevant systems. The purpose of this process is to avoid double entries and improve the quality of the data. Despite this measure, the cross-departmental process of entering new customers is still characterized by numerous manual interfaces. The information is transferred multiple times into different systems, first by sales and then by accounting. The lack of automation in this process not only leads to avoidable inefficiencies but also increases the likelihood of transcription errors and interruptions in the flow of information between departments, as P-3 describes.

The different programs also mean that I have a lot of data. But I can’t use it […] I can only use it by transferring it manually. (Int-2, P-3)

In addition to capturing new customer data, updating existing records is another challenge. In discussions with P-3, we found that changes to payment details in the accounting department are not automatically passed on to other systems and departments. As a result, inconsistent data records can persist between systems without being detected or corrected.

Regular customer data is […] not maintained centrally, but […] where changes occur. […] When it comes to payment terms, since DATEV is the leading system in accounting, the data is changed there accordingly. So there is no system where data changes are somehow recorded centrally. (Int-2, P-3) Then information should actually be sent to all other system users […] I’m just saying that, but it doesn’t happen, yes. (Int-2, P-3)

Furthermore, changes to order numbers or product specifications are not communicated to all departments. In particular, critical updates between departments such as engineering and production are not reliably shared, which can lead to errors in planning and execution. As a result, employees work with outdated and incomplete information.

We had a case where the window sills that we source from the supplier could no longer be manufactured by this person and they deviated from the thickness of the plate and the material of the plate. The production department had the information, but the design department did not. That means we continued to design our plans with the thicker plates. (Int-6, P-4)

The interviews also show that knowledge is not shared in a structured and cross-departmental manner. It often remains unclear which knowledge is relevant for other departments, at which interfaces it is required, and in what form it should be communicated.

Often we don’t know what is important for purchasing […] But purchasing, for example, doesn’t know what is essential for the design department to be able to operate at all. (Int-3, P-4)

Furthermore, there is a lack of binding processes for sharing modified or updated knowledge. Particularly when it comes to making adjustments to ongoing processes, it is often unclear who needs to be informed and when.

Sometimes I just can’t see what has changed. But that’s a purely human problem. Who do I inform and when? (Int-4, P-5)

This illustrates the broad challenge regarding the reliable distribution of knowledge in dynamic project environments. When responsibilities for knowledge transfer remain unclear, there is an increased risk of miscommunication, redundant work, and process delays across departments.

4.4 Tensions in collaboration with external partners

The following findings concern the interactions between the research institution, external contractors, and the company. The collaboration was initiated at the request of the company, which was facing challenges in its digital processes. After an initial introductory meeting with the heads of department, individual interviews were conducted with the relevant areas. The aim was to identify potential for improving existing processes, consistently incorporating the perspectives of employees. During the interviews, it became clear that employees perceived the implementation of the discussions in the company as positive. There was a fundamental openness to change, and the desire for improvement was clearly articulated. The existing dissatisfaction with the current work processes was expressed several times. The first solutions presented in the discussion met with interest and were received with commitment. In the further course of the collaboration, there were delays in setting dates for follow-up meetings. These were due, among other things, to communication issues, which required repeated queries on our part. It became clear that the company management needed longer response times due to heavy workloads and a strong focus on day-to-day operations.

A striking example arose during an interview with the head of production. Even before the conversation began, this person expressed uncertainty about their technical skills and stated that they had no experience with digital topics. This initial reluctance was dispelled by clear communication about the general nature of the questions. Throughout the survey, care was taken to use simple and accessible language and to avoid technical terms in order to prevent uncertainties.

A particularly revealing observation was made during an online meeting in the later stage of the project. The assistant reported that after the discussions, several employees sought out the management to further reflect on the topics discussed. According to the assistant, this brought topics such as communication, organization and the handling of data more into focus. These aspects had already been relevant to some extent before, but were now prioritized. In the course of an ongoing adjustment to a production process, it became clear that a purely operational change was not enough. Rather, it was recognized that the way information was handled and coordinated also needed to be adapted in order to make the process effective in the long term.

A salient issue that emerged from our empirical analysis concerns the layered fragmentation of process knowledge and its implications for collaboration, particularly when external IT service providers are involved. Participants reported that external partners lacked a fundamental understanding of the organization’s internal processes. This absence of domain-specific procedural knowledge at the external level significantly impeded effective coordination and support.

5.1 Busy worker and infrastructural fragilities

This case study approach exemplifies how the design case study method as outlined in ⁴⁹ can be effectively applied in the unique setting of a small or medium-sized enterprise (SME). The theoretically grounded approach – comprising pre-study (context), design intervention (design), and post-study (appropriation) – proved to be not only analytically rigorous but also adaptable to the fluid realities of SMEs. In line with work on design in resource-limited organizations, ⁴⁰ the value of this process lies not only in the prospect of a future IT artifact, but also in how working together made practices, responsibilities, and conflicts more visible. ^{43 , 44}

The findings show that while SMEs excel in domain-specific expertise and operational responsiveness, they lack a systemic perspective on their own processes. The design case study method helped uncover hidden inefficiencies and inconsistencies not evident in financial data but deeply felt in everyday work – such as repeated data entry and unnecessary process complexity. In this sense, the design activities themselves ⁴⁵ became a form of knowledge work that surfaced and reorganised understandings of data work in the organization.

From a socio-informatics perspective, the study underscores the value of participatory design methodologies in environments that are often overlooked in mainstream IT development. The approach did not just produce technical artifacts, but also supported an organizational shift from product-centric to process-oriented thinking.

This highlights the potential of design case studies to serve as translational mechanisms between abstract design theory and concrete organizational practice. The implication for socio-informatics is: rather than treating SMEs as exceptions, they should be viewed as paradigmatic testbeds for context-sensitive, reflexive IT design. Their high variability, lack of standardization, and self-reliant ethos make them ideal environments for the application and further development of grounded, practice-based methods. The flexibility in decision making and non-standardized development routines let SMEs quickly adjust to new solutions, as soon as they understand the benefit. In our case, the CEO decided to give the task of developing an actual IT artifact to solve the detected problems to an external IT partner. This way, the future development and support could be carried out by a professional supplier, building on the theoretical foundation and findings of our research group. Although this is not the traditional way a design case study is carried out, the immediate implementation of a design concept into a real-world setting is a huge success for researchers and company alike.

At the company we examined, we were particularly struck by the work with data and its challenges, such as the distribution of information. One pattern we noticed in data work is what we refer to as “busy work” or, in German, “Eintragungskultur” (data entry culture). Put simply, this is a work culture characterized by the implicit belief that productivity is directly linked to visible activities recorded by the system, in particular frequent keyboard entries or interactions with the user interface. This phenomenon highlights a tension between organizational expectations and employees’ individual self-perception, both of which are still strongly tied to traditional notions of productivity. From a management perspective, continuous data entry is seen as an indicator of performance. Employees, on the other hand, experience this practice as redundant multiple data entry, which is not only labor-intensive but also monotonous and compromises data quality. Management’s focus remains on the visible input process, while the quality of the final information is subordinated. Our findings are consistent with the observations of Moller et al., ¹⁰ who described similar patterns.

In discussions with employee P-6, it became clear that there is no fixed set of rules for data entry. As a result, the same company may be entered into the system under different names. Entering the same information in different variants takes up a considerable amount of time and at the same time reduces the quality of the data and processes, which shows that data quality problems are directly linked to data entry practices (data work). ¹⁶ As other studies have also emphasized, ^{14 , 15} ensuring data quality is a fundamental aspect of this investigation. It influences the entire process chain from data entry to delivery of the goods and therefore requires clear rules and standards for input practices.

The flow of information alongside data entry must also be viewed critically here, as we see in the literature. ^{23 , 24 , 25} Our study shows that the further development of the IT infrastructure without embedding domain-specific process knowledge only partially addressed the underlying problems. The resulting loss of knowledge impaired the company’s ability to develop and maintain a coherent IT architecture that was aligned with the changing processes. As the organization grew, its dependence on the expertise of individual employees became increasingly problematic. In the absence of mechanisms for disseminating knowledge, “knowledge islands” emerged, with key information remaining isolated within individual departments. This led to individual employees becoming overburdened and increased vulnerability to staff turnover. At the same time, a lack of common understanding of processes made collaboration between departments difficult. Instead of cooperation, conflicting interests, restrictive access rights, and the emergence of “dark data” – information that was inaccessible or unknown to other departments – dominated. Instead of addressing these fundamental problems, the company relied on symptomatic solutions: additional software programs, ad hoc restructuring, and the misuse of existing systems. Instead of addressing the root causes, these measures exacerbated the existing gaps in the flow of information in the long term. However, the analysis makes it clear that a lack of standardization ^{17 , 19} and limited exchange between systems ²⁵ in particular are structural causes of these problems.

5.2 Data to knowledge and emerging gaps

The close interplay between data exchange and knowledge transfer is particularly evident in our case. The company’s fragile IT architecture means that data is scattered across different systems, forcing employees to navigate this fragmented environment. As a result, relevant information is rarely available at the right time and in the right place. Instead, employees must actively search for the data they need or wait for it to arrive with a delay. The manual transfer of information – due to a lack of interfaces and technical automation – also impairs data management in organizations. In addition to these technical hurdles, social factors additionally hinder exchange: ²⁷ Employees in individual departments often remain in their own data domain. They do not know who actually uses the data and do not systematically provide up-to-date information to others. These critical dependencies and the associated time-consuming handling of data management not only hinder the processing of tasks within individual departments, but also cross-organizational collaboration. At the same time, data sharing has the potential to transform information into knowledge that is crucial for both internal and external stakeholders. For example, work on a construction site was significantly delayed because information needed for subsequent work steps was missing. It is not only access to data that is crucial, but also its structured distribution, continuous updating, and context-related assignment in order to transform it into organizationally relevant knowledge and distribute it within organizations. ³⁶ We see this as a key feature that requires a smooth and intact infrastructure ^{20 , 21} that connects all systems, provides up-to-date information, defines clear data responsibilities, and enables the continuous exchange of knowledge.

The results also illustrate that knowledge management in organizations is often characterized by implicit practices and personal expertise. Decision-relevant knowledge remains in departments or with individual persons, is insufficiently documented or shared, and thus leads to dependencies and inefficiencies. ³⁹ Although digital tools such as Microsoft Teams or wikis are available, they are hardly integrated into existing work practices and are therefore rarely used. Instead, paper documents and informal conversations dominate, which are only of limited use for systematic knowledge transfer. As highlighted in the studies by Rutz, ³⁸ digital systems only reach their full potential when they are socially embedded and actively anchored in routines. A lack of trust and a strong need for data sovereignty mean that knowledge remains in individual storage locations instead of being viewed as a shared resource across the organization.

5.3 External actors and value of the design case study

The company examined shows a marked dependence on external actors. ³⁵ The example of the IT provider clearly highlights that digitization has historically tended to take place gradually, following the pattern of “buy one piece of software, then the next.” There was no comprehensive evaluation, involvement of employees, or detailed analysis. Communication has so far been limited to the CEO, the CEO’s assistant, and the provider. The implementation of the applications was based exclusively on immediate needs, without taking into account the overall architecture or the long-term corporate strategy. The management’s lack of knowledge about how digitization processes can be systematically designed exacerbates this situation. The company is therefore hardly in a position to propose alternatives and remains heavily dependent on the expert knowledge of the external provider.

Initially, there was also a strong dependence on knowledge in the relationship between the company and the institute that conducted the design case study. At this stage, the prototype that was being developed served less as a finished solution and more as a common object around which different perspectives on data handling, responsibilities, and existing coordination problems could be exchanged. ^{41 , 42} The company accepted the proposed technical solution in prototyping because it had no means of comparison itself. However, a rethink took place in the course of the project, particularly as a result of interviews with the workforce and discussions about processes and possible solutions. The interviews focused on fundamental activities in dealing with data and revealed how intensively and with what a changed perspective the respondents reacted to this. Involving employees in the design phase ⁶ also led to increased interest in digital solutions. The decisive effect was that employees who are not technical experts themselves entered into direct dialogue with management, thereby further advancing the digitization processes. Although the workforce was aware of the challenges involved in handling data and knowledge distribution, this had not previously led to active change. Instead, the company relied on existing routines and invested in machinery to reduce production times, while paper-based documentation and manual recording continued. The discontinuation of the prototype implementation illustrates that the company ultimately opted for a professional overall solution. The results show that the collaboration with our institute as part of the design case study offered significant added value. Even though the prototype was not implemented, it helped to focus attention on the “big picture” and to embark on a more comprehensive path to digitization. For CSCW research, this implies that design case studies can provide valuable impetus for organizations even if they are not fully implemented or are discontinued prematurely. The design case study thus shows that the process of joint design and reflection can trigger transformations even if the prototype is not implemented.

5.4 Limitations

This study deals with several limitations which have to be considered when interpreting the results. The data collection was conducted within a single company and a limited number of employees, not displaying the whole workforce. This means that the results are bound to the organizational and cultural context (an inherent limitation for design case studies such as this) and can only be partially transferees. Additionally, due to the size of the company the number of interviews was rather low. The information was enriched by online meetings, fieldnotes as well observations of processes in situ, to lessen this limitation. One potential critique of our methodological approach may concern the decision to conduct interviews in pairs, particularly involving an assistant to the executive management. At first glance, such constellations might raise concerns regarding the openness and authenticity of employee responses, especially in hierarchical organizational contexts.

However, this setup must be understood in light of the organizational dynamics specific to this SME. The assistant to the executive management played a pivotal role in initiating and facilitating contact with the research team. He expressed a clear interest in critically reviewing and potentially revising internal processes. His involvement was thus not solely administrative but signaled institutional support for reflective inquiry.

Crucially, our observations and follow-up interactions revealed that employees continued the discussion initiated in the interviews beyond our formal sessions. Several participants proactively approached executive management after our departure, reporting that the conversations had clarified their own challenges and led them to articulate process-related issues more explicitly. This unsolicited internal dialogue led directly to a management decision to invest in a professional ERP system – concretely affirming the practical relevance and organizational impact of our intervention.

These developments support our interpretation that the presence of a management representative in interviews did not suppress open discourse. Rather, the setting may have fostered a shared space of reflection across hierarchical levels, consistent with the principles of participatory design in practice-based computing. We acknowledge that the potential for response bias cannot be entirely excluded, but the subsequent employee-driven engagement and management action provide strong evidence against the presence of concealed concerns or inhibited communication.

Thus, while the interview configuration could be seen as a methodological limitation, in this case it appears to have served as a catalyst for intra-organizational learning and change – an outcome aligned with the goals of grounded design and socio-informatics interventions.

The design case study conducted couldn’t be fully executed as the company decided to work with an external contractor towards a holistic solution for its data and knowledge management processes. This meant that especially the appropriation phase could not be realized. This was partially also due to the nature and scope of the aim and funding of the federal project, as this only allowed us to conduct projects with SMEs until the protype status. Nevertheless, our study shows the transformational impact even a (partial) design case study can have on its participants.