           Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                    DOI: 10.55612/s-5002-060-009




       A practice for specifying user stories in multimedia
       system design: An approach to reduce ambiguity

                              Carlos Alberto Peláez, Andrés Solano

          Faculty of Engineering, Universidad Autónoma de Occidente, Cali, Colombia
                                  {capa, afsolano}@uao.edu.co



        Abstract. Various agile approaches have guided the development of solutions
        based on a minimum viable product for the use of user stories (USs). These
        approaches provide a generic process for specifying USs for a wide variety of
        solutions. This study presents an original proposal for a practical approach to
        the specification of USs for multimedia systems, expressed using the Essence
        graphical notation language. The practice includes a set of activities,
        techniques, and tools that can be used by professionals to define the USs of a
        multimedia system, and which can help to mitigate potential ambiguity
        problems such as vagueness and insufficiency in formulation. To explore its
        application, a case study was carried out with the participation of two groups of
        professionals: an experimental group, and a control group. The results for the
        analysis factors are promising, and show that by carrying out the activities that
        make up the practice, a work team can achieve the specification of USs at three
        levels of concreteness, which contribute to the reduction of problems of
        vagueness and insufficiency in the USs of a multimedia system. Using this
        approach, the USs can be guaranteed to meet the value proposition of the
        multimedia system that will be implemented.

        Keywords: User stories, Multimedia systems, Specification, Ambiguity.



 1 Introduction

 User stories (USs) originated as one of the elements used in the eXtreme
 Programming (XP) Planning Game. The first written description of these was
 presented in 1998, and stated that customers define the scope of a project "with user
 stories, which are like use cases" [1]. Their use in the field of software development is
 closely linked to agile work approaches, and their main purpose is to articulate the
 way in which a software function will provide value to the user [2].
    The explicit orientation offered by USs for the creation of value for the user
 encouraged the discussion and alignment of aspects related to user experience (UX)
 and the agile paradigm for the development of products based on interactive systems.
 The application of USs as a mechanism to align the UX with the functional aspects of
 the system enabled the emergence of new working techniques, such as the generation
 of US maps [3]. However, their application in the development of interactive




214
          Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                   DOI: 10.55612/s-5002-060-009




software-based systems has been mainly as artefacts that guide the agile development
process based on methodologies such as SCRUM and XP.
   Agile methodologies have undoubtedly enriched the development of software-
based products with new approaches and perspectives [4]. However, while traditional
agile lifecycles such as SCRUM have offered notable contributions to the software
development industry, they also suffer from certain limitations when it comes to
achieving a higher degree of specification in the UX design of a given solution [5].
   In contrast, a multimedia system (MS) is defined as one that allows for value
creation for interested parties through the deployment of an interactive multimedia
experience (IME), using an ethic and responsible design approach, and addresses the
users’ needs, interests and expectations by influencing their human senses via
storytelling using digital media resources [6]. The original motivation for the
realisation of this research work arose from the question of what a traditional agile
methodology such as SCRUM or XP can offer in terms of the specification of USs
associated with an IME [6]. This arose from the potential offered by the use of USs to
carry out the specification of a software system, with a focus on the needs and
interests of the user regarding the solution, while also recognising the intrinsic
limitations arising from the use of a semi-structured language for the specification of
a US. These limitations refer, for example, to the ambiguity that may arise from the
doubtful and imprecise interpretations to which the US can lead, a current problem
that continues to be studied by several authors [7][8].
   Our research offers a new working approach to the process of specifying USs for
IMEs. The proposal is presented in the form of an artefact [9] that represents a
procedure for the specification of USs using the Essence graphical notation language
[10]. The practice includes a work path that defines specific activities, techniques and
tools that can guide multimedia systems development teams. This contribution aims
to mitigate the occurrence of ambiguities, namely vagueness [11] and insufficiency
[12] in the use of USs in the specific domain of multimedia systems development.
The practice was validated via a case study involving two professionals groups: and
experimental and a control group. The outcomes are promising, as the experimental
group successfully met the US specifications, demonstrating a decrease in issues
related to vagueness and insufficiency within the US, in line with the predetermined
analysis criteria.
   This article is organised as follows: Section 2 describes the background related to
this study. Section 3 describes the materials and methods applied in this research.
Section 4 presents the results of the case study. Section 5 contains a discussion of the
results. Finally, Section 6 gives our conclusions and suggestions for future work.



2 Background

2.1 Application of Agile Methodologies to USs

A background study and documentation review were carried out using a systematic
literature review methodology [13], which is widely accepted as a qualitative
approach to research in disciplines such as software engineering [14].



                                                                                              215
            Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                     DOI: 10.55612/s-5002-060-009




    The findings of the study [15] made it possible to identify software engineering,
 human-computer interaction, and, primarily, user-centred design (UCD) as the main
 disciplines on which most of the existing methodologies and frameworks for MS
 development are based. This gives rise to a need for distinct work approaches to
 address the traditional requirements engineering lifecycle [16]. However, emerging
 proposals related to the production of MSs are moving towards the application of
 practices that involve techniques based on agile methodologies for their development
 [17].
    Some authors have reported difficulties in applying agile methodologies to work
 with UX [18]. One of the main reasons for this is the focus on the development
 process in these methodologies. Despite this difficulty, agile approaches also offer
 artefacts such as USs, which favour UX design under a UCD approach, since their
 structure is based on the user's perspective as opposed to the functionality
 requirements of the system [19]. This has led several researchers to adapt agile
 practices and methodologies to work on UX through USs [20]. Such efforts are
 justified given the constraints imposed by traditional requirements engineering on
 UCD in contrast with USs, as shown in Table 1.

 Table 1. Comparison of requirements engineering vs. user stories

         Traditional                    User stories               Analysis for the benefit of UX
        requirements                                                           design
   engineering practices
 Lead to the development        Focus on the generation of
                                                                 Collaborative work and permanent
 of robust documentation        collaborative workspaces
                                                                 communication spaces among
 as a basis for requirements    that promote synchronous
                                                                 stakeholders for the generation of
 analysis, specification, and   and verbal communication
                                                                 user stories favour UX design
 validation                     among stakeholders
 Focus on the                   Focus on the people
 functionalities to be          (commonly the user), the         Discussions with a focus on
 performed by the system,       action to be taken, and its      creating value for the user can
 or how the system should       value proposition                enrich the contribution that the
 behave in different                                             product can offer to the UX
 situations
 Facilitate the application     Favour the application of an     The UX design process is enriched
 of a process flow for          iterative and incremental        through iteration and continuous
 waterfall development          UCD process flow                 advancements that occur as a result
                                                                 of ongoing stakeholder engagement
                                                                 cycles during the production of the
                                                                 solution

    The challenge of integrating UX with agile methodologies has extended to other
 work approaches, such as LEAN UX methodologies for LEAN startups [21]. In its
 convergence between UX and agile work approaches, LEAN UX faces challenges
 that are more related to results than to the production of detailed deliverables (as in
 traditional UX), where the concept of the minimum viable product (MVP) takes on
 special relevance for UX design [22].




