I am currently revisiting a data upload field in our system. These files (csv, xlsx) contain thousands of rows, which can produce hundreds of errors. Currently, the way we handle this is to spit out a monstrous tooltip of each individual error which is far from user friendly.

I have ideas on how I think I want to handle it, but am looking for examples/best practices of rolled up views of such large amounts of errors.

  • 1
    Are you able to provide a sample of what type of data is in the files and examples of what errors the user can receive? Are users presented with the ability to edit from the same page the errors are presented, or do they have to load the file back into an external editor? Nov 22, 2013 at 1:11
  • A few of the possibilities would be - "student id already exists", "row must contain a numeric value", "invalid data type", etc... No, currently users cannot edit in the UI they must fix data then repeat upload. Nov 22, 2013 at 16:31

3 Answers 3


In my experience IDEs have the best UIs for dealing with large amounts of errors unobtrusively. An example of a UI for managing large numbers of errors can be found in XCode.

When I build a project with warnings or errors, it lets me know without throwing up massive dialogs in my face:

Two warnings

They're already classified into warnings or errors so I can ignore them if they're just warnings. They're surfaced in the UI in the same place I normally look for progress/status.

I can drill in to inspect them by clicking on the disclosure icon (so when I click the yellow warning icon above. Doing so opens the errors and warnings pane:

Errors and Warnings Pane

Within this view I can choose to see my errors grouped By Type or By File, and I can also filter them with a live search for keywords:

enter image description here

Clicking on an error takes me to the place that the error was found.

I guess the best practice would be to treat the errors the same as any other information you are designing interactions with. You could roll up the errors into a summary, allow the users to drill down, sort and filter them depending what their requirements are regarding inspection of errors, or you could even hide them away completely if the users aren't ever going to care about them (you can always log them and notify someone about them in the background so that you don't interrupt the user), just as you would with any other information that doesn't have relevance to the interaction at hand.


Show a summary of the upload results and include any errors.

I was faced with this task in one project and the approach that worked for us was to show a summary of the results complete with any errors that occurred. Depending on the task, the user could either back out, make their changes, and try again, or fix the issues with the upload on the system after committing their updates.

Here are some design considerations we thought about.

  • Can we fix any errors for the users? Sometimes users could be penalized for formatting we didn't expect.
  • Should we commit only the good rows or everything? We thought it would be more work for partial commits since then the user would have to remove the "good" rows from their source file, fix the ones that caused an error, and try again.
  • Can we preview the upload for them? This preserves the state of the system and allows the user to choose to ignore errors as needed.

For UI ideas consider the wizard of importing data into SQL Server. There is a step to make adjustments to the data and a preview before committing.

  • Thanks Jonathan, I have been considering all these same things. Especially whether we should commit the good data and then return a stripped file containing only problem data. Nov 22, 2013 at 16:35

We have a similar situation. We summarize in the UI after file upload with an error alert and a bullet in it for each error type, count, and any helper text.

For example:

• 12 row(s) - Missing {field1}
• 5 row(s) - Duplicate {field2} (must be unique for each {field3})

Now, we're adding a "Download error report" button (final label TBD) to that alert so that users can get more detail, like the exact row/cell that had the issue.

What we're not sure about is if this report should only include rejected line items.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.