Chìa khóa vẫn không phải là Design System

Long Nguyen

Chìa khóa vẫn không phải là Design System

Có bộ Design System rồi, giờ sao nữa?

Đúng rồiiii, bạn hỏi đúng rồi đó!

Vấn đề không phải là bạn tạo ra bộ Design System như thế nào, mà bạn sẽ chung sống với nó ra sao? Từ việc bảo trì, chỉnh sửa, cập nhật, ứng dụng nó để đi giải các bài toán thường ngày của bạn trong công ty.

Xin chào mọi người, mặc dù vẫn đang giai đoạn tuyển sinh cho khóa Design System, nhưng Long vẫn muốn viết về chủ đề này để gửi đến các bạn, nó áp dụng cho học viên đã học, chưa học, cũng như sắp học.

Đặt đúng mong đợi

Nếu mọi người mong đợi khóa học sẽ mang lại một khung lý thuyết để mọi người có thể biết cách gọi tên từng khái niệm, mang về áp dụng cho các bài toán của công ty, thì có thể sẽ thất vọng.

Đúng: khóa học có bộ tài liệu riêng bao gồm hơn 10 eBook pdf tự biên soạn.

eBook cover 1 eBook cover 2 eBook cover 3 eBook cover 4 eBook cover 5 Trang sách 1 Trang sách 2 Trang sách 3 Trang sách 4 Trang sách 5 Trang sách 6 Trang sách 7 Trang sách 8 Trang sách 9 Trang sách 10

Tuy nhiên, bản chất Design System vẫn là được tạo ra để giải quyết vấn đề của designers, đội phát triển phần mềm, và ở vài trường hợp, là bài toán kinh doanh của công ty.

Có nghĩa là Design System vẫn như bao sản phẩm khác: đứng giữa nhu cầu thực tế của nhiều người, ở nhiều team khác nhau. Mà nhu cầu thì lại thay đổi theo mục tiêu chung của công ty tùy từng thời điểm.

Là designer, bạn không thể nào đứng giữa cuộc họp để nói rằng “vì Design System có luật như thế, nên việc a,b,c này không khả thi.”

Khóa học này hoàn toàn không mong muốn đào tạo ra designer như vậy.

Bạn hoàn toàn có thể nói rằng phiên bản Design System hiện tại đang có giới hạn chỗ này: nên nếu cả đội vẫn muốn đạt được mục tiêu đề ra theo đúng timeline, thì đây sẽ là giải pháp: chỗ này sẽ hy sinh thẩm mỹ một chút để đạt được tiến độ, chỗ kia cố gắng dùng lại component…

Như vậy: chìa khóa không phải nằm ở Design System. Chìa khóa nằm ở chính cách bạn hiểu toàn bộ cấu trúc của design system mà bạn tạo nên, biết điểm yếu, điểm mạnh của nó, và quan trọng hơn hết: biết cách trình bày sao cho các thành viên khác hiểu.

Delete group — xóa một nhóm token trong Figma

Hãy hiểu rõ một thứ đến mức bạn có thể tự tin đập nó đi

Sau buổi thứ 2 của buổi học, mình rất vui khi thấy có bạn nhắn tin rằng: sau khi xem xét, em thấy token nhóm A không cần thiết, nên em sẽ remove. Mình vui vì hiểu rằng: chỉ khi hiểu rõ một thứ và tự tin rằng mình có thể xây lại nó, bạn mới dám bỏ thứ đó đi.

Và trong các bài tập tiếp theo, cũng chính nhóm bạn sẽ được trải nghiệm với bộ Design Tokens mà mình tự tạo, chính bạn sẽ tự kiểm chứng được quyết định của mình, cùng với sự ủng hộ và đồng hành cùng mình. Không có đúng, sai ở đây, chỉ đơn giản là những cơ hội để mình được thử nghiệm thôi.

Kiến thức về công cụ

Khóa học sẽ dẫn và chỉ cho bạn cách kết hợp các công cụ của Figma, từ Variables, Components cho đến cách Figma tổ chức file theo Team, Folder…

