When Figma starts designing us

Auto Layout, Grids, and Constraints

• One camp argues Auto Layout is just a visual Flexbox: it speeds up lists, tables, and responsive prototypes, reduces tedious alignment, and makes “implementation-friendly” designs more likely.
• Others say it subtly “locks” layouts into a narrow set of patterns, making freeform exploration harder and nudging everything toward uniform, grid-like apps.
• Several commenters point out that nothing in Figma forces Auto Layout; you can use plain frames, absolute positioning, or detach components. The tension is less about capability and more about how teams choose to use the features.
• There’s frustration that many designers don’t use Figma’s more “systemic” tools (grids, tokens, responsive thinking) consistently.

Creativity vs Consistency

• Developers often welcome Figma’s constraints: most products are CRUD apps that benefit from predictable, reusable patterns and design systems instead of bespoke, hard-to-implement screens.
• Others argue that over-structuring early design kills “play” and personality; exploratory, weird ideas are less likely to emerge when everything starts in a component-driven, auto-laid-out canvas.
• Several say exploratory work should happen with sketches, freeform tools, or code prototypes, while Figma is better for converging on consistent UI built from established components.

Design–Engineering Collaboration and Workflow

• Many see the real problem as isolated design “handoffs”: polished Figma files treated as gospel, divorced from implementation constraints and user flows.
• Preferred alternative: rough sketches → early code prototypes → iterative designer–developer collaboration in code, with Figma used sparingly or later.
• Others counter that in large organizations, detailed Figma specs, props, and mirrors of code components are essential because teams don’t have tight, continuous collaboration.

Designers, Code, and Understanding the Medium

• Multiple voices stress that good web/UI designers should understand HTML/CSS, responsive layouts, and accessibility, not just push pixels.
• Friction often arises when designers create static, pixel-perfect artifacts without grasping browser variability, breakpoints, or implementation cost.
• There’s debate over role boundaries: some think “designer’s job is to dream,” others insist design is problem-solving under constraints, not unconstrained art.

Limits of Figma and Desire for Alternatives

• Some engineers find Figma “too designer‑y”: poor performance with large design systems, weak modeling of CSS features, and brittle deeply nested components.
• Others feel it has become “too engineer‑y”: features like Dev Mode and variables pull designers toward implementation details and away from early research and exploration.
• Several people advocate “designing in the browser” with HTML/CSS-based tools, or mention alternatives (e.g., Penpot, custom in‑browser editors, low‑code metaphors).
• Broader parallel is drawn to low‑/no‑code platforms: as abstractions grow, they either converge on code or become limiting.

Tooling Shapes Thinking

• There’s wide agreement that tools and languages shape mental models, just as programming languages constrain which patterns (e.g., Erlang supervisors vs Redux) even occur to you.
• Some see Figma’s dominance as analogous: when one tool becomes the default, its implicit model of “proper” layout, components, and handoff quietly narrows the design space.

Flat UI and the “Figma Aesthetic”

• A few commenters vent about modern flat, low‑affordance UIs: invisible scrollbars, tile/pill overload, weak cues for what’s clickable.
• Others note this predates Figma and is more about minimalist, Jony Ive/Dieter Rams–style cargo‑culting; Figma merely reflects the prevailing aesthetic.

Organizational and Process Factors

• Many argue Figma isn’t the root cause; organizational incentives, bureaucratic workflows, and scaled product orgs drive “pixel‑perfect handoff” and over‑specification.
• Some want stronger guardrails in Figma (enforced design-system constraints, linting, version control akin to Git) to match engineering practices.
• A Figma PM explains the product’s intent is to sit between freeform and structured design, with features optional and escapable (detaching, removing Auto Layout), and suggests process and “linting on handoff” are better levers than hard technical locks.