tw-rl

Earlier today, someone asked how our design and development process works at Figma. I don't know if this is interesting to anyone, but I ended up writing down our messy, unofficial process in perhaps too much boring detail. 1/n

Allison Grayce @allisongrayce@skuwamoto @figmadesign mind sharing how you do things at a high level while I check your jobs page? 🙃 twitter.com

Phase 0 - brainstorming: We always have way more feature ideas under consideration than we would ever have time to build. Primarily these come either directly from user requests, or from insights that we get from watching people work. 2/n

Sometimes, people make progress on designs even before features make it onto our roadmap. Maybe a designer is particularly passionate about something and wants to spend some time thinking about how something could be better. Could also be a PM or an engineer. 3/n

Having time to explore these early ideas is important because you never know where that nugget of gold is. 4/n

Phase 1 - roadmapping: When a feature becomes important enough, it enters our roadmap. Roadmapping is a black art, quite frankly, and it involves some combination of synthesizing customer feedback, reading the competitive landscape, and lots of internal discussion. 5/n

When a feature enters our roadmap, we try to write down key things like "who is this for" and "what are some specific situations when someone needs this?" This step is surprisingly important to keep a feature from going off the rails. 6/n

Phase 2 - kickoff: Once a feature is ready to start in earnest, we assemble the team, which typically consists of a designer, a PM and some engineers. We try to identify the whole team from the beginning so they can be included in all discussions. 7/n

At this point, we try to map out the work in milestones, which are longer than sprints (~4 weeks). Milestones have specific goals, like "get the first version up on staging". 8/n

TBH, we often don't have a good idea of what will happen beyond the immediate next milestone, but that's ok. 9/n

Phase 3 - exploration: Design starts a wide exploration which, depending on size of project, can take multiple weeks. During this phase, we try to keep tabs on how the exploration is going via design crit + team check-in meetings. 10/n

The deliverables for the exploration phase are: (1) what is the overall model for how this feature will work? (2) do we have a general idea for the direction of the UI? The model is the most important output of this phase. 11/n

For example, for the states feature, we settled on a model where each section in the property inspector corresponded to a group of settings that could be lumped together into a "style". 12/n

And then we argued endlessly about how colors should work, because they don't fit into that model. Fills have colors, as do strokes. So working out at least some of the edge cases is also part of the model. 13/n

Phase 4 - development: Once exploration is done, design enters a refinement phase and engineering begins in earnest. Engineering tasks are tracked in Asana, and design tasks are mostly untracked. 14/n

Feature teams meet a few times a week to make sure that design and engineering stay in sync. Designs may change during this time based on engineering needs, or based on designers having new insights. 15/n

Designs usually change a lot during this process. As the product takes shape and the fog lifts, it gets easier to see what is working and what is not. 16/n

Also, there is a 50/50 chance that we completely missed something during exploration where we're like "oh crap. now what?" and we have to rethink something truly big. 17/n

Phase 5 - testing and refinement: At this point, the feature is mostly done, and we put it up on our staging server. For larger features, it almost certainly won't feel right immediately. 18/n

We usually leave it up on staging to test internally, and sometimes we test with external folks. This can take a few weeks or more for a big feature. We'll tweak and tweak a feature it until we like it. 19/n

BTW, features don't always turn out well. We have literally decided to scrap (or indefinitely pause) features at this phase, which frankly does not feel good. 20/n

Phase 6 - Ship it! 21/n

Is this the perfect process? Definitely not! It's messy and we end up redoing a bunch of stuff. Compared to most teams, I would say we spend more time on exploration and we allow for more design changes during development. 22/n

Redoing work can feel frustrating, but building a product we are happy with is the goal that we all have, and we haven't figured out a better way. 23/n

As we have grown, we have gotten better at organizing this chaos in a thoughtful way. Nowadays, I would say that I see less wasted work although it's *still* the case that some things can't be figured out until you play with the finished code. 24/n

That's it! I'm curious to see how this compares to everyone else's processes out there! 25/25

Addendum: we are also exploring ways we can design more in the open. If we were to share designs earlier in order to get feedback from the community, would that be interesting to you?

Addendum 2: what I described is the process that we use on the teams I'm closest to, which are the editor teams, where we need to do a lot of design. The infra team, in contrast, has very different requirements, and operates differently.