Hệ thống thiết kế - Những cạm bẫy nào cần tránh khi bạn là nhà thiết kế duy nhất?

May 10 2022
Hoặc cách tạo Hệ thống thiết kế phục vụ một mục đích. Bài viết Td; drAn dựa trên kinh nghiệm cá nhân của tôi sẽ cung cấp cho bạn các phương pháp hay để tránh tự mình làm cho hệ thống thiết kế của bạn quá nhanh và biến nó thành một tài liệu không thể mở rộng và cứng nhắc.

Hoặc cách tạo Hệ thống thiết kế phục vụ một mục đích.

Td; dr
Một bài viết dựa trên kinh nghiệm cá nhân của tôi sẽ cung cấp cho bạn các phương pháp hay để tránh việc tự mình làm cho hệ thống thiết kế của bạn quá nhanh và biến nó thành một tài liệu không thể mở rộng và cứng nhắc.

Lần đầu tiên tôi nghe về hệ thống thiết kế là vào năm 2015 và tôi đã có công việc đầu tiên. Vào khoảng thời gian này, những đứa trẻ thú vị đã đăng #avocadotoasts trên Instagram, biểu tượng của Google đang chuyển từ serif sang sans-serif và có một số bài báo ấn tượng đã xác định và xác định lại thế nào là một hệ thống thiết kế tốt (có cái hay hệ thống thiết kế và hệ thống thiết kế tồi… ) .

Khi tôi bắt đầu là nhà thiết kế duy nhất trong công việc đầu tiên này, tôi không có người giới thiệu nào để hướng dẫn tôi trong việc tạo ra một hệ thống thiết kế. Tất cả những gì tôi có thể làm là đọc những bài báo mâu thuẫn và dựa vào chiếc đồng hồ bối rối của mình. Vì vậy, tôi đã mắc rất nhiều sai lầm. Tôi muốn tự mình làm mọi thứ, trong một bối cảnh mà tôi không có thời gian, và bằng cách áp đặt một tầm nhìn mà tôi không kiểm soát được. Nếu đó là một trò chơi lô tô, tôi đã trúng ham rồi.

Kể từ đó, một số bài đọc đã giúp tôi rất nhiều để hình thành ý kiến ​​về chủ đề này, và tôi không thể khuyên bạn nên đọc chúng đủ:

Thiết kế Nguyên tử của Brad Frost , Hệ thống Thiết kế của Alla Kholmatova
, hoặc Sổ tay Hệ thống Thiết kế của InVision .

Không chỉ là một chuỗi nữa đối với nhà thiết kế của chúng ta, Hệ thống thiết kế đưa chúng ta vào tư duy có hệ thống. Coi thế giới là một tập hợp các tương tác, tối ưu hóa cách chúng tôi thiết kế sản phẩm, tạo cầu nối hữu hình giữa nhà thiết kế và nhà phát triển (và cả giữa các nhóm của cùng một tổ chức) , tất cả điều này có được nhờ vào hệ thống thiết kế và những người đã đóng góp vào định nghĩa của nó.

Giống như bất kỳ công cụ mới nào, việc triển khai nó bao gồm rủi ro. Việc tạo ra nó đòi hỏi quá nhiều nỗ lực / quá nhiều thời gian? Nó hoàn toàn mới nhưng không ai sử dụng nó? Nó được coi là một hạn chế hơn là một hướng dẫn? Không sao, hãy để tôi lấy chiếc búa khoan của tôi và chúng ta sẽ cùng nhau phá bỏ nó.

LƯU Ý: Bài viết này ở đây để cung cấp cho bạn các nguồn lý thuyết và hướng dẫn bạn cách tốt nhất để bắt đầu hệ thống thiết kế của riêng bạn, từ quan điểm của một nhà thiết kế khởi nghiệp. Đây không phải là một hướng dẫn thực tế từ A đến Z.

Hệ thống thiết kế - Nó là gì? Vấn đề ở đây là gì ?

Tài liệu về chủ đề này rất phong phú. Có rất nhiều bài báo và tài nguyên mà thậm chí có những người phụ trách chỉ nói về nó (xem bên dưới) . Không cần phải tìm kiếm đâu xa để tìm ra một định nghĩa rõ ràng và đầy đủ:

“Hệ thống thiết kế là một ngôn ngữ trực quan, có tổ chức và đang phát triển điều chỉnh thành phần của một hoặc nhiều sản phẩm.” ~ internet đã ký

