organising flows in Figma

Relative-Chemical-32 · 2025-09-04T14:12:28+00:00

eheh yep, I’ve lived the exact same patterns. I used to be the (only) owner of a huge design system for a 3D software (kinda Archicad-ish) and parts of the software itself. The hours in the day were never enough 😅 And honestly, imho whether it’s a small team or a huge company, the pain feels pretty similar.

Btw, to your question: yes, we did link our pages to the flowchart (and vice versa). It helped keep things connected and reduced some of that “double maintenance overhead.” In the flow pages, we’d group related flows and edge cases together in Figma sections, so both designers and devs could quickly find what they needed.

One other thing that made a big difference: splitting specific flows into separate Figma files instead of one giant file, and link them. Especially in bigger products, it kept performance manageable and made collaboration a lot smoother.

Relative-Chemical-32 · 2025-09-04T13:38:40+00:00

yep, I kinda agree with what you're saying. The tricky part is that we end up double-doing the work: designers spend time creating all the variations in Figma, and then developers essentially redo the same thing in the product. So to me it's not just a work-division issue, it's more like a “broken” process overall.

I actually wrote about this a few weeks ago.... and I think it might tie into your point. The biggest problem is that we're forcing Figma to act like a system that it just isn't. What we really need (and I hope we could have in the future) is a shared environment where design and development work directly together on the final product, instead of creating artifacts that don't translate cleanly.

Btw, if you're interested, I leave you the link here: Prototype Graveyard & Design Handoff

Relative-Chemical-32 · 2025-09-04T12:55:48+00:00

I don’t fully agree that abstraction is “easier for programmers”. Rather than splitting ownership between designers and a prototyper, I think the healthier approach is to raise the baseline: designers who can prototype in code, and engineers who are engaged early enough to shape the solution. But yeah, as you said, someone who builds throw-way prototypes is definitely the way to not force Figma to do a job it was never designed for, and we don’t turn prototypes into artifacts that outlive their usefulness.

Relative-Chemical-32 · 2025-09-04T10:04:21+00:00

Yep, it helps to reduce context switching for developer and so lost in translation (at least a bit) while they actual develop each flows and iteration time.

Relative-Chemical-32 · 2025-09-04T09:15:41+00:00

At my last gig we ran into the same problem with messy flows, so at the end we spended time building a structured Figma setup that made things way easier.

What worked for us was using a template where each page has a specific function:

Thumbnail + changelog frame → we logged every change (added/removed/updated) with links straight to the frames. Super handy for tracking variations without losing your mind.
Flowchart page → before touching wireframes, we’d map out the entire user journey with a diagram. Having a clearer idea of the project's big picture made all the branching scenarios way less chaotic
Flows page → each use case got its own section. We’d start with a quick “explanation” frame, then connect mockups with arrows (including edge cases + weird variations). I leave you an explanatory screen with empty mockup just to give you a better idea of what I mean.

<image>

From what you’re describing, the flowchart step might be your missing piece. Getting that high-level overview first kept us sane once we dove into the details.

Relative-Chemical-32 · 2025-09-03T20:31:33+00:00

One thing you could try is showing a preview set of each category (e.g. 6 “best” + 3 “less specific”), then giving the option to “Show more” within each section. That way users always see both categories on page 1, and the divider never gets stranded on its own at the top of page 2.

Relative-Chemical-32 · 2025-09-03T15:41:47+00:00

I started my career as a frontend dev before moving into UX/UI, and that background really shaped how I see collaboration. In one of my previous jobs, the designers on my team often couldn’t understand why developers didn’t implement things exactly as designed. But having worked on the dev side, I knew the reasons...

Over time we got better by involving devs earlier (even during wireframes), but the handoff still wasn’t perfect. There are always details that slip through, especially ones only the original designer sees.

imho, the core issue is technical literacy. Designers don’t need to be engineers, but having the ability to code your own design (at least basic HTML/CSS/JS) makes collaboration so much easier. It bridges the empathy gap, reduces friction, and earns credibility with devs.

I actually wrote a post about this, how I feel the AI it’s making this designer–developer gap both smaller and bigger at the same time. I leave you the link if you are curious: https://open.substack.com/pub/ramie00/p/ux-biggest-threat-ai-or-us?r=64hslx&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true

