A model-driven framework for automated UI prototyping with the two-hemisphere model

1 Introduction

User interface generation remains a challenging and largely unresolved problem in software engineering, particularly in the context of automating the transformation of domain knowledge into executable front-end artifacts. Automation of repetitive tasks—such as testing, building, and deployment—has particularly contributed to accelerating the software development lifecycle (Nikiforova et al., 2026). This work focuses specifically on the transformation of domain models into user interface representations, rather than general software engineering concerns.

User interfaces must be derived from domain-specific requirements and interaction logic, making their automation dependent on structured domain representations. A well-designed user interface not only ensures accessibility and usability but also directly impacts user satisfaction and system adoption (Nguyen et al., 2018). Importantly, user interface design is highly contextual—dependent on user needs, domain characteristics, and the technical platform (Calvary et al., 2003; Yigitbas et al., 2020). While business logic may remain consistent across platforms, user interfaces often require customization for mobile devices, operating systems, or interaction modalities.

The growing complexity of application environments and the demand for rapid system delivery in an increasingly digitized world highlight the need for efficient user interface development. Traditional, manual adaptation of user interfaces to different contexts is both resource-intensive and error-prone, leading to increased development costs and management overhead (Akiki et al., 2014).

This research addresses the challenge of automating user interface generation from formalized knowledge of the problem domain. The aim is to develop a model-driven transformation approach in which domain-level mappings are conceptually separated from implementation concerns; the current proof-of-concept generator targets React.js and Material-UI. Model-Driven Development (MDD) provides a structured approach for transforming abstract models into executable artifacts through well-defined abstraction layers. In Model-Based User Interface Development (MBUID), these layers are typically formalized in the Cameleon Reference Framework, which distinguishes between Task and Domain Models, Abstract User Interface, Concrete User Interface, and Final User Interface.

In this work, the proposed two-hemisphere model aligns with these levels as follows: the concept model corresponds to domain modeling, the process model approximates task and interaction flow modeling, and the generated UI patterns operate at the CUI/FUI levels.

Since its emergence in 2001 (Lycett et al., 2007), MDD has facilitated partial automation in software development, particularly the generation of static system artifacts such as class definitions. However, full automation of dynamic system components—including user interfaces—remains an unresolved challenge. Although some MDD tools can partially generate user interface forms based on well-defined models, they fall short of delivering fully functional, implementation-ready user interface prototypes.

Recent advances in generative artificial intelligence have introduced new possibilities for user interface design (Stige et al., 2023; da Silva et al., 2011). Recent advances in generative AI (e.g., large language models and multimodal systems) have significantly improved the ability to generate UI code and design artifacts. However, these approaches still face challenges in consistency, traceability to formal models, and alignment with domain-specific semantics, particularly in safety-critical or structured development contexts (Alfaridzi and Yulianti, 2020; Riccio et al., 2020). As such, AI remains limited in its ability to autonomously produce accurate, usable user interface designs without substantial human oversight (Newman and Landay, 2000; Li et al., 2023). Recent generative-AI systems provide increasingly capable mechanisms for producing user interface code and design artifacts from textual, visual, or multimodal inputs. However, generative approaches and model-driven transformation address partly different objectives. Generative AI emphasizes flexible synthesis from comparatively informal inputs, whereas model-driven approaches emphasize explicit source semantics, transformation traceability, and reproducibility. Depending on the development context, AI-generated artifacts may require validation or refinement to ensure consistency with domain requirements; conversely, deterministic model-driven generation is constrained by the expressiveness of its source metamodel and transformation-rule library. The two approaches should therefore not be regarded as direct substitutes. In the proposed framework, AI is considered a potential complementary mechanism for tasks such as semantic pattern classification, while deterministic transformations retain responsibility for model-to-interface traceability. Challenges remain in ensuring traceability to formal models, deterministic behavior, and alignment with domain semantics—particularly in model-driven engineering contexts.

Generative AI differs fundamentally from MBUID approaches. While MBUID relies on explicit transformations between formal model layers, generative AI typically generates user interface artifacts directly from prompts or informal specifications. In this work, AI is not used as a replacement for model transformations but is considered a potential enhancement for specific tasks such as pattern classification (Sharp et al., 2019; Planas et al., 2021). The potential for automating this transformation depends heavily on the formal completeness and consistency of the source model (Joo, 2017; ter Beek and McIver, 2021). High-quality software requires comprehensive modeling of the problem domain to ensure that all aspects of system logic are accurately captured (Nikiforova et al., 2026).

This research follows the Design Science Research methodology, consisting of the following steps:

• 1) Problem identification: lack of integrated user interface generation from process and concept models;
• 2) Objective definition: development of a model-driven transformation framework;
• 3) Design and development: creation of transformation rules and metamodel;
• 4) Demonstration: implementation using React.js and BrainTool models;
• 5) Evaluation: validation using static code analysis, ISO/IEC/IEEE 29119-based functional acceptance testing, and expert heuristic evaluation;
• 6) Communication: presentation of results in this paper.

