Full Text
IMMERSIVE USER RESEARCH FOR B2B SAAS DESIGN IN INDUSTRIAL DIGITAL TRANSFORMATION
Introduction
Digital transformation has become a central strategy for traditional and industrial sectors seeking to improve operational efficiency, data visibility, service quality, organizational coordination, and strategic decision-making. In many industrial companies, this transformation is supported by Business-to-Business Software as a Service systems that organize internal management, sales operations, project delivery, customer service, resource planning, data reporting, workflow monitoring, and cross-departmental collaboration. Unlike consumer-facing digital products, however, industrial Business-to-Business Software as a Service products are embedded in complex organizational environments. Users are not a single homogeneous group, but a network of stakeholders that may include sales teams, operations staff, engineers, project managers, executives, clients, suppliers, service partners, and after-sales personnel.
This complexity creates a methodological challenge for user experience and product designers. Human-centered design emphasizes the importance of understanding users, tasks, environments, and interactive systems throughout the design process. However, conventional user research methods such as interviews, questionnaires, personas, usability testing, and customer journey maps may be insufficient when applied directly to industrial digital transformation contexts. In these settings, user needs are frequently implicit, fragmented, and distributed across multiple roles and business processes. A single user may not be able to clearly articulate the full requirement because the product problem is often located in the relationship between people, workflows, data systems, organizational rules, technical constraints, and decision structures.
In consumer user experience design, designers can often observe relatively direct interactions between users and interfaces. Users open an application, complete a task, encounter friction, and provide feedback about the experience. In industrial Business-to-Business Software as a Service design, the interface is only the visible layer of a deeper organizational system. A dashboard, approval process, reporting module, permission setting, or data-entry form may appear simple on screen, but it may represent a complicated chain of responsibility involving multiple departments and business goals. For this reason, product requirements in industrial Software as a Service environments cannot be fully understood through isolated user statements. They must be interpreted through the practical conditions in which work is performed.
Traditional user research often assumes that users can explain their goals and pain points when asked appropriate questions. This assumption becomes problematic in industrial environments because many users have normalized inefficient workarounds. Employees may not describe a spreadsheet as a problem because they have used it for years. Managers may not recognize that a reporting delay is caused by unclear data ownership. A salesperson may describe a customer problem without understanding how it relates to delivery operations. A technical team may focus on implementation feasibility without seeing the frontline user burden created by a feature. In such environments, user needs are not always spoken directly; they are embedded in routine, conflict, delay, repetition, and informal coordination.
This paper proposes an immersive user research approach for Business-to-Business Software as a Service product design in industrial digital transformation. The approach is informed by contextual design, participatory design, reflective practice, service design, and product innovation research. Rather than treating user research as a separate preliminary stage, the proposed method embeds the designer within real business activities, cross-functional communication, internal tool usage, workflow observation, and requirement negotiation.
The central research question is: how can product designers identify actionable user experience and product requirements for Business-to-Business Software as a Service systems when users, workflows, and decision-making structures are distributed across complex industrial organizations? To address this question, the paper develops a lightweight methodological framework based on reflective design practice in two industrial technology startup contexts. The framework supports designers who work with limited research resources but must still define product direction, system functions, interaction structures, information architecture, and user experience strategy.
The contribution of this paper is threefold. First, it identifies why conventional user experience research methods may be insufficient in industrial Business-to-Business Software as a Service contexts. Second, it proposes an immersive research framework that connects business context, stakeholder mapping, workflow tracing, breakdown identification, and requirement translation. Third, it explains how designers can convert fragmented industrial knowledge into actionable Software as a Service product requirements. The broader aim is to help user experience and product designers participate more effectively in industrial digital transformation, not only as interface designers but also as interpreters of organizational work.
Related Work
User experience and human-computer interaction research have long emphasized the importance of understanding users, contexts, tasks, and interaction environments. Human-centered design standards describe design as an iterative process concerned with making interactive systems more usable, useful, and appropriate to the context of use. In mainstream user experience practice, designers commonly use interviews, surveys, personas, customer journey maps, usability testing, prototyping, and analytics to understand user behavior and improve interaction quality. These methods are valuable and remain important. However, when they are transferred into industrial Business-to-Business Software as a Service contexts, their limitations become more visible.
The first limitation concerns the definition of the user. In consumer products, the user, customer, and decision-maker may often be the same person. In Business-to-Business Software as a Service, these roles are frequently separated. A daily user may operate the system, but a manager may define the requirement, a department head may approve the purchase, and a client organization may judge the final service quality. The product designer therefore needs to understand not only individual usability but also organizational value, process efficiency, data visibility, responsibility distribution, and decision control.
The second limitation concerns the visibility of work. In many industrial settings, important work is not fully visible through interface interaction. Employees may use spreadsheets, messaging tools, phone calls, verbal confirmation, paper documents, shared drives, personal notes, or informal routines to complete tasks. These unofficial workarounds may not appear in formal workflow documents, but they are often essential for understanding real user needs. Contextual design is relevant here because it argues that product definitions can be developed from data gathered while people perform real work. This suggests that designers must examine work as it actually happens rather than relying only on how organizations officially describe it.
The third limitation concerns requirement expression. Industrial users may not describe their needs in the language of digital products. Instead of saying that they need a role-based permission system, they may say that different teams should not see the same information. Instead of saying that they need workflow automation, they may say that they always forget to remind the next person. Instead of saying that they need data validation, they may say that the numbers are often inconsistent. Designers must translate everyday operational descriptions into product, system, and interaction requirements. This translation is not mechanical; it requires interpretation, synthesis, and judgment.
The fourth limitation concerns research access. In consumer user experience, designers can often recruit participants, conduct usability tests, or collect behavioral data. In industrial Business-to-Business contexts, access may be more restricted. Business processes may be confidential, users may be busy, and product teams may not have formal research budgets. Designers in startups may be expected to move quickly from problem discovery to interface design. This creates a need for flexible research methods that can operate within real project constraints.
Service design and service blueprinting provide useful foundations for this research. Service design highlights that user experience is shaped not only by visible touchpoints but also by backstage operational processes. This idea is highly relevant to Business-to-Business Software as a Service design. A Software as a Service interface may be the frontstage layer, while organizational coordination, data preparation, internal approval, and technical support form the backstage layer. If designers only focus on the screen, they may miss the operational system that makes the screen meaningful.
Participatory design further emphasizes that people affected by a system should be involved in its design. In industrial Software as a Service design, this principle is especially important because each stakeholder sees only part of the whole system. Frontline users understand daily pain points, managers understand control and reporting needs, technical teams understand feasibility, and business teams understand customer value. Product designers must synthesize these partial perspectives into coherent product decisions. However, participatory design in early-stage industrial startups may not always take the form of formal workshops. It may happen through meetings, prototype discussions, workflow reviews, and ongoing negotiation.
Reflective practice also supports this study’s methodological position. Professionals often think through action, reflection, and situated problem-solving rather than only through formal theory. This is particularly relevant to product designers in early-stage startups, where methods must be adapted quickly to uncertain business contexts. In such environments, research is not always conducted as a separate academic process. Instead, knowledge emerges through meetings, observations, prototypes, internal debates, user feedback, and iterative design decisions.
Recent product innovation research also demonstrates the importance of connecting user requirements with functional and system-level analysis. User-driven product innovation methods argue that user requirements should not only guide the beginning of design, but should remain connected to functional structures and system behavior throughout the design process. This paper adapts a similar logic to industrial Software as a Service by connecting user needs with workflow structures, data flows, decision flows, and organizational constraints.
Digital transformation literature also suggests that transformation is not merely a technical change. Digital transformation involves organizational responses, new value creation processes, and changes in business structure. These perspectives support the argument that Business-to-Business Software as a Service design in industrial sectors should not be treated as interface design alone. It is also a process of redesigning how work, information, and decisions are organized.
From a design synthesis perspective, designers often make sense of complex, ambiguous information through abductive reasoning and synthesis. This is highly relevant to the present study. In industrial Business-to-Business Software as a Service design, the designer is often faced with scattered information from different departments, partial explanations, inconsistent documents, and competing priorities. The challenge is not only to collect data but also to synthesize it into a meaningful product direction. Immersive user research therefore combines observation with interpretation.
Overall, the literature suggests that a useful user experience research approach for industrial Business-to-Business Software as a Service should meet several conditions. It should study work in context. It should involve multiple stakeholders. It should account for backstage processes. It should connect user needs with organizational structures. It should support design synthesis under uncertainty. Finally, it should be practical enough for early-stage companies with limited research resources. The immersive user research framework proposed in this paper responds to these needs.
Methodology
This study uses a reflective practice-based methodology. The research is based on design experience in two industrial technology startup contexts where the designer participated in Business-to-Business Software as a Service product development during digital transformation processes. The purpose was not to conduct a controlled experiment or large-scale statistical analysis. Instead, the aim was to extract and structure a practical design method from real product design situations.
Reflective practice is suitable for this study because the research question concerns how designers identify requirements in complex industrial environments. The designer’s role was not external to the process. Instead, the designer participated in product planning, internal communication, user research, interface design, workflow definition, prototype development, and cross-functional collaboration. This position allowed the designer to observe how requirements emerged, changed, and were negotiated across business roles.
The study treats the two startup contexts as reflective case materials. They are not presented as controlled comparative cases, but as practical environments from which recurring design problems and methodological insights were identified. In both contexts, the designer worked in conditions common to early-stage industrial technology companies: limited research resources, fast product iteration, unclear product boundaries, multiple stakeholder groups, and a need to translate traditional business processes into digital systems.
The first context involved a startup developing digital tools for an industrial service environment. The product challenge was not simply to design a usable interface, but to clarify how different teams understood work progress, customer status, project delivery, and operational responsibility. Requirements came from multiple internal stakeholders, and many of them were expressed as business frustrations rather than clear product requests. For example, users described delayed communication, repeated manual updates, inconsistent information, and difficulty tracking project status.
The second context involved a startup building internal and client-facing digital systems for industrial operations. In this environment, requirements were distributed across business development, technical delivery, operations, and management. Different roles had different priorities. Sales teams needed customer-facing clarity, operations teams needed task visibility, managers needed data summaries, and technical teams needed structured information. The main design challenge was to transform a fragmented workflow into a coherent Software as a Service structure.
The research process included five main activities. First, business context immersion was conducted. This involved participating in internal meetings, understanding company operations, observing communication among departments, and learning the terminology, constraints, and priorities of the industry context. The purpose was to understand the environment in which the Software as a Service product would operate.
Second, workflow observation was used to identify how tasks were actually performed. Instead of only asking users to describe their needs, the designer observed how sales, operations, delivery, management, and technical teams used existing tools, spreadsheets, communication platforms, and informal workarounds. This helped reveal gaps between official processes and actual practice.
Third, stakeholder mapping was conducted. Stakeholders were mapped according to their responsibilities, goals, pain points, data inputs, data outputs, and decision points. This process helped transform scattered observations into a structured understanding of the product ecosystem.
Fourth, breakdown analysis was performed. Breakdowns were identified where work slowed down, information became inconsistent, responsibilities became unclear, or users had to rely on manual compensation. These breakdowns were treated as potential sources of product requirements.
Fifth, requirement translation was conducted. Observed problems were translated into potential Software as a Service product requirements, including functional modules, role permissions, information architecture, dashboard logic, workflow automation, notification mechanisms, data validation rules, and interface interactions.
Because this paper is based on reflective practice, its findings are qualitative and interpretive. The contribution is not a universal predictive model, but a practical methodological framework that other designers can adapt to similar Business-to-Business Software as a Service and industrial digital transformation contexts.
Case Contexts
The two design contexts shared several characteristics. Both involved industrial technology companies attempting to convert traditional business activities into digital systems. Both operated in fast-changing startup environments where product definitions were incomplete. Both required the designer to communicate with business, operations, technical, and management stakeholders. Both involved digital products that were expected to support not only individual task completion but also organizational coordination.
In the first context, the product team needed to support internal project tracking and service delivery. Users expressed frustration with duplicated communication, unclear project status, and inconsistent information across tools. At first, these appeared to be simple usability or information display problems. However, immersive observation revealed that the deeper issue was workflow fragmentation. Different departments maintained different versions of the same project information. Some updates existed only in chat messages. Some decisions were made in meetings but not recorded in a shared system. Some employees relied on personal memory to follow up tasks. Therefore, the design problem was not merely how to display project status, but how to create a shared operational structure that makes project status reliable, visible, and actionable.
In the second context, the product team needed to design a system that supported operational data, task coordination, and management visibility. Stakeholders had different expectations. Managers wanted high-level dashboards, operations staff wanted simple task tools, technical teams wanted structured data, and business teams wanted customer-facing clarity. Direct interviews generated a long list of feature requests, but the requests were inconsistent. Immersive research helped reveal the underlying pattern: stakeholders were describing different parts of the same data and workflow system. This led to a design focus on defining entities, relationships, permissions, and workflow states before designing detailed screens.
Across both contexts, several common patterns appeared. First, users often did not know how to describe the system they needed. They could describe pain points, but not product architecture. Second, the most important requirements were often hidden in handoffs between roles. Third, existing workarounds, such as spreadsheets or chat-based coordination, revealed important unmet needs. Fourth, management requirements and frontline requirements were sometimes misaligned. Fifth, product decisions required balancing usability, business value, technical feasibility, and organizational discipline.
These patterns shaped the development of the proposed immersive user research framework. The framework was created to help designers move from scattered observations toward structured product decisions. It emphasizes that in industrial Business-to-Business Software as a Service design, a requirement should not be understood only as a user request. It should also be understood as evidence of a relationship among roles, data, workflow, responsibility, and organizational value.
Proposed Framework
The proposed immersive user research framework consists of five stages: entering the business context, mapping stakeholders, tracing workflows, identifying breakdowns, and translating insights into product requirements.
The first stage is entering the business context. Designers must understand the industry environment before defining product features. This includes learning basic business terminology, common operational procedures, company goals, customer types, service models, and technical constraints. In industrial digital transformation, many product problems cannot be understood from interface behavior alone. They are shaped by how the company operates. Designers should therefore ask not only what the user needs on a screen, but why the task exists, who depends on its result, what business consequence occurs if it fails, and what organizational rule shapes the behavior.
This stage requires designers to temporarily suspend the impulse to produce immediate interface solutions. Instead, the designer should build a contextual understanding of the organization. In practice, this may include reading internal documents, attending meetings, reviewing existing tools, observing team communication, and asking stakeholders to explain business logic. The goal is not to become an industry expert, but to understand enough of the business environment to interpret user behavior accurately.
The second stage is mapping stakeholders. Business-to-Business Software as a Service users are usually distributed across multiple departments and organizational levels. A designer should identify daily users, occasional users, decision-makers, managers, clients, technical teams, and external partners. Each stakeholder may have different goals and different definitions of product value. For example, an operations employee may value reduced manual work, while a manager may value visibility and control. A client may value transparency and response speed. Mapping these differences helps prevent the designer from over-optimizing for only one group.
Stakeholder mapping should include more than job titles. It should also identify what each stakeholder contributes to the workflow, what information they need, what decisions they make, what tools they use, and what risks they experience. In industrial Software as a Service, a role may be powerful not because it uses the system frequently, but because it controls data quality or decision approval. Designers should therefore consider both frequency of use and structural importance.
The third stage is tracing workflows. Designers should follow how a task moves from beginning to end across people, tools, and systems. This includes identifying where data is created, where it is transferred, who approves it, who modifies it, who depends on it, and where delays or errors occur. Workflow tracing reveals problems that may not appear in direct interviews. Users may normalize inefficient processes and fail to describe them as problems. By observing the workflow directly, designers can identify hidden friction points.
Workflow tracing can be organized around several questions. What triggers the workflow? What is the first action? Which role performs it? What information is required? What tool is used? What happens next? Where does the information go? Who checks it? What happens if something is wrong? Where does the workflow end? These questions help designers convert vague descriptions into process-level understanding.
The fourth stage is identifying breakdowns. Breakdowns may include information gaps, repeated manual entry, unclear responsibility, delayed approval, inconsistent data formats, fragmented communication, hidden dependencies, or lack of feedback. These breakdowns are important because they often become the real source of Software as a Service product requirements. A requirement is not only a user request; it can also be a symptom of a workflow failure.
Breakdowns can be classified into several types. Information breakdowns occur when the right information is unavailable, outdated, inconsistent, or difficult to find. Responsibility breakdowns occur when users are unclear about who should take the next action. Coordination breakdowns occur when tasks require multiple roles but communication is not supported by the system. Decision breakdowns occur when managers or users cannot understand status, priority, or risk. Data breakdowns occur when data is duplicated, incomplete, or unreliable. Experience breakdowns occur when the interface creates unnecessary cognitive or operational burden.
The fifth stage is translating insights into product requirements. The designer must convert observations into designable elements. A workflow breakdown may become a new dashboard, an automated reminder, a permission setting, a data validation rule, a task status system, or a redesigned information architecture. This translation requires balancing user needs, business objectives, technical feasibility, and organizational constraints.
Translation is the most important stage because it connects research with design action. Designers should avoid copying user requests directly into feature lists. Instead, they should ask what underlying problem the request represents. For example, a request for export functions may indicate a need for reporting flexibility, lack of trust in the system, or the absence of a shared dashboard. A request for more notifications may indicate unclear responsibility or poor workflow visibility. A request for simpler forms may indicate excessive data requirements or poor information hierarchy. By interpreting requests in relation to workflow context, designers can propose better product solutions.
Research Method in Practice
In practice, immersive user research begins before formal user interviews. The designer first collects contextual information about the organization, including its business model, team structure, major workflows, customer relationships, and existing tools. This early stage helps the designer avoid asking questions that are too generic or disconnected from the business situation.
After the initial context learning, the designer identifies key roles. In industrial Business-to-Business Software as a Service, these roles may include business development, operations, engineering, project delivery, finance, customer success, management, and external clients. The designer then observes how these roles communicate and exchange information. Attention is paid to the tools they use, the documents they create, the meetings they attend, and the problems they repeatedly mention.
The next step is workflow shadowing. This does not necessarily require formal ethnography. In an early-stage company, it may involve joining internal meetings, reviewing message threads, observing how spreadsheets are used, asking employees to walk through a task, or following the lifecycle of a customer request. The goal is to understand the movement of work.
After collecting observations, the designer organizes insights into maps. These maps may include stakeholder maps, workflow maps, data-flow maps, decision-flow maps, and pain-point maps. The purpose is not to produce perfect documentation, but to make invisible relationships visible. Once visualized, the designer can identify where product intervention is most valuable.
Finally, the designer translates research insights into product language. For example, if multiple teams repeatedly ask each other for the latest project status, the product opportunity may be a shared project dashboard. If users often forget to update the next responsible person, the opportunity may be workflow automation or task notification. If managers distrust data accuracy, the opportunity may be validation rules, audit logs, or standardized data-entry structures. If different departments use different terms for the same thing, the opportunity may be improved information architecture and terminology standardization.
The practical value of this method lies in its ability to connect small observations with larger product decisions. A single complaint may not be meaningful by itself. However, when similar complaints appear across roles and workflows, they may reveal a structural product opportunity. Immersive research helps designers notice these patterns because they remain close to the work environment over time.
Analytical Dimensions
The proposed method can be further understood through four analytical dimensions: role, workflow, data, and decision.
The role dimension concerns who participates in the system. In Business-to-Business Software as a Service, roles define not only access but also responsibility, authority, and perspective. A designer should ask what each role needs to see, what each role needs to do, and what each role should not be able to change. Role analysis supports permission design, dashboard personalization, notification logic, and task assignment.
The workflow dimension concerns how work moves. A workflow may include task creation, assignment, action, review, approval, reporting, and closure. Designers should identify where the workflow is linear, where it branches, where it loops back, and where exceptions occur. Workflow analysis supports navigation design, status design, process automation, and error handling.
The data dimension concerns what information is created, transferred, modified, and trusted. Data may include customer information, project status, technical parameters, financial values, operational metrics, documents, comments, and audit records. Designers should identify data sources, data owners, data dependencies, and data quality risks. Data analysis supports form design, validation rules, database logic, reporting systems, and dashboard design.
The decision dimension concerns how people judge, approve, prioritize, and act. Decisions may be made by individuals, teams, managers, or clients. Some decisions are formal, while others are informal. Some are based on data, while others rely on experience. Decision analysis supports approval flows, recommendation systems, risk indicators, and management dashboards.
These four dimensions help designers avoid reducing user experience research to preference collection. They also help transform qualitative observations into structured product requirements. For example, if a designer observes that project updates are delayed, the role dimension asks who is responsible for the update; the workflow dimension asks when the update should happen; the data dimension asks what information must be updated; and the decision dimension asks who uses that update to make decisions. Together, these dimensions produce a more complete understanding of the design problem.
Findings
The reflective analysis suggests that immersive user research provides several advantages in industrial Business-to-Business Software as a Service design.
First, it reveals implicit requirements. In traditional industries, users may not always express needs in digital product language. They may describe problems as delays, miscommunication, repeated work, reporting pressure, customer complaints, or management uncertainty. Immersive observation helps designers translate these practical expressions into product opportunities.
Second, it exposes differences between formal process and actual practice. Companies may have official workflows, but employees often rely on informal methods such as spreadsheets, chat messages, personal notes, manual reminders, or verbal confirmation. These informal practices are valuable research material because they reveal what the existing system fails to support.
Third, it helps designers understand multi-role conflicts. A feature that helps one role may create additional work for another. For example, a management dashboard may require frontline employees to enter more structured data. An automated workflow may increase efficiency but reduce flexibility. Immersive research allows designers to identify these tensions before finalizing product requirements.
Fourth, it improves requirement prioritization. In industrial Software as a Service contexts, there may be many competing requests. By understanding workflow dependencies, designers can distinguish between surface-level feature requests and core process problems. This helps teams prioritize features that solve systemic issues rather than isolated complaints.
Fifth, it strengthens communication between design, business, and development teams. When designers can explain requirements through workflow evidence, role relationships, and operational consequences, product discussions become more concrete. This reduces the risk of designing features based only on assumptions or individual opinions.
Sixth, it supports better information architecture. In industrial Software as a Service products, information architecture is often shaped by business logic rather than simple content categories. Designers must decide how entities such as customers, projects, orders, assets, tasks, reports, and users relate to one another. Immersive research helps reveal these relationships.
Seventh, it helps designers identify data quality problems. Many Software as a Service features depend on accurate and consistent data. However, in traditional organizations, data may be incomplete, duplicated, delayed, or stored across disconnected tools. By tracing data flows, designers can identify where data problems originate and design mechanisms to reduce them.
Eighth, it helps early-stage teams reduce product uncertainty. Startups often lack mature product documentation. Immersive research allows designers to build product understanding while the organization itself is still defining its processes. This makes the method useful for ambiguous product environments.
Ninth, it reveals the relationship between internal efficiency and customer experience. In Business-to-Business Software as a Service contexts, customer experience is often shaped by internal operations. A client may experience slow response not because the client-facing interface is poor, but because internal teams lack shared status visibility. Therefore, improving internal workflow may improve external service quality.
Tenth, it helps designers identify which requirements should become system rules and which should remain flexible. Industrial users often request flexibility because their work contains exceptions. However, too much flexibility can create inconsistent data and management difficulty. Immersive research helps designers understand where standardization is necessary and where flexibility should be preserved.
Discussion
The proposed approach expands the meaning of user research in Business-to-Business Software as a Service design. In consumer product design, user experience research often focuses on user behavior, preference, satisfaction, and usability. In industrial Software as a Service design, user experience research must also investigate organizational structure, workflow logic, data movement, and decision-making patterns. The designer is not only studying users, but also studying the system in which users work.
This shift has theoretical and practical implications. Theoretically, it suggests that user experience methods should be adapted for non-consumer and organizational contexts. The unit of analysis should not always be the individual user. In Business-to-Business Software as a Service, the unit of analysis may be a workflow, a role network, a data dependency, or a decision process. Practically, it provides designers with a feasible approach when formal research resources are limited.
The framework also highlights the value of immersion as a design capability. Immersion does not simply mean spending more time with users. It means actively learning the business context, observing real work, recognizing hidden constraints, and translating complex organizational knowledge into design decisions. This requires designers to develop sensitivity to both human experience and operational systems.
Another implication concerns the role of the designer in industrial organizations. In many early-stage companies, the designer is not only responsible for interface design. The designer may also participate in product strategy, requirement definition, workflow modeling, and communication between business and technical teams. The immersive method recognizes this expanded role. It provides a way for designers to make sense of unclear requirements and contribute to product direction.
The method also challenges a narrow understanding of usability. In industrial Business-to-Business Software as a Service, usability cannot be measured only by whether an individual user can complete a task quickly. A system may be easy for one person but harmful to the broader workflow if it produces poor data, hides responsibility, or creates extra work for another team. Therefore, user experience quality should be evaluated at both individual and organizational levels.
This paper also suggests that requirement discovery should be treated as an ongoing process. In fast-changing industrial startups, requirements are rarely stable. Business models evolve, teams change, customers request new capabilities, and internal processes become more formal over time. Immersive research supports continuous learning because the designer remains connected to the changing work environment.
The proposed approach also has implications for design education. Many user experience design courses teach interviews, personas, journey maps, and usability testing as core methods. These methods remain useful, but industrial Software as a Service design requires additional capabilities: understanding organizational systems, mapping workflows, interpreting data dependencies, and negotiating among stakeholders. Designers entering Business-to-Business or industrial contexts may need to develop business literacy and systems thinking in addition to interface design skills.
The approach further suggests that design deliverables should be expanded. In consumer user experience, common deliverables include wireframes, prototypes, personas, and usability reports. In industrial Software as a Service, useful deliverables may also include stakeholder maps, workflow maps, entity relationship diagrams, permission matrices, data-flow diagrams, and decision maps. These artifacts help communicate complex requirements to product managers, developers, executives, and users.
Practical Design Guidelines
Based on the proposed framework, several practical guidelines can be offered for product designers working in industrial Business-to-Business Software as a Service contexts.
First, begin with the business process rather than the interface. Before designing screens, designers should understand what business activity the product supports. A visually polished interface cannot solve a poorly understood workflow.
Second, identify all stakeholder groups early. Designers should distinguish between daily users, managers, buyers, clients, technical teams, and external partners. Each group may define success differently.
Third, observe workarounds carefully. Spreadsheets, chat messages, manual reminders, and informal documents are not signs of poor user behavior. They are evidence of unmet system needs.
Fourth, map data movement. Many industrial Software as a Service problems come from unclear data ownership, duplicated entry, delayed updates, or inconsistent formats. Designers should ask where data comes from, who changes it, and who trusts it.
Fifth, treat conflict as research material. If departments disagree about a feature, the disagreement may reveal deeper tensions between efficiency, control, flexibility, and accountability.
Sixth, translate pain points into system requirements. A complaint such as messy communication is not yet a design requirement. It must be translated into more specific opportunities, such as task assignment, status visibility, notification rules, shared records, or approval workflows.
Seventh, validate concepts through workflow scenarios. Instead of only asking whether users like a design, designers should test whether the design supports the real sequence of work across roles.
Eighth, document assumptions. In fast-moving startup environments, many product decisions are based on incomplete information. Designers should clearly record what is known, what is assumed, and what needs later validation.
Ninth, distinguish between user preference and operational necessity. Some users may prefer familiar tools even when those tools create organizational inefficiency. Designers must balance individual comfort with broader workflow improvement.
Tenth, design for exceptions. Industrial workflows often contain unusual cases, urgent changes, missing data, or special approvals. A system that only supports the ideal process may fail in real use.
Eleventh, make responsibility visible. Many workflow problems occur because users do not know who owns the next action. Clear ownership, status, and accountability can improve both usability and coordination.
Twelfth, use prototypes as research tools. In complex Business-to-Business environments, stakeholders may not fully understand abstract product descriptions. Prototypes help make assumptions visible and encourage more concrete feedback.
Limitations
This research has several limitations. First, it is based on reflective design practice rather than a controlled empirical study. The findings are therefore interpretive and context-dependent. They should be understood as a practical framework rather than a statistically validated model.
Second, the study is based on two industrial technology startup contexts. Although the patterns identified may apply to similar Business-to-Business Software as a Service environments, further research is needed across larger companies, different industries, and more mature organizations.
Third, immersive research depends on access. Designers may not always be allowed to observe internal meetings, client communication, operational tools, or strategic discussions. Without sufficient access, the method may be difficult to apply fully.
Fourth, the designer’s embedded position can create bias. Immersion helps designers understand context, but it may also make them too familiar with internal assumptions. To reduce this risk, designers should combine immersion with periodic external review, user validation, and cross-functional critique.
Fifth, the method may be difficult for teams that expect user experience research to produce quick and simple answers. Immersive research often reveals complexity rather than reducing it immediately. Teams must be willing to treat complexity as useful design knowledge.
Sixth, the paper does not provide quantitative evidence of product performance improvement. Future studies could measure outcomes such as reduced task time, improved data accuracy, higher adoption rates, or lower communication overhead after applying the framework.
Seventh, the method may be more suitable for designers who have cross-functional access. Designers limited to visual interface production may find it difficult to conduct full immersion. Organizational support is therefore important.
Future Research
Future research could develop this framework in several directions. First, the method could be tested across different industrial sectors, such as manufacturing, logistics, energy, healthcare operations, construction, agriculture, and enterprise services. This would help identify which parts of the framework are generalizable and which need industry-specific adaptation.
Second, future studies could compare immersive research with conventional interview-based research in Business-to-Business Software as a Service projects. Such comparison could examine whether immersive methods produce more accurate requirements, reduce redesign, or improve stakeholder alignment.
Third, the framework could be combined with visual modeling tools such as service blueprints, system maps, data-flow diagrams, and journey maps. This would allow designers to represent industrial complexity more clearly and communicate insights to non-design stakeholders.
Fourth, future research could develop evaluation criteria for industrial Software as a Service user experience. Instead of measuring only task completion or satisfaction, evaluation could include workflow continuity, data accuracy, role coordination, decision visibility, and organizational adoption.
Fifth, the approach could be extended to artificial intelligence-assisted Business-to-Business Software as a Service systems. As industrial companies adopt artificial intelligence tools for prediction, automation, and decision support, designers will need to understand not only user needs but also data readiness, trust, explainability, and human oversight.
Sixth, future research could examine how immersive user research changes the designer’s role in organizations. Designers may increasingly act as translators between business, technology, and human experience. This expanded role deserves further study.
Seventh, future work could develop templates and toolkits for applying the framework. These may include stakeholder mapping templates, workflow tracing forms, breakdown classification tables, and requirement translation worksheets.
Conclusion
This paper proposed an immersive user research approach for Business-to-Business Software as a Service design in industrial digital transformation. The study argued that conventional user experience research methods are useful but often insufficient in traditional and industrial contexts because user needs are embedded in complex workflows, role relationships, data dependencies, and organizational constraints.
Based on reflective design practice in two industrial technology startup contexts, the paper presented a five-stage framework: entering the business context, mapping stakeholders, tracing workflows, identifying breakdowns, and translating insights into product requirements. This framework helps designers move beyond isolated interviews and understand how real work is performed across departments and systems.
The main contribution of this research is a practical and lightweight method for product designers working in early-stage industrial Software as a Service environments. It supports requirement discovery, product definition, and user experience strategy by reframing user experience research as immersive organizational and workflow inquiry. For designers working in non-consumer digital products, this approach can improve the accuracy of requirements, reduce misalignment between business goals and user needs, and support more effective product innovation in industrial digital transformation.
The broader implication is that user experience design in industrial digital transformation should not be limited to interface improvement. It should participate in understanding and reshaping the relationships among people, processes, data, and decisions. In this sense, immersive user research can help bridge the gap between traditional industry knowledge and digital product innovation.
Acknowledgments
Not applicable.
Appendix
No supplementary materials are included in this submission.
Introduction
Digital transformation has become a central strategy for traditional and industrial sectors seeking to improve operational efficiency, data visibility, service quality, organizational coordination, and strategic decision-making. In many industrial companies, this transformation is supported by Business-to-Business Software as a Service systems that organize internal management, sales operations, project delivery, customer service, resource planning, data reporting, workflow monitoring, and cross-departmental collaboration. Unlike consumer-facing digital products, however, industrial Business-to-Business Software as a Service products are embedded in complex organizational environments. Users are not a single homogeneous group, but a network of stakeholders that may include sales teams, operations staff, engineers, project managers, executives, clients, suppliers, service partners, and after-sales personnel.
This complexity creates a methodological challenge for user experience and product designers. Human-centered design emphasizes the importance of understanding users, tasks, environments, and interactive systems throughout the design process. However, conventional user research methods such as interviews, questionnaires, personas, usability testing, and customer journey maps may be insufficient when applied directly to industrial digital transformation contexts. In these settings, user needs are frequently implicit, fragmented, and distributed across multiple roles and business processes. A single user may not be able to clearly articulate the full requirement because the product problem is often located in the relationship between people, workflows, data systems, organizational rules, technical constraints, and decision structures.
In consumer user experience design, designers can often observe relatively direct interactions between users and interfaces. Users open an application, complete a task, encounter friction, and provide feedback about the experience. In industrial Business-to-Business Software as a Service design, the interface is only the visible layer of a deeper organizational system. A dashboard, approval process, reporting module, permission setting, or data-entry form may appear simple on screen, but it may represent a complicated chain of responsibility involving multiple departments and business goals. For this reason, product requirements in industrial Software as a Service environments cannot be fully understood through isolated user statements. They must be interpreted through the practical conditions in which work is performed.
Traditional user research often assumes that users can explain their goals and pain points when asked appropriate questions. This assumption becomes problematic in industrial environments because many users have normalized inefficient workarounds. Employees may not describe a spreadsheet as a problem because they have used it for years. Managers may not recognize that a reporting delay is caused by unclear data ownership. A salesperson may describe a customer problem without understanding how it relates to delivery operations. A technical team may focus on implementation feasibility without seeing the frontline user burden created by a feature. In such environments, user needs are not always spoken directly; they are embedded in routine, conflict, delay, repetition, and informal coordination.
This paper proposes an immersive user research approach for Business-to-Business Software as a Service product design in industrial digital transformation. The approach is informed by contextual design, participatory design, reflective practice, service design, and product innovation research. Rather than treating user research as a separate preliminary stage, the proposed method embeds the designer within real business activities, cross-functional communication, internal tool usage, workflow observation, and requirement negotiation.
The central research question is: how can product designers identify actionable user experience and product requirements for Business-to-Business Software as a Service systems when users, workflows, and decision-making structures are distributed across complex industrial organizations? To address this question, the paper develops a lightweight methodological framework based on reflective design practice in two industrial technology startup contexts. The framework supports designers who work with limited research resources but must still define product direction, system functions, interaction structures, information architecture, and user experience strategy.
The contribution of this paper is threefold. First, it identifies why conventional user experience research methods may be insufficient in industrial Business-to-Business Software as a Service contexts. Second, it proposes an immersive research framework that connects business context, stakeholder mapping, workflow tracing, breakdown identification, and requirement translation. Third, it explains how designers can convert fragmented industrial knowledge into actionable Software as a Service product requirements. The broader aim is to help user experience and product designers participate more effectively in industrial digital transformation, not only as interface designers but also as interpreters of organizational work.
Related Work
User experience and human-computer interaction research have long emphasized the importance of understanding users, contexts, tasks, and interaction environments. Human-centered design standards describe design as an iterative process concerned with making interactive systems more usable, useful, and appropriate to the context of use. In mainstream user experience practice, designers commonly use interviews, surveys, personas, customer journey maps, usability testing, prototyping, and analytics to understand user behavior and improve interaction quality. These methods are valuable and remain important. However, when they are transferred into industrial Business-to-Business Software as a Service contexts, their limitations become more visible.
The first limitation concerns the definition of the user. In consumer products, the user, customer, and decision-maker may often be the same person. In Business-to-Business Software as a Service, these roles are frequently separated. A daily user may operate the system, but a manager may define the requirement, a department head may approve the purchase, and a client organization may judge the final service quality. The product designer therefore needs to understand not only individual usability but also organizational value, process efficiency, data visibility, responsibility distribution, and decision control.
The second limitation concerns the visibility of work. In many industrial settings, important work is not fully visible through interface interaction. Employees may use spreadsheets, messaging tools, phone calls, verbal confirmation, paper documents, shared drives, personal notes, or informal routines to complete tasks. These unofficial workarounds may not appear in formal workflow documents, but they are often essential for understanding real user needs. Contextual design is relevant here because it argues that product definitions can be developed from data gathered while people perform real work. This suggests that designers must examine work as it actually happens rather than relying only on how organizations officially describe it.
The third limitation concerns requirement expression. Industrial users may not describe their needs in the language of digital products. Instead of saying that they need a role-based permission system, they may say that different teams should not see the same information. Instead of saying that they need workflow automation, they may say that they always forget to remind the next person. Instead of saying that they need data validation, they may say that the numbers are often inconsistent. Designers must translate everyday operational descriptions into product, system, and interaction requirements. This translation is not mechanical; it requires interpretation, synthesis, and judgment.
The fourth limitation concerns research access. In consumer user experience, designers can often recruit participants, conduct usability tests, or collect behavioral data. In industrial Business-to-Business contexts, access may be more restricted. Business processes may be confidential, users may be busy, and product teams may not have formal research budgets. Designers in startups may be expected to move quickly from problem discovery to interface design. This creates a need for flexible research methods that can operate within real project constraints.
Service design and service blueprinting provide useful foundations for this research. Service design highlights that user experience is shaped not only by visible touchpoints but also by backstage operational processes. This idea is highly relevant to Business-to-Business Software as a Service design. A Software as a Service interface may be the frontstage layer, while organizational coordination, data preparation, internal approval, and technical support form the backstage layer. If designers only focus on the screen, they may miss the operational system that makes the screen meaningful.
Participatory design further emphasizes that people affected by a system should be involved in its design. In industrial Software as a Service design, this principle is especially important because each stakeholder sees only part of the whole system. Frontline users understand daily pain points, managers understand control and reporting needs, technical teams understand feasibility, and business teams understand customer value. Product designers must synthesize these partial perspectives into coherent product decisions. However, participatory design in early-stage industrial startups may not always take the form of formal workshops. It may happen through meetings, prototype discussions, workflow reviews, and ongoing negotiation.
Reflective practice also supports this study’s methodological position. Professionals often think through action, reflection, and situated problem-solving rather than only through formal theory. This is particularly relevant to product designers in early-stage startups, where methods must be adapted quickly to uncertain business contexts. In such environments, research is not always conducted as a separate academic process. Instead, knowledge emerges through meetings, observations, prototypes, internal debates, user feedback, and iterative design decisions.
Recent product innovation research also demonstrates the importance of connecting user requirements with functional and system-level analysis. User-driven product innovation methods argue that user requirements should not only guide the beginning of design, but should remain connected to functional structures and system behavior throughout the design process. This paper adapts a similar logic to industrial Software as a Service by connecting user needs with workflow structures, data flows, decision flows, and organizational constraints.
Digital transformation literature also suggests that transformation is not merely a technical change. Digital transformation involves organizational responses, new value creation processes, and changes in business structure. These perspectives support the argument that Business-to-Business Software as a Service design in industrial sectors should not be treated as interface design alone. It is also a process of redesigning how work, information, and decisions are organized.
From a design synthesis perspective, designers often make sense of complex, ambiguous information through abductive reasoning and synthesis. This is highly relevant to the present study. In industrial Business-to-Business Software as a Service design, the designer is often faced with scattered information from different departments, partial explanations, inconsistent documents, and competing priorities. The challenge is not only to collect data but also to synthesize it into a meaningful product direction. Immersive user research therefore combines observation with interpretation.
Overall, the literature suggests that a useful user experience research approach for industrial Business-to-Business Software as a Service should meet several conditions. It should study work in context. It should involve multiple stakeholders. It should account for backstage processes. It should connect user needs with organizational structures. It should support design synthesis under uncertainty. Finally, it should be practical enough for early-stage companies with limited research resources. The immersive user research framework proposed in this paper responds to these needs.
Methodology
This study uses a reflective practice-based methodology. The research is based on design experience in two industrial technology startup contexts where the designer participated in Business-to-Business Software as a Service product development during digital transformation processes. The purpose was not to conduct a controlled experiment or large-scale statistical analysis. Instead, the aim was to extract and structure a practical design method from real product design situations.
Reflective practice is suitable for this study because the research question concerns how designers identify requirements in complex industrial environments. The designer’s role was not external to the process. Instead, the designer participated in product planning, internal communication, user research, interface design, workflow definition, prototype development, and cross-functional collaboration. This position allowed the designer to observe how requirements emerged, changed, and were negotiated across business roles.
The study treats the two startup contexts as reflective case materials. They are not presented as controlled comparative cases, but as practical environments from which recurring design problems and methodological insights were identified. In both contexts, the designer worked in conditions common to early-stage industrial technology companies: limited research resources, fast product iteration, unclear product boundaries, multiple stakeholder groups, and a need to translate traditional business processes into digital systems.
The first context involved a startup developing digital tools for an industrial service environment. The product challenge was not simply to design a usable interface, but to clarify how different teams understood work progress, customer status, project delivery, and operational responsibility. Requirements came from multiple internal stakeholders, and many of them were expressed as business frustrations rather than clear product requests. For example, users described delayed communication, repeated manual updates, inconsistent information, and difficulty tracking project status.
The second context involved a startup building internal and client-facing digital systems for industrial operations. In this environment, requirements were distributed across business development, technical delivery, operations, and management. Different roles had different priorities. Sales teams needed customer-facing clarity, operations teams needed task visibility, managers needed data summaries, and technical teams needed structured information. The main design challenge was to transform a fragmented workflow into a coherent Software as a Service structure.
The research process included five main activities. First, business context immersion was conducted. This involved participating in internal meetings, understanding company operations, observing communication among departments, and learning the terminology, constraints, and priorities of the industry context. The purpose was to understand the environment in which the Software as a Service product would operate.
Second, workflow observation was used to identify how tasks were actually performed. Instead of only asking users to describe their needs, the designer observed how sales, operations, delivery, management, and technical teams used existing tools, spreadsheets, communication platforms, and informal workarounds. This helped reveal gaps between official processes and actual practice.
Third, stakeholder mapping was conducted. Stakeholders were mapped according to their responsibilities, goals, pain points, data inputs, data outputs, and decision points. This process helped transform scattered observations into a structured understanding of the product ecosystem.
Fourth, breakdown analysis was performed. Breakdowns were identified where work slowed down, information became inconsistent, responsibilities became unclear, or users had to rely on manual compensation. These breakdowns were treated as potential sources of product requirements.
Fifth, requirement translation was conducted. Observed problems were translated into potential Software as a Service product requirements, including functional modules, role permissions, information architecture, dashboard logic, workflow automation, notification mechanisms, data validation rules, and interface interactions.
Because this paper is based on reflective practice, its findings are qualitative and interpretive. The contribution is not a universal predictive model, but a practical methodological framework that other designers can adapt to similar Business-to-Business Software as a Service and industrial digital transformation contexts.
Case Contexts
The two design contexts shared several characteristics. Both involved industrial technology companies attempting to convert traditional business activities into digital systems. Both operated in fast-changing startup environments where product definitions were incomplete. Both required the designer to communicate with business, operations, technical, and management stakeholders. Both involved digital products that were expected to support not only individual task completion but also organizational coordination.
In the first context, the product team needed to support internal project tracking and service delivery. Users expressed frustration with duplicated communication, unclear project status, and inconsistent information across tools. At first, these appeared to be simple usability or information display problems. However, immersive observation revealed that the deeper issue was workflow fragmentation. Different departments maintained different versions of the same project information. Some updates existed only in chat messages. Some decisions were made in meetings but not recorded in a shared system. Some employees relied on personal memory to follow up tasks. Therefore, the design problem was not merely how to display project status, but how to create a shared operational structure that makes project status reliable, visible, and actionable.
In the second context, the product team needed to design a system that supported operational data, task coordination, and management visibility. Stakeholders had different expectations. Managers wanted high-level dashboards, operations staff wanted simple task tools, technical teams wanted structured data, and business teams wanted customer-facing clarity. Direct interviews generated a long list of feature requests, but the requests were inconsistent. Immersive research helped reveal the underlying pattern: stakeholders were describing different parts of the same data and workflow system. This led to a design focus on defining entities, relationships, permissions, and workflow states before designing detailed screens.
Across both contexts, several common patterns appeared. First, users often did not know how to describe the system they needed. They could describe pain points, but not product architecture. Second, the most important requirements were often hidden in handoffs between roles. Third, existing workarounds, such as spreadsheets or chat-based coordination, revealed important unmet needs. Fourth, management requirements and frontline requirements were sometimes misaligned. Fifth, product decisions required balancing usability, business value, technical feasibility, and organizational discipline.
These patterns shaped the development of the proposed immersive user research framework. The framework was created to help designers move from scattered observations toward structured product decisions. It emphasizes that in industrial Business-to-Business Software as a Service design, a requirement should not be understood only as a user request. It should also be understood as evidence of a relationship among roles, data, workflow, responsibility, and organizational value.
Proposed Framework
The proposed immersive user research framework consists of five stages: entering the business context, mapping stakeholders, tracing workflows, identifying breakdowns, and translating insights into product requirements.
The first stage is entering the business context. Designers must understand the industry environment before defining product features. This includes learning basic business terminology, common operational procedures, company goals, customer types, service models, and technical constraints. In industrial digital transformation, many product problems cannot be understood from interface behavior alone. They are shaped by how the company operates. Designers should therefore ask not only what the user needs on a screen, but why the task exists, who depends on its result, what business consequence occurs if it fails, and what organizational rule shapes the behavior.
This stage requires designers to temporarily suspend the impulse to produce immediate interface solutions. Instead, the designer should build a contextual understanding of the organization. In practice, this may include reading internal documents, attending meetings, reviewing existing tools, observing team communication, and asking stakeholders to explain business logic. The goal is not to become an industry expert, but to understand enough of the business environment to interpret user behavior accurately.
The second stage is mapping stakeholders. Business-to-Business Software as a Service users are usually distributed across multiple departments and organizational levels. A designer should identify daily users, occasional users, decision-makers, managers, clients, technical teams, and external partners. Each stakeholder may have different goals and different definitions of product value. For example, an operations employee may value reduced manual work, while a manager may value visibility and control. A client may value transparency and response speed. Mapping these differences helps prevent the designer from over-optimizing for only one group.
Stakeholder mapping should include more than job titles. It should also identify what each stakeholder contributes to the workflow, what information they need, what decisions they make, what tools they use, and what risks they experience. In industrial Software as a Service, a role may be powerful not because it uses the system frequently, but because it controls data quality or decision approval. Designers should therefore consider both frequency of use and structural importance.
The third stage is tracing workflows. Designers should follow how a task moves from beginning to end across people, tools, and systems. This includes identifying where data is created, where it is transferred, who approves it, who modifies it, who depends on it, and where delays or errors occur. Workflow tracing reveals problems that may not appear in direct interviews. Users may normalize inefficient processes and fail to describe them as problems. By observing the workflow directly, designers can identify hidden friction points.
Workflow tracing can be organized around several questions. What triggers the workflow? What is the first action? Which role performs it? What information is required? What tool is used? What happens next? Where does the information go? Who checks it? What happens if something is wrong? Where does the workflow end? These questions help designers convert vague descriptions into process-level understanding.
The fourth stage is identifying breakdowns. Breakdowns may include information gaps, repeated manual entry, unclear responsibility, delayed approval, inconsistent data formats, fragmented communication, hidden dependencies, or lack of feedback. These breakdowns are important because they often become the real source of Software as a Service product requirements. A requirement is not only a user request; it can also be a symptom of a workflow failure.
Breakdowns can be classified into several types. Information breakdowns occur when the right information is unavailable, outdated, inconsistent, or difficult to find. Responsibility breakdowns occur when users are unclear about who should take the next action. Coordination breakdowns occur when tasks require multiple roles but communication is not supported by the system. Decision breakdowns occur when managers or users cannot understand status, priority, or risk. Data breakdowns occur when data is duplicated, incomplete, or unreliable. Experience breakdowns occur when the interface creates unnecessary cognitive or operational burden.
The fifth stage is translating insights into product requirements. The designer must convert observations into designable elements. A workflow breakdown may become a new dashboard, an automated reminder, a permission setting, a data validation rule, a task status system, or a redesigned information architecture. This translation requires balancing user needs, business objectives, technical feasibility, and organizational constraints.
Translation is the most important stage because it connects research with design action. Designers should avoid copying user requests directly into feature lists. Instead, they should ask what underlying problem the request represents. For example, a request for export functions may indicate a need for reporting flexibility, lack of trust in the system, or the absence of a shared dashboard. A request for more notifications may indicate unclear responsibility or poor workflow visibility. A request for simpler forms may indicate excessive data requirements or poor information hierarchy. By interpreting requests in relation to workflow context, designers can propose better product solutions.
Research Method in Practice
In practice, immersive user research begins before formal user interviews. The designer first collects contextual information about the organization, including its business model, team structure, major workflows, customer relationships, and existing tools. This early stage helps the designer avoid asking questions that are too generic or disconnected from the business situation.
After the initial context learning, the designer identifies key roles. In industrial Business-to-Business Software as a Service, these roles may include business development, operations, engineering, project delivery, finance, customer success, management, and external clients. The designer then observes how these roles communicate and exchange information. Attention is paid to the tools they use, the documents they create, the meetings they attend, and the problems they repeatedly mention.
The next step is workflow shadowing. This does not necessarily require formal ethnography. In an early-stage company, it may involve joining internal meetings, reviewing message threads, observing how spreadsheets are used, asking employees to walk through a task, or following the lifecycle of a customer request. The goal is to understand the movement of work.
After collecting observations, the designer organizes insights into maps. These maps may include stakeholder maps, workflow maps, data-flow maps, decision-flow maps, and pain-point maps. The purpose is not to produce perfect documentation, but to make invisible relationships visible. Once visualized, the designer can identify where product intervention is most valuable.
Finally, the designer translates research insights into product language. For example, if multiple teams repeatedly ask each other for the latest project status, the product opportunity may be a shared project dashboard. If users often forget to update the next responsible person, the opportunity may be workflow automation or task notification. If managers distrust data accuracy, the opportunity may be validation rules, audit logs, or standardized data-entry structures. If different departments use different terms for the same thing, the opportunity may be improved information architecture and terminology standardization.
The practical value of this method lies in its ability to connect small observations with larger product decisions. A single complaint may not be meaningful by itself. However, when similar complaints appear across roles and workflows, they may reveal a structural product opportunity. Immersive research helps designers notice these patterns because they remain close to the work environment over time.
Analytical Dimensions
The proposed method can be further understood through four analytical dimensions: role, workflow, data, and decision.
The role dimension concerns who participates in the system. In Business-to-Business Software as a Service, roles define not only access but also responsibility, authority, and perspective. A designer should ask what each role needs to see, what each role needs to do, and what each role should not be able to change. Role analysis supports permission design, dashboard personalization, notification logic, and task assignment.
The workflow dimension concerns how work moves. A workflow may include task creation, assignment, action, review, approval, reporting, and closure. Designers should identify where the workflow is linear, where it branches, where it loops back, and where exceptions occur. Workflow analysis supports navigation design, status design, process automation, and error handling.
The data dimension concerns what information is created, transferred, modified, and trusted. Data may include customer information, project status, technical parameters, financial values, operational metrics, documents, comments, and audit records. Designers should identify data sources, data owners, data dependencies, and data quality risks. Data analysis supports form design, validation rules, database logic, reporting systems, and dashboard design.
The decision dimension concerns how people judge, approve, prioritize, and act. Decisions may be made by individuals, teams, managers, or clients. Some decisions are formal, while others are informal. Some are based on data, while others rely on experience. Decision analysis supports approval flows, recommendation systems, risk indicators, and management dashboards.
These four dimensions help designers avoid reducing user experience research to preference collection. They also help transform qualitative observations into structured product requirements. For example, if a designer observes that project updates are delayed, the role dimension asks who is responsible for the update; the workflow dimension asks when the update should happen; the data dimension asks what information must be updated; and the decision dimension asks who uses that update to make decisions. Together, these dimensions produce a more complete understanding of the design problem.
Findings
The reflective analysis suggests that immersive user research provides several advantages in industrial Business-to-Business Software as a Service design.
First, it reveals implicit requirements. In traditional industries, users may not always express needs in digital product language. They may describe problems as delays, miscommunication, repeated work, reporting pressure, customer complaints, or management uncertainty. Immersive observation helps designers translate these practical expressions into product opportunities.
Second, it exposes differences between formal process and actual practice. Companies may have official workflows, but employees often rely on informal methods such as spreadsheets, chat messages, personal notes, manual reminders, or verbal confirmation. These informal practices are valuable research material because they reveal what the existing system fails to support.
Third, it helps designers understand multi-role conflicts. A feature that helps one role may create additional work for another. For example, a management dashboard may require frontline employees to enter more structured data. An automated workflow may increase efficiency but reduce flexibility. Immersive research allows designers to identify these tensions before finalizing product requirements.
Fourth, it improves requirement prioritization. In industrial Software as a Service contexts, there may be many competing requests. By understanding workflow dependencies, designers can distinguish between surface-level feature requests and core process problems. This helps teams prioritize features that solve systemic issues rather than isolated complaints.
Fifth, it strengthens communication between design, business, and development teams. When designers can explain requirements through workflow evidence, role relationships, and operational consequences, product discussions become more concrete. This reduces the risk of designing features based only on assumptions or individual opinions.
Sixth, it supports better information architecture. In industrial Software as a Service products, information architecture is often shaped by business logic rather than simple content categories. Designers must decide how entities such as customers, projects, orders, assets, tasks, reports, and users relate to one another. Immersive research helps reveal these relationships.
Seventh, it helps designers identify data quality problems. Many Software as a Service features depend on accurate and consistent data. However, in traditional organizations, data may be incomplete, duplicated, delayed, or stored across disconnected tools. By tracing data flows, designers can identify where data problems originate and design mechanisms to reduce them.
Eighth, it helps early-stage teams reduce product uncertainty. Startups often lack mature product documentation. Immersive research allows designers to build product understanding while the organization itself is still defining its processes. This makes the method useful for ambiguous product environments.
Ninth, it reveals the relationship between internal efficiency and customer experience. In Business-to-Business Software as a Service contexts, customer experience is often shaped by internal operations. A client may experience slow response not because the client-facing interface is poor, but because internal teams lack shared status visibility. Therefore, improving internal workflow may improve external service quality.
Tenth, it helps designers identify which requirements should become system rules and which should remain flexible. Industrial users often request flexibility because their work contains exceptions. However, too much flexibility can create inconsistent data and management difficulty. Immersive research helps designers understand where standardization is necessary and where flexibility should be preserved.
Discussion
The proposed approach expands the meaning of user research in Business-to-Business Software as a Service design. In consumer product design, user experience research often focuses on user behavior, preference, satisfaction, and usability. In industrial Software as a Service design, user experience research must also investigate organizational structure, workflow logic, data movement, and decision-making patterns. The designer is not only studying users, but also studying the system in which users work.
This shift has theoretical and practical implications. Theoretically, it suggests that user experience methods should be adapted for non-consumer and organizational contexts. The unit of analysis should not always be the individual user. In Business-to-Business Software as a Service, the unit of analysis may be a workflow, a role network, a data dependency, or a decision process. Practically, it provides designers with a feasible approach when formal research resources are limited.
The framework also highlights the value of immersion as a design capability. Immersion does not simply mean spending more time with users. It means actively learning the business context, observing real work, recognizing hidden constraints, and translating complex organizational knowledge into design decisions. This requires designers to develop sensitivity to both human experience and operational systems.
Another implication concerns the role of the designer in industrial organizations. In many early-stage companies, the designer is not only responsible for interface design. The designer may also participate in product strategy, requirement definition, workflow modeling, and communication between business and technical teams. The immersive method recognizes this expanded role. It provides a way for designers to make sense of unclear requirements and contribute to product direction.
The method also challenges a narrow understanding of usability. In industrial Business-to-Business Software as a Service, usability cannot be measured only by whether an individual user can complete a task quickly. A system may be easy for one person but harmful to the broader workflow if it produces poor data, hides responsibility, or creates extra work for another team. Therefore, user experience quality should be evaluated at both individual and organizational levels.
This paper also suggests that requirement discovery should be treated as an ongoing process. In fast-changing industrial startups, requirements are rarely stable. Business models evolve, teams change, customers request new capabilities, and internal processes become more formal over time. Immersive research supports continuous learning because the designer remains connected to the changing work environment.
The proposed approach also has implications for design education. Many user experience design courses teach interviews, personas, journey maps, and usability testing as core methods. These methods remain useful, but industrial Software as a Service design requires additional capabilities: understanding organizational systems, mapping workflows, interpreting data dependencies, and negotiating among stakeholders. Designers entering Business-to-Business or industrial contexts may need to develop business literacy and systems thinking in addition to interface design skills.
The approach further suggests that design deliverables should be expanded. In consumer user experience, common deliverables include wireframes, prototypes, personas, and usability reports. In industrial Software as a Service, useful deliverables may also include stakeholder maps, workflow maps, entity relationship diagrams, permission matrices, data-flow diagrams, and decision maps. These artifacts help communicate complex requirements to product managers, developers, executives, and users.
Practical Design Guidelines
Based on the proposed framework, several practical guidelines can be offered for product designers working in industrial Business-to-Business Software as a Service contexts.
First, begin with the business process rather than the interface. Before designing screens, designers should understand what business activity the product supports. A visually polished interface cannot solve a poorly understood workflow.
Second, identify all stakeholder groups early. Designers should distinguish between daily users, managers, buyers, clients, technical teams, and external partners. Each group may define success differently.
Third, observe workarounds carefully. Spreadsheets, chat messages, manual reminders, and informal documents are not signs of poor user behavior. They are evidence of unmet system needs.
Fourth, map data movement. Many industrial Software as a Service problems come from unclear data ownership, duplicated entry, delayed updates, or inconsistent formats. Designers should ask where data comes from, who changes it, and who trusts it.
Fifth, treat conflict as research material. If departments disagree about a feature, the disagreement may reveal deeper tensions between efficiency, control, flexibility, and accountability.
Sixth, translate pain points into system requirements. A complaint such as messy communication is not yet a design requirement. It must be translated into more specific opportunities, such as task assignment, status visibility, notification rules, shared records, or approval workflows.
Seventh, validate concepts through workflow scenarios. Instead of only asking whether users like a design, designers should test whether the design supports the real sequence of work across roles.
Eighth, document assumptions. In fast-moving startup environments, many product decisions are based on incomplete information. Designers should clearly record what is known, what is assumed, and what needs later validation.
Ninth, distinguish between user preference and operational necessity. Some users may prefer familiar tools even when those tools create organizational inefficiency. Designers must balance individual comfort with broader workflow improvement.
Tenth, design for exceptions. Industrial workflows often contain unusual cases, urgent changes, missing data, or special approvals. A system that only supports the ideal process may fail in real use.
Eleventh, make responsibility visible. Many workflow problems occur because users do not know who owns the next action. Clear ownership, status, and accountability can improve both usability and coordination.
Twelfth, use prototypes as research tools. In complex Business-to-Business environments, stakeholders may not fully understand abstract product descriptions. Prototypes help make assumptions visible and encourage more concrete feedback.
Limitations
This research has several limitations. First, it is based on reflective design practice rather than a controlled empirical study. The findings are therefore interpretive and context-dependent. They should be understood as a practical framework rather than a statistically validated model.
Second, the study is based on two industrial technology startup contexts. Although the patterns identified may apply to similar Business-to-Business Software as a Service environments, further research is needed across larger companies, different industries, and more mature organizations.
Third, immersive research depends on access. Designers may not always be allowed to observe internal meetings, client communication, operational tools, or strategic discussions. Without sufficient access, the method may be difficult to apply fully.
Fourth, the designer’s embedded position can create bias. Immersion helps designers understand context, but it may also make them too familiar with internal assumptions. To reduce this risk, designers should combine immersion with periodic external review, user validation, and cross-functional critique.
Fifth, the method may be difficult for teams that expect user experience research to produce quick and simple answers. Immersive research often reveals complexity rather than reducing it immediately. Teams must be willing to treat complexity as useful design knowledge.
Sixth, the paper does not provide quantitative evidence of product performance improvement. Future studies could measure outcomes such as reduced task time, improved data accuracy, higher adoption rates, or lower communication overhead after applying the framework.
Seventh, the method may be more suitable for designers who have cross-functional access. Designers limited to visual interface production may find it difficult to conduct full immersion. Organizational support is therefore important.
Future Research
Future research could develop this framework in several directions. First, the method could be tested across different industrial sectors, such as manufacturing, logistics, energy, healthcare operations, construction, agriculture, and enterprise services. This would help identify which parts of the framework are generalizable and which need industry-specific adaptation.
Second, future studies could compare immersive research with conventional interview-based research in Business-to-Business Software as a Service projects. Such comparison could examine whether immersive methods produce more accurate requirements, reduce redesign, or improve stakeholder alignment.
Third, the framework could be combined with visual modeling tools such as service blueprints, system maps, data-flow diagrams, and journey maps. This would allow designers to represent industrial complexity more clearly and communicate insights to non-design stakeholders.
Fourth, future research could develop evaluation criteria for industrial Software as a Service user experience. Instead of measuring only task completion or satisfaction, evaluation could include workflow continuity, data accuracy, role coordination, decision visibility, and organizational adoption.
Fifth, the approach could be extended to artificial intelligence-assisted Business-to-Business Software as a Service systems. As industrial companies adopt artificial intelligence tools for prediction, automation, and decision support, designers will need to understand not only user needs but also data readiness, trust, explainability, and human oversight.
Sixth, future research could examine how immersive user research changes the designer’s role in organizations. Designers may increasingly act as translators between business, technology, and human experience. This expanded role deserves further study.
Seventh, future work could develop templates and toolkits for applying the framework. These may include stakeholder mapping templates, workflow tracing forms, breakdown classification tables, and requirement translation worksheets.
Conclusion
This paper proposed an immersive user research approach for Business-to-Business Software as a Service design in industrial digital transformation. The study argued that conventional user experience research methods are useful but often insufficient in traditional and industrial contexts because user needs are embedded in complex workflows, role relationships, data dependencies, and organizational constraints.
Based on reflective design practice in two industrial technology startup contexts, the paper presented a five-stage framework: entering the business context, mapping stakeholders, tracing workflows, identifying breakdowns, and translating insights into product requirements. This framework helps designers move beyond isolated interviews and understand how real work is performed across departments and systems.
The main contribution of this research is a practical and lightweight method for product designers working in early-stage industrial Software as a Service environments. It supports requirement discovery, product definition, and user experience strategy by reframing user experience research as immersive organizational and workflow inquiry. For designers working in non-consumer digital products, this approach can improve the accuracy of requirements, reduce misalignment between business goals and user needs, and support more effective product innovation in industrial digital transformation.
The broader implication is that user experience design in industrial digital transformation should not be limited to interface improvement. It should participate in understanding and reshaping the relationships among people, processes, data, and decisions. In this sense, immersive user research can help bridge the gap between traditional industry knowledge and digital product innovation.
Acknowledgments
Not applicable.
Appendix
No supplementary materials are included in this submission.