Bàn Giao Thiết Kế–Kỹ Thuật Vượt Ra Ngoài Figma Comments
Tại sao chỉ dùng Figma comments không thể lấp đầy khoảng cách bàn giao thiết kế–kỹ thuật, và điều gì thực sự hiệu quả cho các nhóm nhỏ.
By Ellis Keane · 2026-04-06
Công cụ bàn giao thiết kế–kỹ thuật tốt nhất là công cụ kỹ sư không bao giờ mở
Các nhà thiết kế đầu tư càng nhiều vào việc hoàn thiện Figma handoff – auto-layout, design tokens, chú thích dev mode, tài liệu component – thì việc bàn giao thiết kế–kỹ thuật thực tế thường càng tệ hơn. Không phải vì công việc thiết kế kém – thường rất xuất sắc – mà vì tất cả nỗ lực đó tồn tại trong một công cụ mà kỹ sư miễn cưỡng mở, lướt nhanh rồi đóng lại để đi xây dựng những gì họ nghĩ họ đã thấy.
Tôi đã ở cả hai phía. Tôi bắt đầu với tư cách là nhà thiết kế (hay "nhà thiết kế" – tôi đang xây dựng các trang web tiệm cầm đồ ở New Hampshire, vậy nên hãy hào phóng với danh hiệu đó), và bây giờ tôi viết phần lớn mã kỹ thuật cho Sugarbug. Vấn đề bàn giao thiết kế–kỹ thuật không phải là vấn đề về công cụ, mà là vấn đề về quy trình. Thông tin tồn tại, chỉ là ở sai chỗ vào sai thời điểm.
Một lần bàn giao thiết kế–kỹ thuật điển hình trông như thế này: một nhà thiết kế dành ba ngày đánh bóng frame Figma, thêm mười hai comment giải thích các quyết định về khoảng cách và các trường hợp biên, gắn thẻ kỹ sư và chờ đợi. Kỹ sư mở Figma, nhìn vào frame khoảng chín mươi giây, nghĩ "được rồi, hiểu rồi", đóng tab và xây dựng thứ gì đó đúng 80% và sai 20% theo những cách sẽ mất thêm một tuần trao đổi qua lại để giải quyết. Mười hai comment đó? Có thể đọc được bốn cái.
Bàn giao thiết kế–kỹ thuật không phải là file bạn ném qua tường. Đó là ngữ cảnh cần tồn tại ở nơi kỹ sư làm việc – trong issue, trong PR, trong code – không phải trong công cụ thiết kế mà họ chỉ ghé thăm một lần.
Tại sao Figma comments có dạng sai cho việc bàn giao
Tôi dùng Figma hàng ngày và thực sự thích nó (có lẽ đây là khiếm khuyết tính cách tại thời điểm này). Nhưng Figma comments được tối ưu hóa cho sự hợp tác giữa nhà thiết kế với nhà thiết kế, không phải cho việc bàn giao thiết kế–kỹ thuật, và sự khác biệt đó quan trọng hơn hầu hết các nhóm nhận ra.
Sự không khớp cơ bản là: Figma comments được neo theo không gian vào các frame và component. Chúng tồn tại bên trong file thiết kế. Nhưng kỹ sư không làm việc bên trong file thiết kế – họ làm việc trong các issue Linear, PR GitHub và IDE của họ. Khi nhà thiết kế để lại comment trên frame nói "dropdown này nên thu gọn trên các viewport di động dưới 640px", thông tin đó bị mắc kẹt trong Figma. Nó không trở thành nhiệm vụ. Nó không xuất hiện trong quy trình của kỹ sư. Nó tồn tại trong một vũ trụ song song mà kỹ sư phải nhớ ghé thăm, và (đây là phần thực sự quan trọng) việc ghé thăm Figma không phải là một phần trong vòng làm việc tự nhiên của kỹ sư như việc kiểm tra Linear hoặc xem xét PR.
Kết quả là có thể đoán trước: các quyết định thiết kế quan trọng bị mất, không phải vì ai đó bất cẩn, mà vì thông tin ở sai công cụ. Giống như để lại ghi chú dán trên bàn của ai đó khi họ làm việc từ xa.
Nơi nhà thiết kế để lại ngữ cảnh
- Figma comments – Theo không gian, neo vào frame
- Figma dev mode annotations – Chi tiết nhưng yêu cầu mở Figma
- Slack threads – Dạng trò chuyện, không thể tìm kiếm sau một tuần
- Design system docs – Toàn diện nhưng hiếm khi được tham khảo giữa sprint
Nơi kỹ sư thực sự nhìn vào
- Mô tả issue Linear – Thứ đầu tiên họ đọc trước khi bắt đầu
- Mô tả PR GitHub – Tài liệu tham khảo trong quá trình triển khai
- Code comments – Được phát hiện trong quá trình review
- IDE – Nơi họ dành 90% thời gian
Điều gì thực sự hiệu quả (từ người làm cả hai)
Trong năm qua xây dựng Sugarbug, tôi vừa là nhà thiết kế vừa là (chủ yếu) kỹ sư, có nghĩa là tôi có trải nghiệm bất thường là bàn giao cho chính mình và vẫn mất ngữ cảnh. Nếu tôi không thể nhớ các quyết định thiết kế của chính mình từ thứ Ba tuần trước, thì một kỹ sư riêng biệt sẽ không thể nắm bắt mọi thứ từ một chuỗi Figma comment.
Đây là những gì thực sự hiệu quả trong quy trình bàn giao thiết kế–kỹ thuật của nhóm chúng tôi, và không điều nào trong số đó liên quan đến việc viết Figma comments tốt hơn.
1. Ghi quyết định thiết kế vào issue, không phải file thiết kế
Trước khi kỹ sư bắt đầu xây dựng, ngữ cảnh thiết kế cần tồn tại trong issue Linear (hoặc bất cứ thứ gì nhóm của bạn sử dụng). Không phải là một liên kết đến file Figma kèm theo "xem thiết kế" – đó là cách trốn tránh và mọi người đều biết điều đó. Issue nên bao gồm:
- Cái gì: Ảnh chụp màn hình hoặc frame đã xuất (không phải liên kết Figma – một PNG mà kỹ sư có thể xem mà không cần mở công cụ khác)
- Tại sao: Lý do đằng sau các quyết định chính. "Chúng tôi chọn slide-over panel thay vì modal vì người dùng cần tham khảo danh sách trong khi chỉnh sửa" – một câu giúp tiết kiệm ba vòng "tại sao không phải modal?"
- Các trường hợp biên: Điều gì xảy ra trên di động? Điều gì xảy ra với văn bản dài? Điều gì xảy ra khi không có dữ liệu? Nếu bạn đã nghĩ đến nó, hãy ghi lại. Nếu bạn chưa nghĩ đến, hãy nói ra (thành thật mà nói, "tôi chưa tìm ra trạng thái trống" hữu ích hơn là im lặng)
2. Ревью thiết kế diễn ra trong issue, không phải trong Figma
Khi tôi nhận được phản hồi thiết kế trong quá trình triển khai, tôi muốn nó trong chuỗi issue Linear, không phải là Figma comment mà tôi có thể không thấy trong hai ngày. Issue là nguồn sự thật duy nhất của tôi cho công việc – nếu phản hồi ở đó, tôi sẽ thấy nó lần tiếp theo tôi kiểm tra issue, điều này xảy ra nhiều lần mỗi ngày. Nếu nó ở trong Figma, tôi sẽ thấy nó khi tôi tình cờ mở file đó, điều này có thể không bao giờ xảy ra.
Điều này không có nghĩa là không bao giờ dùng Figma comments. Chúng rất tốt cho sự hợp tác giữa nhà thiết kế với nhà thiết kế, để chú thích các chi tiết hình ảnh cụ thể, và cho các cuộc trò chuyện về chính bản thân thiết kế. Nhưng khi phản hồi trở thành "kỹ sư cần thay đổi thứ gì đó", nó cần chuyển sang quy trình kỹ thuật.
stat: "Hầu hết" headline: "Figma comments không được nhìn thấy trong 48+ giờ khi chúng tôi dựa vào chúng để bàn giao" source: "Kinh nghiệm của nhóm chúng tôi qua 3 tháng theo dõi không chính thức"
3. Đóng vòng bằng ảnh chụp màn hình, không phải giả định
Hình thức xác nhận bàn giao thiết kế–kỹ thuật rẻ nhất là ảnh chụp màn hình. Khi kỹ sư hoàn thành việc triển khai một component, họ dán ảnh chụp màn hình vào PR hoặc issue và gắn thẻ nhà thiết kế. "Cái này có khớp không?" mất mười giây và phát hiện 20% sự khác biệt trước khi được xuất bản. Không có cuộc họp, không có nghi lễ so sánh Figma – chỉ là PNG và một câu hỏi.
Chúng tôi bắt đầu làm điều này cho mỗi UI PR, và số lượng cuộc trò chuyện "cái này không khớp với thiết kế" giảm xuống gần bằng không. Các cuộc trò chuyện còn lại là các trường hợp biên thực sự mà thiết kế không đề cập đến, điều đó tốt – đó là loại điều nên được thảo luận, không phải những thứ cơ bản như "bạn dùng 16px padding thay vì 12px".
4. Để ngữ cảnh tự động chảy giữa các công cụ
Đây là nơi tôi sẽ đề cập đến Sugarbug, vì chúng tôi đã xây dựng nó để giải quyết vấn đề cụ thể này. Nhà thiết kế của chúng tôi để lại comment trong Figma về thay đổi khoảng cách. Sugarbug nhận comment đó, kết nối nó với issue Linear và PR GitHub có liên quan, và kỹ sư thấy nó trong quy trình của họ mà không cần mở Figma. Việc bàn giao thiết kế–kỹ thuật không còn là nghi lễ sao chép-dán thủ công và bắt đầu là thứ gì đó chỉ đơn giản xảy ra.
Nhưng nếu bạn không dùng Sugarbug (và hầu hết các bạn không dùng, chúng tôi vẫn còn trước khi ra mắt), phiên bản thủ công là: chỉ định ai đó làm "cầu nối bàn giao" kiểm tra Figma comments hàng ngày và sao chép phản hồi có liên quan vào các issue Linear. Nó tẻ nhạt, nhưng hiệu quả, và tốt hơn vô cùng so với việc hy vọng kỹ sư sẽ nhớ kiểm tra Figma.
Nếu tôi không thể nhớ các quyết định thiết kế của chính mình từ thứ Ba tuần trước, thì một kỹ sư riêng biệt sẽ không thể nắm bắt mọi thứ từ một chuỗi Figma comment. attribution: Chris Calo
Danh sách kiểm tra bàn giao thiết kế–kỹ thuật của bạn
Nếu bạn chỉ lấy một điều từ bài viết này, hãy để nó là: giải pháp không phải là các công cụ tốt hơn (không phải chủ yếu – mặc dù tôi đang xây dựng một cái, vì vậy hãy coi điều đó với sự nghi ngờ thích hợp). Giải pháp là thiết lập các chuẩn mực về nơi các quyết định thiết kế tồn tại, và đảm bảo rằng "nơi" đó nằm trong quy trình tự nhiên của kỹ sư.
- [ ] Xuất các frame chính dưới dạng PNG vào issue Linear (không chỉ là liên kết Figma)
- [ ] Ghi "tại sao" cho mỗi quyết định thiết kế lớn trong mô tả issue
- [ ] Liệt kê các trường hợp biên đã biết (di động, trạng thái trống, văn bản dài) – hoặc ghi rõ những gì bạn chưa giải quyết
- [ ] Chuyển phản hồi triển khai từ Figma comments sang chuỗi issue
- [ ] Yêu cầu ảnh chụp màn hình trong mỗi UI PR trước khi thiết kế ký duyệt
- [ ] Chỉ định "cầu nối bàn giao" nếu bạn không có công cụ tự động kết nối Figma và Linear
Câu Hỏi Thường Gặp
Q: Tại sao Figma comments thất bại với tư cách là công cụ bàn giao thiết kế–kỹ thuật? A: Figma comments tồn tại bên trong file thiết kế, tách biệt khỏi quy trình kỹ thuật. Kỹ sư làm việc trong Linear, GitHub và IDE – không phải trong Figma. Một comment trên frame không trở thành nhiệm vụ bị bỏ sót trừ khi ai đó sao chép thủ công, và bước đó là nơi việc bàn giao thiết kế–kỹ thuật sụp đổ. Đây không phải là vấn đề về con người – đây là vấn đề ranh giới công cụ.
Q: Sugarbug có kết nối Figma comments với các issue Linear tự động không? A: Có – đó là một trong những vấn đề cụ thể chúng tôi xây dựng nó để giải quyết. Sugarbug thu thập Figma comments và kết nối chúng với các issue Linear và PR GitHub có liên quan, để phản hồi thiết kế xuất hiện trong quy trình của kỹ sư mà không cần ai sao chép-dán giữa các công cụ. Chúng tôi tự mình dùng nó hàng ngày, và sự khác biệt (thành thật mà nói) hơi đáng xấu hổ khi biết ý tưởng đơn giản như thế nào.
Q: Quy trình bàn giao thiết kế–kỹ thuật tốt nhất cho các nhóm nhỏ là gì? A: Ghi quyết định thiết kế vào issue Linear trước khi kỹ sư bắt đầu xây dựng. Bao gồm lý do, không chỉ hình ảnh. Nếu các trường hợp biên xuất hiện trong quá trình triển khai, hãy thảo luận trong chuỗi issue – không phải trong Figma comment mà kỹ sư phải tìm kiếm. Quy trình đơn giản nhất thường là bền vững nhất.
Q: Làm thế nào để xử lý các thay đổi thiết kế sau khi kỹ thuật đã bắt đầu? A: Hãy xử lý chúng như thay đổi phạm vi: ghi lại thay đổi trong issue với trước-và-sau rõ ràng, giải thích lý do và để kỹ sư đánh giá chi phí triển khai trước khi cam kết. Các thất bại bàn giao tồi tệ nhất xảy ra khi thay đổi thiết kế đến dưới dạng Figma comments thông thường trên công việc đã được xây dựng – đó là cách bạn có được các kỹ sư bực bội và các nhà thiết kế thất vọng.
Nhận trí tuệ tín hiệu được gửi thẳng vào hộp thư của bạn.