tw-rl

I'm constantly asked... "How do I organize my files?" So here are my 7 goals for file organization in @figmadesign 👇

01 // Everything that engineers see should be relevant and directly related to what they’re building. That means: • No explorations • No contradictory states Any time there's UI on a page that is NOT supposed to be built... it leads to confusion. My strategy for #1 👇

01 (cont'd) // "Production" vs. "Shaping" projects • I explore only in shaping files • Then move only what is ready for engineering into production files • Production files are published as libraries and imported back into the matching shaping file to detach + explore 🔄

02 // All of the core flows should be clearly outlined • The primary way I organize files is by moving horizontally across "flows" • I have a "title" component I use to name each flow so that I can easily refer to it (I also like linking to this title frame)

03 // It should be easy to see all of the potential variations that a given screen can have • Whenever a screen has a different state or layout variation, I’ll stack that new frame below the default frame • If a screen isn't a part of the core flow it's considered a variation

03 (cont'd) // • If this variation is only happening at the local component level... I’ll often document that within my variants instead of creating a whole new frame just to show something like a hover state. • Dedicating a whole new frame just clutters the page imo...

04 // Clearly show how screens respond at each breakpoint • I’ll display the core layouts for each breakpoint stacked vertically below the parent flow • I’ll show every possible state for web, and then document only what is unique to each specific breakpoint below that

04 (cont'd) // If nothing changes across breakpoints, I'll combine them into a single row. This often happens when a chunk of UI hits its max-width. I'll just make a note about how a layout applies to both `xl` and `2xl` b/c the content can no longer grow.

05 // Clearly document all components and the states they can take • If I’m using a component imported from my design system, I’ll make a note about it and link back to the relevant file. • I try not to rely on the Inspect panel to highlight components that I'm using.

05 (cont'd) // • Any local components that I’m using live in a separate page (I like to use the “🔗” emoji as a page name) • I think have a component wrapper frame that I use to highlight the component name, as well as any state info or other helpful documentation

06 // It should be easy to identify where we're at in the build process for a given file • The first page in each file uses a "Table of Contents" • I break my files into: 1. Production (what's already built) 2. Local Components 3. Shipping (what's in progress)

06 (cont'd) // • In my interviews with developers, I've found that this TOC component is way easier to use for navigation than the Figma file sidebar UI itself... • I then use emojis to map my page names to these different stages of the development lifecycle

07 // It should be easy to figure out what UI relates to specific development tickets/issues • The starting point for devs is often an "issue" in a project management tool • So for feature requests/improvements, I organize my page vertically into "tickets" to map to @linear

07 (cont'd) // • Within each note component, I'll link to the @linear issue (as well as anything else relevant) • I then explain what's changing from what is currently in production • I then copy this frame link and paste into @linear where it automatically previews my text

Hope you enjoyed this little teaser of the @figmaacademy "Workflow" module 😇 Enrollment opens to the public in January! Make sure you're on the list 👇 https://www.figma.academy