Có một số lượng lớn các bài viết hướng dẫn cách các nhà thiết kế có thể nói không . Điều này chủ yếu là về các dịch giả tự do và cách tương tác với những khách hàng khó tính. Ngoài ra còn có các bài viết về các mẹo để đối phó với Người quản lý sản phẩm. Tuy nhiên, còn khi bạn đang hỗ trợ Hệ thống thiết kế thì sao? Phải làm gì với các yêu cầu xung đột từ các nhà thiết kế hoặc nhà phát triển khác.

Tôi không biết mình đang làm gì nữa…

Nếu bạn không phải là một chuyên gia và bạn chỉ mới bắt đầu tạo một hệ thống thiết kế cho công ty của mình từ đầu, bạn có thể không biết nên đi theo hướng nào. Tất nhiên, bạn có thể đọc một số bài báo có công thức về cách bắt đầu , nhưng đôi khi không có gì tốt hơn kinh nghiệm cá nhân. Thử một cái gì đó, đôi khi phạm sai lầm và học hỏi từ những sai lầm. Cởi mở với những điều mới. Hãy là một người “Vâng, hãy thử”.

Bạn phải linh hoạt nhất có thể trong tình huống như vậy. Tuy nhiên, hãy ghi lại các quyết định của bạn nếu bạn không muốn những quyết định thành công vẫn là “ma thuật đen” và những quyết định không thành công sẽ tồn tại như một sự trùng hợp không xác định.

Ý tôi không chỉ là viết ra quyết định mà còn là cách bạn (hoặc những người khác) đạt được điều đó. Lập luận, v.v. Vâng, điều này đôi khi có thể khó khăn. Đặc biệt là khi quyết định mang tính trực giác (linh cảm). Tuy nhiên, nếu bạn học cách đặt câu hỏi cho bản thân và những người khác, cuối cùng bạn có thể bắt đầu hiểu được nguồn gốc của ý tưởng.

Những tài liệu như vậy sẽ cho phép bạn hiểu thêm về mối quan hệ nhân quả và tìm hiểu điều gì hiệu quả và điều gì không. Và lần tới nếu bạn thấy rằng một đề xuất mới phù hợp với một khuôn mẫu đã biết (hoặc đi theo cùng một hướng) - bạn sẽ có thể chỉ ra điều này cho những người khác. Đó là, bạn sẽ học cách đưa ra những lý do hợp lý chống lại các giải pháp rủi ro.

Tôi đã nhìn thấy điều này ở đâu đó trước đây…

Bạn luôn có thể hỏi cộng đồng về các ví dụ khi đưa ra các quyết định tồi tệ . Các nhà thiết kế (và nhiều ngành nghề khác) muốn lập danh sách những việc không nên làm .

Có một phần lớn các bài báo trong danh mục “ 10 quyết định thiết kế tồi tệ nhất ” và những thứ tương tự. Tuy nhiên, liên quan đến các hệ thống thiết kế, điều quan trọng nhất sẽ là các mô tả về các thực hành “Tốt/Xấu”, “Các mẫu”, “Nên & Không nên”, v.v. Và tốt nhất là tìm kiếm chúng trong tài liệu của các hệ thống thiết kế mở.

Thông thường những tài liệu như vậy cung cấp những lập luận ngắn gọn nhưng súc tích ủng hộ hoặc phản đối một giải pháp cụ thể, và chúng có thể giúp ích rất nhiều cho việc phân tích các tình huống phát sinh trong hệ thống của bạn. Và ngay cả trong công việc thiết kế hàng ngày của bạn.

“Những điều nên làm và không nên làm” là yếu tố chính của bất kỳ tài liệu thiết kế hệ thống nào và bạn càng bắt đầu ghi lại những thực hành “Tốt/Xấu” cho hệ thống của mình càng sớm thì bạn càng có thể tránh được nhiều câu hỏi và hiểu lầm.

“ Nếu nó không được ghi lại, nó không tồn tại ”

Các tài liệu là một cam kết. Nhưng cũng có hướng dẫn về “tôi có thể/nên làm gì”. Rốt cuộc, các nhà thiết kế thường đưa ra những quyết định đáng ngờ bởi vì họ không nhận thức được điều gì nên và không nên làm trong hệ thống thiết kế. Trong trường hợp không có nó, tuyên bố “mọi thứ đều có thể xảy ra” là một suy nghĩ hợp lý.

Nhưng ở đây, điều quan trọng cần nhấn mạnh: tài liệu không phải là về các lệnh cấm. Tài liệu được thiết kế để giải thích cách thức hoạt động của hệ thống và chỉ ra một cách hợp lý điều gì đáng làm và điều gì không. Theo đó, nếu nhà thiết kế (hoặc nhà phát triển) chỉ bị thúc đẩy bởi “Tôi thích nó theo cách này” và nó mâu thuẫn với tài liệu — thì bạn có lý do hợp lý và chính đáng để từ chối, tham khảo tài liệu.

Tài liệu giúp thiết lập một ví dụ tốt cho những người khác để tranh luận về ý tưởng của họ. Và biến ý tưởng thành giải pháp sẽ giúp đưa hệ thống thiết kế của bạn lên một tầm cao mới.