216
          Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                   DOI: 10.55612/s-5002-060-009




   The background discussed in this section illustrates the multiplicity of initiatives
around research work focusing on the convergence between UX and agile
methodologies. However, this contrasts with the scarcity of methodologies for the
development of interactive systems and MSs that adopt such techniques within their
development activities and practices. As a result, an initiative that allows for
convergence between the design of interactive MSs and agile techniques focused on
UX has been developed. In particular, it relates to the conception of a minimum
viable systems (MVMS), which defines the specification of an IME [6].
   Table 2 presents a summary that classifies the different forms of existing work
based on a set of characteristics that are relevant to this research. These approaches
have been grouped into three types: traditional LEAN UX, methodologies focused on
the development of interactive systems, and practices focused on the design of a
MVMS. The last of these approaches involves practices based on a LEAN UX
approach specifically for the design of a particular MVMS [17].
   In Table 2, the agile feature indicates whether a set of work approaches uses agile
practices for the development of the solution, whereas the UX feature specifies
whether or not the methodologies are centred on UX principles. The US feature
shows whether a given work approach uses USs as the solution for the solution
specification. The multimedia/interactive system feature indicates whether the focus
of the work is specifically centred on the development of a multimedia/interactive
system. Finally, the full life cycle feature specifies whether or not the work approach
covers the entire life cycle scope for product development.

Table 2. Comparison between LEAN UX-based work approaches and interactive MS
development

                                                              Approaches to the         Practice for
                                    Traditional LEAN
           Feature                                              development of         the design of
                                           UX
                                                                interactive MSs          a MVMS
                                                               No, except for the
            Agile                            Yes                  adaptation of               Yes
                                                                  MPIu+a [23]
                                                               Focused mainly on        Yes; focused
     Embraces the UX                         Yes
                                                                      UCD                on an IME
                                                                 No; traditional
        User stories                         Yes                  requirements                No
                                                              engineering prevails
                                      No; generic and
Based on the development of
                                   potentially applicable
  multimedia/interactive                                               Yes                    Yes
                                    to different types of
          systems
                                          products
        Full life cycle                      Yes                       Yes                    No

   As can be seen, LEAN UX is a working methodology that covers the entire
product lifecycle, and is based on an agile and UX approach. Similarly, it can be
observed that the work approaches for the development of multimedia and interactive
systems prioritise the activities and techniques used in UCD, but there are few




                                                                                                    217
           Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                    DOI: 10.55612/s-5002-060-009




 adaptations of agile and UX-oriented work approaches that are documented and offer
 accurate results. Likewise, the use of traditional requirements elicitation is still a
 dominant practice in the different working methodologies for the development of
 interactive and multimedia systems in the literature [15].
    Considering the aforementioned, the methodologies reviewed for the development
 of MS show limited evidence regarding the utilization and application of best
 practices for US specification. Given that an IME encompasses elements such as
 digital media, sensory perceptions, interaction modalities, responsible design, and
 emotions, it is acknowledged that certain methodologies prioritize US quality.
 Nonetheless, traditional models may neglect aspects like those mentioned above.
 Consequently, the omission of these components could exacerbate issues of
 vagueness and insufficiency in US specifications for MS.


 2.2 Vagueness and Insufficiency and their contribution to ambiguity in user
 stories

 In a recent review by Amna et al. [7] of the state of the art related to ambiguity in
 USs, it is noted that a lack of clarity related to the meaning of a US is one of the main
 aspects contributing to the problem of vagueness, and that this is transversal across all
 linguistic levels [11], particularly when the semi-structured language used for its
 specification is not English [24]. The absence of a clear scope for the development of
 the solution, which would assist in a better interpretation of the US, is also considered
 a significant factor contributing to its vagueness and affecting its implementation
 [25]. In view of this, we highlight works presented by other authors that associate the
 vagueness of a US with the absence of methods for specifying the higher-level
 objectives of the software system [26].
    Another problem associated with ambiguity in the formulation of a US is
 insufficiency, which is related to the possibility that the USs are incomplete in scope
 concerning a task that the user should be able to perform through the use of the
 software system. Several studies have associated this situation with the presence of
 unattended requirements, which do not allow the user to complete the different tasks
 to be performed by the system [27]. Another factor that contributes to insufficiency in
 the formulation of USs is related to scenarios where there is a high degree of
 personnel turnover [28], due to the need for traceability of information about the
 communication between users and the design team during the design and specification
 stages of the software system.
    As a US ambiguity problem, inadequacy can cause uncertainty and confusion
 among developers and other stakeholders, which in turn can lead to delays and
 incorrect implementation of the software system [29].
    In view of the above discussion, this article proposes a practice for the
 specification of USs in the context of interactive MS design, as an alternative to
 traditional work approaches. It can contribute to mitigating potential ambiguity
 problems such as vagueness and insufficiency in its formulation, through the use of
 techniques and tools which reduce the factors that produce such problems.




218
           Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                    DOI: 10.55612/s-5002-060-009




3 Materials and Methods


3.1 Practice for the Specification of US in MS Design: MSUS

