The quality of software products is becoming higher and higher and the same trend is followed by quality assessment criteria. This diversification is the result of technology evolution and of a higher competition between various IT products and service providers.
At a certain moment in time, it was obvious that the lack of bugs was not enough to prove the quality of a software product. Nowadays, efforts are made to improve the quality of the interaction between human operators and software products. However, for a long time, the user's satisfaction was considered just an extravagance or contractual aberration. The users were the only ones blamed for mistakes in using a software product because avoiding the same mistake for another 99 times was considered solid proof against them. The user himself has tried to develop workarounds rather than pointing the usability difficulties to upper management or to a service provider.
The first step which was taken was related to software interface optimization. The importance of the visual outlook of those components, directly manipulated by users, was increased. Thus the purpose of visual components became clearer, graphical representation started to replace the information as text, the help tools became more effective. This step took place somewhere towards the end of the software development lifecycle.
Currently, IT methodologies place the human operator at the centre of their processes. Importance is also given to the visual appearance of a software product, which is defined in the incipient phases of product development. Teams now focus on the outcome of tasks long before writing the first line of code.
A part of these tasks deals with defining user categories, user objectives, the tasks they have to fulfil and the context for running these user tasks. The entire data set is refined during an iterative and interactive process with direct involvement of the final user. In this way, the downsides of a product are identified in early stages and, as a result, fewer resources are required to correct them. Moreover, the final product is more easily adopted by the users.
The impact of such an approach was proved big enough to determine the appearance of an entire dedicated ISO standard family: "ISO 9241 - Ergonomics of Human-System Interaction" and "ISO 25000 - Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE))".
Besides, the main consequence of such methodology adoption is explicitly defined in the ISO standard 9241:210 (2010) "Human-centred design of interactive systems": "increasing the productivity of users and the operational efficiency of organizations".
Interdependence of human-centred design activities - ISO 9241:210 (2010) / pg 11
A simple functionality, such as currency conversion, could be implemented very differently, even if used the same way, because the functionality is used differently depending on user types, workflows involved and the context of use.
In its most known form, a currency converter allows user to select two different currencies for which the system will calculate the amount of money from the second one for each unit from the first currency. However, the purpose which drives such an operation, may require different implementations.
For example, if the converter is included in a billing application, we should assume that that application will be accessed by employees with medium qualification, who will use it with high frequency, from multiple devices (desktops and mobiles). Higher frequency of use is associated with higher risk of human errors. Because of this, it is recommended to have a simplified interface, using non-specialised terms, with minimal user intervention (selections from predefined lists, predefined styles and templates, etc.). The conversion itself can be completely executed by the system if the user selects service billing and the service provider.
On the other hand, if the converter is used to establish a long term banking policy, most probably this operation will be done by highly qualified staff, with lower frequency (few times per year) and the devices used will mainly be desktops with multiple monitors (which allow access to multiple information sources). Under these circumstances, the application should use financial specific terminology, should allow the implementation of different workflows and data formats. The functionality for currency conversion becomes explicit and contextual (both input and output data vary from one context to another).
The above example is theoretical and was selected to prove the antagonism of some possible situations. However, many times, real-life examples could be spectacular, mainly because of the major differences between initial assumptions and the results of user experience researches.
The quality parameters for the software product presented bellow were selected for their general applicability. They are not exclusive and they can certainly be further refined when they are associated with numerical indicators.
Quality parameters for software products:
Effectiveness is defined as the property of one given application to fulfil the needs of a user completely and correctly.
Efficiency is the property of an application to be effective using a reasonable amount of resources. The "reasonable" aspect is generated by the fact that the resources considered are not only financial, material or time-related. They are also associated with the users' cognitive workload (understanding, attention, memory, easy of learning, etc.).
Lack of risks in use. This is probably the most "human" parameter as it is responsible to mitigate the risks in use, as generated by fatigue, negligence or ignorance from the part of human users.
From the above list, the most important parameter for business owners is "Efficiency". No matter how much attention is paid to the final users of an application, the final users' goal will always be subordinated to the objectives of the financiers. Whether it is about maximizing profits or promoting greater respect for endangered life-forms, the effectiveness of the tools used is critical to the very existence of the product.
In conclusion, it should be underlined that methodologies oriented towards the final users successfully respond to the various interests of all those who benefit directly or indirectly from a given product. However, the implementation of such a methodology requires an explicit assumption of the top management, and this is many times associated with a paradigm change in software development for that organization.