Figma Responsive Design: Layout Mobile và Desktop hoạt động thế nào

Một frame Figma trông ổn cả ở desktop 1440px lẫn điện thoại 375px không có nghĩa là hành vi responsive ở khoảng giữa đã được quyết định — Figma chỉ cho bạn xem hai ảnh chụp cố định, còn trình duyệt cần các quy tắc tường minh để lấp đầy mọi kích thước màn hình mà một người dùng thực tế có thể có. Để đi từ "hai frame này trông ổn" đến một layout thực sự đứng vững, bạn cần đọc Auto Layout và constraints như tín hiệu responsive, chứ không chỉ là thiết lập hình ảnh, đồng thời biết rõ đâu là điểm dừng của Figma và đâu là lúc CSS phải tiếp quản. Dưới đây là mô hình tư duy thực dụng, những gì cần kiểm tra trước khi bắt tay vào code, và vị trí của phần responsive tự động từ MarkupGen trong bức tranh đó.

Frame Figma là một bản đặc tả hình ảnh, không phải CSS responsive

Figma render một frame ở đúng một chiều rộng cố định. Không có gì trong file "chạy" qua các kích thước màn hình theo cách một trình duyệt làm — thứ trông giống responsive design trong Figma thực chất là một tập hợp quy tắc (direction, gap và sizing mode của Auto Layout; constraints của layer) mô tả ý định, chứ không phải một mô phỏng hoạt động thật của sự kiện resize. CSS mới là nơi ý định đó trở thành hiện thực: flex-direction, gap, phần trăm, clamp(), và các rule @media mới thực sự phản hồi theo chiều rộng viewport. Hãy coi file Figma là nguồn chân lý cho ý định thiết kế, chứ không phải thứ đã sẵn chứa CSS responsive hoàn chỉnh.

Frame mobile và desktop mô tả một thiết kế, không phải hai

Rất thường gặp cảnh một frame desktop và một frame mobile trong cùng một file được thiết kế cách nhau vài tuần rồi âm thầm lệch nhau — heading level khác nhau, component variant khác nhau, nội dung xuất hiện ở frame này mà không có ở frame kia mà không rõ lý do. Thay vào đó, hãy coi hai frame là hai góc nhìn của cùng một mô hình nội dung: cùng heading, cùng component (dùng variant cho trạng thái, không tạo bản sao riêng lẻ), và cùng thông tin theo cùng thứ tự trừ khi có lý do chủ đích để sắp xếp lại. Khi cả hai frame chia sẻ cùng một cấu trúc nền tảng, phần CSS cần làm chủ yếu là layout — xếp một hàng thành một cột, điều chỉnh số cột của một grid, thu gọn UI phụ — thay vì phải duy trì hai template rời rạc nhau.

Auto Layout và Constraints: điều gì thực sự chuyển thành hành vi responsive

Direction, gap, padding và sizing mode (hug, fill, fixed) của Auto Layout ánh xạ khá sát với Flexbox — xem Figma Auto Layout sang CSS để có bảng ánh xạ đầy đủ từng thuộc tính. Riêng với hành vi responsive, sizing mode là tín hiệu quan trọng nhất: một phần tử "fill" đang cho bạn biết nó nên lớn lên hoặc co lại theo container (flex: 1, width: 100%), còn "fixed" cho biết nó không nên như vậy.

Constraints trả lời một câu hỏi khác — một phần tử hành xử thế nào khi phần tử cha của nó đổi kích thước, điều này quan trọng nhất với bất cứ thứ gì nằm ngoài Auto Layout:

• Left / Right — ghim vào một cạnh, gần giống một offset cố định giữ nguyên vị trí khi phần tử cha đổi kích thước.
• Left and Right — co giãn theo phần tử cha, gần giống width: 100% với margin hai bên cố định.
• Center — giữ nguyên vị trí căn giữa khi phần tử cha đổi kích thước, tương tự margin: 0 auto hoặc cách đặt vị trí căn giữa bằng flex/grid.
• Scale — đổi kích thước theo tỷ lệ cùng phần tử cha; CSS không có một tương đương trực tiếp duy nhất nào, và hành vi này thường được xấp xỉ bằng các đơn vị tương đối (relative units).
• Top / Bottom (và các kết hợp) — cùng logic đó áp dụng cho trục dọc.

Rất nhiều file thực tế dùng cả hai cùng lúc: Auto Layout cho cách các phần tử con của một container tự sắp xếp, constraints cho cách chính container đó hành xử bên trong một thứ lớn hơn nó.

Breakpoint: từ frame Figma đến CSS thực

