How to design a screen in which users must choose a value from a list of options for each row in a 500 row table?

Question

I'm designing an application that's supposed to help ease a very tedious and difficult task.

Prior to this app - each user would be given a spreadsheet with about 5-8 columns, and 300-500 rows. (Each user's spreadsheet would be different).

For each and every row, the user would need to populate a value in the last column. That value would be selected from a list of choices (e.g., an Excel drop-down menu) that usually contained 20-30 choices. The list of choices is exactly the same for every row.

The actual context is sensitive, but here's a hypothetical analogous example - the spreadsheet contains a list of bugs for software development project. Each column has a different piece of information about the bug (e.g, the screen on which the bug occurs, the severity of the bug, who discovered the bug, how repeatable it is, etc.) The user must review each bug, and assign the bug to a developer (from a list of about 20 developers). That assignment is made in the last column.

As you can imagine - this is incredibly tedious and time consuming.

By turning this into a web application, I will at least be reducing the time and trouble of distributing the spreadsheets, and ease the process of merging them.

But, I'd also like to be able to create a UI that streamlines the data-entry work as well.

My worst-case solution is a simple table/grid, with a drop-down menu (i.e. select element) in the last column of every row.

But surely there's a better solution/design pattern for this?

Answer 1

I think a much easier solution for the end user, since you say the list of choices is the same for every row, is to have the table with the last column empty, and then a separate list somewhere on the page, near the table- not a dropdown but a list with all choices visible at a glance - where clicking a name will add it to the row automatically.

This way, instead of the user having to click and scan the dropdown each time, they are looking at one list, clicking the name once and moving on to the next row, clicking again, and so on.

You'll have to take into a few other elements - highlighting the row that's next to insert the name in, logic for selecting the next available row, etc but this would require the least amount of clicks and cognition from the user (imo).

Answer 2

This sounds like a data-entry task, and I think it should be treated as such. That is, assuming that this is a task that returns with some frequency.

When being confronted with such tedious work, it makes sense to optimize for speed rather than being friendly for new users. That means that you can afford your UI being harder to learn, as long as it is faster to use in the end. Your users will gladly spend the effort learning if that means they'll get rid of the tedious task quicker. For learn-ability, the options to select should of course not change all the time.

For one, I'd make sure your users can deal with the whole thing without taking their hands off the keyboard. Hitting a key to select an option is much faster than selecting the option from a list. If all a user needs to do is select a single option for a row, and then move the next row, the very action of selecting the option can also trigger to move to the next row.

Also, for speed, it is important to keep an overview of the the last view items that you did (so you can check if your speed didn't result in mistakes) and a few upcoming items so the user can think ahead. However, drowning your user in a screen full of rows will also make it harder to focus on the current row, so the current row needs more space.

^{download bmml source – Wireframes created with Balsamiq Mockups}

I did something like this some years ago to ease data entry for a gliding club. Instead of endless excel sheets with flights, we could now very quickly enter all the needed data. The time it took to process wend down an order of magnitude, while the error rate wend down as well.

Answer 3

Do multiple rows need to be visible at all? Otherwise why not just display one row at a time. Or get rid of the row abstraction all together. Show the information from a row and all possible choices for him to click and select from.

Answer 4

Some quick thoughts:

• Have two views: one to step through the tickets one by one, using the whole screen for a single ticket, and moving on to the next once an assignment is made, and one to give an overview of the assignments currently made. Both views have different use cases.
• Use something visual to represent the developers (like photographs). This makes selection and identification easier.
• Give a visual indicator of each developer's availability. For instance, the more tickets the developer has been attached to, the more greyed out his photograph becomes. This way, the user can easily identify which developers are free to take on more tickets.
• Generalizing on the last point: think about how your users make these assignments. What would the optimum look like? An equal workload per developer? Developers assigned to issues they have expertise with? People in the same office working together? Try to put the information surrounding these issues in the view. Try to show how well they're doing so far in getting to the ideal.
• Optimize the workflow of moving through tickets. The user reads the tickets and chooses a developer. This can be done by a single click on one of the developer photo's. After the click, the view should shift to the next ticket. This can be confusing, so have some safeguards (going back, going to the table view) and do some testing.
• Have a computerized suggestion. I suspect that for 80% of tickets the developer assigment doesn't matter. Write a reasonable ticket assigner and have the system suggestion outlined in green, so that if the user is ambiguous she can click the suggested ones. It's often the choices where the user doesn't care that take the most energy.

Answer 5

Sorry to cut you off, I don't think this is even humanly possible to focus on a sheet a paper with 500 rows and for each row pick an answer from 20-30 drop down choices which in itself requires intensive visual scanning every time. Even if you are paying people to do that, you are betting on their ability to do this job.

If I could translate this question into the weight lifting sense, you are asking "how can you make a person lift 500 Kilos"?

Coming back to the subject, some of my thoughts are:

• Revisit your whole "need to do this effort".

• Get no more than 15 (if you want to push hard then 20) rows filled by a person at a time at most. Filling more than 10 questions in a survey start causing survey fatigue and we are talking about 300-500! way too much then human can do efficiently. I presume after 20 records, everybody would start putting "crap" just to fill the rest of the form off.

• BUT in case you had to go the way you are going, spread your survey into multiple pages keeping no more than 20 rows on a page. But here I wonder after finding page 1 of 20, how encouraged would users feel to press the "next" page button!

I know some times there are requirements to do the stuff which you are doing but lets also not forget that humans cannot lift 500 kilos either. You got to think better alternates than that.

Answer 6

I would think about what the user is looking to achieve first and foremost and don't get stuck with existing technical solutions.

If the user needs to classify 500 items then how would someone do that in real life? Do you use cards? How are the marked? Is there a way to do it that allows the user to group things and then just label them as a group?

In essence you are trying to find a good solution by first using a potentially bad one.

Answer 7

I know this pain :) I sometimes use just a Google Doc for bug tracking. Usually there are not that many developers as in your case, but they can be grouped in some categories (like PHP, Flash, CSS).

The first idea is to limit the list of devs displayed in the selector. It would be great if you could do it automatically, based on some other columns. If you cannot do this, then you may consider first selecting the field, and then a dev from this particular group - but this may make it worse as well, because users will need to fill in two fields instead of one. Please check it yourself if it works or not.

If it doesn't, there is another suggestion. You can still group the developers, and provided that users know their names, you can use a mechanism similar to the one used in redesigned country selector: http://baymard.com/labs/country-selector You will need to build a dictionary including developer name, field and initials. This will let users limit the list of selectable developers as they type in either the field, initials or a part of name or surname. It should improve the speed dramatically.

Additionally, I think this column should be always visible. The others can be horizontally scrollable, but the one used for assigning developer should be visible all the time. You could also consider moving to another view (unique view for each bug) to avoid scrolling and increase general usability of the interface, with an option to see the complete list. The reason is that users don't need to focus on problems other than the one they analyze at the moment. Once they assign the bug to developer, they switch to another bug (but put it against your requirements, maybe in this case it is different).

Last but not least - have you checked the available bug tracking software? There are quite many options for that, including web applications. Here's a list: http://www.thegeekstuff.com/2010/08/bug-tracking-system/ or even this one: http://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems - but I agree that the general problem with these is that they are complicated in everyday use. This is why I sometimes use Google Doc for that.

Answer 8

You could have a 'copy down' row at the top. So users can use checkboxes to highlight the rows they want to change - enter the common value in the top 'master' row and then click a 'Copy down' button. I did this for an admin area for hotel owners who want to set prices for different dates.

Then its just ticking a load of checkboxes, which can be tedious in itself. If there's any way to group the data so that you can have jQuery to tick a bunch of the rows together than that will further help with the process.