Hành trình hàn gắn “rạn nứt” giữa Product designer & Dev team
Bài viết dành cho PD, DEV, PO, QC… và các bạn đang gặp khó khăn trong việc bàn giao thiết kế một cách tối ưu.
Khi được hỏi, bạn sợ nhất điều gì khi bàn giao thiết kế?
Phần đông Product Designer (PD) đều trả lời xoay quanh việc sản phẩm cuối cùng không giống thiết kế hay thiết kế phải sửa đi sửa lại nhiều lần. Không ngạc nhiên vì đó chính là kiếp nạn mà bất kỳ newbie nào cũng cần chuẩn bị tinh thần trước khi bước 1 chân vào ngành design (dù bước chân trái hay chân phải).
Nhưng có khi nào bạn tự hỏi, DEV/PO/QC sợ nhất điều gì khi nhận file thiết kế từ PD chưa? Hãy ngồi xuống, lắng nghe câu chuyện của tôi. Tôi sẽ giải thích lý do tại sao PD và DEV luôn làm nhau “đau” và cách chúng tôi xoa dịu những nỗi đau đó.
Đã có một khoảng thời gian, tin nhắn đầu tiên tôi nhận từ đồng nghiệp mỗi buổi sáng luôn là: “Màn hình này ở đâu vậy Việt Anh?”. Còn với leader, tôi cảm nhận được sự chán nản ẩn sâu trong đôi mắt của chị mỗi lần tôi gửi link Figma review thiết kế.
Còn người khác, họ luôn sẵn sàng clear hết RAM (cả trong máy lẫn trong não) trước khi mở file thiết kế của tôi. Lâu dần thành tiền lệ xấu, bất kỳ ai cũng sợ hãi ra mặt mỗi khi tôi gửi link thiết kế (sợ hơn cả virus).
Tại sao lại thế? Các bạn hãy xem chiếc design board tôi làm để guideline cho luồng mua vé trên VinID. Mọi thứ không tệ đến thế cho đến khi scope công việc nở liên tục, file thiết kế ngày đang đồ sộ và hổ lốn.
Dạo quanh phố phường, dạo qua thị trường xem các bạn đồng môn thế nào. Ồh, thì ra tôi không cô đơn, ít nhiều họ cũng gặp vấn đề với file design board. Ngay lập tức vấn đề này được đặt lên “bàn cầu siêu” tại buổi retro, với hy vọng đem hết các problems đi “siêu thoát”.
Dấu hiệu đã quá rõ ràng, chúng tôi đã sẵn sàng vào việc. Cùng bắt đầu từ bước “Verify” vấn đề.
Verify — Tìm nguồn cơn vấn đề
Để tìm kiếm nguồn cơn vấn đề (root cause), chúng ta hãy đi từ những điểm chạm gần nhất với chiếc design board. Tôi khoanh vùng các “nghi phạm” và “nạn nhân” trực tiếp gây ra vấn đề hoặc bị ảnh hưởng bởi design board. Chung quy lại, ta có:
- Product Designer (PD) PIC: Bạn thiết kế chính
- PD Maintainer: Bạn PD mới nhận bàn giao lại dự án
- Reviewer: Chị leader review thiết kế
- Product Owner (PO): Chị quản lý sản phẩm
- Developer (DEV): Anh lập trình viên
- Quality Control (QC): Chị kiểm thử
Sau đó, tôi cùng team PD, chia nhau đi lấy “lời khai” của các bên, nhằm hiểu rõ các painpoints thực sự khi họ sử dụng design board là gì. Cô đọng lại tôi có bảng dưới đây:
🔑 Key Finding:
DEV: Luôn bắt đầu từ flow tổng quan, ngại đọc note, ngại tìm design spec của từng màn hình, muốn những thứ liên quan đến nhau ở gần nhau.
PO: Cần flow tổng quan để present trong các buổi grooming/planning. Không quan tâm đến design spec. Cần tìm nhanh các luồng, corner case để rà soát, review với document.
QC: Cần tìm nhanh các luồng, corner case để làm test case.
Kết nối các mảnh ghép với nhau, cuối cùng tôi cũng tổng hợp được nguồn cơn sự việc:
Solution: Giải pháp từ những thứ đã có
Sau 7 7 49 cuộc thảo luận cam go, 1 ngàn lẻ 1 file thiết kế được rà soát, chúng tôi cũng forming được những đầu việc cần xử lý:
Bước 1 — Find PD’s daily “jobs”
Tôi tổng hợp được các loại “jobs” mà PD tại One Mount thường xuyên phải đối mặt và chia chúng thành 3 nhóm:
Bước 2 — Define PD’s “weapons”
Rà soát lại “súng ống” PD có trong tay, tôi nhận ra có 2 trường phái trình bày file thiết kế:
Section lover:
- Chia một màn hình phức tạp ra nhiều section, sau đó trình bày guideline spec, corner case, flow… cho từng section.
- Phù hợp với các màn hình phức tạp, nhiều state… như trang home, landing page, listing…
- *Điểm yếu: Thiếu flow tổng quan gây khó khăn cho PO, DEV, QC khi muốn trình bày cho DEV mới.
Flow da best:
- Tập trung mô tả các luồng xử lý, sắp xếp riêng guideline spec của từng màn hình lên 1 board.
- Phù hợp với các luồng xử lý phức tạp như luồng authentication, luồng thanh toán…
- *Điểm yếu: DEV dễ bị miss guideline spec dẫn đến những sai khác trên sản phẩm thực tế.
Bước 3 — What’s the best practice?
Hãy quay lại với design board luồng bán vé trên VinID mà tôi đã nhắc ở đầu bài viết nào. Nhiệm vụ của tôi là thiết kế trang chi tiết sự kiện và luồng mua vé hoàn chỉnh từ xem chi tiết sự kiện, chọn hạng vé đến thanh toán và nhận vé. Đây là một trang có cấu trúc thông tin phức tạp, mỗi section đều có rất nhiều corner cases, states và kịch bản khác nhau. Mọi chuyện còn phức tạp hơn khi ứng với mỗi kịch bản cần điều chỉnh theo 3 loại sự kiện mà chúng tôi cung cấp, nghĩa là khối lượng công việc sẽ phải nhân lên gấp 3.
Tôi chọn cách trình bày “Section Lover” cho luồng mua vé này. Ở giai đoạn đầu tôi tập trung guideline từng section, tuy nhiên scope liên tục mở rộng, sau 7 7 49 lần thêm bớt và sắp xếp, design board đã trông như này:
Nhờ bước “Verify problem”, giờ tôi đã biết rõ 3 vấn đề lớn khi nhận bàn giao thiết kế: Không có flow tổng, không thống nhất quy chuẩn trình bày, khó phân biệt các phần được cập nhật, thay đổi.
Không chịu khuất phục trước những nghiệt ngã, tôi và team PD đã cải tiến lên phiên bản “Section lover but better” với cấu trúc như sau:
🧠 Luôn nhớ:
- Có full flow: Luồng thẳng từ entry point đến end screen.
- Với những lưu ý ngắn gọn (spec inside) hãy thêm guideline vào màn hình trong flow, giúp dev không bị miss.
- Dẫn link từ màn hình trong flow đến guideline/spec outside.
- Tạo riêng 1 board change log, để ghi lại những thay đổi trong quá trình thiết kế.
Sau khi áp dụng cấu trúc mới vào design board luồng mua vé, tuy số lượng màn hình vẫn rất lớn tuy nhiên chúng đã có hệ thống hơn rất nhiều:
Sau khi onboard các bên về cấu trúc mới, ở vai trò nào, chúng tôi cũng thấy dễ dàng (hơn) trong việc tìm được thứ mình muốn.
Chẳng hạn như:
- Là một PO tôi muốn xem flow tổng quan: Xem 🥎 Full Flow.
- Là một QC tôi muốn tìm các tình huống hiển thị của section ngày sự kiện: Xem ⚽ Guideline > Section A.
- Là một DEV tôi muốn tìm spec của section loại vé: Xem ⚽ Guideline > Section B.
- Là một DEV tôi muốn update các thay đổi của thiết kế: Xem ⚾ Change log.
- Là một PD tôi muốn cập nhật thêm một số luồng tại section giá vé: Thêm tại ⚽ Guideline > Section A.
Kết quả là mọi người đều biết vào đâu để tìm thứ mình muốn, DEV đã giảm thiểu số lần bị miss case, miss spec, PD đã không còn gặp khó khăn vì không biết thêm luồng ở đâu khi scope nở to.
Vậy khi áp dụng với các màn hình đơn giản nhưng có luồng xử lý phức tạp thì sao? Tương tự Section lover, chúng tôi cũng xây dựng được cấu trúc mới cho Flow da best như sau:
Áp dụng với một case study khác, ở đây tôi cần thiết kế 1 bộ các câu hỏi tương tác (One Housing Quiz), đặt rải rác trên website One Housing. Các câu hỏi này tuy thiết kế khá đơn giản nhưng kịch bản rất phức tạp, có nhiều trường hợp cần guideline kỹ. Do đó tôi đã áp dụng cách trình bày Flow da best: tách các flow, nhóm lại theo kịch bản, riêng guideline spec sẽ được đặt riêng 1 section. Ngoài ra tôi còn nhóm tất cả các component có trong luồng, sắp xếp lại theo hệ thống nhằm giúp dev nắm được cấu trúc của từng components khi code.
🧠 Luôn nhớ:
Trong một số tình huống, khi design board quá lớn, tôi có 3 lưu ý giúp DEV tránh được việc bỏ xót các design spec quan trọng:
- Dẫn link từ màn hình trong flow đến section guideline spec của màn hình đó.
- Sắp xếp design spec, section state ngay trong flow.
- Sắp xếp các board theo F-layout: Từ trái sang phải, từ trên xuống dưới.
Kết luận
Tại thời điểm hiện tại, quy trình bàn giao thiết kế đang ở trong giai đoạn “Implement” và đợi “Feedback” từ các team nhằm tối ưu hơn nữa. Về cá nhân tôi, sau khi áp dụng quy trình, các thiết kế đã trở nên logic, liền mạch và có hệ thống hơn rất nhiều, từ đó giảm thời gian làm guideline đáng kể.
Khi hỏi một số bạn DEV mới trong team, về cách họ sử dụng design board, quy trình mới đã cải thiện khoảng 70% vấn đề họ gặp phải. Khi nắm được cấu trúc file, họ không mất nhiều công sức để tìm kiếm như xưa, nhờ đó tình trạng bỏ qua spec, miss case cũng được giảm thiểu.
Quy trình bàn giao thiết kế tuy mỗi công ty đều có tính chất và đặc thù sản phẩm riêng, tuy nhiên cách tôi cùng team PD tại One Mount tìm kiếm và giải quyết vấn đề có thể được áp dụng chung với nhiều tình huống và vấn đề khác nhau. Hy vọng câu chuyện của tôi đã mang lại thông tin hữu ích, cũng như một góc nhìn mới, ít nhiều giúp các bạn trong quá trình thiết kế sản phẩm.
Hẹn các bạn tại các bài chia sẻ khác của One Mount PD Team. Love ❤!