Figma không có tính năng breakpoint gốc — không có thiết lập nào nói "chuyển layout khi dưới 768px". Thứ một file thực sự cung cấp cho bạn là hoặc các frame riêng biệt cho từng kích thước màn hình, hoặc một frame Auto Layout duy nhất tự co giãn linh hoạt mà không hề đổi cấu trúc. Bạn đang gặp trường hợp nào sẽ quyết định CSS có cần rule @media tường minh hay không, và việc chọn giá trị breakpoint khớp với chỗ layout thực sự đổi hình dạng — chứ không phải các chiều rộng thiết bị tùy tiện — chính là phần việc chính. Chuyển breakpoint Figma sang CSS Media Query trình bày chi tiết cả hai mẫu hình này và những chỗ dịch thủ công thường sai.

Biến các quyết định trong Figma thành CSS responsive

Khi các tín hiệu phía Figma đã rõ ràng, phía CSS chỉ còn là một bộ công cụ khá nhỏ được áp dụng nhất quán:

• Flexbox cho phần lớn frame Auto Layout — hàng, cột, thanh nav, danh sách thẻ.
• Grid cho các layout thực sự hai chiều, như dashboard hay gallery mà Auto Layout đang giả lập bằng các hàng và cột lồng nhau.
• Media query ở những chỗ hình dạng layout thay đổi — một sidebar biến thành bottom nav, một grid biến thành một cột duy nhất.
• Fluid sizing (phần trăm, minmax(), clamp()) cho mọi khoảng nằm giữa các chiều rộng mà designer thực sự chỉ định, thay vì thêm breakpoint để lấp đầy khoảng trống.
• max-width để tránh text và nội dung bị kéo giãn quá rộng khó chịu trên màn hình lớn, ngay cả khi bản thân frame Figma không thể hiện giới hạn này.
• Wrapping và stacking (flex-wrap, một hàng biến thành một cột) cho nội dung nên reflow thay vì bị co nhỏ lại.
• Thay đổi visibility cho bất cứ thứ gì thực sự chỉ dành riêng cho mobile hoặc desktop — cần làm cẩn thận, vì ẩn một phần tử bằng display: none cũng loại nó khỏi accessibility tree. Xem Chuyển Figma sang HTML có khả năng tiếp cận nếu nội dung bị ẩn vẫn cần tiếp cận được theo cách khác, như một menu mobile.

Những lỗi thường gặp khi chuyển Figma thành layout responsive

• Coi mobile như một bản desktop thu nhỏ thay vì một layout riêng với thứ bậc và ưu tiên của chính nó.
• Hardcode kích thước pixel ở mọi nơi frame Figma hiện một con số cụ thể, thay vì dùng sizing fill/fixed và constraints để quyết định thứ gì thực sự nên giữ cố định.
• Bỏ qua text wrapping — một heading hay label nút vừa đúng một dòng ở ngôn ngữ gốc có thể xuống hai, ba dòng khi dịch sang một ngôn ngữ dài hơn, và một layout giả định text luôn nằm một dòng sẽ bị vỡ.
• Dựa vào absolute positioning để khớp thiết kế từng pixel, cách này trông đúng ở đúng chiều rộng frame nhưng vỡ ở mọi chiều rộng nằm giữa.
• Chỉ kiểm tra ở đúng những chiều rộng mà frame Figma được vẽ — chẳng hạn 375px và 1440px — mà bỏ qua mọi thứ nằm giữa, đây chính là nơi phần lớn lỗi thực sự xảy ra.

Checklist bàn giao cho developer

Trước khi triển khai hành vi responsive từ một file Figma, nên kiểm tra trực tiếp vài điều trong thiết kế thay vì tự suy đoán:

• Những frame nào tồn tại, và liệu mobile và desktop được chủ đích là cùng một nội dung được cấu trúc lại, hay là hai trải nghiệm thực sự khác nhau.
• Thiết lập Auto Layout trên từng frame — direction, gap, padding, và sizing mode trên các phần tử cần đổi kích thước.
• Constraints trên bất cứ thứ gì nằm ngoài Auto Layout, đặc biệt các phần tử ghim vào cạnh hoặc căn giữa.
• Spacing và typography ở từng chiều rộng frame — chúng co giãn theo, hay giữ cố định?
• Component variant — component có một variant mobile riêng biệt, hay đó là cùng một component được kỳ vọng tự thích ứng?
• Điều gì thực sự khác biệt giữa frame mobile và desktop, và liệu mỗi khác biệt đó có chủ đích hay chỉ là độ lệch phát sinh giữa các lần chỉnh sửa file khác thời điểm.

MarkupGen tự động hóa nền tảng responsive như thế nào

