Hệ thiết kế cho D2C: linh hoạt đến đâu là đủ

Thương hiệu bán thẳng (D2C, tức bán trực tiếp đến người dùng cuối không qua trung gian) sống bằng nhịp chiến dịch liên tục: ra mắt bộ sưu tập mới, sale theo mùa, ngày đôi, ngày lễ. Câu hỏi Sinh Vũ nghe nhiều nhất từ chủ thương hiệu D2C là: hệ thiết kế cần linh hoạt tới đâu để theo kịp, mà không biến thành mớ hỗn độn không ai bảo trì nổi? Câu trả lời không phải "càng linh hoạt càng tốt". Câu trả lời là: linh hoạt đúng chỗ, cứng đúng chỗ.

Hai lớp cần tách ra ngay từ đầu

Mọi hệ thiết kế số đều có hai loại quyết định. Một là quyết định perceptual (lớp cảm nhận): màu sắc, kiểu chữ, hình ảnh, giọng điệu. Đây là nơi thương hiệu biểu đạt cá tính và khác biệt từng chiến dịch. Hai là quyết định chức năng: bố cục trang, luồng thêm vào giỏ, bước thanh toán. Đây là nơi người dùng hoàn thành việc họ cần làm.

Lỗi phổ biến nhất của D2C là trộn lẫn hai lớp này. Mỗi chiến dịch sale Tết, sale Hè lại dựng một bộ giao diện riêng hoàn toàn, cả màu lẫn luồng đều khác. Kết quả là sau ba mùa, codebase có ba bộ, không bộ nào nhất quán, đội kỹ thuật mất nhiều giờ tìm xem lỗi nằm ở bộ nào.

Nguyên tắc của Alla Kholmatova trong cuốn Design Systems đặt vấn đề rõ: hệ tốt cho phép biến tấu ở lớp perceptual trong khi giữ pattern chức năng ổn định. Tách được hai lớp đó, Anh Chị mới có nền để chạy chiến dịch nhanh mà không phá vỡ thứ đang hoạt động tốt.

Kiến trúc token ba tầng: chìa khóa của sự linh hoạt

Token (mã định nghĩa giá trị thiết kế như màu, cỡ chữ, khoảng cách) được tổ chức theo ba tầng:

• Tầng gốc (primitive): liệt kê toàn bộ giá trị thô trong bảng màu, ví dụ xanh lá 500, cam 300. Tầng này không đổi.
• Tầng ngữ nghĩa (semantic hay alias): gán ý định thiết kế vào giá trị gốc, ví dụ "màu nút chính" trỏ vào xanh lá 500. Đây là tầng Anh Chị ghi đè khi chạy chiến dịch mới: "màu nút chính" đổi thành cam 300 cho sale Tết, component không cần sửa một dòng code nào.
• Tầng component: component dùng token ngữ nghĩa, nên tự động nhận diện mới khi tầng ngữ nghĩa thay đổi.

Nathan Curtis của EightShapes gọi token ngữ nghĩa là nơi mang "ý định thiết kế theo ngữ cảnh". Chỉ cần chạm tầng này, toàn bộ giao diện chiến dịch đổi nhất quán, không bỏ sót.

Brad Frost trong The Many Faces of Themeable Design Systems gọi kiến trúc này là bí quyết để theme hóa được, tức là đổi diện mạo cho chiến dịch hay thương hiệu con mà không phải dựng lại hệ.

Khi nào cần bộ khối tự phục vụ cho đội tiếp thị

Nếu đội tiếp thị dựng trang đích (landing page) vài lần một tháng mà lần nào cũng phải chờ kỹ thuật, nhịp chiến dịch sẽ chậm dù hệ token có tốt đến đâu.

Điều kiện để bộ khối tự phục vụ hoạt động ổn là khối phải được kiểm duyệt kỹ trước khi phát hành. Nếu đội tiếp thị được tự do lắp mọi thứ không giới hạn, nhận diện thương hiệu sẽ loãng dần qua từng chiến dịch.

Luồng thanh toán: vùng không được chạm

Đây là nguyên tắc Sinh Vũ giữ cứng với mọi dự án D2C. Luồng thanh toán là khâu chốt đơn, nơi doanh thu thực sự hình thành. Thay đổi giao diện ở đây, dù nhỏ, đều có thể làm khách bối rối hoặc mất tin tưởng đúng lúc quan trọng nhất.

Chiến dịch biến tấu mạnh ở các trang trước: trang chủ chiến dịch, trang danh mục, trang sản phẩm. Nhưng từ trang giỏ hàng vào đến xác nhận đơn, giao diện giữ nhất quán theo năm, không theo mùa.

Token ngữ nghĩa mang ý định thiết kế theo ngữ cảnh, tách khỏi giá trị gốc. Đổi chiến dịch chỉ cần chạm tầng này.

Nathan Curtis, Naming Tokens in Design Systems (EightShapes)

Lỗi thường gặp và cách tránh

• Mỗi chiến dịch dựng một bản giao diện rời: sau vài mùa, không ai biết bản nào còn dùng, bản nào đã bỏ. Cách tránh: tất cả chiến dịch chạy trên một bộ component lõi, chỉ ghi đè token ngữ nghĩa.
• Nhét màu cứng vào component: khi lập trình viên ghi thẳng mã màu vào component thay vì trỏ qua token, mỗi lần đổi theme phải sửa code thủ công từng chỗ, dễ bỏ sót. Cách tránh: quy ước nội bộ: component chỉ được dùng token, không dùng giá trị gốc trực tiếp.
• Linh hoạt quá đà: cho phép đổi mọi thứ khiến qua vài chiến dịch khách không còn nhận ra thương hiệu. Cách tránh: xác định trước các yếu tố nhận diện lõi không được phép thay đổi dù chiến dịch nào.
• Bỏ qua bước khớp thiết kế và code: đội thiết kế dùng Figma, đội kỹ thuật dùng code, hai bên không đồng bộ token dẫn đến bản chiến dịch chạy thật khác xa bản mockup. Sinh Vũ dùng Figma Code Connect để hai bên khớp nhau từ đầu.

Góc nhìn của Sinh Vũ

Với các dự án D2C, Sinh Vũ dựng token theo định dạng DTCG (Design Token Community Group, chuẩn chung để công cụ thiết kế và code đọc được cùng một tệp token). Đội tiếp thị được giao quyền đổi tầng ngữ nghĩa cho từng chiến dịch, bộ component lõi và luồng mua giữ nguyên. Nhịp ra chiến dịch mới không còn phụ thuộc vào lịch kỹ thuật, nhưng cũng không bị thả nổi hoàn toàn vì token và bộ khối đã xác định giới hạn biến tấu.

Mức linh hoạt đủ dùng với D2C nhịp cao là: đổi được diện mạo theo chiến dịch trong vài giờ, không phải vài ngày, mà không cần viết thêm một dòng code nào ngoài tầng token.