The validation of the proposed solution was conducted at three complementary levels. First, the generated source code was analyzed using JavaScript quality tools (JSLint, JSHint, ESLint) to ensure compliance with programming best practices. Second, the resulting user interface prototype was evaluated using the ISO/IEC/IEEE 29119 standard for acceptance testing. This involved defining acceptance criteria commonly applied to manually developed systems and verifying that the automatically generated prototype met these standards. Third, the expert heuristic evaluation was performed.

2 Related work

User interface design is a central component of software development, particularly in the context of web applications, where the user interface serves as the primary point of interaction between the user and the system. It encompasses visual design, interaction logic, and information architecture, collectively forming the front-end layer that mediates system functionality and user experience (Nguyen et al., 2018; Alfaridzi and Yulianti, 2020).

Iterative design process is inherently labor-intensive, requiring multiple cycles of refinement, testing, and stakeholder feedback to reach the desired level of usability and completeness (Bajammal et al., 2018; Suleri et al., 2019; Riaz et al., 2022).

User interface development approaches can be broadly categorized into manual, semi-automated, and automated methods (Molina et al., 2002). Manual approaches, though flexible and highly customizable, are time-consuming and prone to errors. Existing approaches differ in how they transform design artifacts into executable user interface components, with varying levels of automation and semantic integration. This process demands close collaboration between designers and developers to translate visual models into functional code.

Semi-automated approaches aim to bridge the gap between analysis and implementation using design tools that incorporate templates and model-based features. These reduce development time but often struggle with maintainability, particularly when adapting to evolving technologies or changing design requirements (Pelechano et al., 2002).

Automated approaches rely on models and code-generation mechanisms to significantly reduce manual effort. Tools such as Uizard.io, Sketch2Code, VizMod, and ReDraw apply artificial intelligence and machine learning to transform hand-drawn or static design inputs into HTML and other front-end code (Riccio et al., 2020). These tools accelerate initial user interface development but typically require manual refinement to address project-specific needs and to ensure fidelity and interactivity.

Despite their promise, automated solutions often lack interpretability, offer limited adaptability for complex or personalized interfaces, and may not support multi-platform responsiveness or evolving application logic (Alfaridzi and Yulianti, 2020; Diehl et al., 2022). Therefore, while automation can streamline routine design tasks, human oversight remains essential to ensure usability, accessibility, and design quality.

Existing MBUID frameworks such as the Cameleon Reference Framework and adaptive MBUID approaches provide structured transformations across abstraction levels but often lack direct generation of executable user interface code. Conversely, AI-based tools such as Uizard or Sketch2Code generate code but do not explicitly model behavior or domain semantics. This gap motivates the need for a framework that integrates both behavioral and structural models into executable user interface prototypes. Capability Maturity Model Integration and the Model Maturity Index are widely used to assess process and model readiness, ranging from ad hoc practices to optimized workflows (Hinderks et al., 2022). These are conceptually aligned with user interface maturity models, which describe progression from basic sketches to fully functional, refined interfaces. Collectively, such frameworks encourage the development of robust, repeatable, and scalable user interface processes.

Model-Based User Interface Development frameworks, such as the Cameleon Reference Framework, structure the user interface design process into multiple abstraction levels. These frameworks allow transformation of high-level task models and domain concepts into executable user interface components through a series of intermediate models (Planas et al., 2021). While effective in theory, their complexity can hinder adoption, especially by teams with limited experience in formal modeling.

In parallel, low-code and no-code platforms are gaining traction as tools for simplifying software creation through visual programming (Truss and Schmitt, 2024). When integrated with model-driven engineering techniques, these platforms can support faster development and improve scalability. However, challenges related to flexibility, documentation, and developer control still remain (Gilbert et al., 2021; Nikiforova et al., 2024a). Emerging efforts to integrate low-code platforms with large language models seek to enhance usability and planning capacity, but also increase user cognitive load and present new challenges in workflow customization (Riccio et al., 2020).

Existing research and tools in user interface automation often focus on isolated aspects of the design process. Most solutions support partial automation—such as converting static designs into code or generating forms from data schemas—but do not fully integrate process behavior, interaction logic, and data modeling in a unified framework. Moreover, many tools rely heavily on predefined templates, limiting their adaptability to domain-specific requirements or evolving user needs (Suleri et al., 2019).

There are also unresolved concerns related to trust and explainability in AI-generated user interface components (Subramonyam et al., 2021). Without transparent mechanisms to verify the logic and behavior of generated interfaces, designers are often required to intervene manually (Nikiforova et al., 2021) to ensure alignment with usability goals, accessibility standards, and ethical guidelines (Stige et al., 2023). Robust evaluation mechanisms and user-in-the-loop systems are needed to enhance the reliability and acceptance of automated user interface solutions (Subramonyam et al., 2022; Liao et al., 2023; Truss and Schmitt, 2024).

The novelty of this research lies in its model-driven approach to user interface generation based on the two-hemisphere model (Nikiforova et al., 2013). This model integrates two complementary perspectives of the problem domain (Nikiforova and Kirikova, 2004): a process model, which defines workflows, actions, and behavioral logic; and a concept model, which captures the structure and relationships of domain data. This dual representation enables a more holistic generation of user interfaces (Babris and Nikiforova, 2026), where the concept model informs user interface structure and data binding, while the process model drives behavior, user flows, and conditional rendering (Babris and Nikiforova, 2026).

