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 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
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
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
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
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".
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
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
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
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.
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