6 câu hỏi về thành công và thất bại của design system

Dạo gần đây, khi tham gia vào giai đoạn thiết kế ban đầu của design system, tôi có rất nhiều điều phải suy nghĩ.

Liên quan đến chuyện này, đây là nội dung tôi đọc trên UX Collective vào tuần trước. Tôi đã dịch nó cho các thành viên design system trong công ty, thấy tiếc nếu không chia sẻ nên đăng lại ở đây.

Nghe nói đây là phần tóm tắt từ các cuộc phỏng vấn với 10 nhà thiết kế làm việc với design system.

Câu hỏi 1. Nếu muốn thất bại trong vai trò DS thì phải làm gì?

• Trở thành cảnh sát

• Sử dụng quyền lực của designer (nói về chuyện chính trị)

• Tích hợp các thành phần rồi lại không sử dụng chúng

• Làm việc theo kiểu phản ứng sau sự kiện thay vì dự đoán trước nhu cầu của đội ngũ

• Không lắng nghe hay nghiên cứu tiếng nói của người dùng (các designer hoặc developer khác)

• Một DS được tạo ra chỉ vì DS

• Không duy trì roadmap và quy trình công việc rõ ràng

• Tạo ra một trải nghiệm lý tưởng nhưng không thể thực hiện được

• Không kiểm thử cùng với các đội ngũ

• Không hiểu DS như một sản phẩm duy nhất

• Tạo công cụ nhưng không đào tạo mọi người cách sử dụng

• Mang vào quá nhiều lý thuyết xa rời cách làm việc thực tế

• Nghĩ rằng mình có thể làm một mình

• Không tập trung 100% vào việc trao đổi kiến thức với ai đó trong đội kỹ thuật

• Tạo ra các component quá kém linh hoạt và không cho phép detaching

• Không nhờ giúp đỡ và cũng không kết nối với mọi người (dù là nội bộ hay bên ngoài)

• Đứng từ xa để ra lệnh về quy tắc thay vì ở sát bên họ

Câu hỏi 2. Những soft skill nào cần thiết để DS thành công?

• Giao tiếp, giao tiếp, giao tiếp!!!

• Đồng hành cùng người dùng, lắng nghe, đặt câu hỏi và nghiên cứu là cực kỳ quan trọng.

• Hãy khiêm tốn thừa nhận thất bại

• Hãy kiên nhẫn

• Khả năng tạo ra một không gian an toàn

• Dạy người khác

• Đưa ra một tầm nhìn có hệ thống về cách tái sử dụng

• Ngay cả khi mở rộng, vẫn phải kiên quyết giữ sự nhất quán

• Khi hiểu người khác, không nhất thiết phải đồng cảm quá mức. Hãy tiếp nhận quy tắc đúng như bản chất của nó.

• 95% là hard skill và 5% là soft skill cho những lúc mọi thứ đi lệch khỏi quy tắc.

• Hãy khuyến khích và chia sẻ sự phát triển của mọi người

• Tính tự chủ

• Hãy tiếp tục bán sản phẩm (DS)

• Hãy suy nghĩ một cách chiến lược

• Hãy để tất cả mọi người cùng tham gia

• Tạo tiếng vang xung quanh DS

• Hãy dành nhiều thời gian nhất có thể để tìm ra càng nhiều kịch bản càng tốt

• Hãy thống nhất ngôn ngữ.

Câu hỏi 3. Cách vận hành DS nên tập trung hơn hay phân tán hơn?

Có hai cách: một là đội ngũ tập trung chịu trách nhiệm kiểm tra cách mọi người thiết kế, hai là để tất cả mọi người cùng chịu trách nhiệm. Tôi đã hỏi mọi người xem nên chọn cách nào.

• Chúng tôi là một đội quá tập trung nên thường xảy ra nút thắt cổ chai. Nhưng mô hình phân tán cũng có thể gặp vấn đề về suy yếu ownership.

• Chúng tôi có một đội designer hơn 100 người đang tập trung hóa DS.

• Chúng tôi hợp tác với các thư viện alpha do mọi người tạo ra và từ đó xây dựng backlog cho đội DS.

• Chúng tôi đào tạo mọi người để họ tự nguyện tạo component.

• Việc có nên tập trung hóa hay không mang tính chính trị rất nhiều. Trước khi quyết định, cần hiểu chính xác mức độ scale mà bạn cần.

• Cần điều chỉnh kỳ vọng và để mọi người cùng tham gia xây dựng DS.

• Chúng tôi muốn hợp tác, nhưng không biết cách làm tốt nên đã tạo ra quy trình. (Culture vs Process)

• Ban đầu có thể sẽ ít mang tính cộng tác hơn một chút để đảm bảo việc chuyển giao. Khi trưởng thành hơn, có thể làm nó cộng tác hơn.

• Giờ chúng tôi đã đến thời điểm phải phi tập trung hóa nó; cần dạy mọi người cách đóng góp.

• Nếu bạn không đào tạo mọi người, họ sẽ không đóng góp.

• Khi designer muốn vượt ra ngoài tiêu chuẩn để tạo ra kết quả tốt hơn, họ cũng cần có khả năng đồng thời nghĩ về cách chuẩn hóa điều đó.

• DS không thể do 1~2 người làm. Vì đây là việc xây dựng một hệ thống, nên DS phải bắt đầu từ cấp độ squad.

