Development & Design ยท Summer 2016
As a software engineering intern at Figma, I got to implement and design some core features to the file management experience.
Figma - Recovering deleted files
Figma is a collaborative interface design tool that lives on the web. As a web product, users can collaborate on files that live on the cloud in real time. Unlike native design apps, Figma files are created through the web editor and users can navigate these files through an online file browser.
When I started my internship, deleted files were not recoverable. My project involved designing a solution for this.
Here's a short demo of the final implementation. I'll be discussing the process and the decisions we made in more details down below.
Demo of the solution
Home of the deleted files
I started to figure out where the deleted files would be located. The view containing the deleted files could hold files at three different possible levels: global, team and project. For example, at a team level, each team would have a view showing all of the team's deleted files. The second option was a deleted toggle mode per view. Similar to how Dropbox has a button to show deleted files at any folder level, we considered having a toggle mode to show deleted files in the selected view.
Low fidelity mockups of the explorations and investigating modes
Scribbles of file deletion flows and analysis of different possibilities
As a team, we wanted to move away from having so many different modes within the product. Modes add additional state to the app, and as a result, complexity. Since the file editor was moving away from modes, we wanted to stay consistent with the editor and wanted to create a separate view for the deleted files instead.
Example of a toggle mode per project that shows the deleted files in that project
Having an additional view created for each project or team created for the deleted files seemed really extra. The expectation is to create one entity during creation, and having the extra files adds unexpected behaviour as well as takes up a lot of extra space in the user's workspace. Through this discussion, it made most sense to have one global view where all deleted files live.
Example of a Deleted Files View containing files at a global level
After agreeing on the location, we then had to define the terminology that fits best in the user's mental model of our file browser. For the user, what term best defines their deleted files? We narrowed down the options to "Deleted Files" and "Trash".
"Trash" defines a physical container that holds work that you don't want anymore. If a teammate deletes your shared work and suddenly, everyone else sees in their trash, it would be completely absurd in the physical world. Once something is in a trash, it should only belong in that trash.
This didn't fit in the mental model of the collaborative workspace Figma provides. Deleted Files resonates as a place where all files that have a deleted state live in. In the user's mind, all files should live in the same space, but are only separated per view by state. We decided to call the view "Deleted Files".
Organization of Deleted Files View
Within the Deleted Files view, it was important to figure out how we wanted to organize the information. The view contains deleted files that should be actionable.
Users already knew how to use our file browser and how it worked. It didn't make sense to train users to learn a different way of browsing through files, so we chose to adopt the same pattern and interaction used in the other file views.
Overview of high fidelity mockups of different organizations of Deleted Files view
Two examples of high fidelity mockups for the Deleted Files View
When a file gets deleted, the expectation is that they can see the file at the top of the deleted files view. It becomes an anti pattern to force the user to scroll to the bottom to find their deleted files.
In terms of the data shown on each file, users also care about who deleted the file to have a better understanding of the context of why the file is in Deleted Files in addition to the previous data shown before it was deleted.
Organization of each file
Since each file has different permission levels per user, it's important to define what actions are available per file. We decided to allow Restore, Delete Forever and Duplicate to Drafts.
This was my first design task in a professional setting and it was an extremely daunting one. As an initially very obvious feature, it slowly grew into a whole web of edge cases, especially after my work merged with the permission features.
I've learned so many things by going through this design process. Early feedback and introspection allowed me to improve myself for future design processes. I'm extremely thankful for the help of my mentor Jessica Liu and Rasmus Andersson for the help provided during the whole way.
Dev work
After finishing the design of file deletion and restoration, I implemented the full feature on both the frontend and the backend.
I worked on allowing multiple files to be selected at once as well as batch actions. I also helped on the UI for allowing teams to be created without a Slack team.
I've also invested in some performance work, reducing the initial load time of the file browser by several seconds depending on the user. The optimization led to a load time of under 1 second for most users.
Lastly, I've investigated bottlenecks in our incremental webpack builds and proposed solutions, bringing the build time from 9 seconds to 1 second.
As an avid photographer, I decided to take photos for the office whenever an opportunity arises. Here's a photo of the team, taken with my Fujifilm XT-10