Re-designing a Data Entry CMS

Question

Within the last year I joined a scientific research team as a programmer/analyst. Amongst many tools used by the researchers at this company, is a centralized content management system used to log important information about study participants.

We track everything from their age, birth, gender, to their MRI records, to medications, physician visits, attack history, etc... As I'm sure you can imagine, there are literally hundreds of demographic fields as well as over a dozen unique studies participants can be a part of, each of which has their own database fields. Researchers can also use the tool as an interface with our MySQL databases (we have over 25 of them...) and download reports to analyze data.

We're working with a LAMP stack and the site is currently relying on a HEAVY amount of jquery for styling. The website right now is definitely functional but is sore on the eyes (it was developed circa 2010). For each participant, there are multiple tabs with (almost) endless text fields, drop downs, and text boxes. I spent the last week or two essentially rebuilding the site with the foundation framework (as ALL of the CSS is hand written) but everything was still too cluttered and really did not improve the usability of the site.

My question to you all, how should one go about designing a website that's used for data entry and obtaining information? Are there any particular frameworks that solve scientific database entry UX better than others? Are strict data entry websites just not "design friendly" in nature? Having a tough time deciding where to start with this one.

Answer 1

The main buzzword you'll want to be looking for is form design. It's a discipline in its own right, and there will be plenty of important best practices to keep in mind.

That having been said, best practices can only take you so far. One of the most interesting points about data entry is that users are often performing the same task over and over again. What would improve speed for a one-off operation may actually slow down someone who is entering multiple records at once (e.g. autocompleting fields with a server-side callback/AJAX can be very useful if you don't know what values exist in the system, but can introduce an unnecessary delay into form filling if you already know exactly what you're going to write).

That makes it a great candidate for usability testing. The big questions should be:

1. How many records are added at a time?
2. How similar are records that are added?
3. Is the information dependent on existing information in the database?
4. Will multiple users be entering data at the same time?
5. Is the data being simply transcribed from somewhere else, or do users need to use their judgement/expertise?
6. How much validation is helpful?

Answer 2

From what I've read, a summary of the problem is this:

• Input form has hundreds of fields
• Website displays results in many tabs and fields

I would look into creating custom "views".

For the website, a user could choose which fields and tabs to display. If only 10 fields are important to a specific user for whatever task they are performing, they could create a view that only displays the 10 fields. A user could have multiple custom views. Or, you could create global views that employees can choose from without having to create their own views.

I would extend the idea of custom views to queries as well. Perhaps you only want to display records that contain data in fields c, e, and f, but no data in field a.

My most important advice is to find a way not to hard-code one specific view. Our users usually know better than we do what they need.

A little background into why I love views:

At my company, we make games. When a new task is created, it contains data for programmers, artists, musicians, and managers. This resulted in a form with a massive number of fields. We had an issue: artists wanted tasks to be displayed in one way, programmers in another, and on and on. On top of that, each person in the same department had specific fields that they felt were more important to them. Instead of spending massive amounts of time trying to figure out which user was the most right, we used a framework that allowed each user to modify how data should be displayed and queried without programming (views). We also let users share these views with each other. Some of views became more popular than others and were deemed global Views so that all employees could obtain them.

Since my last answer was deleted for unknown reasons (maybe because I specified a product that has a fantastic working example), I've created a new answer for you.

Answer 3

Although I totally get the position you are in, instead of trying to "fix" the old implementation, maybe you should consider starting from the beginning of the UX process, particularly gaining an understanding of what particular types of users (personas) most want to get out of the system (red routes). Maybe working on information architecture. Do some wireframing and prototyping and get user feedback.

I also agree with the poster who mentioned "views" - you mention "researchers" as the users but are they all researching the same thing, from the same perspective?