The proposed MSUS practice facilitates the elicitation, analysis, specification, and
validation of USs for a MVMS, and is used to ensure the necessary conditions to
proceed with the production of the MVMS. The specification path is responsible for
providing the sequence and form of iteration of the different activities that compose it.
The practice is made up of a series of design patterns, such as the route for the
specification of a US, the activities, techniques, and tools that allow for its
application, and a sub-alpha of US of the MS, which allows the work teams to keep
track of the execution status of the set of activities that make up the practice.




Fig. 1. Structure of the proposed practice for the specification of user stories in the design of
multimedia systems.

   Figure 1 shows the practice for US specification in multimedia system design
(MSUS) as a solution artefact. Its design is based on the principles of Essence, the
graphical notation language of the software engineering standard [10]. Essence is a




                                                                                                    219
            Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                     DOI: 10.55612/s-5002-060-009




 simple model of the challenges that all software development teams face, and is
 coupled with a visual language to capture practices to help teams address those
 challenges. The model includes practices, alphas, activities, roles, etc. [10]. Essence
 enables practices and related knowledge to be expressed in a simple, visual way that
 ensures that they can be easily shared, understood, adopted, adapted and applied, both
 independently and in combination with other practices (such as the MVMS practice
 [17]). In view of this, our practice is designed from the context of the Essence kernel
 solution area of interest. This allows us to visualise the interrelationships between the
 activities, techniques, tools, work products, alphas, and roles involved, in order to
 achieve the purpose and demonstrate the scope of the practice.
    It is important to emphasise that this practice establishes the need to previously
 count on the conception of the IME for the definition of the US. For this reason, the
 techniques proposed for the practice rely on the sources of information identified at
 the conception stage of the IME, such as the value proposition of the MS, a clear and
 concrete definition of the scope of the MVMS, and high-fidelity prototypes.

 Specification route. The route pattern for the US specification is made up of a set of
 activities (shown in Figure 1 as pentagons) and techniques (shown as rectangles),
 following the patterns of the Essence standard graphical notation language [30]. The
 main function of a route is to suggest the flow of activities and their associated
 techniques to the work team. Figure 2 presents a simple illustration of a suggested
 flow for the execution of the activities that make up the pathway [6]. In this case, the
 activity shown in yellow is suggested as the first one used by the work team to initiate
 the process of specifying the US, while the red one represents the activity that finishes
 an iteration during the process.




 Fig. 2. Specification route for a US.

   Table 3 lists the set of activities that make up the practice for the specification of
 USs through the specification path, while Table 4 shows the association between each




220
           Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                    DOI: 10.55612/s-5002-060-009




activity and the techniques involved, and offers a step-by-step process for their
application and a set of associated tools as a foundation guide.

Table 3. Activities making up the US specification practice

                Activity code                        Activity
                     A1          Elicitation of US and its alignment with the IME
                     A2          Analysis of US with a focus on the IME
                     A3          Specification of USs aligned with the IME
                     A4          Validation of USs


Table 4. Activities making up the US specification practice

           Technique
Activity                    Technique                     Step-by-step                         Tools
             code
  A1          T1          A general          1. Identify the set of epic USs at         User stories
                          mapping of         the first level, which support the         map [3]
                          the alignment      general history in which the IME is
                          of the US          inscribed.                                 User story
                          with the IME       2. Order the epic USs from                 generation
                                             beginning to end, taking into              guide [31]
                                             account time or event
                                             considerations                             COBIT
                                             3. Identify the USs that make up           Balanced
                                             the IME at the second level, which         Scorecard
                                             are related to the needs to be             [32]
                                             satisfied, based on the dimensions
                                             of multimedia content, responsible
                                             design, and emotions
                                             4. Establish a cause-and-effect
                                             relationship between the second-
                                             level and first-level USs
                                             5. Define a third level of US
                                             candidates for production
                                             6. Establish a cause-and-effect
                                             relationship between the third-level
                                             and second-level USs
  A2           T2        Analysis of USs     1. Conduct a completeness analysis         Definition of
                                             of the second-level USs in regard to       USs in agile
                                             the epic USs that make up the IME          practices [2]
                                             2. Include, adjust, or modify, the first
                                             and second-level USs
                                             3. Perform a completeness analysis
                                             of the third-level USs in regard to the
                                             second-level USs
  A3           T3        US                  1. Evaluate whether the third-level        Definition of
                         specifications      USs meet the degree of specification       user stories
                                             needed for product USs; if a higher        in agile
                                             degree of granularity is required,         practices [2]
                                             generate a fourth level of USs




                                                                                                       221
            Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                     DOI: 10.55612/s-5002-060-009




            Technique
 Activity                    Technique                     Step-by-step                         Tools
              code
                                              2. Use the priority diagram to specify     US
                                              the USs that are clear to both the         generation
                                              stakeholders and the work team             guide [31]
                                              3. Review the structure of each US,
                                              both at the level of syntax in its
                                              specification and its correct
                                              relationship with the dimensions of
                                              multimedia content, responsible
                                              design, and emotions
                                              4. Make the necessary adjustments to
                                              the general map of alignment
                                              between USs and the IME
                                              5. Define the priority of the USs in
                                              the last level vertically
                                              6. Define the priority of the USs in
                                              the last level horizontally
                                              7. For each US, specify a code, start
                                              and end dates, its dependency on the
                                              relationship with the lower-level USs
                                              that must be produced to complete it,
                                              its degree of completeness, its degree
                                              of development concerning its start
                                              and end date, its priority (vertical
                                              and horizontal) and its predominant
                                              influence on multimedia content,
                                              responsive design, or emotions
      A4        T4        Validation and      1. Define the different scenarios          Validation
                          testing of USs      needed to validate each US                 criteria and
                                              2. Define a validation criterion for       satisfaction
                                              each of the identified scenarios,          conditions
                                              based on the Gherkin structure             [33]
                                              3. Evaluate, discuss, and adjust the
                                              validation criteria with the
                                              participation of stakeholders
                                              4. Evaluate the results obtained in
                                              the performance of tests, in contrast
                                              to the criteria

    To construct the general US alignment map (T1 technique), we use the general US
 map artefact for the MVMS illustrated in Figure 3, specified as a work product in
 practice (see Figure 1). This map allows the design team to conceive a set of epic USs
 that are directly aligned with the scope of the IME. According to the nomenclature
 used for the illustration, stories US1, US2, US3, …, USn are the set of epic USs in the
 MS. The second-level USs, identified as US1.1, US2.1 and US3.1, are produced with
 the aim of allowing the work team to analyse whether the completeness of the epic
 USs of the first level is achieved.
    Finally, the USs associated with codes US1.1.1, US2.1.1, and US1.1.2 are
 subjected to a completeness analysis with the top-level USs. These third-level USs are
 considered candidates for production, meaning the designer can move on to the next