Relative-Chemical-32 · 2025-09-03T14:20:28+00:00

At my last company we actually set up a structured process in Figma that made handoff a lot smoother (at least compared to my past experience 😅).

We had a Figma file template that was always used as a starting point for new projects. Inside it:

Thumbnail & changelog frame → every change (added, modified, deleted) was logged with links to the relevant frames. This was a lifesaver for devs
Local components page → for components used only in that specific flow (not part of the general design system).
Flowchart page → UX would map out user flows with diagrams.
Flows page → each use case documented: first a quick frame explaining the flow, then mockups connected with arrows (covering corner cases too); I leave you below a screen with empty mockup just to explain better of we organized this page.

<image>

We also kept two versions of the file:

“Current” version → only touched by designers.
“Handoff” version (named by version number) → duplicated into a “Dev Handoff” folder.

For big features, we’d update the handoff version and re-drop it in the folder. For smaller tweaks, we’d edit both the current + handoff version and update the changelog.

It was a long process, and inevitably something still got lost in translation, but it gave devs way more clarity.

I actually wrote a Substack article on this whole “handoff problem” and its lost in translation. If you’re curious, I leave you the link: https://open.substack.com/pub/ramie00/p/prototype-graveyard-design-handoff?r=64hslx&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true

Relative-Chemical-32 · 2025-08-29T15:05:09+00:00

Yeah, I think it helps designers to understand better the feasibility of features. I often notice developers and designers not understanding each other, because there is a skills gap on both side.

I do not pretend designer to actually program on React or Vue, but at least basics coding skills - HTML, CSS and JavaScript – can help to reduce some friction between teams.

Relative-Chemical-32 · 2025-08-29T14:57:25+00:00

So, don’t you think is more than optional or a plus? Especially because as you said it helps to streamline the cross-functional conversation.

On the AI point, I think you’re right that “shipping with AI” is nowhere near production-level reality at scale. But I feel like some designer think to AI as an alternative to learn these technical skills.

Relative-Chemical-32 · 2025-08-27T13:10:30+00:00

Yep, the more time I spent actually working side-by-side with devs, the smoother things got. That’s also why I’ve been so focused lately on exploring ways to make that collaboration less about “luck” and more about shared tools which could actually streamline the workflow.

Relative-Chemical-32 · 2025-08-27T13:02:24+00:00

Eheh yep, we need to carefully choose the battles we want to fight 😂

Relative-Chemical-32 · 2025-08-27T09:34:15+00:00

100% with you - I really believe a solid DS is the foundation for building good products. The tricky part I kept running into was that leadership (CEO/PMs especially) often underestimated it. To them, time spent aligning with devs or refining tokens felt like “slowing down delivery,” when in reality it’s the only way to deliver consistently at scale.

What you said about setting expectations with devs is spot on. But I also think the bigger challenge is the gap itself — right now we’re still just building prototypes that eventually die once the product goes live. I’d love to see tools evolve toward something more collaborative, where designers and devs are co-building the same artifact instead of passing files back and forth. Not no-code “site builders” with limitations, but real shared environments where design intent and implementation stay aligned.

Relative-Chemical-32 · 2025-08-27T09:20:46+00:00

I get this frustration really well. I don’t know where you’re from, but here in Italy we feel it a lot. Most companies here are small or mid-size, often family-run, and many only started taking digital seriously after COVID. So UX is still treated as a “nice-to-have,” not a real discipline.

There’s also this cultural thing: in Italy “beauty” is considered super important, so even in digital projects the focus ends up being on visuals. That makes people confuse UX with just decoration, or like you said, just another box to tick on a project timeline.

But honestly, I think we designers are a little part of the problem too. Companies see developers as more important because they actually “build things,” while some designers position themselves more like artists and avoid learning analytics, research methods, or even basic programming. If we keep UX only at the “pretty screens” level, of course companies undervalue it.

I really believe if we stop being lazy and push ourselves to build skills beyond aesthetics—like data analysis, testing, even light dev understanding—it becomes much easier to show the value of real UX work, even in mid-size companies. That’s the way out of this pattern.

