User Needs: The alpha and omega of system design

1. User Needs: The alpha and omega of system design We start with user needs Users need to work with the systems we develop People see the world in different ways 13th Century ‘Mappa Mundi’ in Hereford Cathedral Charles Copp September 2007

2. People Networks Collections Technology Standards Biodiversity information systems do not operate in isolation

3. Extracting needs from users is a skilled and neglected art • Users are not good at explaining what they need and many don’t know what they need • You must help them focus on what must be done (and make them aware of what could be done) • Users might not know what is possible and many are not technically skilled and this becomes important in understanding how they might use the system • Users are often not good at testing or trying out software and feed-back can be very slow - the first you hear is someone else saying how bad your system is! • Users don’t read manuals and some can be just plain stupid but that should challenge us to write easier to use software, not to abuse them • a database is only part of a much bigger system including the human network which the software serves and this may need more development than the software. We tend to over-estimate what our users know or how much they can commit to learning complex systems Analysis is a two way process; they change your preconceptions and you change their misconceptions Discovering user needs asks the same questions as we use for field data Who? What? Where? Why? and When?

4. Systems analysis is iterative - many different techniques, but there is no substitute for good foundations • Coding is not the beginning of a project • All too often we give users what we think they should have not what they need. • The first stage of systems analysis tells us: • Who are the users and what do they do • What the current data flow and technical system is like • What tasks and functions need to be part of the new system • What new processes and functions might be incorporated • What parts cannot currently be automated • What problems could new developments solve • What the constraints are • Where the limits of the developed system will be (e.g. because of financial, technical, political or geographical reasons)

5. See: www.recordersoftware.org Building applications: Recorder - some of the lessons • Recorder development included a full systems analysis. The system was prototyped and design included a formal series of multi-participant sessions, second proto-typing and the final buld • Updating and development of the software has continued for a further 7 years • Enforces standards • We got: • A megalithic piece of software that does a lot • But: • Compromises were made along the way for financial reasons e.g. “one size fits all” build • The concepts involved can be difficult even for professional users to understand • No clear work flows therefore difficult to use without training • Boring! Rectangular windows with labels, icons and buttons (not to mention a lot of gray) • The physical (table) model imposed some unexpected limitations

6. Web applications - tailoring software to the user The joy of CSS! • Smaller apps using services • Easily modified interface • Personalised to user • Clear work flows • No steep learning curve • User feedback • Reminders and progress information • Network links

7. Ongoing problems: Finding things in big lists We often create interfaces that are only accessible to the initiated

8. We are a visual species. Pictures make more information quckly available to the uninitiated. We need to do more in this area. Pictures or words?

9. Building applications - learning from games • Games don’t give error messages. They control the environment so that everything the user does is a legal move • Games do not try to do everything. Some are large and have many levels but they usually have a single theme and limited objectives at any level. • Users learn by doing (i.e. they don’t read manuals) • Controls and events are consistent so that users learn by recognition not by recall. Things that look the same, work the same. • There are usually good indicators of progress and completeness so that user feed-back is strong • User controls are embedded in the action, not separate from it • Newer games have innovative ways for multiple users to interact e.g. through avatars and networking. • People play games because they want to not because they have to, so designers work hard to make them interesting, exciting and rewarding • Games are often the drivers for new ways of interacting with computers - If it wasn’t for gamers we would still be using black screens with green text.

10. Data navigation: the search for new paradigms Manipulatingconcepts and data in virtual worlds

11. Data management: looking for new paradigms that give flexibility The emerging web information systems and semantic data retrieval services will require flexible, extensible databases that can handle multiple languages and adapt their structure to changing requirements Concept-based database model being developed for the next version of Recorder

12. Nothing is static. Both user needs and technologies change Final Moral: If we get carried away with the processes of building databases and applications without really understanding the user’s needs and abilities we end up with systems that are difficult to use and solve few real world problems

14. Oh good, we might get a grant for that Creating software Some of the things that happen Hey I have a great idea lets write some new software that does …. Consultation - who do we ask the right people the right questions? Data model and applicaton design I hate interfaces, what’s wrong with the command prompt? Expert just like us Get coding Testing Oversee development and release Technically capable users and data managers Filters back Existing data poor or wrong format Standards I don’t understand it at all and it’s a nasty colour I can’t link it to my GIS Need for thesaurus Users need terms they understand Release software A whole bunch of other people