222
           Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                    DOI: 10.55612/s-5002-060-009




stage of MS production. The third-level USs that are shown enclosed in a red box
with red numbering suggest a prioritisation for possible implementation.




Fig. 3. General map of alignment between USs and the IME.

   To facilitate the map construction process, a US specification card was designed
for the MVMS. This card is illustrated in Figures 4 and 5, which show the front and
back of the card, respectively. This artefact is also specified as a work product in
practice (see Figure 1). The design of these artefacts includes several information
elements, which are consistent with the design factors suggested by the general US
alignment map. These data elements are shown in Table 5 below.




Fig. 4. The front of the US card.




                                                                                               223
           Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                    DOI: 10.55612/s-5002-060-009




 Fig. 5. The back of the US card.


 Table 5. Informative elements contained in the US cards

        Element                                           Description
         Code             Represents a unique identifier for the US throughout the development
                          of the MS
    Start/end dates       Dates on which the implementation of the US starts and should finish
   Name of the story      Name assigned to allow the work team to establish an associative
                          relationship with the content of the story and its relationship with the
                          IME
         Level            Specifies the level with which the US is associated, according to the
                          general US map for the IME
      Dependency          Relationship of association between one US and a higher-level US in
                          the overall user story map for the IME
      Completeness        Degree of implementation of the US, which can be represented as a
                          percentage of its implementation
      Traffic light       Visual representation that relates the degree of completeness of the US
                          concerning its degree of completion as planned for the project. Green
                          indicates that the degree of implementation of the US is within the
                          limits agreed with stakeholders; orange indicates a gap between what
                          was agreed with stakeholders and the degree of US implementation;
                          red is represents a very important gap between the implementation and
                          what was agreed with the stakeholders, and the work team and the
                          stakeholders must assess the reasons why this situation has arisen
        Priority          Specifies the priority of the user story, both vertically (V), which is
                          reflected in the last index of its coding, and horizontally (H), as shown
                          by a number in red, for each line of USs arranged at the US level for
                          production, in the general map of alignment of user experiences with
                          the IME (see Figure 3).
      US statement        Corresponds to the statement of the US, based on the following
                          structure: As <Role>+I need+<Action/Objective>+for+<Value




224
          Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                   DOI: 10.55612/s-5002-060-009




      Element                                        Description
                         Proposition>
     Multimedia          Indicates the alignment between the US and the dimensions that
 content/responsible     characterise the MS
   design/emotions


3.2 Research Methodology for Case Study

To guide the process of designing the practice as a solution artefact, this study relies
on the principles of design science research methodology [34]. This methodology
suggests a set of guidelines for its application [9], which are discussed in this paper,
as follows: (i) the basis of a relevant problem (in this case, the limitation of the
current methodologies for the development of MSs oriented towards practices based
on agile approaches); (ii) a practice for the specification of USs for the design of an
MS as a solution artefact; (iii) an evaluation of the design of the practice for the
conception of the MS; and (iv) a description of the contribution and limitations
observed as a result of an evaluation of the practice for the specification of USs in the
design of MSs.
   Based on the above, the following hypothesis was defined based on the description
of the practice, as a validation mechanism for the case study: The application of the
proposed practice for US specification contributes to a reduction in the number of
problems associated with vagueness and inadequacy in the US generation process for
an MVMS.
   This hypothesis was drawn up based on results reported in previous studies [35]
[36] related to ambiguity problems in USs, such as vagueness, inconsistency,
insufficiency, and duplicity [7]. In this case, our study aims to assess the contribution
of the proposed practice for US specification for an MVMS to the specific problems
of vagueness and insufficiency. These problems are of interest since they prevent an
accurate interpretation of the expected structure and behaviour of the system; we
therefore want to prove that the activities, techniques, and tools that make up this
practice are effective in terms of generating the concrete USs for an MVMS.


3.3 Context of the Problem

To carry out an analysis of the potential contribution of the proposed practice for
MSUS to reducing vagueness and insufficiency as problems of ambiguity in
specification, a research project called Coco-Shapes was carried out to explore the
development of an IME in school contexts. This project arose from the need to teach a
second language (in this case, English) to kindergarten and transition children
between four and five years of age in a private school in the city of Cali, Colombia,
which is committed to an educational strategy of bilingualism for people with limited
resources [37]. The school is located in the Siloé neighbourhood, one of the most
socially and economically vulnerable neighbourhoods in the city [38]. One of the
problems addressed by this initiative is the difficulty faced by the Colombian
population in accessing the learning of a second language in public and private
schools in less prosperous communities [39]. An MS was therefore developed based



                                                                                              225
           Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                    DOI: 10.55612/s-5002-060-009




 on a MVP [17] related to an IME, based on gamification techniques [40]. Currently,
 the school has a population of about 140 students between kindergarten and fifth
 grade.
    Coco-Shapes includes activities related to the themes of colours, shapes, and
 counting. In addition, the solution includes a physical object (with buttons and
 geometric shapes) and digital resources that are displayed on a tablet, as shown in
 Figure 6. In activities involving geometric figures, children must insert the
 corresponding figures into the physical object, whereas in the colour activities,
 students must press the coloured buttons that are also found on the physical object.
 Finally, in the counting activities, children must select the correct option on the
 screen. These activities are divided based on grade levels, and there are three levels of
 difficulty, which strengthen different abilities of the student.




 Fig. 6. The Coco-Shapes object and its components.


 3.4 Formation of Work Teams

 Over a period of one month, 10 professionals (age range between 25 and 30 years)
 with average experience of 4 years MS development and two tutors (leaders with PhD
 degrees and senior experience in MS development) implemented the practice for the
 US specification of Coco-Shapes.
    Two homogeneous groups were formed: a control group, and an experimental
 group. Each was composed of five professionals, and remained unchanged throughout
 the process. Each group developed the specification of the US according to the needs
 of the Coco-Shapes MS under the guidance of a tutor; the control group followed the
 traditional approach defined by SCRUM, while the experimental group used the
 proposed practice for US specification of an MVMS.

 3.5 Validation Mechanisms

 Table 6 lists a set of factors that were defined to facilitate the analysis and evaluation
 of the hypothesis. These factors correspond to those studied during validation, where