Điều đó có nghĩa là bất kỳ tổ chức nào có một hoặc nhiều sản phẩm đều có thể có một hệ thống thiết kế. Một công ty khởi nghiệp có thể sở hữu một công ty, chẳng hạn như một tập đoàn lớn , một chính phủ , hoặc thậm chí một cộng đồng . Nói cách khác, nó là một tài liệu hoàn chỉnh, bao gồm:

  • Nguyên tắc: Các khái niệm chính sẽ ảnh hưởng đến các quyết định thiết kế trong sản phẩm là gì? Thiết kế cần truyền tải những giá trị nào?
  • Hướng dẫn về kiểu dáng: Màu sắc, kiểu chữ, khoảng cách, logo, biểu tượng và hình ảnh minh họa của sản phẩm.
  • Thành phần: Danh sách có thứ tự các thành phần giao diện người dùng (theo loại, theo họ, trong thiết kế nguyên tử…), trạng thái của chúng (di chuột, lỗi, bị vô hiệu hóa…) và cách sử dụng của chúng (làm & không).
  • Các thông lệ tốt: Khả năng tiếp cận và / hoặc các tiêu chuẩn thiết kế sinh thái cần được tôn trọng, chiến lược nội dung sẽ được áp dụng, các quy tắc liên quan đến thiết kế gây chú ý, v.v.
100% khả năng người đàn ông đó đang nói sự thật.

Hệ thống thiết kế có thể có dạng phức tạp hơn hoặc ít hơn tùy thuộc vào nhu cầu của công ty, từ đơn giản nhất (UI Kit & Style Guide) đến phức tạp nhất . Khi được triển khai và hoạt động, một hệ thống thiết kế sẽ cho phép công ty:

  • Giảm mạnh giao diện người dùng và nỗ lực và thời gian sản xuất front-end,
  • Giảm bớt áp lực lên giao diện người dùng để tập trung vào các vấn đề lớn hơn và phức tạp hơn,
  • Kết hợp hài hòa thiết kế các sản phẩm của công ty thông qua ngôn ngữ mạch lạc và dễ nhận dạng bởi người dùng,
  • Điều chỉnh các nhóm phát triển và sản phẩm theo một tầm nhìn chung,
  • Hỗ trợ trong việc giới thiệu các nhà thiết kế mới vào nhóm.

Vào năm 2015, khi tôi muốn tạo ra hệ thống thiết kế đầu tiên của mình, một trong những sai lầm đầu tiên tôi mắc phải là tạo ra nó một mình. Đó là cách tốt nhất để biến công việc của tôi trở nên vô ích. Sau đó, tôi kiệt sức khi cố gắng thuyết phục các nhà phát triển về giá trị của phương pháp này bằng cách áp đặt tầm nhìn của tôi về mọi thứ cho họ bất chấp bản thân tôi.
Ý kiến ​​tồi.

Hệ thống thiết kế là cầu nối giữa nhà thiết kế và nhà phát triển. Nếu nó chỉ được xây dựng bởi người này hay người kia, thì nó sẽ mất vai trò ràng buộc và trở thành một tài liệu áp đặt, bị hiểu nhầm và khó chấp nhận. Đây là lý do tại sao điều quan trọng là phải hợp tác xây dựng nó với các nhà phát triển để đảm bảo nó được chấp nhận.
Đó là một câu chuyện về sự cân bằng.

Minh họa của Adrien Coquet

Hãy tưởng tượng rằng chúng ta đang ở trong một nhóm sản phẩm cổ điển nhỏ (1 PM, 1 Designer, 3-4 Dev) , sau đó chúng ta sẽ phải bắt đầu dự án và thực hiện theo cặp với Nhà phát triển chính . Ưu điểm của bộ đôi này là chúng tôi nghĩ với cách tiếp cận kỹ thuật và thiết kế ngay từ đầu. Ngoài ra, bằng cách bao gồm một trưởng nhóm kỹ thuật, chúng tôi sẽ thu hút sự tham gia của toàn bộ nhóm phát triển trong quá trình này.

Nói về nền tảng, bây giờ cặp đôi có thể đồng ý về cơ sở, nghĩa là:

  • Kiến trúc: tùy thuộc vào ngăn xếp kỹ thuật được sử dụng (React, VueJS…), cần xác định kiến ​​trúc thành phần hợp lý nhất để sử dụng. Nó sẽ là theo gia đình, sử dụng, hay nguyên tử? Không có giải pháp chung nào nhưng chỉ có một giải pháp tốt: hiểu cách hoạt động của các công nghệ front-end để sắp xếp tổ chức của hệ thống thiết kế và logic của mã.
  • Nguyên tắc thiết kế: với các nhà phát triển, chúng tôi cũng xác định những giá trị nào sẽ cấu trúc phần còn lại của sự hợp tác. Trong trường hợp có xung đột về một thành phần hoặc sự khác biệt về mức độ ưu tiên, nguyên tắc nào sẽ phân xử cuộc thảo luận?
  • Quy ước đặt tên: điều cần thiết là phải sắp xếp mọi người về cách đặt tên của các phần tử vì đây là nơi bắt đầu tạo ra ngôn ngữ thiết kế / dev. Các thành phần sẽ được đặt tên trong camelCase, PascalCase hay kebab-case (vâng, nó là một thứ thật ) ? Tên của một thành phần (ví dụ: family-parent-child…) và của một biến được tạo thành là gì?
  • Công cụ: về điểm mạnh của tất cả những điều này, một điểm chuẩn nhỏ của hệ thống hiện có là điều cần thiết để xác định công cụ nào sẽ là công cụ tốt nhất để giải quyết ngữ cảnh của bạn. Ví dụ: tôi đã làm việc rất nhiều với các ngăn xếp ReactJS / NodeJS, vì vậy sự kết hợp hoàn hảo cho chúng tôi từ lâu là Figma - Zeroheight - Storybook .
    Nhưng có rất nhiều công cụ mà bạn sẽ tìm thấy trong các tài nguyên của tôi .