Các chức năng như Swap, Slot, Variable Mode… cũng sẽ được khai thác để chúng ta hiểu mình có thể đi xa đến đâu khi triển khai một Design System.

Phạm vi triển khai trong khóa học sẽ được đặt trong ngữ cảnh của một tập đoàn, để mọi người có cơ hội nhìn thấy một Design System có thể lớn và phức tạp đến mức nào.

Và việc bạn biết bạn có thể đi xa tới đâu, không có nghĩa rằng bạn phải đi tới đó

Cốt lõi vẫn phải quay về chính công ty mà bạn đang làm.

Môi trường, số lượng thành viên, văn hóa công ty, quy trình làm việc… tất cả đều là những biến số khiến bạn phải tự quan sát và lựa chọn một phương án Design System phù hợp cho tổ chức của mình.

Bạn hoàn toàn có thể nhắn tin cho Long để hỏi về một case thực tế và cùng thảo luận xem nên xử lý như thế nào, với điều kiện đừng đưa quá nhiều thông tin dự án nếu những thông tin đó không được phép chia sẻ nhen.

“Em được làm cái này không?”

Được, được hết á, nhưng bạn hãy cố gắng cung cấp thêm:

  • Lý do mà bạn muốn đi theo hướng này
  • Ví dụ trong tháng tới, có một yêu cầu design cho phần này xuất hiện, bạn thử tưởng tượng xem mình sẽ giải bài toán đó như thế nào?

Và những câu hỏi này không phải hỏi đố, nó là hỏi thật để giáo viên và học viên cùng nhau giải case, vì mình học qua lại mà, biết đâu giải pháp mới này thực sự có thể giải quyết vấn đề đó mà giáo viên cũng không nhận ra thì sao.

Đừng để lý thuyết là tiếng ồn, đến nỗi nó át đi giọng nói gần bạn nhất

Đừng để lý thuyết là tiếng ồn, đến nỗi nó át đi giọng nói gần bạn nhất: là đồng nghiệp, sếp, và chiến lược công ty

Từ lúc mới đi làm đến giờ, mình vẫn tin không một khung lý thuyết nào được áp dụng 100% cho một tổ chức hết. Lý do là vì designer thì hay làm dự án freelance ngoài giờ, và nhờ nhiều lần ngồi thu thập yêu cầu với stakeholders, mình nhận ra cốt lõi vẫn là sự lắng nghe, phản ứng nhanh, tập hợp lý thuyết và kinh nghiệm các dự án trước ra để có một quy trình được customized để phù hợp với khách hàng.

Và trong thời buổi hiện nay, khi mà cứ vài tháng, AI lại ra một model mới mạnh mẽ hơn, đi kèm với nhiều khả năng có thể làm ảnh hưởng quy trình cũ, niềm tin vào việc này lại mạnh hơn bao giờ hết.

Hãy chủ động quan sát, và khi muốn hành động, lý thuyết chỉ nên là một nền tảng giúp bạn tự tin tham chiếu khi đưa ra quyết định thôi.

Final playbook

Vậy sau khóa học, bạn cần mang theo điều gì?

Nếu phải gói gọn khóa học này vào một điều, Long không muốn bạn kết thúc khóa học với một Design System hoàn hảo.

Long muốn bạn hiểu vì sao Design System của mình được xây như vậy.

Bạn biết nó đang giải quyết vấn đề gì.

Bạn biết nó có thể đi xa đến đâu.

Bạn biết nó đang có giới hạn ở đâu.

Bạn biết khi nào nên giữ lại, khi nào nên thay đổi, và khi nào một thứ tưởng như rất quan trọng lại có thể được bỏ đi.

Và quan trọng nhất, bạn biết cách giải thích những quyết định đó với những người đang cùng bạn xây dựng sản phẩm.

Vì vậy, chìa khóa cuối cùng vẫn không nằm ở Design System.

Nó nằm ở chính bạn.