User Needs - The alpha and omega of system design
Charles J.T. Copp
Abstract
This presentation will include user needs, the role of interfaces and web services in building systems to serve different types of users and the use of thesauri for providing appropriate user-targeted terms.
Developers jokingly complain that the problem with software is the users: ‘users never read manuals and can be bloody-minded or even downright stupid’. Most potential users do not really understand their data requirements or have a clear idea of what can be delivered. This is especially true in large scale information projects, of which the database software forms only a part, for instance, a local or regional biodiversity network. Is there any consensus on what the potential users want out of a biodiversity network?
The key issues are: who are the users, what are their real needs, what problems can the proposed system solve, how can different levels of user get what they need, will their requirements change over time, and who will pay for it? In the UK at least, a failure to solve these issues contributes to the confusion and demoralisation in library, museum and school services. All too often the debate is of what should they get not what do they need? Is there a danger of this with biodiversity networks?
Establishing user needs is a difficult and under-estimated task. The, now outmoded, Structured Systems Analysis and Design Methodology (SSADM) was particularly good for describing existing systems and establishing user requirements. Data flow diagrams (DFDs) remain one of the most powerful tools for charting the limits of the system and defining what parts affect what users but have little to say about user interfaces. Times move on and the rise of prototyping, extreme programming, object-oriented methodologies and web-related technologies have given us new paradigms for system development but the user definition problems remain much the same. Much of the effort still goes into data capture, data storage and linking or querying distributed databases but not enough effort goes into data re-purposing or repackaging for different types of users. Even less effort goes into what sort of data were needed in the first place. The result is increasingly large, interconnected data systems that solve few real-world problems.
The work to create data models and set terminology, validation and verification standards on an international scale continues to be spectacularly successful and TDWG and related projects can be justifiably proud of their achievements. This is not true for usability of data access applications, which is probably the greatest limiting factor in extending the value of these systems. For instance, it is quite clear that the choice of language and depth of information used in answering questions from children, members of the public or keen local naturalists are very different. Likewise in building applications “one size never fits all”.
We are still at the rudimentary stage of interface design, ergo the example of the blank text box labelled “Enter a species name”, and hierarchical taxonomic trees are little use to non-specialists. Real progress will only come with interfaces that designed for the level of knowledge of the user. It is especially important to give users the means to explore what is held within a system according to their level of experience and interest. Users must not be forced to follow a rigid access routine.
Developers jokingly complain that the problem with software is the users: ‘users never read manuals and can be bloody-minded or even downright stupid’. Most potential users do not really understand their data requirements or have a clear idea of what can be delivered. This is especially true in large scale information projects, of which the database software forms only a part, for instance, a local or regional biodiversity network. Is there any consensus on what the potential users want out of a biodiversity network?
The key issues are: who are the users, what are their real needs, what problems can the proposed system solve, how can different levels of user get what they need, will their requirements change over time, and who will pay for it? In the UK at least, a failure to solve these issues contributes to the confusion and demoralisation in library, museum and school services. All too often the debate is of what should they get not what do they need? Is there a danger of this with biodiversity networks?
Establishing user needs is a difficult and under-estimated task. The, now outmoded, Structured Systems Analysis and Design Methodology (SSADM) was particularly good for describing existing systems and establishing user requirements. Data flow diagrams (DFDs) remain one of the most powerful tools for charting the limits of the system and defining what parts affect what users but have little to say about user interfaces. Times move on and the rise of prototyping, extreme programming, object-oriented methodologies and web-related technologies have given us new paradigms for system development but the user definition problems remain much the same. Much of the effort still goes into data capture, data storage and linking or querying distributed databases but not enough effort goes into data re-purposing or repackaging for different types of users. Even less effort goes into what sort of data were needed in the first place. The result is increasingly large, interconnected data systems that solve few real-world problems.
The work to create data models and set terminology, validation and verification standards on an international scale continues to be spectacularly successful and TDWG and related projects can be justifiably proud of their achievements. This is not true for usability of data access applications, which is probably the greatest limiting factor in extending the value of these systems. For instance, it is quite clear that the choice of language and depth of information used in answering questions from children, members of the public or keen local naturalists are very different. Likewise in building applications “one size never fits all”.
We are still at the rudimentary stage of interface design, ergo the example of the blank text box labelled “Enter a species name”, and hierarchical taxonomic trees are little use to non-specialists. Real progress will only come with interfaces that designed for the level of knowledge of the user. It is especially important to give users the means to explore what is held within a system according to their level of experience and interest. Users must not be forced to follow a rigid access routine.