While having a conversation with a LIMS professional the other day I realized that there are some popular misconceptions about system usability floating around. There's a faulty perception that a computing paradigm that is widely used is necessarily the most desirable. Hold the phone! Some system architectures originated when computers were mainly console based. Back then usability took a back seat to the capabilities of the hardware (green/dark screens, low resolution). Those constraints, rooted in this past, have been superseded today.
It is important to get to know how users perceive your solutions. This goes beyond simply handing them a questionnaire or asking them whether the system meets the requirements. I'm talking about sitting with them while they use the system and asking them how much they enjoy what they are doing. When I did this myself a while back I was surprised to learn that they were not always happy.
As humans we like to follow. If I'm not mistaken there is some research out there to support this supposition. Following well-trodden design paths and paradigms for laboratory software development is no exception. We see a system or a set of interfaces of an existing system and we assume that laboratory personnel must have wanted it when in fact the interface decisions may have been made by technical professionals.
I'll give you a practical example from LabTools. There are several fields on the inventory table that refer to some other static entities stored in other tables. Let's consider a vendor name for instance. For data integrity's sake we'll say that '3M' is the identity but 'Minnesota Mining and Manufacturing' is the long name. When I show the inventory record I show the fields actually stored in the record -- that is, vendor ids, not descriptive names. The entire module is based off of a spreadsheet the users concocted to manage inventory, so the module followed suit with the main interface sitting in a grid. When the users saw this they balked. 'What happened to the long names?' they asked. 'Geez, it sure is hard to work with these identities...' they said.
Having worked for years with an enterprise-level LIMS I never thought that users felt this way about field identities. An identity like '3M' is a no-brainer, but try 'SRICITC' for 'Shanghai Research Institute of Chemical Industry Testing Centre.'
One solution is to select the descriptions from the other tables in the main SQL statement that drives the grid but that would make my query contain more joins than it already has making it, well, ugly.
Another related request came along for dynamic lookup for certain entities like on the Google website where for every letter you type some 'suggestions' appear. I always thought that users cared little for such a feature and, as such, implemented using the standard good old popup buttons that launch scrollable pick lists. My predisposition against the search feature was that it is highly inefficient and increases load on your servers as your user base increases. However, it may actually be a necessary evil when users are 'on the go' and know some of the identity but not all of it.
Today, thanks to AJAX (provided you are producing a web application) you can create a 'lookup' for descriptive information or for an identity search. This allows users to peek at more information regarding a certain cryptic identity that is visible on the screen without forcing the user to leave that screen and that is the direction I'm going to handle both the dynamic lookup and the identity description problems.
In summary, usability means digging a big deeper for dissatisfaction. Meeting requirements is the first hurdle. The system should not be a pain to work with. Identities are cryptic and there should be a relatively painless way to reduce confusion. Solving the problem with more SQL needlessly complicates those queries and will negatively affect performance, often for information that the user may not need. Offer them a way to 'lookup' that information as needed. Finally, take time to learn some of the newest techniques for developing web-based solutions (AJAX) to help you achieve higher degrees of usability.Go Back
Citation: Experiences with User Centered Design. (2012). Retrieved Wed Mar 22 22:16:16 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1326387999