Studies of development practices in Information and Communication Technology (ICT) companies reveal that usability and user experience (UX) are often not addressed consistently or explicitly in current software development processes. A key reason is the lack of formal requirements that can be objectively verified, or formulation of those requirements at a level that will allow verification. The primary motivation for this workshop is the need for systematic methods, based on empirical research, to define and confirm statements of usability and UX requirements for software systems.

Agile and lean processes for software development in the ICT industry have become widely adopted during the past decade. The requirements for usability and UX in these processes are often not formally defined or validated. This is due to various factors such as limited time, periodic changes of goals, and most importantly lack of suitable UX requirements methods for this new development context. Thus, as the agile and lean software development processes become pervasive, attention is necessary on defining more suitable methods to build and preserve high-quality UX designs along the development process. This problem of omission or poor formalization of UX requirements is limiting the success of projects in the public and private sectors.

For the public sector, studies of ICT companies that work with public authorities in Europe suggest that a critical problem is the lack of formal UX requirements in the Call for Tenders (cf. Request for Proposals). In fact, during the implementation, the company that obtained the contract is likely to focus only on the requirements agreed upon as part of the Call for Tenders. Thus, the contracting company has no incentives to consider additional requirements.

For the private sector, perhaps the hallmark of a successful UX professional is flexibility, due to the recurrent need for negotiation, tighter time constraints and multiple stakeholders. The post-hoc narratives of UX contributions to products often sound like the idealized exploratory phase followed by a narrowing of the scope with a steady progress toward a product that meets the requirements expressed by users. In practice, however, the real story often is of projects with processes and methods that differ widely across development projects but follow common principles and lead to similar artefacts, such as personas, story mapping, and prototypes. Some projects may never create a formal requirements document, but will reveal the increasingly formalized UX requirements through a sequence of prototypes and product versions.

For both public and private endeavours, the problem of formalizing requirements is a balancing act among various factors, such as identifying user classes, satisfying buyers, driving innovation, and keeping consistency among products from the same company.

Useful Links