If you would like to minimize your implementation costs and increase user acceptance while managing risk, you are not alone (see Chart 1). Using resources with expert-level design skills and true hands-on experience can help you accomplish these goals and more. How is this possible? Think back to a time when you first learned to do anything; writing your first MS Excel macro, creating your first MS PowerPoint presentation or even just making a pancake! Chances are it took longer than expected and the resulting product was less than prize worthy. Your macro was convoluted, your presentation was simplistic and lacking in automation, and your pancakes were burnt on the outside but mushy in the middle. However, once experience and expertise had been attained, slithe time it took to accomplish those same tasks had diminished while the quality had markedly improved. The same is true for implementing solutions in a Laboratory Information Management System (LIMS). LIMS Implementation Experts design fast, efficient solutions that are high in quality and provide an excellent user experience (UX). Utilizing expert design resources will increase LIMS user acceptance levels while reducing your LIMS project time and cost.
Impact of Expert LIMS Designers on IT and the Informatics Group
- Reduced implementation budget
- Lower maintenance costs
- Less calls to support
Novice LIMS solution designers can miss key business logic criteria, design overly complex interfaces, and cause errors in sample data handling. If a section of the design does not satisfy a compliance requirement adequately another project to remedy this shortcoming must be initiated. This new project will add to your project time and budget. Novices may also generate poor quality code documentation which can increase the time it takes to address and rectify bugs and maintain your existing code. If the design is not done in a modular fashion reuse of existing code will be problematic and later modifications may well require code changes in multiple locations. Additionally, a confusing user interface designed by a novice will inevitably lead to more support calls as well as lower end user satisfaction.
Impact of Expert LIMS Designers on the End User
- Higher user acceptance
- Increased harmonization between labs
- Reduced learning curve
Solutions that are overly complex and don’t provide good user feedback lead to confusion and a poor user experience. Providing feedback in the form of tool-tips, descriptive error messages, and interface options (enabled/disabled vs visible/invisible) allow the users to navigate the solution efficiently and with minimal anxiety.
If the LIMS solution is cumbersome or unintuitive, it will only be adopted and utilized by those forced to do so. This is unfortunate because a process improvement delivered through informatics automation, implemented within a global or site-wide LIMS, can increase productivity on a massive scale.
Most LIMS utilize the Model View Controller (MVC) pattern. While this is a common pattern for enterprise systems, it can be daunting for the inexperienced. Making changes to existing controller code can have unintended consequences that often manifest in unexpected areas. Below is an example of a feature request and the steps an experienced LIMS Designer/Developer takes when designing a solution.
Example – Feature Request:
Our senior lab personnel need to have the ability to edit\fix lot numbers after the sample has been created in the LIMS.
1 – Understand the Business Logic:
Understanding the business logic behind the change creates a solid design foundation which enables faster development, better test cases, and minimizes rework:
- Identify the appropriate statuses for when a lot number can be updated.
- Find out associated audit information (should a note be added?).
- Assemble a list of roles that are authorized to make\review the changes.
- Map out the forms that can allow this change to be made.
- Identify the related objects that are affected by the change (child lots, inventory, reports, etc.).
2 – User Interface Design (UI):
Good user interface design dramatically reduces the number of support calls by hiding unnecessary\unauthorized components, providing detailed feedback, and using intuitive application interaction mechanisms that users are familiar with:
- Decide how the users will change the lot number (in-grid, separate form, etc.).
- Decide on how the interface will be controlled.
- Form tools.
- Invisible\Visible based on business logic.
- Enabled\Disabled based on business logic.
- Provide good error and change conformation feedback.
3 – Development Considerations:
Reusing existing modules can reduce development time considerably but it is not always the appropriate solution. Below are some questions that help clarify when the reuse of existing modules is appropriate.
- Does the existing code support the change without modifications?
- How many other modules use this code?
- Will modification of the module impact functionality outside the scope of the current project?
- How much additional regression testing will be needed?
4 – Test Case Design and Informal Testing
Test cases which consider all or most possibilities, combined with informal testing identify errors and design issues early on. Some testing considerations are listed below:
- Invalid input type (eg. special characters ‘*, !, ~, ’).
- Logging in as roles with and without authorization for editing and reviewing.
- Check all areas of the system identified in stage 1 of the design.
- Check affected objects identified in stage 1 of the design.
In summary, utilizing expert LIMS solution designers and developers will end up saving you an exponential amount of time and money. This is true for your LIMS project but will also have benefits beyond your go-live date by reducing the amount of time spent on support calls, project re-work, and corrective actions. Utilizing experts is well worth the cost.
Have you run into situations where a project had to be reopened because an aspect wasn’t considered by a novice designer/developer? Does your support team receive recurring calls on a particular module or feature that you later learn was designed or developed by a novice? Have any of your LIMS implementation projects been extended due to an error discovered in formal testing that could be traced back to a novice LIMS designer/developer?