Content uploaded by Nelson Medinilla
Author content
All content in this area was uploaded by Nelson Medinilla
Content may be subject to copyright.
A preview of the PDF is not available
How a Human-Centered Approach Impacts Software Development
Abstract and Figures
Usability has become a critical quality factor in software systems, and it requires the adoption of a human-centered approach to software development. The inclusion of humans and their social context into the issues to consider throughout development deeply influences software development at large. Waterfall approaches are not feasible, since they are based on eliminating uncertainty from software development. On the contrary, the uncertainty of dealing with human beings, and their social or work context, makes necessary the introduction of uncertainty-based approaches into software development. HCI (Human-Computer Interaction) has a long tradition of dealing with such uncertainty during development, but most current software development practices in industry are not rooted in a human-centered approach. This paper revises the current roots of software development practices, illustrating how their limitations in dealing with uncertainty may be tackled with the adoption of well-known HCI practices.
Figures - uploaded by Nelson Medinilla
Author content
All figure content in this area was uploaded by Nelson Medinilla
Content may be subject to copyright.
... Personas, scenarios, storyboards, and visual brainstorming were cited by Ferre and Medinilla (2007), as examples of HCI techniques. Ferre and Medinilla went ahead to stress that HCI techniques have to be dynamically applied for as long as approaches to interactive systems development continue to change. ...
Human–computer interaction (HCI) practice has emerged as a research domain in the HCI field and is growing. The need to transfer HCI practices to the industry began significantly with the works of Nielsen on usability engineering. To date, methods and techniques for designing, evaluating, and implementing interactive systems for human use have continued to emerge. It is, therefore, justified to conduct a systematic mapping study to determine the landscape of HCI practice research. A Systematic Mapping Study method was used to map 142 studies according to research type, topic, and contribution. These were then analyzed to determine an overview of HCI practice research. The objective was to analyze studies on HCI practice and present prominent issues that characterize the HCI practice research landscape. Second, to identify pressing challenges regarding HCI practices in software/systems development companies. The results show that HCI practice research has steadily increased since 2012. The majority of the studies explored focused on evaluation research that largely contributed to the evaluation methods or processes. Most of the studies were on design tools and techniques, design methods and contexts, design work and organizational culture, and collaboration and team communication. Interviews, case studies, and survey methods have been prominently used as research methods. HCI techniques are mostly used during the initial phase of development and during evaluation. HCI practice challenges in companies are mostly process-related and on performance of usability and user experience activities. The major challenge seems to be to find a way to collect and incorporate user feedback in a timely manner, especially in agile processes. There are areas identified in this study as needing more research.
... Presently, the physical user interfaces of embedded systems can be properly evaluated only by experts of HCI and especially experts in the physicality field. However, due to the gap between the software engineering and HCI fields, embedded software developers have been unable to collaborate with HCI experts [21][22][23][24][25][26][27][28][29][30][31][32]. This practice results in either inadequate evaluation of products by non-experts or unrelated personnel, or release of products without any evaluation of the physical user interface. ...
Physical interfaces suffer from interaction complexities leading to usage difficulty and poor acceptance by the end-users. Usability techniques focus on the overall usability issues while overlooking the in-depth physicality aspects of the interface and interaction. This study proposes a physicality-focused quantitative evaluation method (PQEM) to assist embedded system developers in managing the interaction complexities of their products. The acceptance of the embedded system developers towards the proposed method was assessed by means of a user study. The results suggested their strong acceptance. By using this method, we further propose a range of values for appliances, which can be treated as a catalogue or as guidelines as they design and develop physical interfaces. A second user study was conducted to assess the acceptance of embedded system developers for the proposed catalogue. In this study, spatial cognition is concerned in assisting and facilitating the designers and developers in designing physical interfaces of embedded products. We used intensive interviewing as the cognitive method to assess the influence of the catalogue of values from PQEM on performance in designing and developing physical interfaces.
... When taking a closer look at the results of the process, scholars mention that agile development practices should pay more attention to usability concerns. Literature often states that either pragmatic and hedonic qualities do not play a role at all [1,3,14,41,44], or only at a time much too late to have a major impact on the resulting product [40,51]. One goal should thus be to include a user-focus during the process. ...
For the creation of software products, the idea of iterative and incremental development and design is widely accepted and embedded in various methodologies. However, earlier activities within software projects are often the cause for the projects termination. Such activities are often described as the product discovery phase. Therefore, this study develops PDISC, a method for software product discovery. Following a design science research approach, a systematic literature review extracts design requirements and method fragments from literature. The method fragments describe early activities and are documented using process deliverable diagrams. Collectively, such method fragments form a method database that is used to develop PDISC. PDISC helps practitioners to conduct early activities in a systematic way in order to create a product vision.
... According to Jerome and Kazman [2005], it is common that R&D engineers take decisions regarding usability issues. However, some studies reported that software engineers tend to view usability issues as less important than the 'real' parts of the system [Ferre and Medinilla 2007], and consider the user-interface as something that can be dealt with towards the end of the development process [Costabile 2000]. Programmers' attitude towards usability (and other) issues is probably affected by various factors, including individual characteristics and previous programming experience and education. ...
In this article, we discuss the possible connection between the programming language and the paradigm behind it, and programmers'tendency to adopt an external or internal perspective of the system they develop. Based on a qualitative analysis, we found that when working with the visual, interobject language of live sequence charts (LSC), programmers tend to adopt an external and usability-oriented view of the system, whereas when working with an intraobject language, they tend to adopt an internal and implementationoriented viewpoint. This is explained by first discussing the possible effect of the programming paradigm on programmers'perception and then offering a more comprehensive explanation. The latter is based on a cognitivemodel of programming with LSC, which is an interpretation and a projection of themodel suggested by Adelson and Soloway [1985] onto LSC and scenario-based programming, the new paradigm on which LSC is based. Our model suggests that LSC fosters a kind of programming that enables iterative refinement of the artifact with fewer entries into the solution domain. Thus, the programmer can make less context switching between the solution domain and the problem domain, and consequently spend more time in the latter.We believe that these findings are interesting mainly in two ways. First, they characterize an aspect of problem-solving behavior that to the best of our knowledge has not been studied before-the programmer's perspective. The perspective can potentially affect the outcome of the problem-solving process, such as by leading the programmer to focus on different parts of the problem. Second, relating the structure of the language to the change in perspective sheds light on one of the ways in which the programming language can affect the programmer's behavior.
... Presently, the physical user interfaces of embedded systems can be properly evaluated only by experts of HCI and especially the experts in the physicality field. However, due to the gap between the software engineering and HCI fields, the embedded software developers have been unable to collaborate with the HCI experts (Biel et al., 2010;Ferre and Medinilla, 2007;Folmer et al., 2006;Gulliksen, 2007;Hussein et al., 2010;Joshi et al., 2010;Juristo and Ferre, 2006;Majid et al., 2011;Memmel et al., 2007;Moundalexis and Deery, 2009;Nunes, 2009;Vukelja et al., 2010). This practice results in either inadequate evaluation of the product by non-experts or unrelated personnel, or release of the products without any evaluation of the physical user interface. ...
Embedded systems are becoming more significant in our daily lives with the advent of ubiquitous computing. The increasing demands of multifarious functionalities and other factors lead to an increased focus of development on internal software issues. Negligence towards the interaction aspects of physical interface is resulting in the generation of interaction complexities for the user. This work evaluates, compares, and highlights the significance of physicality aspects of embedded system interfaces using five subjects including; washing machine; camera; oven; sound system; and MP3 player. The quantitative evaluation approach helps in a simple investigation by applying the numeric values for each aspect. The result analysis highlights the significance of exposed state, tangible transition, and inverse action over other physicality aspects. This study is especially valuable for the embedded system developers who may not have exposure or expertise to Human-Computer Interaction or its sub-field, Physicality. Managing and incorporating physicality aspects in embedded systems is a key factor for producing natural interaction products.
... Twenty-two (26.5%) of the publications included in the review address this issue, and see UCD as a means to establish and communicate a product vision in order to ''improve the line of sight between strategy and teamlevel execution'' [72]. While UCD provides suitable concepts for approaching ill-defined problems and delivering a product with a high degree of innovation, exploratory activities are insufficiently addressed in ASD [125]. Kettunen [119] points out that, while agile methodologies are useful means to iteratively select and refine product features, large-scale product innovations are beyond their scope [119]. ...
... Presently, the physical user interfaces of embedded systems can be properly evaluated only by experts of HCI and especially the experts in the physicality field. However, due to the gap between the software engineering and HCI fields, the embedded software developers have been unable to collaborate with the HCI experts (Biel et al., 2010;Ferre and Medinilla, 2007;Folmer et al., 2006;Gulliksen, 2007;Hussein et al., 2010;Joshi et al., 2010;Juristo and Ferre, 2006;Majid et al., 2011;Memmel et al., 2007;Moundalexis and Deery, 2009;Nunes, 2009;Vukelja et al., 2010). This practice results in either inadequate evaluation of the product by non-experts or unrelated personnel, or release of the products without any evaluation of the physical user interface. ...
The physical interaction aspects of embedded systems have been neglected in comparison to internal software issues in the software engineering field. Physical interfaces suffer from interaction complexities leading to usage difficulty and poor acceptance by the end-users. Meanwhile, the usability techniques focus on the overall usability issues while overlooking the in-depth physicality aspects of the interface and interaction. This study proposes a physicality-focused quantitative evaluation method to assist the embedded system developers in managing the interaction complexities of their products. The acceptance of the embedded system developers towards the proposed method was assessed by means of a user study. The results suggested their strong acceptance. The aim of this study is to re-emphasise the natural physical aspects of embedded system interfaces leading to intuitive interaction.
Software development has significantly matured in the last decade. However, one of the critical challenges today is uncertainty inherent to every aspect of software development including requirement specifications, design, coding, and testing. In this paper, we propose a framework for uncertainty management in software engineering. The framework is used to model uncertainty inherent to software development activities and manage their consequences. The framework consists of four main phases: identification and prioritization, modeling and analysis, management and planning, and monitoring and evaluation. Commercial off-the-shelf (COTS)-based development is selected as an example to illustrate how the proposed framework is used in a simple but intuitive case study to represent uncertainty and manage its consequences.
Opening up the design process to the intended users and descriptions of their projected use entail many technical issues. People need to develop new vocabularies for discussing and characterizing designs in terms of the projected activities of the intended users. These vocabularies should be accessible to the users, so that they can help define the technology they will use. People also need to be able to integrate and coordinate such use-oriented design representations with other representations produced in the course of system development. Further, people need to be able to assess design alternatives with use-oriented criteria and to integrate and coordinate such assessments with those that they make on traditional grounds, like correctness, reliability, efficiency, and maintainability. People need to develop new sorts of tools and techniques to support the development and use of use-oriented representations and methods in design. People also need to produce education to help system developers understand the need for use oriented approaches and adopt such methods in their work. This is a lot to ask for, but to do anything less is to risk losing sight of the line among human beings using and controlling their technology and its antithesis.
This paper reports the results of a recent survey of user-centered design (UCD) practitioners. The survey involved over a hundred respondents who were CHI'2000 attendees or current UPA members. The paper identifies the most widely used methods and processes, the key factors that predict success, and the critical tradeoffs practitioners must make in applying UCD methods and processes. Results show that cost-benefit tradeoffs are a key consideration in the adoption of UCD methods. Measures of UCD effectiveness are lacking and rarely applied. There is also a major discrepancy between the commonly cited measures and the actually applied ones. These results have implications for the introduction, deployment, and execution of UCD projects
Any system designed for people to use should be (a) easy to learn; (b) useful, i.e., contain functions people really need in their work; (c) easy to use; and (d) pleasant to use. In this note we present theoretical considerations and empirical data relevant to attaining these goals. First, we mention four principles for system design which we believe are necessary to attain these goals; Then we present survey results that demonstrate that our principles are not really all that obvious, but just seem obvious once presented. The responses of designers suggest they may sometimes think they are doing what we recommend when in fact they are not. This is consistent with the experience that systems designers do not often recommend or use them themselves. We contrast some of these responses with what we have in mind in order to provide a more useful description of our principles. Lastly, we consider why this might be so. These sections are summaries of those in a longer paper to appear elsewhere (Gould & Lewis, 1983). In that paper we elaborate on our four principles, showing how they form the basis for a general methodology of design, and we describe a successful example of using them in actual system design (IBM's Audio Distribution System).
The practice of building software is a "new kid on the block" technology. Though it may not seem this way for those who have been in the field for most of their careers, in the overall scheme of professions, software builders are relative "newbies."
In the short history of the software field, a lot of facts have been identified, and a lot of fallacies promulgated. Those facts and fallacies are what this book is about.
There's a problem with those facts—and, as you might imagine, those fallacies. Many of these fundamentally important facts are learned by a software engineer, but over the short lifespan of the software field, all too many of them have been forgotten. While reading Facts and Fallacies of Software Engineering, you may experience moments of "Oh, yes, I had forgotten that," alongside some "Is that really true?" thoughts.
The author of this book doesn't shy away from controversy. In fact, each of the facts and fallacies is accompanied by a discussion of whatever controversy envelops it. You may find yourself agreeing with a lot of the facts and fallacies, yet emotionally disturbed by a few of them! Whether you agree or disagree, you will learn why the author has been called "the premier curmudgeon of software practice."
These facts and fallacies are fundamental to the software building field—forget or neglect them at your peril!