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

Fabr

ı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

Keywords:

Socially Aware Design, Participatory Design, User Stories, Requirements Engineering, OpenDesign.

Abstract:

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.

1 INTRODUCTION

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 proﬁciency on

the part of potential users (G1, 2019). Such problems

https://orcid.org/0000-0002-9545-2098

https://orcid.org/0000-0002-0899-1713

https://orcid.org/0000-0002-1445-1238

https://orcid.org/0000-0002-1479-947X

https://orcid.org/0000-0002-4531-1473

https://orcid.org/0000-0003-3441-0887

https://orcid.org/0000-0002-4830-5298

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

scientiﬁc 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

523

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 clariﬁcation steps.

Investigations have described the beneﬁts 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-

ﬁts in employing user stories in everyday work envi-

ronment.

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 clariﬁcation. First, the concept of

OpenDesign was clariﬁed 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 clariﬁcation, 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)

clariﬁcation 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 reﬂects 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; ﬁnally, Section 5 presents the con-

clusion remarks.

2 THEORETICAL AND

METHODOLOGICAL

BACKGROUND

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

deﬁned 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-

riﬁcation of the problem to the deﬁnition 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

524

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, reﬂecting 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-

pants.

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 speciﬁc 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-

ﬁcation 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 simpliﬁed description of a re-

quirement and can ﬁt into agile process structures.

Therefore, a “user story” represents a deﬁnition 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

PROCESS: METHODOLOGY

AND MODEL

The activity dynamics adopted in this research reﬂects

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 ﬁelds, 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

525

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 deﬁned 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 deﬁni-

tion of requirements; (3) creation of User Stories; (4)

prioritization of stories; (5) reﬁnement of functiona-

lity; and (6) summary of features.

1. Anticipating Problems and Solutions: From the

identiﬁcation 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 Deﬁnition: Possible solu-

tions and ideas described in the Evaluation Frame-

work were used to support the initial identiﬁca-

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 reﬁne-

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 ﬁnal arti-

fact to be completed online and collaboratively by

the project participants.

3. Creating User Stories: For this ﬁrst 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

overview.

4. Prioritization of Stories: We used the Con-

siderIt

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. Reﬁnement of Features: To better deﬁne the fea-

tures raised and prioritized, we performed a col-

lective and face-to-face reﬁnement 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 speciﬁcations

to each user story; so we come to a lower granu-

larity and therefore closer speciﬁcation to imple-

mentation.

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-

https://trello.com/

https://consider.it/

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

526

Develop

Evaluation

Frame

Develop the

Stakeholder

Diagram

Brainstorming

Develop the

Semiotic

Framework

Creating User

Stories

Prioritization

of stories

Scope and Reuse

Refinement

of features

Summary of

features

Synthesis

(Overview)

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 reﬁned 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

CONCEPT AND USER STORIES

This section presents the results of the process de-

ﬁnition and instantiation in the OpenDesign project.

Among our results, we highlight the clariﬁcation 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 Clariﬁcation

The collaborative use of the Socially Aware Design

artifacts (Stakeholder Diagram, Evaluation Frame,

and Semiotic Framework) provided clariﬁcation 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 identiﬁed stakeholders

and their position in the diagram.

In the EF, partially illustrated in Figure 2b, many

questions and problems were raised for the identiﬁed

stakeholders. The participants also proposed ideas

Articulating Socially Aware Design Artifacts and User Stories in the Conception of the OpenDesign Platform

527

and solutions using this artifact. For example, for

the stakeholder “computer student” the problem arose

that “they (the students) might ﬁnd 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 simpliﬁed 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-

form.

Finally, the initial deﬁnition 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 identiﬁcation of User

Stories from the SD, we seek a level of abstraction

closer to the prospective use of the OpenDesign plat-

form by the identiﬁed 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

group.

• 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 ﬁles, manage project documentation, and write

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

528

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 ﬁlter 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

jobs.

#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 ﬁrst 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 ﬁnally 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 reﬂecting on the necessary roles in

deﬁning 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 identiﬁed 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 reﬁne 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 reﬁned 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.

Reﬁned 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

5 CONCLUSION

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

http://opendesign.ic.unicamp.br/

Articulating Socially Aware Design Artifacts and User Stories in the Conception of the OpenDesign Platform

529

(a) Stakeholder Diagram Produced for the OpenDesign Project.

(b) Partial Illustration of the Evaluation Frame for the Open-

Design Project.

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

530

Repository

Help and Tutorial #4 #5 #7 #37 #92

Documentation #9 #31 #51 #64 #91

File Storage #45

OpenDesign

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

Collaboration

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

OpenDesigners

Portfolio #23 #26 #81

Favorite Projects #62

Private Communication #84

Reputation #87

Project

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

Wishlist

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 Deﬁned 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 identiﬁcation of different

interests and perspectives, which resulted in the spe-

ciﬁcation 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.

ACKNOWLEDGEMENTS

This work is ﬁnancially supported by the S

Paulo Research Foundation (FAPESP) (grants

#2015/24300-9, #2017/06762-0 and #2018/25972-9),

National Council for Scientiﬁc and Technological

Development (CNPq) (grant #306272/2017-2), and

Coordenac¸

ao de Aperfeic¸oamento de Pessoal de

ıvel Superior (CAPES) - Finance Code 001.

REFERENCES

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

531

mente consciente de sistemas computacionais.

https://bv.fapesp.br/pt/auxilios/98824/opendesign-

tecnicas-e-artefatos-para-o-design-socialmente-

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.

http://agilemanifesto.org/. 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

2019.

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

Kingdom.

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.

Sch

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

avaliac¸

ao de interfaces humano-computador. Uni-

camp, Campinas, SP, Brazil.

ICEIS 2020 - 22nd International Conference on Enterprise Information Systems

532