Figma
Figma là công cụ thiết kế UI/UX trên nền tảng web. Nó cho phép thiết kế, dựng nguyên mẫu và cộng tác thời gian thực, được sử dụng nhiều cho các nhà thiết kế và nhóm sản phẩm/phát triển.
Bắt đầu
Bản đồ thân thiện cho người mới về điều hướng cốt lõi của Figma và vòng lặp cộng tác đầu tiên.
Quét nhanh
- Vị trí ≠ quyền: Drafts/Projects (Nháp/Dự án) khác với mức truy cập.
- Chia sẻ đúng phạm vi; kiểm tra quyền truy cập 1 lần.
- Dùng comment để theo dõi phản hồi và quyết định.
1) Mục đích & kết quả
Làm quen thật nhanh: tạo file đầu tiên, tổ chức nó, và chia sẻ an toàn. Bạn kết thúc với một link review và một file người khác có thể tự điều hướng mà không cần hướng dẫn.
- Hiểu Drafts vs Projects vs Files.
- Tạo và đặt tên file với cấu trúc cơ bản.
- Chia sẻ với quyền phù hợp (
can view/can edit). - Dùng comment để theo dõi phản hồi và quyết định.
2) Ai • Khi nào • Ở đâu trong điều hướng
Dành cho bất kỳ ai mới dùng Figma hoặc mới vào team. Nội dung bám theo Help Center: Get started + file browser + sharing.
- Ai: designer, PM, engineer, học sinh/sinh viên.
- Khi nào: tuần đầu, dự án mới, link review cho khách hàng.
- Ở đâu: Help Center → Get started.
- Tab liên quan: Files and projects (Tệp & dự án), Figma Design, FigJam, Figma Slides.
3) Mô hình tư duy / luồng
Có 2 lớp: file nằm ở đâu (dễ tìm) và ai được làm gì (quyền). Chia sẻ có thể kế thừa từ team/project, nên hãy kiểm tra kế thừa trước khi thêm người 2 lần.
- Bắt đầu ở Drafts để tự khám phá; chuyển vào Project để làm chung.
- Chia sẻ file cho 1 deliverable; chia sẻ project cho một bộ deliverable.
- Ghi quyết định trong comment; resolve thread khi xong.
- Cẩn thận với Trash/restore—xóa ảnh hưởng cộng tác viên.
4) Đối tượng, thuật ngữ & việc cốt lõi
Học “danh từ” một lần; dùng được cho mọi sản phẩm. Sau đó dùng danh sách việc cốt lõi như checklist hằng ngày.
- Drafts: không gian cá nhân; vẫn có thể chia sẻ.
- Projects: nhóm các file liên quan trong một team.
- Files: Design (.fig), FigJam (.jam), Slides (.deck).
- Quyền:
can view,can edit(và owner/admin tùy trường hợp). - Việc: tạo + đặt tên + dựng cấu trúc file.
- Việc: chia sẻ link + thu/resolve comment.
5) Luồng chuẩn (happy path) #1 — Tạo file đầu tiên
Một file nhỏ, dễ mở lại và review sau này.
- Tạo file mới trong Drafts hoặc trong team/project (chọn vị trí).
- Đổi tên (tên dự án + loại tài liệu).
- Thêm 2 page/khu vực: Start here, Work.
- Thêm 1–2 frame/section mẫu và gắn nhãn.
- Chuyển file vào đúng project (nếu bạn bắt đầu ở Drafts).
- Mở Share và xác nhận quyền truy cập mặc định của link.
Kết quả mong đợi: Một file đã đặt tên, có cấu trúc, nằm đúng chỗ, sẵn sàng chia sẻ.
6) Luồng chuẩn (happy path) #2 — Chia sẻ + vòng lặp comment
Chia sẻ một lần, rồi dùng comment như backlog phản hồi.
- Nhấn Share, chọn quyền, copy link.
- Nhờ 1 reviewer mở link và xác nhận truy cập.
- Vào comment mode (
C) và ghim 2 comment vào đúng vị trí. - Dùng
@mentionsđể gán người phụ trách. - Trả lời kèm quyết định; resolve các thread đã xử lý.
- Kiểm tra lại Share sau mọi thay đổi.
Kết quả mong đợi: Một link review duy nhất với phản hồi được theo dõi và resolve rõ ràng.
7) Điểm ra quyết định
4 lựa chọn A/B phổ biến giúp tránh hỗn loạn giai đoạn đầu.
| Tình huống | Chọn A | Chọn B |
|---|---|---|
| Vị trí bắt đầu | Drafts (tự thử nghiệm). | Project (làm chung + dễ tìm). |
| Phạm vi chia sẻ | File (một tài liệu). | Project/team (nhiều file). |
| Cần quyền chỉnh sửa | Yêu cầu quyền edit. | Chỉ duplicate khi thật sự cần tách nhánh. |
| Kiểm soát sao chép | Chia sẻ mặc định để cộng tác. | Hạn chế copy/sharing khi bắt buộc. |
8) Nguyên tắc an toàn, kiểm chứng & luyện tập
Hầu hết lỗi người mới là do quyền + tổ chức file. Dùng các bước kiểm tra này trước khi gửi link.
Nên / Không nên & bẫy thường gặp
- Nên: Đặt tên page/section sớm.
- Nên: Chia sẻ phạm vi nhỏ nhất đủ dùng.
- Nên: Resolve comment khi xong.
- Không nên: Đừng tùy tiện Trash file đã chia sẻ.
- Không nên: Đừng mời người ngoài vào cả team chỉ vì 1 file.
- Không nên: Đừng duplicate để “lách” quyền.
Lỗi thường gặp
Lỗi: Chia sẻ sai cấp
Tránh: Chọn đúng file vs project vs team; kiểm tra quyền kế thừa.
Lỗi: Cấu trúc không rõ ràng
Tránh: Thêm Start here + page/section có nhãn.
Lỗi: Feedback nằm trong chat
Tránh: Ghi quyết định bằng comment.
Lỗi: Bị “hớ” quyền truy cập
Tránh: Test link với 1 reviewer.
Lỗi: Xóa nhầm
Tránh: Học cách restore trước khi dùng Trash.
Thế nào là ổn
- Mở file ra là thấy ngay điểm bắt đầu rõ ràng.
- Reviewer truy cập được ngay.
- Comment thể hiện quyết định và được resolve.
Checklist: trước khi gửi
- File đã đặt tên + đúng vị trí.
- Pages/sections đã gắn nhãn.
- Share settings đã kiểm tra.
- Ít nhất 1 reviewer đã test.
- Có kế hoạch dùng comment.
Checklist: sau khi gửi
- Reviewer xác nhận truy cập.
- Resolve 2+ comment.
- Không vô tình mở rộng quyền.
- File vẫn nằm đúng project.
- Link được gửi kèm ngữ cảnh.
Bài thực hành (5–15 phút)
- Tạo + đổi tên một file.
- Thêm Start here + Work pages.
- Chia sẻ
can viewcho một người. - Nhận 2 comment và resolve.
- Mở lại Share và xác nhận quyền.
Kết quả mong đợi: Một file khởi đầu gọn gàng với quyền đúng và feedback đã resolve.
Kiểm tra bạn làm đúng
- Reviewer mở link được ngay mà không cần hướng dẫn.
- Điều hướng rõ ràng, dễ hiểu.
- Thread được resolve gọn gàng.
Liên kết tài liệu chính thức
- Guide to the file browser — Drafts, Deleted files, điều hướng.
- Guide to sharing and permissions — mức chia sẻ + quyền kế thừa.
- Add comments to files — comment mode, mentions, threads.
Nguồn tài liệu: Figma Learn Help Center: Get started, Guide to the file browser, Guide to sharing and permissions, Add comments to files.
Figma Design
Nền tảng để xây dựng UI sạch, tái sử dụng trong các file Design.
Quét nhanh
- Frames + Auto layout = ổn định.
- Components/variants = tái sử dụng.
- Chạy workflow: 1 màn hình + 1 bộ component.
1) Mục đích & kết quả
Xây UI trong file Design để càng lớn càng vẫn dễ chỉnh. Bạn sẽ có 1 màn hình gọn gàng và 1 bộ component tái sử dụng.
- Dùng frame + layer để tổ chức màn hình.
- Dùng quy tắc layout (Auto layout) để giảm căn chỉnh thủ công.
- Dùng component/variant để tái sử dụng và đồng nhất.
- Giữ naming gọn để review và handoff.
2) Ai • Khi nào • Ở đâu trong điều hướng
Dành cho thiết kế màn hình, component và prototype trong file design. Dựa theo Help Center → Figma Design.
- Ai: designer + người review.
- Khi nào: tạo UI hoặc một design system nhỏ.
- Ở đâu: Help Center → Figma Design.
- Tab liên quan: Dev Mode, Files and projects, Figma Slides.
3) Mô hình tư duy / luồng
Một file Design gồm canvas + cây layer + bảng thuộc tính. Lộ trình nhanh nhất là mã hóa cấu trúc (frames), quy tắc (Auto layout), và tái sử dụng (components).
- Frame định nghĩa biên (màn hình/khối chứa).
- Layer định nghĩa thứ bậc và hành vi chọn.
- Auto layout mã hóa quy tắc khoảng cách/padding.
- Component lan truyền thay đổi tới instance.
4) Đối tượng, thuật ngữ & việc cốt lõi
Các thuật ngữ này xuất hiện xuyên suốt tài liệu chính thức. Danh sách “việc” là thứ bạn làm hằng ngày.
- Frame: container cho một màn hình/section.
- Component/instance: bản gốc + các bản dùng lại.
- Variants: một bộ component với thuộc tính (size/state).
- Auto layout: quy tắc khoảng cách co giãn.
- Việc: dựng 1 màn hình với hierarchy + tên lớp rõ ràng.
- Việc: chuyển UI lặp lại thành component/variant.
5) Luồng chuẩn (happy path) #1 — Dựng một màn hình gọn
Tạo một màn hình không “vỡ” khi text thay đổi.
- Tạo screen frame (preset thiết bị hoặc tự đặt).
- Thêm một container trên cùng và bật Auto layout (dọc).
- Thêm header + khối nội dung; set padding/spacing.
- Tạo một nút (button) và dùng lại 2 lần.
- Đổi tên các layer quan trọng (Header, CTA, Content).
- Nhờ 2 comment review về cấu trúc.
Kết quả mong đợi: Một màn hình có spacing theo “quy tắc”, và layer dễ đọc.
6) Luồng chuẩn (happy path) #2 — Component nút với variants
Mô hình hóa size/state mà không cần nhân bản component.
- Thiết kế một nút.
- Chuyển thành component.
- Tạo variants cho size và state.
- Đặt tên property rõ ràng (size=, state=).
- Thả instance và đổi property.
- Sửa component gốc và kiểm tra instance cập nhật.
Kết quả mong đợi: Một bộ button variants giúp giảm việc làm trùng lặp.
7) Điểm ra quyết định
Các lựa chọn này ảnh hưởng mạnh tới khả năng chỉnh sửa và handoff.
| Tình huống | Chọn A | Chọn B |
|---|---|---|
| UI lặp lại | Component + instances. | Copy/paste cho các trường hợp thật sự “one-off”. |
| Nội dung thay đổi | Auto layout + constraints. | Layout thủ công cho hình tĩnh. |
| Nhiều trạng thái | Variants + properties. | Tách component riêng chỉ khi cần. |
| Tính nhất quán | Dùng styles/variables cho token dùng chung. | Giá trị trực tiếp để thử nghiệm. |
8) Nguyên tắc an toàn, kiểm chứng & luyện tập
File Design sẽ chậm và khó kiểm tra khi cấu trúc mơ hồ. Giữ file “inspectable” cho người khác (và cho bạn sau này).
Nên / Không nên & bẫy thường gặp
- Nên: Đặt tên frame và các layer quan trọng.
- Nên: Dùng component/variants cho phần lặp.
- Nên: Dùng Auto layout khi nội dung có thể tăng.
- Không nên: Đừng để tên mặc định khắp nơi.
- Không nên: Đừng detach instance trừ khi tách nhánh (fork).
- Không nên: Đừng trộn loạn nhiều hệ spacing.
Lỗi thường gặp
Lỗi: Group quá nhiều
Tránh: Ưu tiên frames/components thay vì group sâu.
Lỗi: Spacing không nhất quán
Tránh: Để Auto layout xử lý spacing/padding.
Lỗi: Không có chiến lược component
Tránh: Bắt đầu từ button/input/card.
Lỗi: Variants lộn xộn
Tránh: Dùng tên property/value nhất quán.
Lỗi: Khó handoff
Tránh: Giữ một page/section ‘Handoff’ cho màn hình cuối.
Thế nào là ổn
- Cây layer đọc như một dàn ý.
- Component bao phủ phần UI lặp lại.
- Đổi text không làm vỡ căn chỉnh.
Checklist: trước khi kiểm
- Frames đã đặt tên và sắp xếp.
- Auto layout dùng đúng chỗ.
- Có ít nhất 1 component chủ lực.
- Variants bao phủ các state.
- Canvas có điểm vào rõ ràng.
Checklist: sau khi kiểm
- Instance cập nhật đúng.
- Variants chuyển đúng.
- Export chạy được (PNG/SVG).
- Reviewer tìm đúng chỗ nhanh.
- Không vỡ alignment sau khi sửa.
Bài thực hành (5–15 phút)
- Tạo 1 screen frame.
- Dựng stack header/content với Auto layout.
- Tạo button component với 2 size + 2 state.
- Đặt 3 instance và đổi variants.
- Export 1 asset (SVG/PNG).
Kết quả mong đợi: Một màn hình UI nhỏ + một bộ button component tái sử dụng.
Xác minh bạn làm đúng
- Thuộc tính Auto layout hiển thị rõ.
- Variants có tên rõ ràng.
- Export đúng như kỳ vọng.
Liên kết tài liệu chính thức
- Figma Design (category) — kiến thức nền tảng và hướng dẫn.
- Auto layout (guide) — layout thích ứng.
- Create and use variants — states/options qua properties.
Nguồn tài liệu: Figma Learn Help Center → Figma Design (category), cùng các guide về Auto layout, frames và variants.
Dev Mode
Xem inspect, điều hướng và handoff thiết kế để triển khai.
Quét nhanh
- Tìm các mục Ready for dev, rồi Inspect đúng node.
- Dùng status + annotation để giảm mơ hồ.
- Ghi câu hỏi ngay trong file (comment).
1) Mục đích & kết quả
Dev Mode là chế độ “ưu tiên dev” để điều hướng và inspect thiết kế. Bạn sẽ có phạm vi ‘ready’ rõ ràng và có thể lấy spec đáng tin từ Inspect.
- Bật/tắt Dev Mode (
Shift+D) khi có. - Dùng view ready-for-dev để tìm đúng mục tiêu cần build.
- Inspect selection để xem thuộc tính, đo đạc, biến (variables) và snippet code (nếu có).
- Dùng status + annotation để giảm mơ hồ.
2) Ai • Khi nào • Ở đâu trong điều hướng
Dành cho engineer triển khai UI và designer chuẩn bị handoff. Dựa theo Help Center → Dev Mode.
- Ai: engineer, designer làm handoff.
- Khi nào: lúc build, review spec, theo dõi thay đổi.
- Ở đâu: Help Center → Dev Mode.
- Tab liên quan: Figma Design, Billing.
3) Mô hình tư duy / luồng
Dev Mode ưu tiên điều hướng + inspect. Vòng lặp: tìm thiết kế đã sẵn sàng → chọn đúng node → inspect → copy thông tin → hỏi ngay trong file.
- Sidebar giúp nhảy tới section/frame nhanh.
- Trạng thái Ready for dev làm rõ “ý định triển khai”.
- Inspect panel hiển thị spec và snippet.
- Annotation cung cấp ghi chú triển khai (lọc theo category).
4) Đối tượng, thuật ngữ & việc cốt lõi
Các thuật ngữ này dùng xuyên suốt docs Dev Mode; danh sách “việc” là thứ team lặp lại mỗi ngày.
- Ready for dev: status gán cho frame/section/component.
- Inspect: đo đạc/thuộc tính/variables; snippet code khi có.
- Annotations: ghi chú/đo đạc; có category để lọc.
- Statuses & notifications: giữ mọi người đồng bộ về mức sẵn sàng/cập nhật.
- Việc: triển khai từ đúng target hiện hành.
- Việc: giảm hỏi-đáp qua lại nhờ notes + status.
5) Luồng chuẩn (happy path) #1 — Designer chuẩn bị ‘ready for dev’
Làm cho dev nhìn phát biết ngay cái gì cần build.
- Dọn naming cho các frame/section mục tiêu.
- Gán status Ready for dev cho phạm vi cần triển khai.
- Thêm 2–3 annotation cho hành vi/spacing khó.
- Dùng category để dev lọc notes.
- Chia sẻ file và trỏ đúng khu vực ready-for-dev.
- Cập nhật status/notes khi thiết kế đổi.
Kết quả mong đợi: Dev mở Dev Mode là tìm được ngay thứ cần build kèm notes quan trọng.
6) Luồng chuẩn (happy path) #2 — Developer triển khai bằng Inspect
Dùng Dev Mode như nguồn spec “chuẩn nhất”.
- Mở file và bật Dev Mode.
- Dùng view ready-for-dev để tìm màn hình mục tiêu.
- Chọn đúng node cần triển khai.
- Xem size/spacing/typography và variables trong Inspect.
- Copy snippet nếu có; nếu không thì ghi lại thuộc tính chính.
- Để comment nếu có chỗ mơ hồ.
Kết quả mong đợi: Triển khai theo spec nhất quán từ đúng node, và câu hỏi được ghi lại trong file.
7) Điểm ra quyết định
Chọn hướng phù hợp với quyền truy cập và quy trình.
| Tình huống | Chọn A | Chọn B |
|---|---|---|
| Không có quyền Dev Mode | Inspect trong Design Mode. | Hỏi admin về seat/setting Dev Mode. |
| Thiết kế chưa đánh dấu ready | Yêu cầu Ready for dev + notes. | Tránh triển khai từ bản thử nghiệm. |
| Nhiều notes | Lọc theo annotation category. | Nhờ dọn bớt nếu nhiễu cản tiến độ. |
| Cần mapping sang code | Dùng snippet + cú pháp code của variables. | Dịch thủ công nếu không có snippet. |
8) Nguyên tắc an toàn, kiểm chứng & luyện tập
Dev Mode hiệu quả khi ‘ready’ rõ ràng và luôn được cập nhật.
Nên / Không nên & bẫy thường gặp
- Nên: Đánh dấu phạm vi ready thật rõ.
- Nên: Annotate hành vi/case biên.
- Nên: Chọn đúng node trước khi Inspect.
- Không nên: Đừng build từ màn hình thử nghiệm chưa đánh dấu.
- Không nên: Đừng tách spec ra nhiều ảnh chụp màn hình.
- Không nên: Đừng để status Ready for dev bị cũ.
Lỗi thường gặp
Lỗi: Ready quá rộng
Tránh: Chỉ đánh dấu phần sẽ ship ngay.
Lỗi: Inspect nhầm layer
Tránh: Chọn đúng phần tử thật, không phải wrapper/group.
Lỗi: Variables không rõ
Tránh: Đảm bảo nhìn được value/mode của variables.
Lỗi: Spec bị lệch theo thời gian
Tránh: Kiểm tra cập nhật/recency trước khi code.
Lỗi: Mất câu hỏi
Tránh: Hỏi ngay trong file qua comments/annotations.
Thế nào là ổn
- Target ready nhìn là thấy ngay.
- Notes bao phủ phần khó.
- Inspect cho spec nhất quán.
Checklist: trước khi kiểm
- Targets đặt tên rõ.
- Đã gán status Ready.
- Có notes cho case biên.
- Dev có quyền truy cập.
- Xác định một “điểm vào handoff”.
Checklist: sau khi kiểm
- Dev tìm target nhanh.
- Ít nhất 1 element được verify spec.
- Câu hỏi được ghi trong file.
- Status Ready được cập nhật nếu thay đổi.
- Triển khai khớp notes.
Bài thực hành (5–15 phút)
- Bật Dev Mode.
- Đánh dấu 1 frame Ready for dev.
- Thêm 2 annotation (spacing + hành vi).
- Inspect một layer button/text.
- Copy snippet hoặc ghi lại thuộc tính chính.
Kết quả mong đợi: Một handoff mini để dev có thể điều hướng và inspect tin cậy.
Xác minh bạn làm đúng
- Phạm vi ready hiển thị rõ.
- Notes có ý nghĩa.
- Inspect hiện đúng giá trị.
Liên kết tài liệu chính thức
- Guide to Dev Mode — kiến thức cơ bản + quyền truy cập.
- Use code snippets in Dev Mode — Inspect tạo code.
- Dev Mode statuses and notifications — đánh dấu ready + theo dõi cập nhật.
- Add measurements and annotate designs — notes + categories.
Nguồn tài liệu: Figma Learn Help Center → Dev Mode (hướng dẫn, điều hướng, inspect, code snippets, status/annotation).
FigJam
Bảng trắng cộng tác cho họp hành, workshop và lên ý tưởng.
Quét nhanh
- Chuẩn bị section trước; test quyền truy cập.
- Dùng spotlight + timer + voting để facilitation.
- Kết thúc bằng Actions + người phụ trách.
1) Mục đích & kết quả
FigJam dành cho board cộng tác (họp, workshop, brainstorm). Bạn sẽ có một board mọi người vào được, theo được, và rời đi với bước tiếp theo rõ ràng.
- Tạo board (trống hoặc dùng template).
- Tổ chức bằng các section có nhãn (agenda).
- Điều phối bằng spotlight, timer và voting.
- Chia sẻ đúng quyền (mở open session nếu cần).
2) Ai • Khi nào • Ở đâu trong điều hướng
Dành cho facilitator và team chạy các buổi làm việc cộng tác. Dựa theo Help Center → FigJam + các guide về meeting.
- Ai: team, facilitator, học sinh/sinh viên.
- Khi nào: sync, retro, brainstorm, planning.
- Ở đâu: Help Center → FigJam.
- Tab liên quan: Get started (chia sẻ), Files and projects.
3) Mô hình tư duy / luồng
Một board nên “chạy” tốt trước/trong/sau buổi họp: chuẩn bị → mời → điều phối → tổng kết. Quan trọng nhất là cấu trúc + quyền trước khi mọi người vào.
- Chuẩn bị section trước (đừng bắt đầu với board trống).
- Xác nhận quyền truy cập (mời theo email vs open session).
- Dùng spotlight để dẫn sự chú ý; dùng timer/voting để hội tụ quyết định.
- Chốt bằng một section Summary/Actions.
4) Đối tượng, thuật ngữ & việc cốt lõi
Các thuật ngữ này xuất hiện nhiều trong tài liệu meeting; danh sách “việc” là thói quen lặp lại được.
- Section: khu vực nhóm mà bạn có thể ẩn/hiện/di chuyển.
- Open session: link mời tạm thời (tối đa 24h trên gói trả phí).
- Spotlight: yêu cầu người khác “theo” góc nhìn của bạn.
- Timer & voting: giới hạn thời gian và ra quyết định.
- Việc: chạy một buổi làm việc có cấu trúc và có tham gia.
- Việc: chốt thành actions + người chịu trách nhiệm.
5) Luồng chuẩn (happy path) #1 — Chạy một buổi team sync
Một flow họp đơn giản dẫn dắt bằng board.
- Tạo file FigJam mới (file browser hoặc
figjam.new). - Thêm section: Updates, Blockers, Actions.
- Chia sẻ và xác nhận ai cũng vào được (
can editđể tham gia). - Mở open session nếu cần người tham gia bên ngoài.
- Dùng spotlight khi đi qua từng section.
- Dùng timer để timebox mỗi phần.
Kết quả mong đợi: Mọi người đi theo cùng một flow trên board và rời đi với action items.
6) Luồng chuẩn (happy path) #2 — Brainstorm → vote → actions
Thu ý tưởng và hội tụ minh bạch.
- Tạo section Ideas; yêu cầu mọi người dán sticky trong 3 phút.
- Gom các sticky giống nhau và gắn nhãn chủ đề.
- Bắt đầu voting và set số vote/người.
- Kết thúc voting và xem kết quả.
- Chuyển các chủ đề top vào Actions kèm người phụ trách (mentions).
- Thêm một đoạn tóm tắt ngắn ở đầu board.
Kết quả mong đợi: Ưu tiên được xếp hạng và bước tiếp theo rõ ràng được ghi ngay trên board.
7) Điểm ra quyết định
Chọn chế độ cộng tác phù hợp với đối tượng.
| Tình huống | Chọn A | Chọn B |
|---|---|---|
| Người tham gia bên ngoài | Open session (tạm thời). | Mời qua email để có quyền lâu dài. |
| Quyền | can edit cho workshop. | can view cho review chỉ xem. |
| Điểm bắt đầu | Dùng template để nhanh. | Board trống cho flow tùy biến. |
| Ra quyết định | Voting để hội tụ. | Chỉ thảo luận cho nhóm nhỏ. |
8) Nguyên tắc an toàn, kiểm chứng & luyện tập
FigJam “fail” khi cấu trúc hoặc quyền chưa sẵn sàng. Guardrails giúp buổi làm việc mượt và kết quả tái dùng được.
Nên / Không nên & bẫy thường gặp
- Nên: Chuẩn bị section trước buổi họp.
- Nên: Test quyền với 1 người tham gia.
- Nên: Dùng timer/voting để giữ nhịp.
- Không nên: Đừng bắt đầu trên board trống.
- Không nên: Đừng để quyết định chỉ nằm trong voice/chat.
- Không nên: Đừng mời quá rộng ở phạm vi lớn.
Lỗi thường gặp
Lỗi: Không có agenda
Tránh: Dùng 3–6 section khớp flow.
Lỗi: Vấn đề truy cập
Tránh: Set Share trước khi gửi link.
Lỗi: Cả nhóm bị lạc
Tránh: Dùng spotlight để dẫn.
Lỗi: Tranh luận quá lâu
Tránh: Timebox + vote.
Lỗi: Không chốt
Tránh: Tạo Actions kèm owner.
Thế nào là ổn
- Sections dẫn dắt cả buổi.
- Quyết định/actions nhìn thấy rõ.
- Board đủ gọn để mở lại sau này.
Checklist: trước khi chạy
- Đã tạo sections.
- Đã set Share settings.
- Đã quyết định có open session hay không.
- Có kế hoạch timer/voting.
- Chừa khu vực Summary.
Checklist: sau khi chạy
- Actions có owner.
- Tóm tắt outcome chính.
- Dọn bớt “noise”.
- Chia sẻ link kèm vị trí trỏ.
- Board tái dùng làm template (tùy chọn).
Bài thực hành (5–15 phút)
- Tạo một board mới.
- Thêm section Ideas/Cluster/Actions.
- Chạy timer 2 phút cho ý tưởng.
- Bắt đầu voting (3 vote/người).
- Chuyển “winner” vào Actions.
Kết quả mong đợi: Một board workshop nhỏ có timebox ý tưởng và voting.
Xác minh bạn làm đúng
- Người tham gia vào được.
- Timer/voting chạy được.
- Actions rõ ràng.
Liên kết tài liệu chính thức
- Run meetings in FigJam — Open sessions, spotlight, timer, voting.
- Create your first meeting board in FigJam — setup board + sections.
- FigJam (category) — thêm hướng dẫn FigJam.
Nguồn tài liệu: Figma Learn Help Center → FigJam và các guide meeting (open session, spotlight, timer, voting, sections).
Figma Slides
Tạo, trình chiếu và xuất slide deck ngay trong Figma.
Quét nhanh
- Chế độ presenter vs chế độ khán giả: chia sẻ đúng thứ.
- Muốn tương tác thì khán giả cần quyền; screen-share là đơn giản nhất.
- Có thể preload offline và xuất file.
1) Mục đích & kết quả
Làm slide deck và trình bày theo kiểu cộng tác. Bạn sẽ có một deck sẵn sàng để present (có/không notes) và có thể export khi cần.
- Tạo deck trong Drafts hoặc project của team.
- Dựng slide trong slide/grid view (có thể dùng template).
- Present bằng presenter view (có/không notes).
- Xuất PDF/PPTX hoặc lưu một bản .deck nếu cần.
2) Ai • Khi nào • Ở đâu trong điều hướng
Dành cho mọi người tạo và trình chiếu deck trong Figma Slides. Dựa theo Help Center → Figma Slides docs.
- Ai: người thuyết trình, đồng thuyết trình, team.
- Khi nào: làm deck, thêm notes, xuất deliverable.
- Ở đâu: Help Center → Figma Slides.
- Tab liên quan: Get started (chia sẻ), Files and projects.
3) Mô hình tư duy / luồng
Deck được chỉnh như một file, rồi trình chiếu ở chế độ presenter/audience. Screen-share là đơn giản nhất; muốn khán giả tương tác thì người xem phải có quyền truy cập.
- Tạo deck → thêm nội dung → thêm notes (tùy chọn).
- Present: Present hoặc Present + Notes (notes chỉ bạn thấy).
- Offline: preload presenter view để trình chiếu khi mất mạng.
- Export khi cần file ngoài Figma (PDF/PPTX).
4) Đối tượng, thuật ngữ & việc cốt lõi
Các thuật ngữ này dùng trong docs chính thức; danh sách “việc” là routine lặp lại được.
- Presenter view: full screen, spotlight cho co-presenters, có chế độ offline.
- Audience view: thứ khán giả thấy; dùng qua presentation link.
- Presenter notes: notes dạng markdown; cần quyền
can editđể thêm. - Xuất (Exports): PDF/PPTX (có giới hạn).
- Việc: trình chiếu mượt (đúng cửa sổ/link).
- Việc: export/chia sẻ deliverable an toàn.
5) Luồng chuẩn (happy path) #1 — Tạo deck + notes
Tạo một deck nhỏ, dễ review.
- File browser → Create new → Slide deck (Drafts hoặc project).
- Chọn template (hoặc bắt đầu trống).
- Thêm 5 slides (Title, Agenda, Key point, Visual, Next steps).
- Mở presenter notes và thêm 2 gạch đầu dòng cho 2 slide (markdown).
- Chia sẻ deck với co-presenters (ít nhất
can view). - Chạy thử nhanh trong Present mode.
Kết quả mong đợi: Một deck có cấu trúc và notes, sẵn sàng trình chiếu.
6) Luồng chuẩn (happy path) #2 — Present (notes + offline + link)
Tránh “sốc” vào ngày thuyết trình.
- Nhấn Present; chọn Present hoặc Present + Notes.
- Nếu screen-share, chia sẻ cửa sổ audience (không phải cửa sổ notes).
- Nếu sợ rủi ro mạng: menu options → Make available offline → đợi trạng thái sẵn sàng.
- Copy presentation link nếu khán giả cần mở audience view.
- Co-presenters mở presenter view nếu cần takeover spotlight.
- Xuất PDF/PPTX sau buổi nếu cần.
Kết quả mong đợi: Flow trình chiếu ổn định, chia sẻ đúng chế độ và có phương án dự phòng.
7) Điểm ra quyết định
Chọn theo nhu cầu của khán giả.
| Tình huống | Chọn A | Chọn B |
|---|---|---|
| Quyền truy cập của khán giả | Chỉ screen-share. | Chia sẻ presentation link cho audience view. |
| Yếu tố tương tác | Cấp người xem quyền can view. | Tránh tương tác nếu bị hạn chế chia sẻ. |
| Notes | Present + Notes. | Present (không notes). |
| Xuất file | PDF để chia sẻ/in ấn. | PPTX cho workflow PowerPoint (có giới hạn). |
8) Nguyên tắc an toàn, kiểm chứng & luyện tập
Lỗi Slides chủ yếu là chọn sai mode + sai quyền. Guardrails giúp notes luôn riêng tư và link hoạt động ổn.
Nên / Không nên & bẫy thường gặp
- Nên: Test các chế độ Present sớm.
- Nên: Chia sẻ cửa sổ audience khi dùng notes.
- Nên: Preload offline nếu cần.
- Không nên: Đừng nghĩ khán giả tương tác được nếu chưa có quyền.
- Không nên: Đừng test link sát giờ.
- Không nên: Đừng kỳ vọng PPTX giống y hệt 100%.
Lỗi thường gặp
Lỗi: Notes hiện cho khán giả
Tránh: Share cửa sổ audience view, không share cửa sổ notes.
Lỗi: Co-presenter không takeover được
Tránh: Họ phải mở presenter view.
Lỗi: Offline chưa sẵn sàng
Tránh: Đợi chỉ báo offline-ready.
Lỗi: Người xem bị chặn export
Tránh: Owner có thể hạn chế export/copy; chỉnh setting nếu cần.
Lỗi: PPTX lệch
Tránh: Xác định có giới hạn; ưu tiên PDF khi có thể.
Thế nào là ổn
- Presenter có quyền truy cập.
- Notes luôn riêng tư.
- Export đúng nhu cầu phân phối.
Checklist: trước khi chạy
- Đã chốt vị trí lưu deck.
- Đã thêm presenter.
- Đã thêm notes nếu cần.
- Đã test link (nếu dùng).
- Đã preload offline (nếu cần).
Checklist: sau khi chạy
- Buổi trình chiếu mượt.
- Audience view hoạt động đúng.
- Đã lưu export nếu cần.
- Deck nằm đúng project.
- Đã ghi nhận feedback.
Bài thực hành (5–15 phút)
- Tạo một deck mới.
- Thêm 5 slides.
- Thêm notes cho 2 slides.
- Mở Present + Notes và copy presentation link.
- Xuất PDF.
Kết quả mong đợi: Một deck nhỏ có thể present và export mà không “toang”.
Xác minh bạn làm đúng
- Các mode chuyển đúng.
- Link mở được audience view.
- Export PDF thành công.
Liên kết tài liệu chính thức
- Create a new slide deck — Tạo deck + chọn template.
- Present a slide deck — Presenter view, offline, links.
- Add and view presenter notes — Notes + Present + Notes.
- Export from Figma Slides — PDF/PPTX và giới hạn.
Nguồn tài liệu: Figma Learn Help Center → Figma Slides: tạo deck, present (kể cả offline và link), presenter notes và export.
Tệp và dự án
Cách Figma tổ chức công việc: team, project, file và các mô hình cộng tác với khách hàng.
Quét nhanh
- Vị trí = dễ tìm; quyền = hành động; seat = quyền truy cập sản phẩm.
- Dùng project cho công việc chung; tránh dùng Drafts làm “nguồn sự thật”.
- Chốt mô hình làm với khách hàng sớm (mời/tham gia/connected project).
1) Mục đích & kết quả
Giữ công việc dễ tìm và cộng tác “đúng kỳ vọng”. Bạn sẽ có cấu trúc team → project → file gọn gàng và một cách cộng tác với khách hàng rõ ràng.
- Dùng project để nhóm các file liên quan (Design/FigJam/Slides).
- Di chuyển/đổi tên file để cấu trúc luôn “đúng hiện tại”.
- Chia sẻ đúng phạm vi (file vs project).
- Chọn mô hình làm với khách hàng (mời, tham gia không gian khách, hoặc connected project).
2) Ai • Khi nào • Ở đâu trong điều hướng
Dành cho người tổ chức công việc hoặc cộng tác với khách hàng. Dựa theo Help Center → Administration → Files and projects.
- Ai: lead, admin, agency, bất kỳ ai cần tổ chức file.
- Khi nào: dự án mới, sắp xếp lại, onboarding khách, chốt dự án.
- Ở đâu: Help Center → Files and projects.
- Tab liên quan: Get started (file browser), Billing (seats).
3) Mô hình tư duy / luồng
3 “cần gạt”: vị trí (dễ tìm), quyền (được làm gì), seat (quyền dùng sản phẩm). Với khách hàng, hãy chốt vị trí + hệ quả về seat sớm để tránh phát sinh chi phí hoặc mất quyền truy cập.
- Drafts mặc định là riêng tư; project trong team dùng cho công việc chung.
- Chia sẻ file cho 1 deliverable; chia sẻ project cho nhiều deliverable.
- Khách hàng thường chỉ cần xem/bình luận—đừng “over-seat”.
- Connected projects có thể cho mỗi bên dùng seat từ gói của mình (cần admin setup; trả phí).
4) Đối tượng, thuật ngữ & việc cốt lõi
Các thuật ngữ này xuất hiện trong guide chính thức; danh sách “việc” là routine hằng tuần.
- Project: nơi chứa các file liên quan.
- Connected project: project chia sẻ giữa bên host và bên ngoài (trả phí + cần admin).
- Transfer/save a copy: các lựa chọn khi kết thúc engagement.
- Việc: không để công việc production chỉ nằm trong Drafts cá nhân.
- Việc: chia sẻ phạm vi nhỏ nhất đủ dùng.
- Việc: định nghĩa kế hoạch quyền truy cập/transfer khi kết thúc dự án.
5) Luồng chuẩn (happy path) #1 — Tạo không gian project gọn gàng
Tạo một project mà người mới vào team có thể nắm trong vài phút.
- Tạo project trong đúng team/org.
- Đặt tên rõ ràng (Client • Product • Quarter).
- Tạo/di chuyển các file chính vào project.
- Thêm page/section ‘Start here’ trong mỗi file.
- Chia sẻ project cho team; chia sẻ file cho stakeholder khi cần.
- Pin/star project và chia sẻ link “nguồn sự thật”.
Kết quả mong đợi: Một project dễ tìm, đúng quyền truy cập và file dễ điều hướng.
6) Luồng chuẩn (happy path) #2 — Thiết lập cộng tác với khách hàng
Chọn phương án ít ma sát và ít rủi ro nhất.
- Chốt: khách chỉ review hay cần edit trực tiếp?
- Option A: mời khách vào project/file của bạn (phổ biến khi bạn quản lý công việc).
- Gán loại seat tối thiểu cần thiết (View để review; seat trả phí nếu cần edit).
- Option B: tham gia không gian của khách nếu họ quản lý (xác nhận quyền/seat).
- Nếu cả hai bên dùng gói trả phí và cần không gian chung, cân nhắc connected projects (cần admin phê duyệt).
- Ghi lại kế hoạch transfer/backup khi kết thúc dự án.
Kết quả mong đợi: Quyền rõ ràng, chi phí dự đoán được và có kế hoạch khi kết thúc dự án.
7) Điểm ra quyết định
Chốt sớm để tránh làm lại.
| Tình huống | Chọn A | Chọn B |
|---|---|---|
| Vị trí làm việc | Team của bạn (bạn quản lý). | Team của khách (khách quản lý). |
| Mức tham gia của khách | Chỉ review → seat View + quyền truy cập. | Edit → đảm bảo có seat trả phí ở nơi file “sống”. |
| Cả hai bên đều dùng gói trả phí | Connected project. | Chỉ mời (invites). |
| Kết thúc dự án | Transfer ownership nếu cần. | Save/import bản copy nếu sẽ gỡ quyền truy cập. |
8) Nguyên tắc an toàn, kiểm chứng & luyện tập
Phần lớn vấn đề là chia sẻ quá rộng và nhầm lẫn seat. Guardrails giúp cấu trúc gọn và làm việc với khách “sạch”.
Nên / Không nên & bẫy thường gặp
- Nên: Dùng project cho công việc chung.
- Nên: Mời ở phạm vi nhỏ nhất.
- Nên: Thống nhất kế hoạch wrap-up sớm.
- Không nên: Đừng mời khách vào toàn bộ team của bạn.
- Không nên: Đừng mặc định quyền truy cập là “mãi mãi”.
- Không nên: Đừng để production chỉ nằm trong Drafts.
Lỗi thường gặp
Lỗi: Chia sẻ quá rộng
Tránh: Mời theo project/file thay vì mời cả team.
Lỗi: Nhầm seat và permission
Tránh: Seat = quyền dùng sản phẩm; permission = hành động trên file.
Lỗi: Không có quy ước
Tránh: Naming nhất quán + có Start here.
Lỗi: Tưởng connected project “tự động”
Tránh: Cần admin hai bên phê duyệt; xác nhận yêu cầu.
Lỗi: Không có kế hoạch backup
Tránh: Chốt transfer/copy/import trước khi đổi quyền.
Thế nào là ổn
- Projects khớp các workstream.
- Stakeholders chỉ có quyền xem.
- Quy trình làm với khách được ghi lại.
Checklist: trước khi kiểm
- Đã tạo project.
- File chính đã nằm trong project.
- Đã chọn phạm vi chia sẻ.
- Giả định về seat đã được xác nhận.
- Đã viết kế hoạch wrap-up.
Checklist: sau khi kiểm
- Người mới vào team tìm được file.
- Khách review được không lỗi quyền.
- Editor edit được; viewer vẫn là viewer.
- Backup/transfer đã xử lý.
- Project giữ được sự gọn gàng.
Bài thực hành (5–15 phút)
- Tạo một project.
- Di chuyển 2 file vào đó.
- Chia sẻ project cho 1 viewer và 1 editor.
- Thêm page Start here kèm hướng dẫn.
- Viết kế hoạch truy cập cho khách (3 gạch đầu dòng).
Kết quả mong đợi: Một không gian project dễ tìm, quyền rõ ràng và có kế hoạch làm việc với khách được ghi lại.
Xác minh bạn làm đúng
- Files hiển thị trong project.
- Quyền viewer vs editor hoạt động đúng.
- Start here giải thích điều hướng.
Liên kết tài liệu chính thức
- Files and projects (category) — kiến thức nền tảng về tổ chức.
- Guide to collaborating with clients in Figma — mời vs tham gia không gian khách; seats.
- Guide to connected projects — thiết lập host/external.
- Guide to the file browser — Drafts/Deleted files/điều hướng.
Nguồn tài liệu: Figma Learn Help Center → Administration → Files and projects, cùng các guide về cộng tác với khách và connected projects.
Thanh toán
Gói, seat, phê duyệt và hoá đơn (không nhầm “seat” với “permission”).
Quét nhanh
- Yếu tố tạo chi phí: gói + số seat trả phí (Full/Dev/Collab).
- Seat ≠ permission: đừng trộn hai khái niệm.
- Phê duyệt + hoá đơn là routine chính của admin.
1) Mục đích & kết quả
Billing chủ yếu là gói + seat. Bạn sẽ có thể giải thích các loại seat, yêu cầu/phê duyệt nâng cấp, và tìm hoá đơn mà không nhầm seat với quyền (permissions).
- Loại gói quyết định tính năng; loại seat quyết định chi phí.
- Loại seat ≠ permission (
can editkhông phải là seat). - Phê duyệt seat kiểm soát nâng cấp (thủ công vs tự động).
- Hoá đơn + thông tin thanh toán phục vụ quy trình tài chính.
2) Ai • Khi nào • Ở đâu trong điều hướng
Dành cho admin quản lý subscription và member yêu cầu seat. Dựa theo Help Center → Billing.
- Ai: admin org/team, billing admin, members.
- Khi nào: onboarding, đổi seat, review hoá đơn.
- Ở đâu: Help Center → Billing.
- Tab liên quan: Dev Mode (ảnh hưởng seat), Files and projects.
3) Mô hình tư duy / luồng
Tách bạch rõ: gói (tính năng), seat (quyền dùng sản phẩm), permission (hành động trên tài nguyên). Yêu cầu + phê duyệt seat là pipeline nâng cấp; hoá đơn là dấu vết kiểm toán.
- Starter/Professional/Organization/Enterprise khác nhau ở tính năng và chu kỳ tính phí.
- Loại seat gồm Full, Dev, Collab (trả phí) và View (miễn phí).
- Permission quyết định bạn làm được gì trong file/project cụ thể.
- Approval quyết định nâng cấp tự động hay phải admin duyệt.
4) Đối tượng, thuật ngữ & việc cốt lõi
Các thuật ngữ này dùng trong docs billing; danh sách “việc” là routine lặp lại.
- Loại seat: Full / Dev / Collab / View.
- Seat request: member yêu cầu nâng cấp.
- Approval settings: phê duyệt tự động vs thủ công.
- Billing groups: nhóm chi phí theo cost center (chỉ Enterprise, tuỳ chọn).
- Việc: cấp seat tối thiểu đúng nhu cầu.
- Việc: review hoá đơn và chi phí dự kiến.
5) Luồng chuẩn (happy path) #1 — Member yêu cầu đúng seat
Lấy đúng quyền bạn cần mà không phải “lách”.
- Xác định hành động bạn cần (edit design, dùng Dev Mode, v.v.).
- Thử thực hiện; nếu bị chặn, làm theo prompt seat request.
- Gửi request kèm bối cảnh project + timeline.
- Chờ duyệt (tránh duplicate file để lách quyền).
- Sau khi duyệt, xác nhận tính năng hoạt động.
- Nếu chỉ review, đề nghị giữ View seat nhưng xin permission phù hợp trên file.
Kết quả mong đợi: Bạn nhận đúng loại seat tối thiểu cần cho vai trò.
6) Luồng chuẩn (happy path) #2 — Admin quản lý seats + hoá đơn
Kiểm soát chi phí mà không chặn công việc.
- Mở quản lý seat và xem số lượng seat hiện tại.
- Kiểm tra chính sách duyệt (tự động vs thủ công).
- Xử lý các seat request đang chờ (duyệt/từ chối).
- Gán đúng loại seat (Full vs Dev vs Collab vs View).
- Mở hoá đơn để xem lịch sử và chi phí dự kiến.
- Cập nhật thông tin thanh toán/hoá đơn nếu cần.
Kết quả mong đợi: Cấp seat khớp nhu cầu thật, duyệt theo policy, hoá đơn truy vết được.
7) Điểm ra quyết định
Dùng các lựa chọn này để tránh “đốt tiền”.
| Tình huống | Chọn A | Chọn B |
|---|---|---|
| Nhu cầu người dùng | Chỉ review/comment → View seat + quyền truy cập. | Cần chỉnh sửa → seat trả phí. |
| Chính sách duyệt | Thủ công để kiểm soát. | Tự động để nhanh (theo dõi chi tiêu). |
| Kế toán Enterprise | Dùng billing groups. | Bỏ qua nếu không cần. |
| Quyền cho dev | Dev seat nếu cần Dev Mode. | View seat nếu chỉ review thiết kế. |
8) Nguyên tắc an toàn, kiểm chứng & luyện tập
Vấn đề billing thường là ‘sai seat cho công việc’ và ‘nhầm seat với permission’. Guardrails giúp việc nâng cấp có chủ đích.
Nên / Không nên & bẫy thường gặp
- Nên: Nội bộ hoá tiêu chí cấp seat.
- Nên: Review seats theo quý.
- Nên: Dạy rõ seat vs permission khi onboarding.
- Không nên: Đừng mặc định nâng mọi người lên Full.
- Không nên: Đừng bỏ qua seat requests (mọi người sẽ “lách”).
- Không nên: Đừng dùng workspaces như billing groups.
Lỗi thường gặp
Lỗi: Nhầm seat với permission
Tránh: Nhắc lại: seat = quyền dùng sản phẩm; permission = hành động trên file.
Lỗi: Cấp dư
Tránh: Dùng Dev/Collab/View đúng mục đích.
Lỗi: Không cấu hình approvals
Tránh: Thiết lập và truyền thông quy trình nâng cấp.
Lỗi: “Mù” hoá đơn
Tránh: Thường xuyên xem lịch sử hoá đơn và chi phí dự kiến.
Lỗi: Dùng sai billing groups
Tránh: Chỉ dùng cho cost center trên Enterprise.
Thế nào là ổn
- Seat khớp vai trò.
- Nâng cấp được duyệt kèm bối cảnh.
- Hoá đơn được đối soát.
Checklist: trước khi kiểm
- Đã xác nhận loại gói.
- Đã chia sẻ định nghĩa seat.
- Đã cấu hình approvals.
- Đã gán billing admins.
- Đã kiểm tra thông tin hoá đơn.
Checklist: sau khi kiểm
- Seat requests được xử lý nhanh.
- Số seat khớp ngân sách.
- Hoá đơn được lưu cho finance.
- Người dùng có đúng quyền cần.
- Cấu trúc org được dùng đúng.
Bài thực hành (5–15 phút)
- Tìm loại seat của bạn.
- Gửi hoặc review một seat request.
- Là admin: đổi một seat test (nếu được phép).
- Mở lịch sử hoá đơn và ghi chú chi phí dự kiến.
- Giải thích seat vs permission cho một teammate.
Kết quả mong đợi: Bạn vận hành được nền tảng: seats, approvals, hoá đơn.
Xác minh bạn làm đúng
- Bạn định nghĩa được seat vs permission.
- Bạn tìm được số lượng seat.
- Bạn tìm được hoá đơn.
Liên kết tài liệu chính thức
- Guide to billing at Figma — Gói, seats, hoá đơn.
- Manage seats in Figma — Loại seat + luồng admin.
- Make a seat request — Luồng member yêu cầu nâng cấp.
- Manage payment and invoice details — Hoá đơn và thông tin billing.
- Workspaces vs billing groups — Cộng tác vs kế toán.
Nguồn tài liệu: Figma Learn Help Center → Billing và các docs quản lý seat (loại seat, approvals, hoá đơn, billing groups/workspaces).
Figma Sites Beta
Tạo và xuất bản website từ Figma với preview, cài đặt và domain.
Quét nhanh
- Lưu ý beta: mọi thứ trên canvas đều sẽ được publish.
- Preview trước, rồi publish/update có chủ đích.
- Subdomain là cố định; hỗ trợ unpublish/republish.
1) Mục đích & kết quả
Xuất bản website responsive trực tiếp từ một Sites file. Bạn sẽ có 1 trang preview ổn trên nhiều breakpoint và một routine publish/update/unpublish có kiểm soát.
- Tạo Sites file (template/trống/từ Design).
- Preview và test trên nhiều breakpoint.
- Publish lên figma.site (tuỳ chọn domain riêng).
- Quản lý cài đặt (SEO/social/password/cookie consent) trước khi publish.
2) Ai • Khi nào • Ở đâu trong điều hướng
Dành cho team muốn ship site đơn giản nhanh với hosting tích hợp. Dựa theo Help Center → Figma Sites Beta.
- Ai: designer làm trang web.
- Khi nào: landing page, site marketing nhỏ, site nội bộ.
- Ở đâu: Help Center → Figma Sites Beta.
- Tab liên quan: Figma Design, Files and projects, Billing.
3) Mô hình tư duy / luồng
Sites file chứa các trang web trên canvas; preview mô phỏng hành vi người xem; publishing sẽ đưa lên live. Lưu ý beta: mọi trang web trên canvas đều được đưa vào khi publish—hãy để các trang chưa xong ở file khác.
- Dựng trang → preview → sửa lỗi → publish.
- Thay đổi chỉ lên live sau khi bạn publish một bản cập nhật.
- Unpublish sẽ gỡ site khỏi web (có thể republish lại sau).
- Subdomain figma.site được gán không thể đổi sau khi publish.
4) Đối tượng, thuật ngữ & việc cốt lõi
Các thuật ngữ này xuất hiện trong Sites docs; danh sách “việc” là routine release.
- Webpage: sẽ trở thành một phần của site đã publish.
- Preview: mở preview nội tuyến (ví dụ
Shift+Space). - Breakpoints: các kích thước responsive bạn chuyển trong preview.
- Publish modal: tiêu đề/URL, Issues, phạm vi truy cập.
- Việc: preview qua các breakpoint trước mỗi lần publish.
- Việc: giữ file publish không có trang chưa hoàn thiện.
5) Luồng chuẩn (happy path) #1 — Dựng + preview một trang responsive
Xác nhận hành vi trước khi đưa bất cứ thứ gì lên live.
- Tạo Sites file mới (
figma.com/site/newhoặc từ file browser). - Thêm/đổi tên 1 webpage và dựng nhanh header/hero/CTA.
- Preview (
Shift+Space) và chuyển các breakpoint. - Sửa các lỗi layout quan sát được ở từng breakpoint.
- Test link/interaction trong preview.
- Lặp lại đến khi trang hoạt động đúng.
Kết quả mong đợi: Một trang preview đúng trên nhiều breakpoint, link hoạt động ổn.
6) Luồng chuẩn (happy path) #2 — Publish + update (và unpublish khi cần)
Ship có chủ đích, rồi kiểm soát cập nhật.
- Rà soát site settings (SEO/social previews/password/cookie consent).
- Mở Publish modal (File icon → Publish).
- Xác nhận title/URL và phạm vi truy cập (public vs nội bộ trên Org/Enterprise).
- Xem mục Issues và sửa các lỗi quan trọng.
- Publish và chia sẻ URL live.
- Sau khi chỉnh sửa, publish một bản update để đẩy thay đổi lên live.
- Nếu cần, unpublish trong site settings; republish sau để dùng lại domain.
Kết quả mong đợi: Site live chỉ cập nhật khi bạn publish, và có cách unpublish rõ ràng.
7) Điểm ra quyết định
Các lựa chọn này giúp tránh publish nhầm và “sốc” về phạm vi truy cập.
| Tình huống | Chọn A | Chọn B |
|---|---|---|
| Có trang chưa hoàn thiện | Chuyển sang file khác trước khi publish. | Rủi ro: mọi webpage đều được publish. |
| Phạm vi người xem (Org/Enterprise) | Chỉ nội bộ cho nhân viên. | Public web cho khách bên ngoài. |
| Domain | Dùng figma.site để nhanh. | Domain riêng để đúng brand (cần setup thêm). |
| Kỷ luật release | Preview + sửa Issues trước khi publish. | Publish nhanh chỉ khi đúng là bản nháp. |
8) Nguyên tắc an toàn, kiểm chứng & luyện tập
Sites là xuất bản thật. Guardrails tập trung vào trang publish nhầm, cập nhật bị “cũ”, và các giới hạn của beta.
Nên / Không nên & bẫy thường gặp
- Nên: Preview qua các breakpoint trước mỗi lần publish.
- Nên: Hoàn tất settings trước khi publish.
- Nên: Tách các trang chưa xong sang file khác.
- Không nên: Đừng kỳ vọng export code để host bên ngoài.
- Không nên: Đừng kỳ vọng đổi được subdomain figma.site.
- Không nên: Đừng nghĩ sửa xong là lên live nếu chưa publish update.
Lỗi thường gặp
Lỗi: Ship nhầm trang
Tránh: Mọi thứ trên canvas đều publish—tách file.
Lỗi: Site live bị cũ
Tránh: Publish update sau khi chỉnh sửa.
Lỗi: Bỏ qua Issues
Tránh: Sửa lỗi quan trọng và test lại preview.
Lỗi: Chọn sai phạm vi truy cập
Tránh: Chọn public vs internal có chủ đích.
Lỗi: Nhầm về domain
Tránh: Domain riêng là tuỳ chọn; subdomain cố định sau khi được gán.
Thế nào là ổn
- Chỉ những trang dự định mới được publish.
- Preview khớp hành vi live.
- Cập nhật theo routine release.
Checklist: trước khi kiểm
- Tất cả trang đã sẵn sàng (hoặc đã chuyển đi).
- Đã chốt Title/URL.
- Đã rà soát settings.
- Đã test preview ở các breakpoint.
- Đã kiểm tra Issues.
Checklist: sau khi kiểm
- URL live tải đúng.
- Thay đổi chỉ xuất hiện sau khi publish/update.
- Phạm vi truy cập đúng.
- Không có trang chưa hoàn thiện bị lên live.
- Đã ghi chú kế hoạch rollback (republish phiên bản trước nếu cần).
Bài thực hành (5–15 phút)
- Tạo Sites file từ template.
- Thêm/đổi tên 1 webpage.
- Preview và chuyển 3 breakpoint.
- Mở Publish modal và xem mục Issues.
- Publish 1 lần, rồi sửa nhỏ và publish update.
Kết quả mong đợi: Một site nhỏ bạn có thể preview và publish/update có chủ đích.
Xác minh bạn làm đúng
- Preview chạy ổn ở các breakpoint.
- Publish modal hiển thị trạng thái đúng.
- URL live chỉ cập nhật sau publish/update.
Liên kết tài liệu chính thức
- Publish, update, or unpublish a site — Publish modal, issues, access, unpublish, republish phiên bản trước.
- Explore Figma Sites — Phím tắt preview và kiến thức cơ bản.
- Review and update your site settings — SEO, password, cookie consent, previews.
- Manage a custom domain for your site — Thiết lập domain.
Nguồn tài liệu: Figma Learn Help Center → Figma Sites Beta và các bài về publish/preview (ghi chú beta, trạng thái publish, breakpoints, settings, domains).