226
           Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                    DOI: 10.55612/s-5002-060-009




F1, F2, and F3 correspond to problems of vagueness, and F4 and F5 correspond to
insufficiency detected in the US [7].

Table 6. Factors considered in the analysis of the case study

           Identifier                       Analysis factors
              F1        Number of vagueness issues related to the structure of the US
              F2        Number of vagueness problems related to unclear words
              F3        Number of vagueness problems related to semantics
              F4        Number of incomplete USs
              F5        Number of unattended requirements of the solution

   The first factor (F1) refers to the number of USs that do not comply with the basic
structure, which should include three elements: the role, the action/objective, and the
value proposition. The second (F2) refers to the use of words in the US whose
meaning is not clear to stakeholders, as they are technical business terms or terms that
suggest subjectivity in a US (such as ‘many’, ‘few’, ‘high’, ‘low’, ‘several’,
‘different’, etc.). The third factor (F3) refers to the absence or imprecision of a
specific, meaningful scope, which results in an equivocal interpretation of the US.
The fourth factor (F4) consists of the number of USs that omit details of the
functionalities desired by the user. Finally, the fifth factor (F5) relates to the number
of system requirements that are consistent with the scope of the solution but are not
expressed by the US.
   In the case study, the total set of USs produced by the work teams was considered
in the analysis of the factors defined above. When each team had completed the US
specification process, the coach for that team assumed the role of evaluator for each
analysis factor.


4 Results of the Case Study

Before conducting the case study, the work teams collaboratively surveyed the
stakeholders of the Coco-Shapes multimedia experience by interviewing the teachers
and directors of the school. This process allowed them to determine the needs of the
stakeholders (managers, teachers, and students), the learning objectives and the
activities associated with each of them, the context of the use of the system, and the
hardware components, software, and physical objects that made up the solution. The
pre-production of Coco-Shapes allowed the value proposition of the systems to be
identified and the scope of the MVMS to be defined, and enabled a series of high-
fidelity prototypes of the multimedia experience to be produced. All of these are
important inputs to the US specification. The following sections describe the process
and the results achieved by the control and experimental groups.




                                                                                               227
              Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                       DOI: 10.55612/s-5002-060-009




 4.1 Results from the Control Group


 Process. The control group followed the traditional approach defined by SCRUM
 [32], which consisted of the following stages:

       1.   Identification of epics
       2.   Definition of the USs related to each epic
       3.   Specification of acceptance criteria for each US
       4.   Prioritisation of the USs

    The work team implemented these stages over one month, under the supervision of
 a tutor, and obtained the results presented in Table 7. It is important to mention that
 during the course of this month, the work team carried out two iterations of analysis
 and adjustments to the USs, based on meetings with stakeholders.

 Table 7. Overall results for the control group

               Analysis                                Tutor's Observations
 Identifier
                factors
 Epics         10           The epics were grouped based on the following elements: learning
                            activities for kindergarten grade (3) and transition grade (3), teacher
                            (2), physical object (1), and system control (1).
                            The team wrote the epics and USs based on an analysis of information
                            collected previously, such as stakeholder needs, learning objectives and
                            activities, value proposition, high-fidelity IME prototypes, and the
                            journey map. In this process, physical (Post-it notes) and digital
                            (Google Jamboard) resources were used. The colours of the Post-it
                            notes helped in representing the US groups.
 US            61           The professional team maintained active and assertive communication
                            with the school's stakeholders, and held a weekly one-hour meeting in
                            which they asked questions about the details of the US acceptance
                            criteria.


 Problems identified by the control group. The tutor detected problems with
 vagueness in the written USs related to unclear words; for example, sample US18
 included a word (underlined below) for which the meaning is not clear, and is
 subjective for the development team.

      US18: As a <kindergarten student> I want < to fish a series of objects from a pool
      by pressing coloured buttons on the physical object>, which <helps me to identify
      colours in the English language>.

   In addition, the US32 sample had inaccuracies in its scope, which may lead to
 misinterpretation of the US. From the fragments underlined below, it is not clear how
 many colours should be pressed and where the user should perform the action (tablet




228
           Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                    DOI: 10.55612/s-5002-060-009




or physical object), and it is also difficult to identify the context in which the audio
should be played.

   US32: As a <transition student>, I want <to press colours for the main character to
   prepare cotton candy, while audio sets the scene for the activity> so that <I can
   learn the secondary colours resulting from the combination of the primary colours
   and their representation in English>.

   Other USs omitted details of the desired functionalities in Coco-Shapes, as was the
case for US41, since the user's action, the number of tables to include, and the specific
data to be observed from each were not specified.

   US41: As a <teacher>, I want <tables and texts that tell me the scores of my
   students for each activity> so that <I can get all the information on my students'
   scores>.


4.2 Results from the Experimental Group

Process. The experimentation group followed the practice activities for the
specification of US in multimedia system design, in the following order:

    1. Definition of epics associated with the MVMS value proposition and the
       EMI event flow, according to the scope of the solution.
    2. Division of first-level epics based on the following elements: digital media,
       sensory perceptions, interaction modalities, responsible design, and
       emotions.
    3. Division of the second-level epics into other specific USs that will be put
       into production by the development team.
    4. Assignment of priorities to third-level USs.
    5. Definition of a series of validation criteria for each third-level US.
    6. Elaboration of the general map of US alignment with the IME.

  The work team implemented these stages over a period of one month, under the
supervision of a tutor, and obtained the results shown in Table 8. Similarly to the
control group, the team conducted two iterations of analysis and adjustments to the
US, based on the stakeholder meetings.