Compared with Babris and Nikiforova (2026), this paper extends the earlier concept by formalizing the transformation pipeline, adding the user interface metamodel, specifying routing/state generation, integrating React/Material-UI code generation, and reporting acceptance-test-based evaluation. Compared with Babris and Nikiforova (2026), this paper moves from mockup-oriented generation toward executable React prototypes with state, routing, CRUD structures, and validation.

Compared to standards such as IFML combined with BPMN, the two-hemisphere model differs in its tighter integration of data and process semantics within a single modeling structure. While IFML separates interaction flow and domain modeling, the proposed approach emphasizes direct traceability between process actions and data concepts during transformation, reducing synchronization complexity and improving consistency in generated user interface behavior.

To highlight the novelty of our contribution, Table 1 contrasts the proposed framework with established existing approaches which can be grouped into three categories:

• 1) MBUID frameworks, which provide structured abstraction but limited executable output;
• 2) AI-based tools, which generate user interface artifacts but lack semantic traceability;
• 3) Hybrid approaches, which partially integrate models and automation.

Table 1. Literature-based qualitative comparison of characteristics of existing approaches.

Among the approaches considered in this comparison, none simultaneously integrates behavioral (process) and structural (concept) models with executable user interface generation.

The comparison is qualitative and based on characteristics reported in the literature rather than experimental benchmarking. The ratings are intended to provide a high-level overview rather than a quantitative performance assessment.

As seen in the comparison, the proposed framework distinguishes itself by integrating both process and concept models through the two-hemisphere model, which enables the generation of prototypes that are not only structurally coherent but also behaviourally consistent. Unlike AI-based mockup-to-code tools (e.g., Uizard, Sketch2Code, ReDraw), our approach explicitly models state and routing logic, ensuring realistic navigation flows. At the same time, unlike general MBUID frameworks such as Cameleon or the adaptive MBUID approaches, our framework produces execution-ready React/Material-UI code, validated through linting and ISO 29119 acceptance tests. This dual emphasis on model-driven rigor and implementation-ready output positions our work as an incremental contribution that combines model-driven rigor with executable prototype generation that bridges the gap between conceptual modeling and practical prototyping.

By grounding user interface generation in formal and semantically rich domain models, the proposed solution provides a structured model-driven basis for web user interface prototype generation. Scalability and industrial generalizability require further multi-case evaluation. The next section presents the details of this solution and its implementation within the framework of MDD.

3 Solution

This section presents the model-driven solution developed for the automatic generation of web user interface prototypes using the two-hemisphere model (Nikiforova et al., 2024a). The solution integrates the principles of MDD, leveraging domain models to generate React.js based front-end code. It is designed within the Meta Object Facility framework, with its main components classified according to three key user interface categories: concept elements, navigation elements, and presentation elements. The conceptual architecture is illustrated in Figure 1, where white blocks represent solution components, and annotated elements highlight extensions and innovations.

The transformation process consists of three stages:

• 1) Model extraction: parsing process and concept models;
• 2) Model mapping: linking processes to user interface states and concepts to user interface components;
• 3) Code generation: instantiating user interface patterns into framework-specific components.

The text classification mechanism currently uses rule-based keyword matching rather than machine learning algorithms.

The transformation process begins with the creation of a two-hemisphere model, which can be constructed using modeling tools that support process and concept model integration (e.g., BrainTool) (Nikiforova and Gusarovs, 2017), which captures both the process and concept models of the problem domain. This model can be developed using any modeling environment that supports the definition and export of structured representations of processes and concepts. The resulting model is then serialized into a machine-readable format (e.g., XML or JSON) for further transformation. Although BrainTool is used as a proof-of-concept modeling environment, the approach is not tool-specific. The transformation relies on structured representations of process and concept models, which can be derived from standard modeling languages such as BPMN (process) and UML class diagrams (concepts), provided they are serialized into a machine-readable format. The concept model is used to define data entities, mapped to CRUD operations, and supplemented with demo data for visualization. Each process defined in the model corresponds to an element of application behavior and is mapped to a user interface state within a navigation structure derived from the process flow. In the current implementation, this structure is represented through state charts and corresponding React Router routes. These routes are linked to container components that encapsulate state, logic, and user interaction for each view.

A key innovation is the integration of a pattern classification mechanism that maps process names to suitable user interface patterns from a predefined library. For example, the process “Show Cart” would be matched to a “Shopping Cart” user interface pattern using a text classification method. This pattern provides a reusable interface template, including layout and behavioral logic, which is integrated into a higher-level view construct (for example, in React.js container) representing the user interface state associated with that process.

The design leverages established MDD principles: the source model represents a Platform-Independent Model. However, the current implementation directly maps to a Platform-Specific Model targeting React.js and Material-UI. Future work will introduce an explicit intermediate abstraction layer to decouple transformation logic from specific user interface frameworks (Babris et al., 2019; Kleppe et al., 2003). The metamodel developed for this solution defines three abstract user interface layers to ensure modularity, separation of concerns, and reusability across implementation platforms:

• Navigation units, which represent high-level views or pages.
• Interaction controllers, which manage interface state and business logic (for example, react containers).
• Presentation components, which define the structure and appearance of individual user interface elements (for example, react components).

In case of React.js, each Container is defined by its name, dependencies, concepts, and methods. Components, in turn, are linked to Containers via props, and contain content that defines the interface's structure and behavior. This architecture supports modularity, reuse, and scalability, aligning well with the dynamic requirements of modern web interfaces. Data management is handled through Redux.js, and state transitions are modeled using XState, supporting rich interaction logic.

The two-hemisphere model, initially developed at Riga Technical University (Nikiforova et al., 2013), structures domain knowledge into a process model and a concept model. The process model describes domain behaviors, while the concept model captures data structures. The link between these two models—represented by data flows mapped to concepts—enables transformation into detailed software artifacts. Each process can be mapped to user interface navigation flows, and each concept to structured data views. This bidirectional relationship forms the basis of the proposed transformation logic.

The concept model contains data entities described through attributes, actions, and relationships. These are mapped to React.js components that represent forms, tables, or other data presentation elements. Based on object-oriented design principles, relationships between classes are translated into navigation links or related views (Koch and Mandel, 1999). While the BrainTool currently supports a limited set of field types, this can be extended to include richer input types such as text, enums, dates, and files (Mahatody et al., 2021), improving user interface richness and user interaction.

Navigation elements are derived from the process model, which naturally resembles a state chart structure. States represent user-visible views or internal transitions, and transitions correspond to possible interactions (Sunitha and Samuel, 2019; Pimentel et al., 2014). The transformation mechanism derives navigation routes from the serialized process model and maps them to corresponding state transitions and user-visible views within the generated interface structure. Using XState, each process is transformed into a state node, complete with context and actions. For user interface development, it's critical to determine whether a state should be visible to the user or serve only as an internal transition. An additional attribute is proposed for the process model to mark this distinction.

Presentation design focuses on rendering the user interface and defining both static and dynamic views (Koch and Mandel, 1999). Using user interface patterns, the system determines the layout and styling of components. A pattern library, aligned with frameworks like Material-UI, provides predefined templates such as forms, cards, modals, and grids. These are applied based on pattern matching with process names using a lightweight text classification method (Hasheminejad and Jalili, 2012). The static presentation model assigns a view to each navigation node, while the dynamic presentation model defines user interaction and state changes.

Transformation rules serve to associate processes with user interface patterns. The rule design begins with keyword extraction from process names (Haz et al., 2024). The current implementation relies on keyword-based mapping (e.g., “Show,” “Add”), which introduces sensitivity to naming conventions. This limitation is acknowledged, and future work will incorporate semantic analysis and machine learning-based classification to improve robustness and reduce dependency on strict naming patterns.

The accuracy of this mapping depends on the quality of process naming and the granularity of the user interface pattern library (Hasan et al., 2017). Contextual cues from the concept model may also assist in refining the selection. For example, a process named “Show Item” may correspond either to a catalog detail page or to inventory management. Likewise, synonyms such as “Basket” and “Cart” may lead to different pattern selections if the vocabulary is incomplete. These cases illustrate the dependence of the approach on naming consistency and pattern-library granularity.

Each transformation rule is formalized as a tuple mapping keywords to patterns, and where ambiguity exists, priority is assigned to more specific matches. While the current solution relies on deterministic keyword matching, future research may integrate machine learning techniques for adaptive pattern selection based on historical usage and domain semantics.

The proposed solution (Figure 2) is implemented using React.js and Redux.js, with BrainTool serving as the source model editor. The toolchain processes BrainTool's XML output to extract models, generates code templates based on user interface patterns, and outputs a working prototype.

While the current system demonstrates successful transformation from the two-hemisphere model to user interface prototypes, future enhancements include enriching the pattern library, supporting additional frameworks (e.g., Ant Design), and improving BrainTool integration with predictive modeling and pattern suggestions. Further, the integration of AI-driven pattern classification and cross-framework semantic mapping will enhance adaptability and reduce developer intervention.

The transformation pipeline is specified at the conceptual level, including input formats, mapping principles, and generation logic. Although the implementation is not publicly available due to commercialization objectives, the transformation pipeline is described at a level intended to support independent conceptual reimplementation and further evaluation.

4 Formalization of the solution

The transformation algorithm converts a serialized two-hemisphere model into an executable user interface prototype through four main steps: (1) model parsing, (2) intermediate user interface model construction, (3) pattern selection, and (4) framework-specific code generation.

The source two-hemisphere model MTH is represented as:

MTH=(P,C,A,F,T,RC)

where:

• P denotes the set of processes;
• C denotes the set of concepts;
• A: attributes of concepts;
• F ⊆ P × C process and concept relations;
• T ⊆ P × P denotes the process transitions.
• RC ⊆ C × C concept relationships.

The target user interface model MUI is represented as:

MUI=(S,R,V,D,Comp,Act)

where:

