Bài viết này với kinh nghiệm tù việc xây dựng Design System và hướng dẫn cho team làm việc chung của mình. Nên đôi khi nó vẫn có tìm ẩn là không phù hợp với team của các bạn, nhưng dù sao vẫn là mục đích chia sẻ kinh nghiệm để tránh lỗi nhé.
Các bạn cũng nghe nhiều về Design System rồi, nó có muôn vàn thứ để giải thích và một trong số đó ảnh hưởng rất lớn cho nhiều thứ sau này đó là Component. Đúng vậy, mình thích Component “xịn” haha. Component “Xịn” ở đây thường được tạo bởi một nhóm với việc được đặt tên (naming), cách xử lý bố cục tốt (auto layout), …. Lý do quan trọng của Component “Xịn” là tính hiệu quả, tăng khả năng chuyển giao từ designer đến developer (mình hay gọi cái này là delivery from design to engineer). Vì vậy đây cũng là giá trị của 1 bạn Designer Ui tốt mang lại dành cho chính công ty đó.
Bởi vì thế để đạt được những điều trên thì chính bản thân mình cũng đã có rất nhiều sai sót để tạo nên được sự linh hoạt, hay đặt câu hỏi và vài đúc kết ngắn đây để nói lên tiêu đề chính bài này:
Flexible (Linh hoạt) Repeat (Lặp lại) Useful (Sử dụng hiệu quả) Increaseable (Tính mở rộng) Tactical (Mục đích rõ ràng)
Vậy giờ là mình có tên gọi kiểu này là 🍏 FRUIT để tiếp tục nhé.
1) 🔄 Flexible (Linh hoạt)
Linh hoạt ở đây có nghĩa là thành phần con (instance component) có khả năng điều chỉnh. Vậy thì nó sẽ lại được phân ra các loại như sau nữa:
Khả năng ẩn hiện thành phần (Boolean)
Mục đích của việc này nhầm ẩn hiện nhanh thành phần mà bạn mong muốn trong component đó. Hãy nhớ rằng việc đặt tên cũng phải thật rõ ràng để dễ dàng nhận biết mục đích thành phần muốn ẩn đi.
Thay đổi màu sắc, trạng thái,… (Variant)
Mục đích Variant Badge này là để phân loại màu sắc, độ nổi bật
Thay đổi thành phần (Swap Instance)
Ở mục này thì việc dùng Swap Instance để đổi icon có trong Button
Responsive design (đối với bạn này có thể làm variant thay cấu trúc hoặc sau này dùng thêm variables)
Đây là ví dụ Variant với thuộc tính mình đặt tên sẽ là Device (hoắcize, platform) Bạn thấy đấy với ví dụ này, với sản phẩm nhỏ thì nó ổn. Nhưng với sản phẩm độ phức tạp cao thì mình khuyên là bạn nên tách ra.
2) Repeat (Lặp lại)
Về bản chất, mọi thành phần đều có thể lặp lại. Thách thức về khả năng tái sử dụng của một thành phần nảy sinh khi chúng ta bắt đầu nghĩ về tính đặc trưng của nó. Ở khái niệm Lặp lại này chỉ có 3 loại cụ thể tính đặc trưng như sau:
Chỉnh sửa ✏️ Text (Text Properties)
Việc ghi đè nó dễ rủi ro tìm ẩn ở đây ví dụ: Các bạn gõ chữ ở đâu đó hoặc copy từ đâu đó rồi dán vào thành phần bằng cách thủ công. Thì rất dễ bị hư hại phần style chữ. Nên ghi chữ vào Text properties sẽ giảm thiểu chỗ này. Kèm theo đó khi mình đặt tên cho Text Properties cũng dễ nhìn ra chỗ nào cần sửa chữ ví dụ như : ✏️ Title, ✏️ Label, ✏️ Description,…
Chỉnh sửa tỉ lệ hình (Aspect ratios)
Ở vấn đề này thường thì chúng ta chỉ hay gặp các tỉ lệ hình như: 16:9, 4:3, 1:1, … Với ví dụ này mình sẽ làm 1 Card có hình được làm tỉ lệ sẵn, việc chúng ta cần làm là Nested Instance để card có thể linh hoạt tỉ lệ ảnh
Sắp xếp danh sách (Lists)
Đây là dạng những component dạng danh sách (list). Khi này Component này có nhiệm vụ tạo variant để có thể đưa ra được số lượng nên xuất hiện. Ví dụ Text Field list, sẽ có variant properties tên là count nhầm muốn xuất hiện bao nhiêu item ra . Trong sắp xếp danh sách này là hiện tượng thường khó đoán nhất khi chúng ta nghĩ đến khả năng sử dụng của các thành phần có thể tùy chỉnh. Vì thường chúng ta cứ tạo component rồi xài chứ ít ai đụng vào kiểu danh sách (list). Vấn đề sẽ xảy ra khi ai đó trong team phá vỡ cấu trúc danh sách vấn đề nó sẽ xảy ra. Vấn đề này thường hay xảy ra với các thành phần như: Tables, Menus, Lists, Forms, Navigation,…
DONATE CHO MÌNH NHÉ!
CÙNG MÌNH TRIỂN KHAI Ý TƯỞNG THIẾT KẾ. TẠO RA TRẢI NGHIỆM TỐT CHO KHÁCH HÀNG VÀ GIÁ TRỊ CHO CỘNG ĐỒNG