Thư viện thiết kế ≠ Hệ thống thiết kế

Các vấn đề thường phát sinh khi người dùng (hoặc người đóng góp) không hiểu hệ thống thiết kế là gì và coi nó như một thư viện thiết kế. Nhiều nhà thiết kế đã quen với việc xử lý các thư viện thiết kế có sẵn và phải sửa đổi chúng cho phù hợp với nhu cầu của họ.

“Tôi thích UI-Kit này, nhưng nó được tạo ra mà không có bất kỳ cân nhắc nào cho các trường hợp sử dụng của tôi và vì vậy tôi cần tùy chỉnh nó”. Nghe có vẻ khá hợp lý phải không? Có, nếu chúng ta đang nói về các giải pháp của bên thứ ba mà bạn (hoặc người khác) sẽ chỉ sử dụng một phần nhỏ. Nhưng trong trường hợp hệ thống thiết kế nội bộ, điều này có thể dẫn đến sự hỗn loạn.

Một cái gì đó tương tự như thế này, nhưng hơi khác một chút….

Theo tôi, khó nhất là khi người dùng yêu cầu những thay đổi nhỏ. Những thay đổi khá nhỏ:

• Thêm khả năng sử dụng các biểu tượng trong tiêu đề.
• Thay đổi thứ tự các khối trong danh sách.
• Hiển thị 3 nút thay vì 2 (được xác định bởi một thành phần).

• Tính nhất quán của cách tiếp cận với các thành phần khác.
• Sự phức tạp của việc triển khai mã và các thành phần thiết kế (Figma, Sketch, v.v.).

Trước tiên, bạn cần tìm hiểu xem mẫu có giao nhau với một số thành phần khác hay không. Để làm điều này, bạn cần phải thuộc lòng tất cả các thành phần và hành vi của chúng hoặc xem qua từng thành phần và xem liệu đề xuất có xung đột với bất kỳ thành phần nào khác không. Nếu có những xung đột nhỏ nhất, cần phải thảo luận về đề xuất không phải trong sự cô lập, mà trong bối cảnh hành vi của một số thành phần. Điều này thường có thể yêu cầu mời nhiều người hơn vào cuộc thảo luận.

Sự phức tạp của việc thực hiện

Rất thường xuyên, những gì trông giống như một giải pháp đơn giản trong thiết kế có thể đòi hỏi nỗ lực rất lớn trong quá trình phát triển. Có lẽ do kiến ​​trúc hiện tại không đủ linh hoạt. Có lẽ nó chỉ đi ngược lại các tiêu chuẩn/phương pháp cơ bản được sử dụng trong quá trình phát triển. Về mặt lý thuyết, hầu hết mọi thứ đều có thể, nhưng một số thứ sẽ đòi hỏi nhiều nỗ lực hơn. Trong tình huống như vậy, bạn có thể cần hiểu tầm quan trọng của những thay đổi này: “Rất vui được có” hoặc “nhu cầu cấp bách”.

Chúng tôi là đầy tớ, không phải độc tài

Hệ thống thiết kế là một sản phẩm . Nhưng nó là một cái rất cụ thể. Mặc dù sự thành công của phần lớn các sản phẩm có thể được đo lường bằng số tiền chúng kiếm được, nhưng đối với một hệ thống thiết kế, chỉ số chính là có bao nhiêu người dùng sử dụng nó và nó giúp cuộc sống của họ dễ dàng hơn bao nhiêu. Nói cách khác, một hệ thống thiết kế là “Sản phẩm trung thực nhất” . Và điều đó đòi hỏi rất nhiều trách nhiệm. Chúng ta không chỉ cần làm tốt nhất những gì khách hàng muốn, mà còn giúp họ hiểu hậu quả của mỗi quyết định đáng ngờ:

• thiếu linh hoạt trong triển vọng
• sự chậm trễ trong phát triển giải pháp (do sự phức tạp của giải pháp và bảo trì của nó)
• nhu cầu thay đổi theo tầng đối với các thành phần hoặc thỏa thuận khác
Đóng góp hệ thống quản lý thiết kế

Cuối cùng, hệ thống thiết kế là về người dùng (nhà thiết kế và nhà phát triển). Vì vậy, bạn phải rất chú ý đến họ. Rốt cuộc, không có họ, chúng ta chẳng là ai cả. Và nếu các chỉnh sửa hợp lý và không vi phạm bất cứ điều gì — tại sao không thực hiện chúng?

Tất cả những lý do để nói “không” chỉ nhằm đảm bảo rằng chúng tôi tạo ra sản phẩm mà người dùng cần chứ không phải sản phẩm họ muốn.

Khi được hỏi về ý kiến ​​đóng góp của khách hàng trong quá trình phát triển Ford Model T, Henry Ford đã có một câu nói nổi tiếng: “Nếu tôi hỏi mọi người họ muốn gì, họ sẽ nói những con ngựa chạy nhanh hơn.”

Cảm ơn vì đã đọc! Hãy giữ liên lạc! Kết nối với tôi trên LinkedIn và theo dõi tôi trên Dribbble và tại đây trên Medium để biết thêm nội dung liên quan đến thiết kế.