• S denotes states;
• R denotes routes;
• V denotes views;
• D denotes data models;
• Comp stands for generated user interface components.
• Act stands for navigation actions.

The transformations are defined as:

Φ1:MTH×L→MUIΦ2:MUI→CodeReact

where L denotes the user interface pattern library. The transformation process is based on the following rules:

• Process-to-route mapping.
• Process transition mapping.
• Concept-to-view mapping.
• Process-concept binding.
• Pattern candidate selection.
• Pattern scoring.
• Pattern selection.
• Pattern instantiation.

The transformation procedure is summarized in the following algorithm (Table 2):

Table 2. Algorithm.

Where: KM, keyword matching score; CS, concept-context score; SP, pattern specificity score.

Input: MTH, pattern library L

Output: React.js prototype

• Parse process and concept models.
• Generate states and routes from processes and transitions.
• Generate data models from concepts.
• Extract keywords from process names.
• Identify candidate user interface patterns.
• Calculate pattern scores.
• Select the highest-scoring pattern.
• Generate React components and routing.
• Produce executable source code.

Ambiguities may occur when several patterns satisfy the same keyword set. For example, the process name Show Item may correspond either to a catalog-detail pattern or an inventory-management pattern. In such cases, pattern selection is refined using the related concepts and neighboring processes. Likewise, synonymous process names (e.g., Cart and Basket) require appropriate vocabulary definitions in the pattern library.

In the current implementation, the weights are set to α = 0.50, β = 0.30, and γ = 0.20. Keyword matching receives the highest weight because process-name semantics constitute the primary pattern-selection signal, while concept context and pattern specificity are used as secondary disambiguation criteria. These values were selected empirically during development and were kept fixed for the reported case study, but systematic sensitivity analysis of the weights remains future work.

To complement the formal transformation rules and algorithm, Figure 3 presents a simplified user interface metamodel used by the proposed framework. The metamodel illustrates the main elements of the generated user interface and their relationships. Routes provide navigation to states, each state contains one or more views composed of reusable components, and components are bound to underlying data models. User actions trigger state transitions and support interaction logic. This structure serves as the target model of the transformation process and provides the basis for generating executable React.js artifacts.

These examples show that deterministic keyword matching is transparent and reproducible, but it depends on consistent process naming and sufficient pattern-library granularity. Priority is determined by neighboring processes in the transition graph and concepts connected through data-flow relations. Future extensions may use semantic similarity or machine-learning-based classification to improve pattern selection in cases where process names are incomplete, ambiguous, or domain-specific.

5 Application case

To demonstrate and preliminarily evaluate the proposed model-driven solution, it was applied to a realistic domain scenario: an online shopping platform. The demonstration showcases the full transformation pipeline, from domain modeling with the two-hemisphere model to the generation and validation of a functioning web user interface prototype. The objective is to assess the effectiveness of the transformation process and evaluate both the generated source code and the resulting interface's alignment with domain requirements.

The process begins with the definition of the source model (Figure 4) using the two-hemisphere approach, which comprises a process model and a concept model created in BrainTool. The source model reflects the business logic and data structures of a subscription-based online store that allows users to register, browse products, add items to a cart, and place orders. The selected domain offers a representative use case for demonstrating user interaction workflows typical of e-commerce systems (Fernández et al., 2001; Babris and Nikiforova, 2026).

The domain processes include user registration and login, browsing a product catalog, cart management, checkout, and redirection to the user profile after order completion. These steps model the entire customer journey and are depicted through process flows and related concepts in the two-hemisphere model. The defined process model includes distinct states such as “Register,” “Login,” “View Products,” “Add to Cart,” “Checkout,” and “Profile.” Corresponding concepts like “User,” “Item,” “Cart,” and “Order” are linked via data flows that establish semantic relations between actions and data.

After constructing the source model, the transformation engine processes the exported XML from BrainTool. This includes parsing the process and concept models, mapping concepts to CRUD operations, and interpreting process flows as states and transitions for navigation. React.js components are generated using predefined user interface patterns, which are matched to process names via text classification methods (Nikiforova et al., 2024b). For example, a process named “Show Cart” is matched to a “Shopping Cart” user interface pattern. These patterns, once selected, guide the generation of layout and interaction logic, ensuring consistent and reusable user interface structures.

The transformation pipeline uses React.js for component-based user interface construction, Redux.js for state management, Material-UI for layout and styling, and XState for modeling application state transitions. The state chart generated from the two-hemisphere model defines the navigation logic between views and user actions. This allows seamless transitions, for instance, from viewing product details to cart management and checkout, or from login to profile redirection.

The generated prototype currently uses mock data. Integration with real backend services requires additional mapping between API schemas and the concept model. Schema mismatches must be resolved manually or through future automated schema alignment mechanisms.

To enrich the generated interface and simulate real user interaction, the system integrates mock data using the Faker.js library. This data is generated based on the concept attributes in the two-hemisphere model, enabling functional previews of input fields, tables, and user interface widgets. In cases where concept relations exist (e.g., between “Item” and “Image”), related elements are generated using predefined constants (e.g., five images per item), ensuring adequate demonstration of linked views and nested components.