Table 8. Overall results for the experimental group

            Quantity                          Tutor's Observations
  First-      10     The epics were grouped based on the following elements of the IME:
  level              system configuration, story character, physical object, colour
  epics              identification, colour combinations, identification of geometric figures,
                     association of geometric figures with real objects, counting from one to
                     10, counting from one to 20, and student progress.




                                                                                               229
               Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                        DOI: 10.55612/s-5002-060-009




                Quantity                          Tutor's Observations
     Second-      35     The team used the Miro software tool1 to divide the first-level epics
      level              into the following types: digital media, sensory perceptions, interaction
      epics              modalities, responsible design, and emotions.

     Third-         98       The team of professionals maintained frequent communication with the
      level                  school's stakeholders, holding at least one meeting per week where they
      epics                  raised questions to refine the US validation criteria.


 Issues identified in the experimental group. The tutor detected vagueness problems
 in the written USs that were related to unclear words; for example, sample US4.1.1
 included a word (underlined below) whose meaning is not clear, and is subjective for
 the development team. In addition, US5.1.3 refers to "a button", but it is not clear
 whether the button is shown on the tablet or forms part of the physical object.

      US4.1.1: As a <student>, I want <the multimedia experience to include animations
      and eye-catching 2D images of Coco fishing for objects in a pool, a reproduction
      of the instructions and coloured buttons on the physical object that can be pressed>
      that will <help me to identify colours in the English language>.

      US3.1.3: As a <student>, I want <a multimedia system that uses animations and
      2D images to show Coco spinning a roulette with the names of the colours written
      on it, which stops when I press a button, and the name of the colour is stated via
      audio> so that <I can easily recognise the colours presented on the display device>.

      US10.3.4 presented a problem of insufficiency, as it did not include enough detail
      about the specific data that the teacher expects to see in the report.

      US10.3.4: As a <teacher>, I want <the multimedia system to allow me, via a touch
      screen, to see the score for each student> so that <I can manage all of my students'
      information>.


 4.3 Overall Results

 Table 9 presents the results for each analysis factor considered by the control and
 experimental groups, which were evaluated by the respective tutor. The analysis
 factors were applied to the total number of USs specified by each group. The ratio
 shown in the table was calculated by dividing the number of problems for each factor
 by the total number of USs specified by each group.




 1
     URL: https://miro.com/es/




230
           Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                    DOI: 10.55612/s-5002-060-009




Table 9. Comparison of analysis factors

                                           Control                    Experimental
Factor     Analysis factor        Type                Ratio                                    Ratio
                                            group                        group
  F1     Number of                Epic         1       0.1                 0                    0
         vagueness issues         US          37   0.60655738              0                    0
         related to the
         structure of the US
  F2     Number of                Epic         0            0                 0                0
         vagueness issues         US           5       0.08196721            10           0.10204082
         related to unclear
         words
  F3     Number of                Epic         0            0                 0               0
         vagueness issues         US           5       0.08196721             4          0.040816327
         related to semantics
  F4     Number of                Epic         0            0                 0                0
         incomplete USs           US           3       0.04918033             4          0.040816327
  F5     Number              of   Epic         1           0.1                0                0
         unattended               US          41       0.67213115             2           0.02040816
         requirements of the
         solution

   Figure 7 presents a comparison of the average overall ratios for the control and
experimental groups, considering the overall results in the factors under study. It can
be seen that there is a reduction of approximately 10% in the number of ambiguity
problems in the set of USs formulated using the proposed MSUS practice.




Fig. 7. Comparison of the average ratios between groups.

   Figure 8 presents a comparison between the average ratios of the control and
experimental groups for the factors related to vagueness and inadequacy, as explained
in Table 6 in Section 3.5. It can be seen that the proposed MSUS practice contributed




                                                                                                       231
           Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                    DOI: 10.55612/s-5002-060-009




 significantly to a reduction in the number of US ambiguities related to insufficiency
 factors and, to a lesser extent, to those related to vagueness.




 Fig. 8. Comparison of factors between the control and experimentation groups.



 5 Discussion of Results

 From the general results for the analysis factors (see Figure 7), we see that the
 average of the overall proportion between the control and experimental groups shows
 that there are differences between each group with a significance of 10%. This
 indicates that the experimental group obtained a lower number of ambiguity problems
 in the set of USs formulated using the proposed MSUS practice. This can be
 considered a positive result, since the professionals who were part of the control and
 experimental groups were people with experience in the development of MSUS.

    Regarding the formulation of the epics, the results in Table 9 for the control and
 experimental groups could be interpreted as not having a major impact on the
 specification of the MVMS. However, this interpretation can be seen to be inaccurate
 when the specification scope of the epics is compared with the scope of the MVMS,
 because, since it is epic, it implies that the set of USs associated with the IME was not
 considered. In this case, the control group did not consider a key element of the IME
 in the form of the main character, Coco, the spectacled bear. Since this IME is aimed
 at children, this character plays an important role in the child's interactive relationship
 with the system, and is therefore a crucial element. The absence of the epic had a
 noticeable impact on the US comparison concerning the IME scope.
    Each analysis factor considered in the formulation of the US is discussed below.
    For factor F1, a difference was found between the control group and the
 experimental group. The tutor of the control group detected that the professionals
 analysed the inputs before specifying the USs, and focused strictly on the actions
 performed by the user in the system, i.e., the moments of interaction between the user



232
          Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                   DOI: 10.55612/s-5002-060-009




and the system. Meanwhile, the experimental group, in addition to specifying USs
involving user actions, also identified other USs associated with multimedia content
objectives, responsible design, and emotions, thanks to the T3 technique included in
the proposed MSUS practice.
   For factor F2, we note that since the experimental group identified a greater
number of USs, more vagueness problems were found related to unclear words. The
tutor of the experimental group identified that when writing USs related to
multimedia content, responsible design, and emotions, the professionals tended to use
subjective words to specify the characteristics of the system in terms of its design,
such as ‘eye-catching interface’, ‘funny bear’, and ‘funny music’.
   A significant difference was observed for factor F3. This suggests an important
