Final paper I wrote while in design school for Foundations of HCI course
Abstract
In this paper, I suggest a small change in the software engineering lifecycle which can greatly impact how developers and project managers view the users they are building for. I argue that the term 'user' used in Software Engineering paints an apathetic picture and falls short of communicating the bigger picture. It fails to communicate that people are not creatures of absolute logic, but rather emotional beings.
I briefly discuss how the definition of a user changes if we look at them through the three paradigms of HCI, the benefits of how this change in perspective can help software engineering, the challenges of incorporating this change, and suggest a few places from where we can get the ball rolling. Some of these impact points include rethinking how software engineering lifecycles are taught in schools and colleges, incorporating theories and practices from other disciplines like sociology, and creating a healthier environment for discussion.
1. Introduction
In the 1960s and early 1970s, computers were becoming increasingly powerful and were able to perform complex tasks. However, it became difficult to write useful, efficient, and scalable software with the existing practices. This situation was dubbed as the "Software Crisis" at the first NATO Software Engineering Conference at Garmisch, Germany in 1968 [1]. This led to the emergence of software engineering processes being discussed. Some even considered this as the origin of software engineering despite the term being coined earlier [2].
On the other hand, the discipline of Human Computer Interaction (HCI) came into existence during the early 1980s. One of the key attributes of a computer was its ability to perform a range of tasks, each requiring a unique interaction mechanism. The field of HCI has been built using knowledge from disciplines ranging from psychology, sociology, computer science, and many others. There has always been an emphasis to recreate the human-human interaction when using computers to perform the same tasks. After the 1980s, Human Computer Interaction has gone through changes which can be broadly categorized into three perspectives of viewing a system, or as they are popularly known as, the three paradigms of HCI [3].
There has been research to come up with an integrated approach to the human-centered design process and the software engineering process [4][5]. I make no attempt to suggest any sort of hybrid process. Instead, I try to provide suggestions to help create a more empathetic and contextual software engineering by taking a look at how HCI has remodelled itself over the years [6]. I ask the question: why is it that software engineering describes the person at the end of a technological terminal merely as a 'user'? This disregards the context of use and the qualities that make the person human. And how software engineering can take inspiration from its younger cousin, the field of Human Computer Interaction.
In this paper, I argue that the term 'user' used in Software Engineering paints an apathetic picture and falls short of communicating the bigger picture. It fails to communicate that people are not creatures of absolute logic, but rather emotional beings. Most of whom will try using the product in unorthodox ways, experimenting curiously, thinking along the lines of "what does this button do?" [7]. The word 'user' can have a thousand different meanings in the same software requirement specification document [8] and falls awfully short of conveying the context of use and the numerous factors influencing the interaction and the system.
In this paper, I briefly discuss how the definition of a user changes if we look at them through the three paradigms of HCI, the benefits of how this change in perspective can help software engineering, the challenges of incorporating this change, and suggest a few places from where we can get the ball rolling. Inspiration for this direction has been taken from research which has been done on making context-aware frameworks for specific applications [9][10].
2. Software Engineering Through the Three Paradigms of HCI
2.1 The First Paradigm
The present-day usage of the word 'user' in software engineering fits closely with how the process would look through the lens of the first paradigm. The mentalist nature of looking at interactions and the relationship with the system is the shortcoming of such an approach. It also portrays the user as a robotic entity which will perform the tasks with the same efficiency at every instance.
2.2 The Second Paradigm
This is perhaps the most interesting part to look at. If software requirement specifications are modelled by considering the context of use, then we get a richer picture of how and why the user performs tasks in the specifications. For example, similar tasks (for example, sending a text message) with different contexts (with one hand occupied, while cooking, etc.) will need to have unique use cases defined for each one and a different approach to be applied every time.
2.3 The Third Paradigm
Looking at software engineering and the third paradigm is tricky. However, it is highly applicable in places like airports. Designing for places like airports is hard. People try to perform the same tasks (like printing a boarding pass) but have vastly different nationalities, cultural, economical, and political information having an influence on their interpretation of the system. Coming up with use cases which convey the amount of such data is extensive, but also helps create a realistic picture of the situation.
I do not suggest a specific way of remodelling how users are defined in a software engineering process in this paper. Instead, I'm trying to make the suggestion that a shift in perspective towards the third paradigm above helps us describe the system which we desire to build in a richer and realistic way. Below, I describe some of the benefits and challenges associated with this approach.
3. Benefits
3.1 Context of Use is Described in the Documents
This means that there is a more empathetic connection and understanding of what the user will be thinking when performing the task. Developers and project managers can have a better understanding of the conditions their solution is required in.
3.2 Easier Decision Making and Rationale
It will be easier to go back and look at why certain decisions were agreed upon and the use cases they apply to. It also offers a lucid explanation in case of legal disputes between parties as well. This makes it easier for teams where a new member has been added. Being able to go through all the context will help them understand what is the true value of the software for the user. It is also beneficial for new project managers to keep track of where things are.
3.3 Easier to Add New Scenarios
If the system encompasses a set of contexts for which it will be used in, when a new addition is made to the system, a new instance of it can be added for every context, leading to a well-thought system. It can also be extended to other products if the target audience is similar.
4. Challenges
4.1 Managing More Data
More descriptions bloat the specifications and make it painful to sift through. The reason for having a software engineering process in the first place was to decrease the complexity. Only in software where providing the contextual description of the user would outweigh the disadvantage of increasing the size of the specifications would such a move be sensible.
4.2 Quality of Specification
There is no point in providing specifications about the context of use and how the user uses the system if it is done in an awful way. First of all, writers will need to be trained for this new format of documentation. This is a big problem as there is a lack of quality in technical writers with a lot of them confused about their actual role in an organization [11].
5. Towards a Human Centered Software Engineering Process
The notion of the user as a mysterious creature of logic, performing every task efficiently is deeply rooted currently in the present practices. There are a few ways in which we can begin to address those concerns. However, we need to remember that this shift in perspective is a slow change process which will require time and have a lot of resistance from the existing practices and working culture, especially where the practices have been well established. Below are a few suggestions of where we can begin from.
5.1 Education and Curriculum
The software industry is currently dominated by people belonging to a computer science engineering background; they are the prime drivers for the software engineering process. Changing the way we teach this in schools and colleges can usher in a new age of more empathetic practitioners. To teach about human behavior to engineering students, faculty must clearly define why knowledge about design and human behaviour along with computer science is important for developing software. Exposure to interdisciplinary topics develops a variety of problem-solving skills and, more importantly, helps them develop empathy towards other team roles as well. Knowing about the design process will enable them to shape an idea from scratch and become capable leaders of large interdisciplinary teams in the future.
The computer science engineering curriculum today fails to answer the question "What to build?" rather they have been designed to answer "How to build?"
In all of the evaluations they face in college, computer science students are provided with well-defined requirements and test cases to consider, which is far away from the vague and ambiguous circumstances a developer usually finds themselves in. They are taught about a software development life-cycle having a stage for gathering user requirements. A process which falls woefully short of actually providing answers for what is to be made. The process of collecting and interpreting user information is not seen in high priority, hence causing tendency in students to downplay these topics. Some don't even bother doing it or learning about it as they consider it to be just common sense and extraneous.
Making students understand and define the systems using methods which help them see the human side of their users creates a deeper and more realistic understanding of the system. If a solid foundation is laid early, then we can see a more enriched software engineering process in practice.
5.2 Multi-disciplinary Approach
So far, I haven't provided any direction of defining how to describe the user in the software engineering process. One possible way out of many could be the application of concepts such as Distributed Cognition [12] and Activity Theory [13].
Taking inspiration from distributed cognition, one can define the user in software engineering as the whole entity of the flow of information, showcasing the bigger picture to the developer when they reference the context of the system they are building. For example, knowing that a person is being influenced by their friends, the money they have, how much time they have, and how they are getting all this information is crucial for a team building a mobile application for ordering pizza. It helps them see all the factors which the person has in the back of their head as they use the mobile application.
The same concept can be extended to activity theory as well. Defining a whole system using the activity theory will help encapsulate the boundaries of the things which were considered. It can also be easily applied like in the case of pizza ordering above. One particular advantage which activity theory offers is that use cases can be designed for a whole activity system, decreasing the size of the specification.
One small precaution, however, needs to be taken if any of the above methods are applied in their raw forms: the description of the user will need to be updated frequently as now it is not just the user, but the whole ever-changing contextual system which is considered as the user.
6. Discussion
A lot of what has been stated above can be called common sense practice. But why haven't things changed? How can we move forward? What are other practices in the industry? These are some of the questions we need to ask ourselves periodically and have healthy discussions about our practices. The term 'user' and the current practices have become so ubiquitous to some engineers that they think this might be the only way. We need to engage them in discussions about why? How? And what if?
We need role model organizations where it is common to see engineers seeing the users as human beings. We need these organizations to set a marker showing where to start from and how to make the workplace culture having greater empathy.
7. Conclusion
It is disappointing to see that software engineering practices, despite all the changes throughout the last fifty years, still fail to see the user as a complex entity whose actions are greatly determined by the context they are in. Its younger cousin Human Computer Interaction (HCI), however, has remodelled itself in that regard. This paper is a small attempt at bringing forth this very aspect. It also talks about how we can begin to change the software engineering practices towards richer and more understanding ways. Eventually, it would be pleasing to see things change for the best, where developers are able to see the user in the same light as most user-centered designers do. But that vision is miles away and the journey can start by moving in this direction one step at a time.
References
[1] NATO Science Committee, Report on Software Engineering, January 1969
[2] Bertrand Meyer, The Origin of Software Engineering, April 2013 on BertrandMeyer.com
[3] Harrison et al., The Three Paradigms of HCI, CHI 2007 ACM Information Interfaces and presentation
[4] Brown J, HCI and Requirements Engineering - Exploring Human-Computer Interaction and Software Engineering Methodologies for the Creation of Interactive Software, SIGCHI Vol. 29 No. 1, January 1997
[5] Espana S, Linking requirements specification with interaction design and implementation http://personales.upv.es/jopana/Files/Books/Linking_requirements.pdf
[6] Boehm Barry, A view of 20th and 21st century software engineering, ICSE 06 Pages 12-29
[7] Dexter's Laboratory, Excerpt - "What does this button do?" link - https://www.youtube.com/watch?v=kfj0sRiEqx4
[8] Software Requirement Specifications, Wikipedia https://en.wikipedia.org/wiki/Software_requirements_specification
[9] Henricksen et al., A Software Engineering Framework for Context-Aware Pervasive Computing, Proceedings of the Second IEEE Annual Conference on Pervasive Computing and Communications (PERCOM'04) 2004 IEEE
[10] Dey et. al., A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications link - http://www.cc.gatech.edu/fce/ctk/pubs/HCIJ16.pdf
[11] Grey Jim, Software Technical writing is a dying career, June 2015 link - https://softwaresaltmines.com/2015/06/16/software-technical-writing-dying/
[12] Rogers et al., Distributed Cognition: an alternative framework for analysing and explaining collaborative working. Journal of Information Technology, 1994, vol 9(2), 119-128.
[13] Suchman Lucy, Plans as Situated Actions, Book