Overview: Storage is a file sharing service. Clients can upload and download files of various types including custom reports, training materials and documentation. Due to legal regulations, Spectrum Enterprise cannot keep files or folders in the archives after 12 months (365 days) from when they’re archived.
Duration:
2 Weeks
My Role:
I worked as the lead UX Designer on the re-design of the Archives page.
Team:
Elisa Krebs, Product Designer
Pramit Sanyal, Product Manager
Tara McDaniels, UI Designer
Otis Garrison, Content Designer
How might we help our clients understand when and why their files are being deleted from Archives.
SETTING CONTEXT
The Ask
Storage is a Spectrum Enterprise product and file sharing service where clients can upload and download files including custom reports, training materials and documentation.
Due to legal regulations, Spectrum Enterprise cannot keep files or folders in the archives after 12 months (365 days) from when they’re archived.
If not re-designed, the Archives page would have no context around if, when or why files are being deleted.
There was a high likelihood that a client could have a file or folder disappear from Archives and have absolutely no idea why.
SETTING CONTEXT
The Problem As We Know It
This product was originally designed by a UX designer that only worked in high-fidelity and left no documentation of their design decisions.
The work got handed over to my mentor around a year ago and she only had the bandwidth to make incremental changes in high fidelity for small feature enhancements.
In Q1 of 2021, I inherited this work and became the lead UX designer on the product. I had to move everything from high fidelity in Sketch into Axure to work on wireframes in lower fidelity.
SETTING CONTEXT
The Questions I Needed Answered:
Who uses Storage?
Only 2 clients: CALNET (California Network and Telecommunications) and NYCDOITT (New York City Department of Information Technology and Telecommunications).
Because these are 2 of the largest clients of Spectrum Enterprise, the business is extremely protective over who gets to interact with them and will not let our UX team conduct interviews or any user sessions. The only feedback we get is when a CSM shares client feedback with us.
What is the purpose of the archive feature? What need does it solve?
We are unsure how users are using Archives. There are 2 possibilities:
Clients are using Archives as as a pseudo-delete — since we don’t offer a delete function, they don’t care if files get deleted.
Clients are using Archives as a true archive — a way to store files safely, separate from their current files and will care if their files get randomly deleted.
DESIGN INSIGHT + DECISION
Because we don't know user intentions, it is best to err on the side of caution and give the user as much context and warning as possible about file deletion.
How do we move forward when I have no research to work off of and a tight timeline?
Let’s do it very intentionally.
DESIGN EXPLORATION
Internal Inspiration
To begin, I searched through our existing design system components and other portal features for similar use cases and treatments.
Two other products stood out to me (Users and Billing) and I identified 3 existing patterns to draw inspiration from:
Page-level warning: Something on this page needs attention
Card-level warning: Pulls the attention down to the card with consistent coloring and iconography.
Table cell warning: Pulls the attention down to a table cell with consistent coloring and iconography.
DESIGN EXPLORATION
First Iteration
Based on my first round of internal pattern exploration, I met with my content designer, put together a first iteration of wireframes and presented them to my PM for feedback.
We recommended adding:
Persistent microcopy under the H2
A page-level warning banner
A cell-level warning on the file or folder nearing deletion
DESIGN EXPLORATION
Iterating on Options
I agreed with the sentiment of this ask, but not with the approach. Adding a Delete Date column to the table would mean repeating the same data the Archived Date with only the year changed.
I felt this didn’t address the problem that my product manager was truly getting at: Even with the understanding that a file would be deleted 365 days from the date archived, how could we make it easier and more clear for a user when a file would be deleted?
I put together a few options and met with our art director to discuss.
DESIGN INSIGHTS
After discussing iterations, we decided:
What works:
Providing a day countdown (i.e. Will be deleted in 2 days) takes the guess work out of figuring out the deletion date.
Important info is kept flush left, following the pattern of how we know users look at web pages.
Keeping icons and caution messaging paired in the same table cell.
What doesn’t work:
Using the date something will be deleted (i.e. Will be deleted on 4/16), which still requires a user to figure it out themselves.
Separating the icon from the caution microcopy feels a bit disjointed and is not the best experience for someone using a screen reader.
Replacing the file icon with the caution icon means that there is no way of knowing what type of file it is.
DESIGN EXPLORATION
External Inspiration
I looked at and pulled inspiration from 2 other file storage products:
Dropbox
Google Drive
I realized that we don’t put the file extension on the end of our file names. Because there was no design documentation when the product was first built, I don’t know if this was an intentional design decision or an oversight.
Regardless, it wasn’t consistent with other file sharing services and posed a problem with general usability when we implemented the caution icon in the previous iterations.
DESIGN INSIGHT + DECISION
Include the file extension at the end of the file name, so a user doesn’t have to depend on the icon to know the file type.
NAVIGATING STAKEHOLDERS’ DESIGN OPINIONS
Defending Design Decisions
After presenting the next few iterations, my PM expressed that we should tell users how to unarchive something in the mircrocopy — something along the lines of “press the ellipse menu to unarchive a file.”
We typically don’t give direction for how to take action on something in our portal unless it is extremely technical. It’s UX best practice that if you need to explain how to do something to the user on a page, it’s not intuitive enough.
However, I was the lead UX designer on our design system table usability tests and watched 30 users intuitively interact with a more menu to archive and unarchive a file.
Once I was able to present my PM with the data from another user test, he understood that the table interactions were extensively tested and came on board.
Ultimately, it was decided that we didn’t have enough time for a usability test.
What can we feasibly design?
COLLABORATION WITH DEVELOPMENT
Technical Constraints and Workarounds
I chatted constantly via Teams and in meetings with my developer and PM to clarify the feasibility of our proposed enhancements.
1. Discovered that we weren’t currently storing an Archive Date, but we do store a Last Modified date. Once a file is archived, it can’t be modified further, so therefore the Last Modified date is the archive date. We could use this to backfill the data for the files currently in Archives, and then work with our dev team to clean up the data and start capturing a true archive date moving forward.
2. A dynamic page-level warning that notifies if any file on the page is within 14 days of being deleted is possible, once we solve for bullet point 1.
3. The deletion date for the folder and all of the files in that folder will be the same — so we don’t need to worry about a folder having files with different deletion dates.
4. It is possible for us to have a countdown in the table cell. The front end would do the math based on the Archived Date and tell the error text to show up and start counting down if it’s within 14 days of being deleted.
THE FINAL DESIGN
Helping our clients understand when and why their files are being deleted.
THE FINAL DESIGN
No Files Nearing Deletion
Persistent microcopy on the page
because a user should be informed of how we’re handling their files at all times.A Date Archived table column
to make it extremely transparent when a file was archived.Table sorted by the Date Archived column on load
to prevent files nearing deleted from being hidden by pagination.File extensions added to the end of file name
so that a user isn’t dependent on the icon to know the file type.
THE FINAL DESIGN
Files Nearing Deletion
A dynamic page-level warning when a file is within 14 days of deletion
so a user knows immediately when landing on the page that files need their attention.Visual icon indication on the file or folder row that is about to be deleted
taking the guessing game out of trying to figure out which files will be deleted.Countdown microcopy on the row to indicate how many days until deleted — taking the the math out of trying to figure out when a file will be deleted.
THE FINAL DESIGN
Modal Content Update
I worked with our content designer to update the modal copy at the time of archive.
The modal is a reminder that archiving is not permanent, files or folders can be unarchived and also was a bit of a compromise with my PM’s previous concern about users not knowing how to archive.
REFLECTION
What did I learn and what would I do differently?
I learned to check in with development early and often.
Having a strong working relationship with my developer allowed me to understand the data available and continuously verify the feasibility of the enhancements we wanted to make. This potentially saved me a re-design at the end of the project and gave her a heads up of what was to come!
I learned that design truly is a team sport.
This project would not have been successful without the many collaboration sessions with my team. Every single part of the final design was a team effort and each person’s speciality brought an interesting perspective to the design.
Some things I still feel uneasy about:
How do our users actually use Archive and will that change when we implement a true delete?
Does a user need to know who archived a file?
If we know that only 2 clients use this service, why is it so difficult for us to get access to them for research? They requested the product, wouldn’t they want to help us improve it?
I really regret not pushing back harder on testing. I’m working with UXR to set up a user test and any changes needed will hopefully be picked up next quarter.