• Điều này rất khác nhau tùy theo quy mô đội ngũ; đôi khi đội DS tập trung vào phát triển core component còn các ambassador khác sẽ lan tỏa nó.

• Cuối cùng, chúng tôi là một đội tập trung nhưng làm việc cộng tác với các ambassador. Quyết định cuối cùng thuộc về đội DS.

4. Bạn nghĩ DS là một tập hợp quy tắc chi tiết và mang tính hạn chế hơn, hay là thứ rộng mở hơn để designer có tự do tạo bố cục mới?

Đóng hay mở? Nếu bạn làm công việc liên quan đến design system thì hẳn sẽ quan tâm đến câu hỏi này. Tôi cũng vậy, nên đã quyết định hỏi mọi người.

• Với những gì liên quan đến "accessibility", hãy tiếp cận theo hướng hạn chế hơn

• Chúng tôi bắt đầu cùng nhau từ một cấu trúc cơ bản, nhưng rồi bắt đầu tạo ra một vài điểm thiếu nhất quán. Vì vậy, chúng tôi quyết định không đóng hoàn toàn 100% mà đặt ra thêm một số ràng buộc. Dù vậy, chúng tôi luôn cố tìm cách trả lại điều gì đó cho designer

• Điều này tùy tình huống, vì vậy hãy đo lường rủi ro trước rồi mới quyết định. Nói chung, đội càng nhỏ = độ linh hoạt càng cao

• Đây không chỉ là việc sáng tạo và tạo ra các thành phần mới. Bạn cần những component đủ linh hoạt để đáp ứng nhu cầu của mọi người

• DS là kinh doanh. Component càng ít càng tốt.

• Mọi người phải thích dùng DS. Nhìn bề ngoài, người ta dễ nghĩ nó giống như đồng phục nên không cần linh hoạt (nhưng không phải vậy)

• Không thể quá hạn chế ngay từ đầu. Khi có đủ thời gian trôi qua, nó có thể bắt đầu tiến hóa thành những pattern cụ thể.

• Với các designer mới gia nhập công ty, nhiều ràng buộc hơn đôi khi lại hữu ích. Muốn phá vỡ quy tắc thì trước hết phải bắt đầu từ quy tắc.

• Chúng tôi cung cấp đủ nguyên liệu để mọi người có thể tự tạo công thức của riêng họ.

• Điều này phụ thuộc vào độ trưởng thành của đội. Nếu có nhiều junior hơn, họ có xu hướng yêu cầu nhiều guideline thiết kế hơn vì họ hiểu ít tài liệu hơn. Vì vậy cần đào tạo nhiều hơn, nhưng vẫn cố gắng không nhốt họ lại mà để họ làm việc tự do. Thách thức lớn nhất là khiến mọi người tự đọc và sử dụng tài liệu, nên có thể cần đưa nó đến gần designer hơn, như trong Figma.

• Nếu là chuyện về accessibility và thẩm mỹ thì nên hạn chế hơn.

• Token rất quan trọng để giữ tính nhất quán.

• Tài liệu tốt là tài liệu cân bằng được giữa việc hài hòa với mọi người và để họ có tự do.

Câu hỏi 5. Bạn nghĩ gì về DS được kết nối với branding và marketing?

(Tôi không quá rành mảng này nên dịch hơi khó.)

Tôi hiểu rằng design system cuối cùng vẫn phải xoay quanh sản phẩm số, nhưng vì sản phẩm có thể là một trong những nền tảng thương hiệu quan trọng nhất, nên tôi tò mò muốn biết mọi người liên kết hai thứ đó trong suy nghĩ như thế nào.

• Cách nghĩ về branding gắn với DS là hãy nghĩ ngược lại xem nó tác động đến DS như thế nào.

• Chúng tôi bắt đầu điều chỉnh design system theo brand để căn chỉnh diện mạo và cảm giác của thương hiệu.

• DS phục vụ cho khả năng scale và brand ID, nhưng mức độ kết nối giữa hai thứ này khác nhau tùy đội branding.

• Since DS is a language, MKT could support with assets for it;

• Đội branding nên tham gia DS ngay từ đầu để xây dựng các quy tắc nền tảng.

• Điều này khác nhau tùy công ty. DS là công cụ để củng cố thương hiệu, nên việc căn chỉnh là rất quan trọng. Kết nối giữa hai lĩnh vực này cũng ảnh hưởng đến accessibility của DS.

• Điều quan trọng là tìm ra cách đồng bộ với đội branding để căn chỉnh chiến lược.

• They were used to join projects that the company already had a partner to support with branding, so they would come together with these partners to bring the brand inside the DS;

• Đôi khi có thể dùng chung tài liệu và hệ thống, nhưng phần lớn là không. DS là interface. Đội thương hiệu thường có một "branding system" riêng, và phổ biến hơn là các thư viện tương tác với nhau. Hai thứ đó không hoàn toàn giống nhau.

Câu hỏi 6. Có thể đo lường thành công của DS như thế nào?

• Khảo sát nhận thức để hiểu mức độ tham gia, adoption và tình trạng của các đội ngũ

• Mức độ bao phủ component (DS được dùng đến đâu so với việc bị hard-code)

• Adoption

• Time to market

• ROI

• Figma Analytics

• Phản hồi từ các đội phát triển

• Accessibility

• Số lần các component được sử dụng

[xguru]

Wow, hay quá. Cảm ơn bạn đã tổng hợp!