The result of the transformation process is a working prototype composed of modular React.js source files. These files are organized into Containers and Components according to the user interface metamodel and can be directly launched in a web browser. The environment for this demonstration includes prepared code templates, transformation scripts, and runtime configuration. An auto-generated prototype with catalog, item and cart functionalities is shown in Figures 5–7, displaying the resulting user interface generated from the two-hemisphere model.

The transformation process not only generates static layout templates but also integrates routing logic using React Router and user interactions based on the state chart created from the process model. Dynamic behaviors such as form submission, cart updates, and navigation between views are fully supported, enabling end-to-end testing of the user flow.

6 Evaluation

The validation of the proposed approach can consequently be considered at three complementary levels:

• Code quality assessment—the JavaScript code generated by the transformation process is analyzed using static code analysis tools—JSLint, JSHint, and ESLint. These tools validate code correctness, readability, maintainability, and adherence to industry standards. The analysis confirms that the generated code is modular, cleanly structured, and conforms to JavaScript development best practices.
• Functional compliance—the prototype is tested against the expected functional behavior described in the domain model. Acceptance testing is conducted using ISO/IEC/IEEE 29119 standards, ensuring that the application correctly implements all defined use case scenarios. These include user registration and login, product catalog browsing, cart management, and order placement, all of which were verified to function as specified.
• Expert heuristic evaluation—assessing potential usability problems in the generated user interface according to Nielsen's established usability heuristics.

These evaluation perspectives address different properties of the generated artifact. Static analysis provides evidence concerning source-code quality, acceptance testing provides evidence concerning functional conformance to the modeled workflows, and heuristic evaluation provides evidence concerning potential usability limitations of the generated interface. The study demonstrates technical feasibility and provides initial expert-oriented evidence regarding user interface quality, while not claiming comprehensive end-user usability validation.

Table 3 summarizes the technical and functional evaluation results, including static code analysis, acceptance testing, generation performance, and required manual intervention. Because these measures do not assess interface usability directly, a separate expert heuristic evaluation was conducted. Its methodology and empirical results are reported in Section 7 and Table 4.

Table 3. Evaluation metrics for generated UI prototype.

Table 4. Consolidated findings from the pilot expert heuristic evaluation.

The purpose of this evaluation was not to establish general usability across application domains, but to determine whether the automatically generated prototype exhibited major usability problems in the evaluated case. The assessment considered established HCI dimensions including visibility of system status, consistency, correspondence between the interface and user expectations, error prevention and recovery, recognition rather than recall, interaction efficiency, and clarity of feedback. This evaluation complements the software-oriented validation because conformance to functional requirements and static-code-quality criteria alone does not establish the usability of a generated interface. This pattern-based design approach promotes interface consistency across application views, reducing the need for manual adjustments.

The 25 acceptance test cases were manually derived from the defined e-commerce use case scenarios, covering core workflows such as registration, browsing, cart management, and checkout. These tests were not auto-generated and were designed to reflect standard user interaction scenarios.

The evaluation indicates that, in the evaluated case, the generated prototype satisfied the defined functional requirements and code-quality checks and was executable without additional modifications in the evaluated case study. The absence of critical linting issues and the successful execution of all 25 acceptance-test scenarios provides preliminary evidence of correctness and does not represent exhaustive validation. In addition to static code analysis, future evaluations should include runtime quality metrics (e.g., Google Lighthouse) to assess performance, accessibility, and best practices compliance. The current evaluation does not cover complex user interface scenarios such as role-based rendering, pagination, or advanced state management. These remain areas for future validation.

The observed generation time and modular code structure provide evidence of technical feasibility in the evaluated case.

7 Expert heuristic evaluation

In addition to code-quality analysis and functional acceptance testing, a pilot expert heuristic evaluation was conducted to assess the usability characteristics of the automatically generated user interface. The purpose of this evaluation was not to establish end-user usability statistically, but to identify potential usability problems in the generated prototype and to determine whether the interface conforms to established human–computer interaction principles.

For the pilot inspection, three independent evaluators participated in the expert heuristic evaluation. Their profiles were as follows:

• 1) E1 was a researcher and lecturer at Riga Technical University with more than 8 years of experience in human-computer interaction, usability evaluation, and interaction design.
• 2) E2 was a UX/UI specialist and researcher at Riga Technical University with 12 years of experience in user interface design, user experience, and e-commerce interface design.
• 3) E3 was a software developer and researcher affiliated with Riga Technical University with 15 years of experience in front-end development and UX, including React, Material Design, and accessibility-oriented development.

These profiles were used to obtain complementary assessments of task-flow usability, visual/interface design, and implementation-oriented interaction quality. None of the evaluators participated in the implementation or generation of the evaluated prototype.

The evaluation was based on Nielsen's 10 usability heuristics (Gonzalez-Holland et al., 2017):

• 1) (H1) visibility of system status;
• 2) (H2) match between the system and the real world;
• 3) (H3) user control and freedom;
• 4) (H4) consistency and standards;
• 5) (H5) error prevention;
• 6) (H6) recognition rather than recall;
• 7) (H7) flexibility and efficiency of use;
• 8) (H8) aesthetic and minimalist design;
• 9) (H9) helping users recognize, diagnose, and recover from errors;
• 10) (H10) help and documentation.