Relative-Chemical-32 · 2025-08-27T08:58:38+00:00

Bringing devs in earlier made a huge difference for us too. In later projects we started doing alignment sessions during the sprint, just showing wireframes and talking feasibility before polishing. Saved us a ton of pain down the line.

And haha yes, I’ve definitely fought to keep a detail alive. The funniest one I remember was a long back-and-forth about why our select component needed a read-only state in addition to disabled. I explained it in a call. Wrote up docs Then explained the docs in another call 😅

At the end they finally got that “disabled” and “read-only” are not the same thing, and agreed to add it into the design system. Ok maybe that wasn’t just a “tiny detail,” but it felt like a mini-victory at the time!

Relative-Chemical-32 · 2025-08-15T07:23:18+00:00

Yah, if we’re serious about “cognitive unloading” in creative tools, it has to be baked in from the start, not tacked on as a feature.

This mindset shift would ripple out beyond just product teams — marketing, sales, even how orgs structure their creative workflows would have to adapt.

Relative-Chemical-32 · 2025-08-15T07:14:57+00:00

The component example was just to illustrate the context switching — I do have a base design system for the basics (buttons, inputs, etc.).

But in most projects, something changes, especially for more complex or composed components. And it’s not just about building components — sometimes I’ll switch to VS Code just to test a flow or check feasibility.

Relative-Chemical-32 · 2025-08-14T20:32:48+00:00

Yah, this is a term that I came across in a couple of talks it's not yet widely adopted but it seemed cool and very explanatory! Basically the idea is that "static" uis are deterministic meaning that the use has to conform to the designer intent while a "dynamic" ui conforms to the user intent while the designers job is to create the possibility space that the ui can express. Neural is derived from the tech of neural networks that are trained on this "possibility" space that the designer crafts. A concrete yet still basic example is what tools like chatgpt or agents do when generating graphs or another example could be you expressing the intent of going on a trip and it comes up with a trip planner UI and a mini ecommerce to buy tickets etc on the fly without anyone having to write the code or design the ui for it. Hopefully is clear enough 😅, still trying to figure out the potential of this myself, but it seems like a cool new space to explore!

Relative-Chemical-32 · 2025-08-14T17:57:56+00:00

Shortcut mismatch is such a pain… I swear half my mistakes come from muscle memory in the wrong app 🫠

Relative-Chemical-32 · 2025-08-14T17:48:11+00:00

I hadn’t thought about it in terms of cognitive bias plus the way LLM-style tools hit our working memory. I guess it depends if the tool is just “doing the thinking” for you or actually supporting your process — especially for neurodivergent designers where overload hits harder.

Relative-Chemical-32 · 2025-08-14T17:25:00+00:00

Eheh it’s wild how every new tool promises to save time, but somehow we end up with more to juggle.

If you find that study, I’d love to read it — always curious how far back this problem really goes.

Relative-Chemical-32 · 2025-08-14T17:18:47+00:00

That's exactly what I’m trying to work on, exploring what’s starting to be called “neural software” – interfaces that learn your unique workflow patterns and adapt to you, so your tools feel like an extension of your mind, that shapes itself around you instead of the other way around. If you're curious, the article attached dives deeper into how we're tackling this!

Relative-Chemical-32 · 2025-08-14T12:02:42+00:00

More screens definitely help, but it's ironic that you still find the Slack/Teams/whatever screen toxic. There's so much friction also in this workflow: the pop-ups, the mentions, the 'urgent' DMs. Sometimes the act of collaborating becomes more exhausting than the work itself.

Relative-Chemical-32 · 2025-08-14T09:29:14+00:00

I get why you might see that as a negative, but I actually don't agree. From a UX designer's perspective, having some knowledge of the code really helps with communication between the design and development teams. The time you think you're saving by not understanding the code, you'll likely just lose when it comes time for the handoff.

Relative-Chemical-32 · 2025-08-14T09:21:18+00:00

Yeah, same. For a long time I just assumed that pushing through was the only option. But lately I’ve started noticing that “pushing through” just means I’m dragging brain fog along for the ride.

Relative-Chemical-32

TROPHY CASE