Cạm bẫy số 2 - “Chúng tôi không có thời gian!”

Vào năm 2017, khi tôi muốn tạo ra hệ thống thiết kế thứ hai của mình, tôi đã cùng các nhà phát triển tạo ra nó. Sự hợp tác thật tuyệt vời nhưng chúng tôi có rất ít thời gian và nguồn lực để xây dựng nó. Vì đã có một sản phẩm hiện có, chúng tôi muốn gấp rút mọi thứ ngay lập tức, nhưng điều đó khiến chúng tôi kiệt sức và sau đó chúng tôi gặp rất nhiều khó khăn trong việc cập nhật hệ thống thiết kế…
Ý tưởng tồi.

Hệ thống thiết kế là một sản phẩm theo đúng nghĩa của nó, và giống như bất kỳ sản phẩm nào, nó có lộ trình riêng. Có nghĩa là, một khi việc đóng khung trước đó đã được thực hiện với đội ngũ kỹ thuật, thì nhất thiết phải có giám đốc sản phẩm. Mục tiêu ở giai đoạn này là giảm thiểu rủi ro tắc nghẽn nhanh chóng tiết kiệm thời gian thực hiện hệ thống thiết kế:

  • Bằng cách chia dự án thành nhiều lần lặp lại. Sự phân chia sẽ phụ thuộc rất nhiều vào cách bạn sắp xếp thứ tự ưu tiên cho các chủ đề. Đối với điều này, mỗi nhóm sản phẩm có công thức của nó. Tuy nhiên, vẫn rất thú vị khi tự hỏi bản thân rằng liệu chia theo thành phần, theo trang, theo đường dẫn có tốt hơn không? Hay để làm theo nhu cầu của lộ trình sản phẩm?
  • Bằng cách tự động hóa các thay đổi. Một số công cụ như Zeroheight cung cấp “ mã thông báo thiết kế ”, tức là các khóa mà nhà phát triển có thể sử dụng để tự động liên kết cơ sở mã và hệ thống thiết kế. Bạn cũng có thể thiết lập phiên bản cho hệ thống thiết kế của mình để tránh xung đột hợp nhất, đặc biệt nếu bạn làm việc với nhiều nhà thiết kế, bằng các công cụ như Abstract , Kactus hoặc plugin Github này .
  • Số lần lặp càng nhiều, càng có ít thành phần để thực hiện.

Vào năm 2020, khi tôi muốn tạo ra hệ thống thiết kế thứ ba của mình, tôi đã tạo ra nó với các nhà phát triển và bằng cách lặp lại. Mọi thứ đang diễn ra rất tốt nhưng nó nhanh chóng trở nên rất phức tạp đối với tôi khi sửa đổi / loại bỏ các thành phần, bởi vì khi nó phát triển, hệ thống thiết kế trở nên cứng nhắc đến mức thay đổi nhỏ nhất cũng bị khóa…
Ý tưởng tồi.

Hệ thống thiết kế là một tài liệu sống động và phát triển. Hãy quên rằng trong thế giới của công việc, các thương hiệu, tổ chức và bối cảnh không ngừng phát triển, coi đó như một định luật được viết ra bằng đá. Để được đưa vào thế giới đang thay đổi này, hệ thống thiết kế phải có khả năng thích ứng:

  • Bằng cách cho phép bản thân thất bại. Nếu một thành phần phản hồi một vấn đề tại một thời điểm nhất định, điều đó không có nghĩa là nó sẽ luôn phản hồi nó. Đây có lẽ là điều khó nhất để học, nhưng cho phép bản thân thất bại là cho phép bản thân học hỏi.
  • Bằng cách tạo ra các quy trình đơn giản và linh hoạt. Chỉ nên có các nhà phát triển, nhà thiết kế và người quản lý sản phẩm tham gia. Một ý tưởng sẽ là thử nghiệm beta các thành phần nhất định trong quá trình kiểm tra người dùng của bạn, một ý tưởng khác là xử lý các thay đổi thành phần dưới dạng sửa lỗi. Điều quan trọng là phải thử nghiệm các phương pháp trước khi quyết định phương pháp nào phù hợp với bạn nhất.

Nếu bạn thích bài viết này, đừng ngần ngại ủng hộ và chia sẻ nội dung này

Yeita

Để biết thêm…

Tất cả các tài nguyên dưới đây là miễn phí và có thể chia sẻ, hãy tự xử lý ♥ ️

© Copyright 2021 - 2022 | vngogo.com | All Rights Reserved