Doanh nghiệp đang âm thầm mất tiền vì thiếu hệ thống thiết kế

Chi phí thiếu design system (hệ thống thiết kế) là chi phí ẩn: không có dòng nào trong báo cáo tài chính, không có cảnh báo nào trong dashboard, nhưng nó nằm ở mọi chỗ trong vòng lặp làm việc hàng ngày. Vì không nhìn thấy được, nó thường bị bỏ qua hoặc bị quy cho nguyên nhân sai. Bài này giúp Anh Chị nhận diện các dấu hiệu cụ thể, và hiểu tại sao chúng liên quan trực tiếp đến tiền.

Chi phí ẩn hoạt động như nợ tích lũy

Nielsen Norman Group ghi nhận rằng UX debt (nợ trải nghiệm người dùng) làm tăng chi phí sửa lỗi theo thời gian, vì các vấn đề thiết kế bị chôn vùi dưới nhiều lớp tính năng mới, khiến việc sửa sau này tốn kém hơn làm đúng ngay từ đầu. Nguyên tắc này áp dụng hoàn toàn cho design debt (nợ thiết kế), khái niệm được phát triển song song với Technical Debt của Ward Cunningham: nợ tích lũy theo thời gian, mỗi biểu hiện riêng lẻ trông nhỏ, nhưng tổng cộng gây ra chi phí lớn. Khác với nợ kỹ thuật, nợ thiết kế thường không có trong báo cáo kỹ thuật nên khó được ưu tiên xử lý.

Những dấu hiệu trực quan dễ đo được

Anh Chị có thể kiểm tra ngay bằng cách trả lời các câu hỏi sau:

• Mỗi sprint, team có dành hơn hai giờ họp chỉ để thống nhất màu sắc, khoảng cách, hoặc cách hiển thị nút không?
• Developer trong team có thói quen copy-paste component (thành phần giao diện) từ file cũ thay vì dùng thư viện chung không?
• Trong file Figma hiện tại có nhiều phiên bản của cùng một component, và không ai chắc phiên bản nào là chính thống không?
• Mỗi sprint có ít nhất một đến hai bug UI có thể truy ngược về dùng sai màu hoặc spacing (khoảng cách) không?

Nếu trả lời có cho từ hai câu trở lên, chi phí ẩn đang chạy đều mỗi tuần.

Những dấu hiệu ngầm khó nhận ra hơn

Một số dấu hiệu không hiện rõ trong sprint log hay bug tracker, nhưng lại tốn kém hơn theo thời gian:

• Nhân sự mới, cả designer lẫn developer, mất hơn hai tuần mới hiểu được quy tắc UI hiện tại vì quy tắc đó chủ yếu tồn tại trong đầu người cũ.
• Mỗi lần thuê agency ngoài làm banner hoặc landing page, kết quả visual bị khác sản phẩm chính, và team phải mất thêm vòng chỉnh sửa để kéo lại.
• Khi có yêu cầu kiểm tra WCAG (tiêu chuẩn tiếp cận web) hoặc brand audit (kiểm tra nhận diện thương hiệu), không ai biết bắt đầu rà soát từ đâu vì không có tài liệu chuẩn.

Baymard Institute ghi nhận rằng sự không nhất quán trong giao diện làm tăng cognitive load (tải nhận thức) của người dùng và có thể ảnh hưởng đến niềm tin. Điều này có nghĩa là thiệt hại không chỉ nằm ở nội bộ: khách hàng cuối cũng cảm nhận được sự lộn xộn, dù họ không đặt tên cho nó.

Tại sao những dấu hiệu này thường bị bỏ qua

Có ba lý do phổ biến:

• Chỉ tính chi phí rõ, bỏ qua chi phí mờ. Tiền lương nhân sự xuất hiện trong bảng lương, nhưng giờ họp thống nhất visual không ai đếm.
• Quy nhầm nguyên nhân. Khi bug UI xuất hiện, phản xạ tự nhiên là tìm ai sai, không phải hỏi hệ thống đang thiếu gì.
• Chờ đến khi có audit bên ngoài. Lúc đó chi phí sửa lớn hơn chi phí xây hệ thống từ đầu, vì vấn đề đã chôn vùi dưới nhiều lớp.

Nợ thiết kế tích lũy âm thầm. Mỗi lần bỏ qua một quy tắc không được ghi lại, mỗi lần dùng sai một giá trị màu vì không có nguồn chính thống, chi phí sửa về sau tăng lên. Vấn đề không phải ở con người mà ở việc con người không có công cụ để làm đúng.

Kinh nghiệm thực hành Sinh Vũ, dựa trên khung Technical Debt của Ward Cunningham

Bước đầu tiên: đo trước khi quyết định

Sinh Vũ thường đề nghị khách tự đo chi phí ẩn trước khi bàn đến bất kỳ giải pháp nào. Cách đơn giản nhất:

• Đếm số bug UI trong ba sprint gần nhất. Truy xem bao nhiêu bug có nguyên nhân là dùng sai màu, spacing, hoặc component không đồng nhất.
• Ước tính số giờ họp thống nhất visual mỗi tuần, nhân với đơn giá giờ thực tế của nhân sự liên quan.
• Hỏi nhân sự mới gần nhất: họ mất bao lâu để hiểu được quy tắc UI hiện tại, và họ tự học từ đâu?

Con số ra được từ ba phép tính này thường là căn cứ thuyết phục hơn bất kỳ lý lẽ nào về giá trị dài hạn của hệ thống. Nếu con số nhỏ, thì chưa phải lúc đầu tư lớn. Nếu con số đáng kể, thì câu hỏi không còn là "có nên làm không" mà là "bắt đầu từ đâu".