I spent the summer of 2016 as a software engineering and design intern at Figma. I mainly worked on two projects: designing, building, and shipping the project activity feed, and researching a techincal spec for a future plugin API. Along the way, I also rearchitected our CSS workflow, introducing CSS Modules to the codebase.
Project Activity Feed
Figma is an online, collaborative design tool. A core part of the collaborative experience is the shared filesystem where projects and files are stored, and users work together.
When multiple designers are working on a project together, all kinds of activity takes place. Designers can create and edit files, leave comments, update the project settings, change sharing preferences, and so on.
In the months leading up to launch, we wanted to make sure that working together on a project wasn’t a chaotic experience, and creating the project activity feed was the first step in that process.
When designers, engineers, and PMs on a team work together, how do we give them a sense of what’s going on?
Still in limited preview, Figma was fast becoming the go-to tool for our users. However, wtih Multiplayer about to launch, we had a renewed focus on improving the collaborative user experience. Through talking to our current users, we realized two things:
- Figma is used not just by designers, but often by engineers, and PMs too.
- When teams adopt Figma, they often want to know what’s been happening at the team, project, and indivual user level.
My goal was to explore ways to solve this problem, and then go out and build it.
01. Audit and Research
Before diving into problem, I took a couple of days to survey other products and put together an audit of activity feeds. Here’s a few of them.
Next, I sat down and identified a few different personas of our target users (individual contributors, engineers, PMs), and the kinds of scenarios they find themselves in.
03. Problem Spec
This research helped me frame the problem better, and break it down into five constituent issues. For this first version, we decided to focus on two key issues: visibility and helping users view and debug history.
In this way, starting with our users’ goals and investigating other products helped me frame the problem well. It also prepared me well for the next stage of the design process: ideation and exploration.
The next step was going wide and being generative; coming up with a whole bunch of ways to surface activity. I explored ways to do so at the global, team, project, and user level. I also took a look at different kinds of “stories” that we could show users.
04. High-fidelity Explorations
Having explored many directions, I then converged into a few good options, and drew them out in high-fidelity. At a high level, we were exploring two ideas: a visual, card-based activity feed, versus a sidebar based historical log.
In the end, we decided to build a simple version of the sidebar for our initial release. It fit into the existing interface design, and offered the core feature of the activity feed: the historical log and a way to debug missing files.
The design phase allowed us to explore a wide variety of ideas, and I’m sure some will manifest themselves in other ways in the future. Concepts like presences—showing who’s online—as well as the ability to manage comments in one place will be key in the future.
Having decided on a first version, I transitioned into the next phase: engineering.
After four weeks of design, I led the project’s engineering for the rest of my internship.
01. Database and Logging
Working with Ruby and Postgres, I set the database schema, wrote migrations, and set up event logging at various points in our codebase.
02. Back-end API
Next, I created new API end-points, implemented pagination, and connected them to the front-end to post and get activity data.
03. Collation Algorithm
An important part of the engineering was to combine multiple similar events into compact stories. This collation had to maintain causal order (a file can’t be edited after it has been deleted), but it also had to avoid the noise of hundreds of similar events.
To solve this issue, I came up with an online algorithm that responded to each incoming event in real-time. Through a series of heuristics, it would combine similar events together across time, action type, user, and file.
04. Front-end UI
Next, I implemented the UI on the front-end using TypeScript, React, Redux, and CSS Modules, along with infinite scrolling for the feed.
05. Polish and shipping
Finally, after much polish and a couple weeks on staging, we shipped the activity feed to all users with Figma’s public launch!
Working at Figma was an amazing experience. In a hybrid role at the intersection of design and engineering, I was able to carry my feature from idea to production. As someone with a passion for engineering and design, working on design tools was a great way to make impact in a part of the industry I cared about.
I’m really bullish on the future of Figma. I believe that real-time collaboration and an online-first workflow will become commonplace in all kinds of industries—writing, architecture, animation, film, sales, design—and tools like Figma will be at the forefront of that change.
In addition to working on the activity feed, I also spent a lot of time improving our front-end tooling by introducing CSS Modules and fixing our Webpack build. I also spent the last two weeks of my internship researching and writing a spec for a future Figma API. If you’d like to hear about these and other projects, please drop me a line at firstname.lastname@example.org.