The inspection considered the e-commerce workflow represented in the case study, including registration and login, catalog browsing, product inspection, shopping-cart management, checkout, and navigation to the user profile. Each evaluator independently inspected and interacted with the generated runnable prototype by completing the principal e-commerce workflow, including catalog browsing, product inspection, cart manipulation, and checkout. The evaluators subsequently assessed the interface against Nielsen's 10 usability heuristics. Figures 5–7 document representative views of the prototype used during the evaluation. Interaction states that were not implemented or encountered during the evaluated workflow, including detailed validation and error-recovery states, were not inferred and were therefore treated as outside the scope of the present inspection.

Each evaluator first inspected the documented workflow and subsequently assessed the individual views and controls against the 10 heuristics. For every identified problem, the affected interface/view, violated heuristic, description, and severity were recorded separately. After the three inspections were completed, observations referring to the same underlying usability problem were consolidated. The consolidated severity was determined from the median of the ratings assigned by the evaluators identifying the issue. Where an observation could be associated with more than one heuristic, the heuristic describing the primary usability consequence was used for counting purposes, while secondary associations were retained where relevant.

The severity of each usability problem was assessed using a five-point scale:

• 1) 0—not a usability problem: the observation does not require corrective action;
• 2) 1—cosmetic: a minor visual or presentation issue that does not substantially affect interaction;
• 3) 2—minor: a usability problem that may cause limited inconvenience but does not prevent task completion;
• 4) 3—major: a usability problem that can cause substantial difficulty or interfere with successful task completion;
• 5) 4—critical: a usability problem that can prevent task completion or requires correction before deployment.

The three independent inspections produced 22 individual issue observations: eight from E1, seven from E2, and seven from E3. After observations referring to the same underlying problem were consolidated, nine unique usability problems remained. Of these, three were rated cosmetic (severity 1), five minor (severity 2), one major (severity 3), and none critical (severity 4). No consolidated observations were classified as severity 0.

The consolidated findings can be seen in the Table 4. The most frequently affected heuristic was H2—match between the system and the real world, with three consolidated findings, followed by H8—aesthetic and minimalist design, with two findings. Individual findings were additionally associated primarily with H1, H3, H5, and H7. No critical usability violations were identified. H9 could not be assessed as comprehensively as the other heuristics because detailed validation and error-recovery states were not implemented or encountered during the evaluated workflow.

The findings indicate that the automatically generated prototype exhibited predominantly minor or cosmetic usability problems, with one major problem and no critical violations identified. The major issue concerned the absence of a clearly visible order summary in the generated shopping-cart pattern. The remaining observations were mainly associated with terminology, system-state feedback, presentation of internal model attributes, efficiency of cart manipulation, and visual hierarchy.

Importantly, several of these findings can be traced directly to the current transformation strategy rather than to isolated implementation defects. Displaying identifiers, for example, suggests that the concept-to-interface transformation does not yet sufficiently distinguish between domain attributes required internally and attributes meaningful to end users. Similarly, the terms “List Items” and “SHOW CHECKOUT” indicate that process or pattern names can propagate too directly into user-facing interface labels. The findings therefore identify concrete opportunities for improving the pattern library and transformation rules: adding metadata describing attribute visibility, introducing user-facing label mappings, generating persistent state feedback, enriching shopping-cart patterns with order summaries and quantity controls, and improving semantic generation of demonstration data.

These results distinguish technical correctness from interface usability. Successful source-code generation and functional acceptance testing demonstrate that the resulting application can execute the modeled processes, but they do not guarantee that the generated representation of those processes follows optimal interaction-design conventions.

The heuristic evaluation should therefore be interpreted as evidence concerning the usability properties of the generated prototype examined in this case study, rather than as proof of general usability of all interfaces generated by the framework. Moreover, heuristic inspection represents expert judgement rather than direct measurement of user performance or satisfaction. The present heuristic evaluation did not systematically assess accessibility- and runtime-specific characteristics such as keyboard navigation, focus management, screen-reader compatibility, responsive behavior, or recovery from erroneous input. Dedicated accessibility and runtime testing therefore remain subjects for future work.

8 Limitations

A limitation of the current study is the restricted availability of the implementation due to planned commercialization. While this does not affect the validity of the conceptual framework or reported results, it may limit direct reproducibility. This is partially mitigated by the detailed description of the transformation process, but the generator itself is treated as a closed implementation.

The generated artifact is an interactive user interface and therefore its quality cannot be characterized solely in terms of source-code correctness and functional conformance. Relevant HCI properties include usability, accessibility, consistency, visibility of system status, quality of interaction feedback, error prevention and recovery, and cognitive workload. The present framework addresses some of these properties indirectly through reusable interface patterns and consistent component generation, but the transformation rules do not currently encode a complete HCI quality model.