contribution from the T3 technique, since it promotes the revision of the degree of
specification of the US, as well as its correct structure. The tutor of the experimental
group recognised that the time invested in carrying out the steps of the technique was
extensive, but completing all the steps contributed significantly to achieving a greater
degree of certainty regarding the vagueness factor under study.
   For factor F4, it is evident that the difference between the ratios is small. Although
the tutors emphasised the rigorous work done by the teams in terms of active
communication with the stakeholders, it was noted that the experimental group was
able to do a better job thanks to the information given on the front of the cards to
assist in writing the USs. The "dependency" and "completeness" fields were important
in reducing the number of incomplete USs, as they allowed the work team to maintain
better traceability of USs related to the same action or objective.
   Finally, for factor F5, we observed an interesting difference between the control
group and the experimental group. The tutor of the experimental group highlighted
the following aspects of the process:

    •    The use of first-level epics allowed the experimentation group to write a set
         of epics that ensured the value proposition and scope of the IME of MVMS
         for the different roles involved in the use of Coco-Shapes.
    •    At the second level, the experimentation group defined a set of epics with a
         higher degree of concreteness than the previous ones, which were classified
         based on the structural components of the IME: digital media, sensory
         perceptions, interaction modalities, responsible design, and emotions.
    •    At the third level, the experimentation group was able to write a set of USs
         for subsequent implementation with a high degree of concreteness. The use
         of the overall US alignment map made it possible to have a global view of
         how the USs were aligned with the second-level epics and were organised by
         the team according to their priority.

   Overall, the results for the ambiguity factors are promising in terms of the
contribution of the proposed MSUS practice to reducing the problems of vagueness
and insufficiency when writing USs. The results of our evaluation of the ambiguity
factors provide evidence that a satisfactory degree of compliance with the hypothesis
raised by this study was achieved (see Section 3.2) when the work carried out by the
control and experimental groups in the specification of USs was contrasted.




                                                                                              233
           Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                    DOI: 10.55612/s-5002-060-009




    Finally, comments derived from the application of the practice by members of the
 experimental team are presented, indicating an optimistic outlook regarding the
 utilization of the practice.

      •   The activities within the specification route are deemed highly beneficial for
          transitioning to the solution’s implementation phase. The template
          established for the user story and validation criteria, particularly the
          scenarios, provide precise guidance on implementing the user stories.
      •   The route recommends creating a user story alignment map, serving as a
          crucial foundation for planning the implementation. This includes
          prioritizing the user stories.
      •   Decomposing user stories across three levels proved to be a complex
          experience; however, it is noteworthy that the third level of user stories
          attained a commendable degree of precision.
      •   As a team, experienced a sense of calm during user story specification
          process, as each prescribed activity provided us with a set of specific
          techniques for execution.


 6 Conclusions and Future Work

 Based on the discussion of results presented in this study, it can be concluded that the
 proposed MSUS practice has shown its effectiveness in terms of its application, and
 can contribute to a reduction in the number of ambiguity problems in the specification
 of USs where the scope of the IME of MVMS governs the specification process
 carried out by a work team. These results motivate us to apply the MSUS practice in
 other contexts of use, and to study the overall impact on the solution design process
 via variables such as the time invested in the specification of USs, the number of
 iterations, the user's level of experience and work style, and others that fall outside the
 scope of this research.
    In addition to the above, there is an opportunity to evaluate the potential
 contribution of the proposed MSUS practice to the development of MS by teams
 whose professionals have a basic level of experience.

 CRediT author statement. Carlos Alberto Peláez: Conceptualization,
 Methodology, Formal analysis, Writing – original draft preparation. Andrés Solano:
 Methodology, Validation, Writing – review and editing.


 References

 1.   Beck K.: Extreme Programming Explained: Embrace Change, Addison-Wesley
      Professional (1999)
 2.   SCRUMstudy™, Una Guía para el Cuerpo del Conocimiento de SCRUM,
      SCRUMstudy™, Avondale, Arizona, 2017




234
           Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                    DOI: 10.55612/s-5002-060-009




3.    Patton J., Economy P.: User Story Mapping: Discover the Whole Story, Build the Right
      Product, O'Reilly Media, Inc. (2014)
4.    Ivar Jacobson International, Essence - Agile Software Development Best Practice,
      https://www.ivarjacobson.com/lean-agile/Essence-agile-software-development-best-
      practice
5.    Xu, X., Dou, Y., Qian, L., Zhang, Z., Ma, Y., & Tan, Y.: A Requirement Quality
      Assessment Method Based on User Stories. Electronics, 12(10), 2155 (2023).
      https://doi.org/10.3390/electronics12102155
6.    Peláez C., Solano A., Granollers T.: Proposal to conceive multimedia systems from a
      value creation perspective and a collaborative work routes approach, Interaction Design
      and Architecture(s), 49, pp. 8–28 (2021). https://doi.org/10.55612/s-5002-049-001
7.    Amna R., Poels G.: Ambiguity in user stories: A systematic literature review, Information
      and Software Technology, p. 106824 (2022). https://doi.org/10.1016/j.infsof.2022.106824
8.    Kuhail, M. A., & Lauesen, S.: User Story Quality in Practice: A Case Study. Software,
      1(3), 223-243 (2022). https://doi.org/10.3390/software1030010
9.    Hevner A.R., March S.T., Park J., Ram S.: Design science in information systems
      research, MIS Quarterly, pp. 75–105 (2004). https://doi.org/10.2307/25148625
10.   Object Management Group: Essence – Kernel and Language for Software Engineering
      Methods, OMG (2018)
11.   Kamthan P., Shahmir N.: Effective user stories are affective. in: Ubiquitous Computing
      and Ambient Intelligence, 11th International Conference, Philadelphia, PA, USA (2017).
      https://doi.org/10.1007/978-3-319-67585-5_59
12.   Melegati J., Wang X.: QUESt: New practices to represent hypotheses in experiment-
      driven software development. In: Proceedings of the 2nd ACM SIGSOFT International
      Workshop on Software-Intensive Business: Start-ups, Platforms, and Ecosystems, New
      York, NY, USA (2019). https://doi.org/10.1145/3340481.3342732
