Articulating Socially Aware Design Artifacts and User Stories in the
Conception of the OpenDesign Platform
ulio C
esar Dos Reis
1 a
, Andressa Cristina Dos Santos
1 b
, Emanuel Felipe Duarte
1 c
ıcio Matheus Gonc¸alves
1 d
, Breno Bernard Nicolau de Franc¸a
1 e
, Rodrigo Bonacin
2 f
and M. Cecilia C. Baranauskas
1 g
Institute of Computing, University of Campinas, Campinas, Brazil
Center for Information Technology Renato Archer, Campinas, S
ao Paulo, Brazil
Socially Aware Design, Participatory Design, User Stories, Requirements Engineering, OpenDesign.
Gathering and understanding requirements and features in a system play a central role in its acceptance and
proper use. Unconventional systems involving uncertainties about their requirements demand methods that
adequately support the capture of stakeholder’s needs, desires and objectives. The OpenDesign project aims at
supporting the design of computational solutions to wide-ranging problems under a holistic and socially-aware
perspective through an open and collaborative platform. Designing this platform with a proper understanding
of the desired features is for sure a hard task. In this paper, we investigate and characterize an ideation process
to be used in situations involving uncertainties about requirements, as experienced in the OpenDesign Project.
This process involves the collaborative construction of user stories, articulated with Socially Aware Design
artifacts, created through participatory practices, as part of the platform design and prospection of potential
uses of it. Based on the results, we organize the core concepts permeating the OpenDesign proposal, expressed
in a map synthesizing its features.
In recent years, the unwanted impacts computer sys-
tems can have on economic, ethical, political, and so-
cietal issues have become more evident. Several cases
reported in international and national media illustrate
these impacts, such as the Volkswagen Scandal, one
of the largest auto companies, which admitted in 2015
(with deployment to date) to have developed software
that alters pollutant emissions results (G1, 2015). In
the Brazilian context, the eSocial platform was also
criticized by renowned Brazilian researchers, high-
lighting what he called “gross errors”, such as not
considering zip codes, email address format, and even
worrying with the level of computer proficiency on
the part of potential users (G1, 2019). Such problems
seem to stem from a software development view that
does not privilege the social world in which solutions
are used and make sense; that is, a view that does not
consider software development as a socio-technical
activity. Such a diagnosis was already point out in
the area of industrial design since the 1970s by Pa-
panek (Papanek, 1971), who highlighted the impacts
caused by a culture driven by economic and technical
issues while neglecting the social context of design,
the intended audience and society in general.
In this sense, open-source communities some-
times excel at creating quality software products,
emerging from their philosophy, governance and par-
ticipation. The phenomenon of open-source dis-
tributed development has drawn the attention of the
scientific community to ways in which open source
communities articulate themselves. However, litera-
ture does not reports about extensive community ef-
forts similar to open-source in the design of interac-
tive systems, as activities preceding code develop-
ment itself, such as clarifying the design problem and
proposing alternative solutions.
The OpenDesign Project (Baranauskas, 2017) is
situated in this context, which stems from the ab-
Reis, J., Santos, A., Duarte, E., Gonçalves, F., Nicolau de França, B., Bonacin, R. and Baranauskas, M.
Articulating Socially Aware Design Artifacts and User Stories in the Conception of the OpenDesign Platform.
DOI: 10.5220/0009418205230532
In Proceedings of the 22nd International Conference on Enterprise Information Systems (ICEIS 2020) - Volume 2, pages 523-532
ISBN: 978-989-758-423-7
2020 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
sence of open environments for software system de-
sign that involves stakeholders with a socio-technical
perspective, and integrates various artifacts, methods,
guidelines, and tools to support different stages of a
project. OpenDesign is based on principles associated
with agile (Beck et al., 2001) and lean (Poppendieck
and Poppendieck, 2003) methods of software deve-
lopment, as well as open-source movements. The
aim is to obtain open collaboration, egalitarianism,
meritocracy and self-organization. Additionally, the
project is based on theories, practices and methods of
Organizational Semiotics (Liu and Li, 2014), Univer-
sal Design (Connell et al., 1997), and Participatory
Design (Muller et al., 1997). In general, OpenDesign
aims to provide an approach and software platform
to support the design of computational solutions in a
systemic and socially conscious view, starting from
the initial activities of understanding the problem and
proposing solution ideas.
Existing literature lacks studies in the direction of
our investigation. Boisseau et al. (2018) presented
a literature review related to the concept of open-
design. Although it contributes to disseminate the
open approach, their work emphasized product de-
sign. Our work presents further concerns related to
technology design and our approach to design in-
cludes addressing early problem clarification steps.
Investigations have described the benefits of partici-
patory practices and user stories in software develop-
ment. Kautz (2011) presented an exploratory study
to assess user participation in agile software develop-
ment projects. Lucassen et al. (2016) studied the per-
ceived effectiveness of user stories by showing bene-
fits in employing user stories in everyday work envi-
This work contributes to the early stages of the
‘open’ process for system design. In this paper,
we propose: (1) a meta-design template to support
OpenDesign practices, and (2) a process template
for requirements clarification. First, the concept of
OpenDesign was clarified in a collaborative dynamic
with the following artifacts of Socially Aware Design:
Stakeholders Diagram (SD), Evaluation Frame (EF),
and Semiotic Framework (SF). In the following, we
conducted the clarification, creation and prioritization
of user stories for the OpenDesign platform. The pro-
cess featured a practice inspired by Participatory De-
sign and resulted in a set of user stories from various
stakeholders involved in the process. Based on user
stories, a concept map was collaboratively built by or-
ganizing feature groups for the platform.
We highlight the key contributions of this article
as follows: (1) the instantiation of a Socially Aware
Design process for ideation to be used in situations in-
volving uncertainties about requirements, as we expe-
rienced in the OpenDesign platform proposal, promo-
ting solutions that make sense to stakeholders; and (2)
clarification and organization of the requirements for
building a collaborative platform that can openly pro-
mote system design. This includes the selection, cre-
ation, adaptation, and experimentation of techniques
and artifacts in the early stages of system design.
This paper is organized as follows: Section 2
presents the theoretical and methodological founda-
tions of Participatory Design, Socially Aware Design
and User Stories; Section 3 presents the dynamics of
activities conducted, which reflects the methodologi-
cal path taken in the ideation of the OpenDesign Plat-
form; Section 4 presents and discusses results of this
process with respect to the OpenDesign concept and
the feature concept map that characterizes the Open-
Design platform; finally, Section 5 presents the con-
clusion remarks.
In the OpenDesign perspective, the design of inte-
ractive systems is understood as a social process that
involves both the characterization of the design pro-
blem and its solution. It involves a dialogue not only
of the designer with the design materials as proposed
by Sch
on (1990), but also mainly among the indivi-
duals participating in the process (e.g., designers, de-
velopers, users and other stakeholders). This dialogue
contrasts various design views and various ways of
framing design situations. Several artifacts (informal,
formal and technical) are used as communication and
mediation tools among participants during the pro-
cess of creating the interactive system (Baranauskas,
2009, 2014). Thus, system functionalities should be
defined based on the understanding of the stakehol-
ders’ needs, their aspirations and objectives. To this
end, it is necessary to enable the effective participa-
tion of stakeholders in the process, from joint cla-
rification of the problem to the definition of system
functionalities in design. In this paper, this process is
supported by techniques and practices based on Parti-
cipatory Design, Socially Aware Design, and collabo-
ratively constructed User Stories. These concepts are
described in the following subsections.
ICEIS 2020 - 22nd International Conference on Enterprise Information Systems
2.1 Participatory Design
The Participatory Design is characterized by the ac-
tive participation of system end-users throughout the
software design and development cycle (Vieira and
Baranauskas, 2003). More than sources of informa-
tion, end-users (and other stakeholders) perform ef-
fective contributions at every stage of the design and
development cycle, reflecting their perspectives and
needs. The quality in the design and the resulting
system is a consequence of the mutual learning and
combination of backgrounds from the various partici-
Participatory Design methods are characterized by
the use of simple techniques and small compromise of
materials or digital resources; Brainstorming, Story-
boarding, and Workshop techniques are widely used.
Participatory practices extend throughout the (con-
ventional) software life cycle. Muller et al. (1997)
presented a collection of 61 participatory practices
used at different stages of the system life cycle (pre-
design, design, evaluation, post-design). Our work
does not focus on a specific practice, but on a more
systemic view, uses ideas, practices and principles
existing in Participatory Design as a way to stimu-
late the effective participation of stakeholders in the
understanding of functionalities.
2.2 Socially Aware Design
Socially Aware Design (Baranauskas, 2014) aims at
supporting the work of understanding problems con-
sidering technical, formal and informal aspects in the
design process. In this framework, it is assumed that
a design solution depends on and impacts on the for-
mal and informal aspects of organizations and society
towards the construction of a technical solution. So-
cially Aware Design consists of a set of artifacts and
practices for clarifying the problem, including the SD,
EF, and SF, some of which originated in Organiza-
tional Semiotics (Liu, 2000; Liu and Li, 2014). These
artifacts are used to support the design problem clari-
fication and the proposition of ideas and/or solutions
to different stakeholders. They support the unders-
tanding of social and technical issues involved in the
problem, without losing their relation to the situated
context of the design, which gives meaning to the pro-
blem and stakeholders’ demands.
2.3 User Stories
User Stories is one of the key development prac-
tices for teams using agile software development and
project management methods (e.g., Scrum or eXtreme
Programming). A User Story is a representation that
aims to capture a description of a software resource
from an end-user perspective. The user story spells
out the user’s role, what they want, and why. A user
story helps creating a simplified description of a re-
quirement and can fit into agile process structures.
Therefore, a “user story” represents a definition of a
high-level requirement, containing enough informa-
tion for developers to produce a reasonable estimate
of the effort to implement it.
User Stories can be considered a starting point for
a conversation that establishes the actual requirements
of the product. In this paper, they were written col-
laboratively by product stakeholders, also helping to
prioritize prospective functionalities during the sys-
tem design period. Identifying and describing user
stories thus serve as reminders of what is still mis-
sing and why of those needs to be developed. Cou-
pled with user stories, product backlog, and sprint
practices are accomplished (Schwaber and Beedle,
2002). A backlog acts as an ordered list of stories to
be developed based on priorities set by their business
value and technical feasibility (Schwaber and Bee-
dle, 2002). In our work, user stories were aligned
with Participatory Design practices because user sto-
ries specify involved roles, the notion of purpose and
business value.
3 OpenDesign IDEATION
The activity dynamics adopted in this research reflects
the path conducted by the OpenDesign project team
aiming to articulate the Socially Aware Design model
with open source practices and lean agile methods.
This dynamic considers the insertion of collabora-
tive and participatory practices, used to assess their
relevance to the design process of the OpenDesign
platform. The elicitation and understanding of fea-
tures in the OpenDesign followed a process in which
the project team and other researchers, as stakehol-
ders, were invited to collaborate on participatory prac-
tices for the creation, prioritization, and organization
of features. Participants included 7 researchers of
Human-Computer Interaction and Software Engine-
ering fields, 13 graduate students, and 1 undergra-
duate student. Stakeholders contributed to include
their vision and needs in the context of the project.
The process described in Figure 1 does not repeat
a conventional software development. In our work,
there was an initial effort in its conception, that is, in
Articulating Socially Aware Design Artifacts and User Stories in the Conception of the OpenDesign Platform
understanding the concept to be implemented through
design activities (rounded blue boxes with dotted bor-
der in Figure 1). Subsequently, these were associa-
ted with the development of the software itself (red
rounded boxes with a continuous border in Figure 1).
The activities represented in gray and dashed boxes
have both design and software development nature.
The SD, EF, and SF are artifacts of Socially Aware
Design. User Stories were also used in the process in
a participatory and online manner.
Each of the defined activities (rectangles in Figure
1) was carried out collaboratively (i.e., involving mul-
tiple stakeholders) and at least in two moments: (1)
in activities, we call warm-ups, in which participants
contributed individually and previously to the elabo-
ration of artifacts (documents), usually using online
tools; and (2) in face-to-face meetings, in which parti-
cipants interacted to generate a consolidated artifact.
At both times, collaborative tools were used to pro-
vide a shared view of the project to all participants.
Among the collaborative face-to-face meetings and
online activities, we highlight the following: (1) an-
ticipation of problems and solutions; (2) initial defini-
tion of requirements; (3) creation of User Stories; (4)
prioritization of stories; (5) refinement of functiona-
lity; and (6) summary of features.
1. Anticipating Problems and Solutions: From the
identification of stakeholders, it becomes possi-
ble to anticipate prospective problems and their
associated solution ideas. To this end, the Evalua-
tion Frame was used for describing, for each layer
of the Stakeholder Diagram, a set of problems or
questions. Also, it associates possible solutions or
ideas on how to solve these problems succinctly.
This artifact was completed online and collabora-
tively with the support of the SAwD tool (da Silva
et al., 2016).
2. Initial Requirements Definition: Possible solu-
tions and ideas described in the Evaluation Frame-
work were used to support the initial identifica-
tion of requirements at a high level of abstrac-
tion. For this purpose, the requirements were
described based on the different steps of the Se-
miotic Framework. The framework is typically
populated from the highest step (Social World)
to the lowest step (Physical World), in a refine-
ment approach in which a requirement on a higher
step may derive requirements on the immediately
lower step. However, the up and down movements
of the ladder can be performed iteratively, as the
understanding of the initial requirements matures
as they are listed. This was the third and final arti-
fact to be completed online and collaboratively by
the project participants.
3. Creating User Stories: For this first step, Par-
ticipatory Design contributed with action dyna-
mics that made it possible to bring stakeholders
into the design process. We proposed a participa-
tory practice that combined the concept of User
Stories with a collective brainstorming session to
create stories for OpenDesign. The session was
facilitated and used as materials a whiteboard on
the wall, visible among the participants, on which
user stories written with post-its were glued and
organized by all participants. User stories were
designed and crafted for potential OpenDesign
stakeholders, previously raised using the Stake-
holder Diagram. All user stories were later in-
serted into the Trello
tool, which allowed us to
visually organize the project in the form of charts
and tasks in the form of cards. Such organization
helped to categorize user stories and to obtain an
4. Prioritization of Stories: We used the Con-
tool to prioritize User Stories, inserted
into the tool for discussion and voting by project
members. ConsiderIt provides a slider where
users can vote for how much they agree or disa-
gree with an idea (in this case, a user story), while
listing positive or negative points for that idea.
ConsiderIt enables participants to justify their ra-
ting, or comments on points raised by others.
Thus, user stories were put into ConsiderIt. Those
involved in the project were asked to rate them ac-
cording to their priority for developing the Open-
Design platform.
5. Refinement of Features: To better define the fea-
tures raised and prioritized, we performed a col-
lective and face-to-face refinement of user stories.
To this end, involved researchers in the project
looked at the list of user stories prioritized in Con-
siderIt and deliberated on what were, in fact, the
key stories for the OpenDesign platform to be im-
plemented. Following this deliberation, an online
form was created that allowed participants to as-
sociate features with more detailed specifications
to each user story; so we come to a lower granu-
larity and therefore closer specification to imple-
6. Summary of Features: Finally, in the last step,
the participants jointly and in person created a
synthesis of backlog in a concept map. The cre-
ation of a functional synthesis map involved the
collaborative analysis of the user stories and sug-
gestion of categories to organize them. This syn-
ICEIS 2020 - 22nd International Conference on Enterprise Information Systems
Develop the
Develop the
Creating User
of stories
Scope and Reuse
of features
Summary of
Figure 1: Process Conducted in the OpenDesign Project.
thesis map plays a key role in the elaboration of
an overview of the platform’s potential modules.
The categories emerged from the analysis of the
stories and they were refined through face-to-face
discussions among the participants. Researchers
iteratively suggested new categories and changes
of elements from one category and to another until
the conclusion of the map.
4 RESULTS: OpenDesign
This section presents the results of the process de-
finition and instantiation in the OpenDesign project.
Among our results, we highlight the clarification of
the OpenDesign concept (cf. Subsection 4.1) and the
prioritized set of user stories (cf. Subsection 4.2). In
addition, at the end of this section, we present a dis-
cussion in which we analyse the process and the ob-
tained practical results (cf. Subsection 4.3).
4.1 OpenDesign Concept Clarification
The collaborative use of the Socially Aware Design
artifacts (Stakeholder Diagram, Evaluation Frame,
and Semiotic Framework) provided clarification of
the OpenDesign concept among the project stakehol-
ders. Figure 2 presents examples of artifacts produced
by the participants.
In the SD, illustrated in Figure 2a, several cate-
gories of professionals and organizations were indi-
cated as stakeholders at all layers. For example, on the
one hand, even distant from the development of the
OpenDesign platform itself (in the outermost layer),
educational institutions such as the Campinas State
University (Unicamp), and funding such as S
ao Paulo
State Research Support Foundation (FAPESP), affect
and are affected by the OpenDesign to some degree,
so they should not be overlooked. On the other hand,
programmers and HCI professionals involved in the
project have a direct relationship with the project, and
consequently, with the OpenDesign platform. Figure
2a presents a complete list of identified stakeholders
and their position in the diagram.
In the EF, partially illustrated in Figure 2b, many
questions and problems were raised for the identified
stakeholders. The participants also proposed ideas
Articulating Socially Aware Design Artifacts and User Stories in the Conception of the OpenDesign Platform
and solutions using this artifact. For example, for
the stakeholder “computer student” the problem arose
that “they (the students) might find that design is just
the “make-up” of a computer system, can be done
later, on top.
(Translation from Portuguese lan-
guage of the original phrase by the researchers). For
such problem, the following solution/ideas were pro-
posed: “Providing teaching materials, tutorials and
concrete examples; Providing simplified versions and
grounded and detailed versions of the materials, with
practical tips and examples; Suggest ‘next’ steps for
the work done. (Translation from Portuguese lan-
guage of the original phrases by the researchers). The
anticipation of potential problems and issues provided
by this artifact supported to raise initial requirements
for a solution within a design project, in this particu-
lar case, initial requirements for the OpenDesign plat-
Finally, the initial definition of requirements based
on the SF, partially illustrated in Figure 2c, enabled
the organization of requirements into the levels of the
Framework. This encompassed requirements from
the social world (e.g., contributing to distributed de-
sign and providing universal access to people) to the
physical world requirements (e.g., server needs and
platform compatibility with assistive technologies).
At a high level of abstraction, the requirements in the
SF inspired a participatory approach, described in the
next subsection. Based on the identification of User
Stories from the SD, we seek a level of abstraction
closer to the prospective use of the OpenDesign plat-
form by the identified stakeholders.
4.2 User Stories
The use of the artifacts (described in the previous sec-
tion) represented the basis for creating user stories. In
the user story creation stage, a total of 95 user stories
were created after the participatory practice, already
considering the removal of redundant/duplicate sto-
ries. In the next step, we chose the user stories that
would be essential for the development of the Open-
Design platform and then associated system functio-
nalities with each one. Table 1 lists those user sto-
ries considered essential. With this practice, partici-
pants collectively produced a map that synthesizes the
key concepts involved in the OpenDesign concept, as
well as groups desired functionalities for the OpenDe-
sign platform. Figure 3 graphically illustrates the con-
cept map and requirement groups from user stories.
In the following, we describe the conceptual groups,
This “on top” means the frontend be constructed on top
(and after) of the backend of the system.
including functional and non-functional requirements
associated to the number of the user stories:
OpenDesign: The platform should present a list
of featured projects, as well as allow its users to
search existing projects; The aesthetics of the plat-
form must be pleasant and customizable; The phi-
losophy behind the platform should be communi-
cated, as well as tutorials and demonstrations on
how to use the platform; the platform must have a
support forum, terms of use and a mechanism for
reporting terms violations; Finally, the platform
must follow accessibility criteria and recommen-
dations. This description relates to some of the
essential stories (#33, #38, #41 and #92) that ap-
pear in this group.
OpenDesigners: Platform users can have a port-
folio that highlights projects they have contributed
to; users can bookmark projects for follow-up and
later reference; users can communicate with each
other privately via chat; the platform should pro-
vide a form of reputation among its users, accor-
ding to their contributions and their peer recogni-
tion. This description relates to some of the essen-
tial stories (#23, #84 and #87) that appear in this
Project: The platform should allow the creation
and maintenance of projects, by considering the
choice of a desired software license; the platform
must allow the control of project visibility (public
or private); a project overview as well as a dash-
board with metrics; project access control; Pos-
sibility to export, version, compare, diverge and
combine projects; ways to publicize (share) an
existing project; and a view of the history of exis-
ting projects on the platform. This description re-
lates to some of the stories considered essential
(#35, #47 and #54) that are in this group.
Collaboration: Within a project, the platform
should enable design steps to be established; it
should be possible to suggest or propose ideas to
which users can contribute by voting, rating or
feedback; There should also be a way to moderate
contributions as well as deliberate ideas and make
decisions. It should still be possible to create eva-
luations within the project and request feedback
from any input, product, and/or artifact. This des-
cription relates to some of the stories considered
essential (#49 and #3) that appear in this group.
Repository: Within a project, the platform should
enable the creation of a repository of knowledge
and design artifacts, where users can store digi-
tal files, manage project documentation, and write
ICEIS 2020 - 22nd International Conference on Enterprise Information Systems
Table 1: User Stories Considered Essential.
# User stories
#31 As designer I want design process documentation so I can understand how to replicate that proposal.
#33 As amateur I want filter projects and backlogs to choose how and what to contribute.
#35 As amateur/enthusiast I want to see images and videos of projects on the platform so I can get to know the enabled
#38 As OpenDesigner I want to look for problems/projects so I can contribute to it.
#41 As OpenDesigner I want to know the artifacts available on the platform so that I can use in my project.
#47 As an OpenDesigner I want to share my project so that I can engage the community.
#54 As the project owner I want set the license to secure and set limits for contributors.
#67 As an IHC teacher I want the platform supports multiple design paradigms so I can work multiple with my students.
#92 As a user, I want an FAQ to resolve recurring questions by collaboratively building solutions.
help documentation and tutorials. The story con-
sidered essential #31 appears in this group.
Other desired aspects were elicited, but not conside-
red priorities for the first versions of the platform,
such as integrated code creation (IDE) functionality,
prototype hosting, kanban style card functionality for
various uses. Also portability so that the platform can
be used on different devices, as well as communica-
ting with different devices, and finally the desire for
the platform to be made available as a service. These
desired, but not priority aspects, were categorized in
a priority rank to be considered in the next versions.
4.3 Discussion
From the methodological point of view, the main fea-
ture of the proposed process is the integration bet-
ween design and requirements engineering. The mo-
tivation for this integration is given by the idealiza-
tion proposed in the project, formalized in the light of
agile methods of software development and practices
of free software development without losing sight of
the practices of Socially Aware Design. This inte-
gration occurs primarily in the planning and at end
of each iteration with ongoing reviews and ongoing
stakeholder involvement. In this sense, the different
levels of abstraction that were used to describe func-
tionalities (SF, User Stories, and Functionality Map)
were necessary to think design and development in an
integrated way. While one type of abstraction is better
suited to software development itself, another type is
better suited to the design and prototyping of interac-
tion with the platform and user interfaces.
In general, we understand that the SD was a valu-
able source for reflecting on the necessary roles in
defining user stories and, hence, the platform. The
EF allowed participants to anticipate problems that
permeate the platform and potential solution refer-
rals, both from a divergent perspective, where alterna-
tive paths are identified in an ideation process. After-
wards, they need to converge in a deliberation process
to a solution through the SF. In this stage, it was pos-
sible to understand the value or type of contribution
of each functionality to the OpenDesign platform.
Practices conducted to prospect and refine several
stakeholder requirements on the OpenDesign plat-
form culminated in two complementary views: 1) the
feature map being an overview of the platform con-
cept; 2) the user stories set in a backlog, expected
to continue with software development. By adopting
the practice of User Stories, conducted in a participa-
tory manner with different stakeholders, it was possi-
ble to identify candidate features for the platform that
were refined in participatory analysis and detailing
activities. Participatory practices fostered the emer-
gence and discussion of new ideas that took shape and
evolved during the discussions. This favored the ma-
turation of user stories and served as an object for the
construction of shared meaning among participants.
Refined user stories during participatory practices
resulted in functionalities related to several aspects of
the platform, which included: project management;
people’s engagement and participation; collaboration
and sharing of knowledge; and technical aspects in-
volved in building the platform. These stories proved
adequate to form a basic set of functionalities for the
platform and indicated possible extensions. Currently
at the moment, the tracking of design artifacts hap-
pens continuously at development time. The project
is in the beta phase of the platform
Unwanted impacts that computer systems can trig-
ger on economic, ethical, political, and societal issues
have become increasingly visible. Such impacts have
been associated with systems development visions
that do not privilege the social world in which solu-
tions are used. In this paper, we envisage the design
Articulating Socially Aware Design Artifacts and User Stories in the Conception of the OpenDesign Platform
(a) Stakeholder Diagram Produced for the OpenDesign Project.
(b) Partial Illustration of the Evaluation Frame for the Open-
Design Project.
(c) Partial Illustration of the Semiotic Framework for the
OpenDesign Project.
Figure 2: Populated Artifacts of the Socially Aware Design (Original Messages in Portuguese Language).
ICEIS 2020 - 22nd International Conference on Enterprise Information Systems
Help and Tutorial #4 #5 #7 #37 #92
Documentation #9 #31 #51 #64 #91
File Storage #45
Search and Featured Projects #22 #33 #38 #48 #62
Nice and Customizable Aesthetics #30 #90
OpenDesign Philosophy #69 #70 #71 #94
About, Tutorials, Demos #11 #14 #41 #92
Support Forum #21 #86 #89
Reporting Support #75
Accessibility #94 #95
Terms of use #73
Establish Design Steps #42 #45 #49 #60
Proposition Suggestion #17 #25 #32 #36
Moderate Contributions #3 #53 #59
Deliberation Discussion #24
Feedback Rating #26 #27 #29 #65 #80 #82 #85 #87
Portfolio #23 #26 #81
Favorite Projects #62
Private Communication #84
Reputation #87
Create and Maintain Projects #26 #43
Create and Maintain License #28 #50 #54 #83
Visibility Control (Public, Private…) #56
Overview #6 #8 #35 #40 #51 #60 #64 #72 #84
Access control #1 #18 #49 #52 #55 #56 #61
Export, Fork and Merge #13 #15 #44 #66 #81
Version control #39 #56 #68 #93
Metrics and Dashboard #57 #79
Share Project #47
Histórico #9
IDE #16 #19 #20
Prototype Hosting #27
Cards (Kanban, Card Sorting…) #46
Portability #63 #95
Software as a Service #2
Figure 3: Map of Features Defined for the OpenDesign Platform (with Indication of Number of the User Stories).
of systems as a socio-technical activity, for which the
involvement and perspectives of stakeholders should
be considered from the ideation of such systems. We
investigated the concept of OpenDesign and illustrate
the methodological process and artifacts used in the
design of a platform to support the ideation and col-
laborative creation of systems aligned with this con-
cept. We adopted participatory practices to unders-
tand the problem and identify requirements involving
different stakeholders and integrated them with prac-
tices known as user stories. The synergy between
these practices favored the identification of different
interests and perspectives, which resulted in the spe-
cification of requirements towards the construction of
a software platform that implements the concept. The
platform has been implemented in sprints enhancing
OpenDesign concepts and practices. A beta version of
the platform is currently being tested for evaluation in
relevant cases. Future work will involve the investi-
gation of the several use cases with the platform.
This work is financially supported by the S
Paulo Research Foundation (FAPESP) (grants
#2015/24300-9, #2017/06762-0 and #2018/25972-9),
National Council for Scientific and Technological
Development (CNPq) (grant #306272/2017-2), and
ao de Aperfeic¸oamento de Pessoal de
ıvel Superior (CAPES) - Finance Code 001.
Baranauskas, M. C. C. (2009). Socially aware comput-
ing. In da Rocha Brito, C. and Ciampi, M. M., edi-
tors, Proceedings of the ICECE’2009 VI International
Conference on Engineering and Computer Education,
pages 84–88, Buenos Aires, Argentina. Council of Re-
searches in Education and Sciences (COPEC).
Baranauskas, M. C. C. (2014). Social awareness in hci. In-
teractions, 21(4):66–69.
Baranauskas, M. C. C. (2017). Opendesign:
ecnicas e artefatos para o design social-
Articulating Socially Aware Design Artifacts and User Stories in the Conception of the OpenDesign Platform
mente consciente de sistemas computacionais.
consciente-de-sistemas-computacionais/. More info
like: Regular Fapesp research Grant: #2015/24300-9.
Accessed October 2019.
Beck, K., Beedle, M., Van Bennekum, A., Cock-
burn, A., Cunningham, W., Fowler, M., Grenning,
J., Highsmith, J., Hunt, A., Jeffries, R., et al.
(2001). Manifesto for agile software development. Accessed October 2019.
Boisseau, E., Omhover, J.-F., and Bouchard, C. (2018).
Open-design: A state of the art review. Design Sci-
ence, 4:e3.
Connell, B. R., Jones, M., Mace, R., Mueller, J., Mullick,
A., Ostroff, E., Sanford, J., Steinfeld, E., Story, M.,
and Vanderheiden, G. (1997). The principles of uni-
versal design.
da Silva, J. V., Pereira, R., Buchdid, S. B., Duarte, E. F.,
and Baranauskas, M. C. C. (2016). Sawd-socially
aware design: an organizational semiotics-based case
tool to support early design activities. In International
Conference on Informatics and Semiotics in Organi-
sations, pages 59–69. Springer.
G1 (2015). Erros grosseiros: esocial rejeitou e-mail com
ıfen. Posted in em 05/11/2015. Accessed October
G1 (2019). ‘dieselgate’: veja como esc
andalo da volks-
wagen comec¸ou e as consequ
encias. Posted in
23/09/2015 15h48 and updated 05/02/2019 20h51.
Accessed October 2019.
Kautz, K. (2011). Investigating the design process: parti-
cipatory design in agile software development. Infor-
mation Technology & People, 24(3):217–235.
Liu, K. (2000). Semiotics in information systems engi-
neering. Cambridge University Press, Cambridge,
United Kingdom.
Liu, K. and Li, W. (2014). Organisational semiotics for
business informatics. Routledge, Abingdon, United
Lucassen, G., Dalpiaz, F., van der Werf, J. M. E. M., and
Brinkkemper, S. (2016). The use and effectiveness
of user stories in practice. In International working
conference on requirements engineering: Foundation
for software quality, pages 205–222. Springer.
Muller, M. J., Haslwanter, J. H., and Dayton, T. (1997). Par-
ticipatory practices in the software lifecycle. In He-
lander, M. G., Landauer, T. K., and Prabhu, P. V., edi-
tors, Handbook of Human-Computer Interaction (Se-
cond Edition), pages 255 – 297. North-Holland, Ams-
terdam, second edition edition.
Papanek, V. (1971). Design for the real world, including
less developed countries. Accessed October 2019.
Poppendieck, M. and Poppendieck, T. (2003). Lean
Software Development: An Agile Toolkit: An Agile
Toolkit. Addison-Wesley, Boston, MA, USA.
on, D. A. (1990). The design process. In Howard, V. A.,
editor, Varieties of Thinking: Essays From Harvard’s
Philosophy of Education Research Center. Routledge,
Abingdon, United Kingdom.
Schwaber, K. and Beedle, M. (2002). Agile software deve-
lopment with Scrum, volume 1. Prentice Hall, Upper
Saddle River, NJ, USA.
Vieira, H. and Baranauskas, M. C. C. (2003). Design e
ao de interfaces humano-computador. Uni-
camp, Campinas, SP, Brazil.
ICEIS 2020 - 22nd International Conference on Enterprise Information Systems