In particular, successful transformation does not guarantee that an interface is optimally usable for a specific user population or context of use. Accessibility properties such as keyboard navigation, screen-reader compatibility, focus management, semantic labeling, and contrast require dedicated validation. Similarly, cognitive workload and interaction efficiency depend on task structure, information density, user expertise, and domain context and cannot be inferred from code-quality or functional acceptance tests.

Accordingly, the framework should be interpreted as a mechanism for producing structurally and behaviorally consistent executable prototypes rather than automatically producing finalized user experiences. The expert evaluation reported in this study provides preliminary evidence concerning interface usability, while broader validation with representative end users, accessibility testing, and workload-oriented measures remains necessary before claims concerning general user-interface effectiveness can be made.

9 Conclusions

This paper presented a model-driven framework for generating user interface prototypes from the two-hemisphere model. The approach integrates process and concept models to produce structurally and behaviorally consistent user interface code.

The evaluation demonstrates feasibility, but limitations remain in platform dependence, pattern selection robustness, and handling of complex user interface logic. Future work will address these challenges and extend support for multiple frameworks and intelligent transformation mechanisms.

This study focuses on the development of a solution for automating user interface prototype generation using the principles of model-driven engineering. The approach is built upon the two-hemisphere model, which integrates conceptual and process-level representations of the problem domain. By applying model transformation techniques, the proposed method enables the automatic generation of front-end source code for web application interfaces, thereby enabling automated generation of executable front-end prototype code while preserving traceability to the underlying process and concept models.

The research began with an exploration of existing methods and techniques for user interface development, identifying reusable design elements and formal representations suitable for automation. A taxonomy of user interface elements and patterns was established to serve as the foundation for a target metamodel, enabling systematic mapping from abstract models to user interface components. To support transformation logic, the two-hemisphere model was extended with process metadata, distinguishing processes relevant for user interface exposure. A transformation mechanism was then developed, allowing the generation of user interface prototypes by translating domain models into structured interface representations.

The solution was implemented and evaluated using an e-commerce prototype case study representing common transactional web-application workflows. In the evaluated case, the generated user interface prototype was functionally consistent with the defined acceptance scenarios and structurally aligned with the source model. The transformation process resulted in executable code that passed the reported static-analysis checks and all defined acceptance-test scenarios.

The results provide preliminary evidence that the two-hemisphere model can serve as a viable source representation for model-driven user interface prototype generation. Unlike UML, which often caters to software architects and may be less accessible to domain experts, the two-hemisphere model offers a semantically rich yet intuitive structure that bridges the gap between business logic and interface design. The research highlights the importance of a well-defined pattern library, where user interface patterns are precisely described, reusable, and compatible with one another. It was also shown that extending the model's notation—such as adding field type attributes or process visibility markers—enhances its capacity to support user interface generation tasks.

The current approach focuses on structural user interface generation and does not fully address advanced personalization or custom design systems. Future extensions will incorporate theming, design tokens, and user-specific adaptations.

The developed approach has potential practical benefits by automating the transformation of modeled domain information into executable prototype code. In the evaluated case, the generator produced a runnable prototype without post-generation source-code modification. However, reductions in total development effort or development time relative to manual, model-based, or AI-assisted alternatives have not yet been established through controlled comparative evaluation. The generated prototypes can support iterative design, early validation, and collaboration between developers and designers. However, these potential development-process benefits have not yet been evaluated experimentally. The solution could potentially be integrated into modeling tools such as BrainTool, which can be further extended with user interface pattern libraries, process prediction features, and support for multiple user interface frameworks.

Despite the promising results, the solution recognizes certain limitations. While the current transformation process supports React.js and Material-UI, extending support to additional frameworks (e.g., Ant Design or Bootstrap) could enhance flexibility and industry applicability. Furthermore, improvements in pattern selection—potentially using machine learning—could further automate and refine the transformation process, especially in more complex domains (Uyanik and Sayar, 2024).

Future research should explore the integration of artificial intelligence to automate pattern selection and composition, thereby reducing the reliance on manual intervention. Investigating how to map the semantics of popular user interface frameworks such as Material Design or Ant Design to transformation logic could further expand the approach's applicability. Additionally, the architecture developed in this paper opens the door to bidirectional transformation and code re-engineering, allowing future systems to maintain consistency between code changes and the originating models.

This study presents a structured and evaluated approach for the automatic generation of user interface prototypes using a model-driven framework grounded in the two-hemisphere model. The research contributes to bridging the gap between domain modeling and user interface implementation, offering a model-driven basis for improving consistency and traceability between domain models and executable user interface prototypes. Comparative efficiency and scalability remain to be established through multi-case experimental evaluation. The proposed solution not only addresses enduring challenges in user interface design and development but also lays the groundwork for further innovation in model-based user interface engineering.

While full source code availability is constrained by commercialization objectives, the presented framework is specified in sufficient conceptual detail to support independent reimplementation and further research.

Generative AI statement

The author(s) declared that Generative AI was not used in the creation of this manuscript.

Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.

Publisher's note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Footnotes

Edited by: Martin Shepperd, Brunel University London, United Kingdom

Reviewed by: Monica Pereira, Brunel University London, United Kingdom

Ade Azurat, University of Indonesia, Indonesia