13.   Kitchenham B., Charters S.: Guidelines for performing systematic literature reviews in
      software engineering, (2007)
14.   Genero M., Piattini M., C.-L. J.A.: Métodos de investigación en ingeniería del software,
      Grupo editorial RA-MA (2014)
15.   Peláez C., Solano A., Granollers T., Collazos C.: Methodologies and trends in multimedia
      systems: A systematic literature review, Lecture Notes in Computer Science, Orlando,
      FL, USA, Springer, pp. 109–127 (2019). https://doi.org/10.1007/978-3-030-21902-4_9
16.   Sommerville I.: Software Engineering, Pearson, London (2016)
17.   Peláez C., Solano A.,Granollers T.: Proposal of a practice to conceive a minimum viable
      multimedia system, IEEE Latin America Transactions, 19(9), pp. 1590–1598 (2021).
      https://doi.org/10.1109/TLA.2021.9468613
18.   NN/G Nielsen Norman Group: Agile is not easy for UX. (How to) Deal with it,
      https://www.nngroup.com/articles/agile-not-easy-ux/
19.   Choma J., Zaina L.A., Beraldo D.: Userx story: Incorporating UX aspects into user
      stories elaboration, International Conference on Human-Computer Interaction, Toronto,
      Canada (2016). https://doi.org/10.1007/978-3-319-39510-4_13
20.   Ananjeva A., Persson J.S., Bruun A.: Integrating UX work with agile development
      through user stories: An action research study in a small software company, Journal of
      Systems and Software, 170, p. 110785 (2020). https://doi.org/10.1016/j.jss.2020.110785
21.   Ries E.: The lean startup: How Today's Entrepreneurs Use Continuous Innovation to
      Create Radically Successful Businesses, Portfolio Penguin, London (2011)
22.   Gothelf J., Seiden J.: Lean UX: Designing Great Products with Agile Teams, O'Reilly
      Media, Inc., USA (2017)
23.   Moré A.: MPIu+ a Ágil: El Modelo de Proceso Centrado en el Usuario como
      Metodología Ágil, Universidad de Lleida, Lleida (2010)




                                                                                               235
            Interaction Design and Architecture(s) Journal - IxD&A, N.60, 2024, pp. 214 - 236
                                     DOI: 10.55612/s-5002-060-009




 24.   Gazzerro S., Marsura R., Messina A., Rizzo S.: Capturing user needs for agile software
       development. In: Proceedings of the 4th International Conference in Software
       Engineering for Defence Applications (2016). https://doi.org/10.1007/978-3-319-27896-
       4_26
 25.   Lin J., Yu H., Shen Z., Miao C.: Using goal net to model user stories in agile software
       development. In: 15th IEEE/ACIS International Conference on Software Engineering,
       Artificial Intelligence, Networking and Parallel/Distributed Computing, Las Vegas, NV,
       USA (2014). https://doi.org/10.1109/SNPD.2014.6888731
 26.   Araujo L., Siqueira F.: Using i* with Scrum: An Initial Proposal. In iStar (pp. 19-24).
       (2016)
 27.   Thamrongchote C., Vatanawood W.: Business process ontology for defining user story.
       In: IEEE/ACIS 15th International Conference on Computer and Information Science
       (ICIS), Okayama, Japan (2016). https://doi.org/10.1109/ICIS.2016.7550829
 28.   Sohan S.M., Richter M.M., Maurer F.: Auto-tagging emails with user stories using
       project context. In: International Conference on Agile Software Development,
       Trondheim, Norway, (2010). https://doi.org/10.1007/978-3-642-13054-0_8
 29.   Gilson F., Irwin C.: From user stories to use case scenarios: Towards a generative
       approach. In: 25th Australasian Software Engineering Conference (ASWEC), Adelaide,
       SA, Australia, (2018). https://doi.org/10.1109/ASWEC.2018.00016
 30.   Jacobson I., Ng P.W., McMahon P.E., Goedicke M.: The Essentials of Modern Software
       Engineering: Free the Practices from the Method Prisons! Morgan & Claypool (2019).
       https://doi.org/10.1145/3277669.3277673
 31.   Cohn M.: User Stories Applied: For Agile Software Development, Addison-Wesley
       (2004)
 32.   ISACA, Marco de Referencia COBIT® 2019: Introducción y Metodología, ISACA,
       Schaumburg, IL 60173, USA (2018)
 33.   Cohn M.: Agile Estimating and Planning, Pearson Education (2005)s
 34.   Geerts G.: A design science research methodology and its application to accounting
       information systems research, International Journal of Accounting Information Systems,
       12(2), pp. 142–151 (2011). https://doi.org/10.1016/j.accinf.2011.02.004
 35.   Müter L., Deoskar T., Mathijssen M., Brinkkemper S., Dalpiaz F.: Refinement of user
       stories into backlog items: Linguistic structure and action verbs: Research preview. In
       Requirements Engineering: Foundation for Software Quality: 25th International Working
       Conference, REFSQ 2019, Essen, Germany (2019). https://doi.org/10.1007/978-3-030-
       15538-4_7
 36.   Dilorenzo E., Dantas E., Perkusich M., Ramos F., Costa A., Albuquerque D., Perkusich
       A.: Enabling the reuse of software development assets through a taxonomy for user
       stories,       IEEE         Access,        8,       pp.       107285–107300       (2020).
       https://doi.org/10.1109/ACCESS.2020.2996951
 37.   Fundación Able: Colegio La Fontaine, http://fundacionable.org/lafontaine/
 38.   Universidad Icesi: Repositorio Biblioteca Digital - Universidad Icesi,
       https://repository.icesi.edu.co/biblioteca_digital/bitstream/10906/65186/1/comuna_veinte.
       pdf
 39.   INFOBAE: Fedesarrollo alertó sobre la calidad educativa en Colombia: Aunque hay
       mayor cobertura hay menor desempeño, El País (España), 06 02 2023.
 40.   Peláez C., Solano A.: A practice for the design of interactive multimedia experiences
       based on gamification: A case study in elementary education, Sustainability, 15(3), p.
       2385 (2023). https://doi.org/10.3390/su15032385




236