Mỗi bản xuất bắt đầu từ chính thiết lập Auto Layout và resizing constraints của frame, chứ không phải một danh sách breakpoint chung chung — direction, gap và padding được giữ nguyên chính xác, còn sizing fill/hug được dịch thành CSS linh hoạt, nhờ vậy kết quả co giãn theo mọi kích thước màn hình mà không cần viết tay media query cho phần lớn layout.

Với những thiết kế mà mobile thực sự cần một cấu trúc khác — menu xếp chồng thay vì nằm ngang, hero được sắp xếp lại, sidebar bị ẩn đi — trình biên tập tích hợp có thể tạo riêng một layout Mobile hoặc Desktop được thiết kế đúng mục đích cho trang hiện tại từ HTML/CSS đang có, kèm media query riêng; bạn xem trước trước khi áp dụng, và kích thước màn hình của người xem sẽ quyết định layout nào được hiển thị kể từ đó. Dù theo hướng nào, đầu ra vẫn ưu tiên HTML ngữ nghĩa thay vì <div> lồng nhau, ở Vanilla CSS, Tailwind, Bootstrap, Bulma, Materialize hay Pico, kèm điểm chất lượng AI tự động cho mỗi bản xuất. Không điều nào trong số này thay thế được checklist ở trên — đây là điểm khởi đầu được sinh ra từ các tín hiệu thật của thiết kế, vẫn đáng để rà soát như bạn rà soát bất kỳ bản triển khai responsive nào khác trước khi lên production.

Nếu muốn xem chính file Figma của bạn phản hồi ra sao trên cả hai kích thước màn hình, hãy thử công cụ chuyển Figma sang HTML — hoặc chuyển thẳng sang React nếu đó là stack bạn đang dùng — miễn phí, không cần thẻ tín dụng.

Câu hỏi thường gặp

Một thiết kế Figma nên xử lý layout mobile và desktop như thế nào? Hãy coi chúng là một thiết kế duy nhất được thể hiện ở hai chiều rộng — cùng nội dung, cùng heading và component — chứ không phải hai file không liên quan. Auto Layout và constraints mô tả cách cấu trúc chung đó nên thích ứng; những khác biệt cấu trúc thực sự, như một nav bị thu gọn hay một hero được sắp xếp lại, sau đó được triển khai bằng CSS media query.

Auto Layout và constraints của Figma có tự động làm thiết kế trở nên responsive không? Không. Chúng mô tả ý định — một phần tử nên có kích thước hay hành xử thế nào khi container của nó thay đổi — nhưng ý định đó vẫn phải được dịch thành Flexbox, Grid, fluid sizing hay media query trong CSS thực tế. Không có Figma lẫn công cụ chuyển đổi nào tự sinh ra mọi quyết định responsive một mình.

Làm sao để chọn breakpoint CSS từ một thiết kế Figma? Figma không có tính năng breakpoint gốc, vì vậy hãy đặt breakpoint dựa trên chỗ hình dạng layout thực sự thay đổi, chứ không phải theo các chiều rộng thiết bị tùy tiện. Nếu thiết kế dùng frame riêng cho từng kích thước màn hình, layout của mỗi frame thường trở thành một khối @media; nếu thiết kế dựa vào resizing linh hoạt của Auto Layout, nó thường không cần breakpoint nào cả.

Sự khác biệt giữa Auto Layout và constraints trong Figma là gì? Auto Layout kiểm soát cách các phần tử con của một frame được sắp xếp — direction, gap, padding, sizing — gần nhất với display: flex. Constraints kiểm soát cách một phần tử hành xử khi phần tử cha của nó đổi kích thước, như bị ghim vào một cạnh, căn giữa, hay co giãn theo tỷ lệ, điều này quan trọng nhất với các phần tử nằm ngoài Auto Layout hoặc với cách một frame Auto Layout nằm bên trong một thứ lớn hơn nó.

Mobile và desktop có nên tách thành các file Figma riêng biệt không? Không nhất thiết, và giữ chúng trong cùng một file với component dùng chung thường giúp dễ phát hiện độ lệch hơn. Điều quan trọng hơn cấu trúc file là liệu hai frame có đại diện cho cùng một mô hình nội dung — cùng component và thứ bậc — với layout, chứ không phải nội dung, là thứ thay đổi giữa chúng.

Tôi nên kiểm tra gì trước khi triển khai một thiết kế Figma theo hướng responsive? Những frame nào tồn tại, thiết lập Auto Layout và constraint của từng frame, spacing và typography thay đổi (hay không thay đổi) thế nào giữa các frame, component có variant mobile riêng biệt hay không, và những khác biệt nào giữa frame mobile và desktop là chủ đích thay vì độ lệch ngẫu nhiên.