Menu
File Upload Feature
- UX Design
- User Research
- Interaction Design
- Usability Testing
Overview
Connecto generates reports for users to review and make business decisions. It’s in the early stages of development and doesn’t utilize an API to transmit data, so users must manually feed information into the system by uploading XML files, which get parsed and distributed into new reports.
Problem
When a user uploads a file that contains a parsing error, it prevents ingestion, and they’re unaware that the affected file didn’t upload in the app and assume it is functioning as expected.
Solution
The solution provided users with a summary of the upload, the ability to fix errors, and removed development team resources from the process. It saved time, eliminated confusion, and gained users’ confidence in the application.
Discovery
Users informed the product team that they received an error message when uploading files into the system. However, they noticed that some reports were distributed to the table.
User Research
User Interviews
I conducted user interviews to learn about their experience.
Existing Flow
To integrate data into Connecto Application:
- Users utilize a separate system to generate information
- They convert the data to an XML file
- Next, they upload the XML file to Connecto
- Then, the data gets distributed into new reports placed in a table that users can open and review.
Previous
Next
Key Takeaways:
- Users received a 504 Gateway Timeout error when trying to upload an XML. However, the file gets uploaded, parsing happens, but an error message is returned. As a result, they see new reports in the table.
- They need to know why they are receiving this error and need more confidence that all of the data is getting added.
- The XML file can contain information for up to 500 different entries.
- XML file upload saves time and reduces the effort of manually typing data into individual reports.
Interview with Development Team
I synced with the development team and asked the questions below to understand how the process worked on the backend.
Questions for Dev:
- How does the process on the backend work?
- What could be causing errors?
- How can users resolve issues?
- What are we capturing on the backend that we can display to users on the front end? Can we share information about the errors?
- Are there any front-end limitations?
- How much effort do you want to put into this?
Parsing Process (Backend):
- User uploads an XML file
- The parser parses them out
- Python reads it in an object and validates the fields for errors.
- It looks at the next candidate, repeats the validation process, and…
- Decides to accept or reject it as an error.
- If it accepts, it creates a new report
(this is how it generates the count for created).
- If it accepts, it creates a new report
Key Takeaways:
- An error log is available, but the view may not be user-friendly.
- The backend captures the number of files created and the number of errors.
- The system stores the report ID and error message in a separate collection in our database.
- If there is a validation error, it will include the field name.
- In the XML file, there’s a numbering of the order (array index of where the file falls in XML), which tells you where the file failed.
- Validation
- Max string length is 50 – 60 characters long, which might be violated sometimes. The only validation we have is that the string is too large or is not a number.
- Date/time – we don’t worry about that validation error.
- Certain fields have integers (whole numbers).
- We are at the mercy of what the user inserts.
User Persona
I used the insights to define a persona to understand the target user and provide a better context for me to solve their problems.
Sketches
Exploring Solutions
I explored a few solutions and shared them with the team.
What would the next steps look like for users?
- A better error message could appear in the snack bar that popped up, but it would disappear too quickly.
- A dialog box that users could close.
- Page with table to view the ingestion error.
- Users can edit the value and change it themselves.
We decided to move forward with displaying upload information and allowing users to resolve issues.
User Flow
There were 2 Paths that I had to consider for the flow – uploads that have errors and uploads without errors:
Uploads with Errors
- User selects an XML file from their computer to upload
- Backend checks for validation
- A modal appears containing a summary of the upload (# of reports created successfully, # of reports with errors); with the following options:
- Copy to Clipboard
- Edit function to fix errors
- Cancel Upload
- Then, they will see a Confirmation snack bar (the file was uploaded or canceled)
Uploads without Errors
- User selects an XML file from their computer to upload
- Backend checks for validation
- A toast will appear, confirming a successful upload (including # of reports)
Wireframes
Wireframes
Before landing on the final wireframes, I presented and tested them with stakeholders.
High Fidelity Design
Mockups
After several iterations, I moved forward with high-fidelity designs.
Usability Testing
Feedback:
- Need a Copied To Clipboard confirmation or text (copy-to-clipboard doesn’t close the modal).
- Add an example of what the copied text format would look like if pasted into an email.
- Update the “Upload File” button to “Proceed with Upload.”
- Add a “Delete All Errors” button to save time and clicks if they have a large number of errors to resolve.
Handoff
I incorporated feedback into the final designs and provided annotations in the files handed off to the development team.
Results
- Users have visibility of upload errors and can resolve issues themselves.
- The solution removed the development team’s responsibility from the process, saved time, and eliminated confusion.
- Users also felt confident and trusted that all uploaded data got inserted into the system.
Copyright © 2023 Nina Betts