Nhà thiết kế sản phẩm và nhà phát triển không luôn hòa hợp — đây là cách họ cùng làm việc với nhau

Hãy tưởng tượng bạn đang chịu trách nhiệm triển khai một ứng dụng hiển thị những quán cà phê sang trọng trong thành phố của bạn. Dave, nhà thiết kế sản phẩm của bạn, đã tạo ra một bản vẽ dây đẹp mắt và anh ấy muốn mẫu nguyên bản sẽ sẵn sàng trong vòng ba tuần.

Bạn biết cách Dave hoạt động, và bạn biết cách loại yêu cầu này thường kết thúc. Với một lịch trình chặt chẽ và một số hướng dẫn mơ hồ để thực hiện, bạn chắc chắn sẽ không impression anh ấy. Nhưng hé, đây là công việc của bạn, vì vậy bạn vẫn cố gắng hết mình.

Ba tuần sau, bạn quay lại với Dave với mẫu nguyên bản đã hoàn thành.

Và anh ấy tức giận.

Theo ý kiến của anh ấy, bạn hoàn toàn phớt lờ hướng dẫn của đội anh ấy. Bạn không triển khai đúng pixel họ chỉ định, bạn không làm đúng các gam màu, và — ôi — tất cả các hiệu ứng đặc biệt đâu rồi?

Bây giờ bạn tức giận với Dave và đội của anh ấy nữa. Trong suốt ba tuần đó, họ hoàn toàn không liên lạc với bạn.

Và bây giờ, sau những tuần bạn dồn sức đẩy để đưa ra mẫu nguyên bản đúng hẹn, tất cả Dave muốn thấy là quản lý của bạn để anh ấy có người tốt hơn để la mắng.

Làm thế nào sự căng thẳng và mối quan hệ xấu xuất hiện

Là một nhà phát triển, bạn làm hết sức mình để tránh xung đột, và như những nhà thiết kế sản phẩm như Dave cũng vậy. Tại sao, vậy thì, những tình huống không thoải mái như vậy vẫn xảy ra?
Một số nhà thiết kế sản phẩm muốn tất cả sản phẩm chi tiết và phức tạp của họ đã sẵn sàng từ hôm qua.

Điều đó không phải vì họ là những người xấu tính.

Những nhà thiết kế như vậy thường thiếu kiến thức kỹ thuật về tất cả các framework và công sức vào phần backend. Để biến một mẫu nguyên bản thành sản phẩm hoạt động, cần nhiều hơn chỉ là một chút ma thuật.

Cũng có những nhà phát triển không hiểu công sức mà nhà thiết kế đặt vào công việc, tuy nhiên. Họ sẽ làm lỏng lẻo với các chi tiết thiết kế như sự sắp xếp hoặc lựa chọn font, rồi đổ lỗi cho nhà thiết kế vì làm cho sản phẩm trông tệ.

Nếu mọi thứ hoàn toàn sai lầm, nhà thiết kế sẽ chấp nhận sản phẩm tệ như vậy để tránh xung đột. Bạn có thể tưởng tượng phản ứng của chủ sở hữu sản phẩm khi họ nhìn thấy kết quả xấu xí từ ý tưởng đẹp của họ.

Một số nhà phát triển, đặc biệt là những người vẫn còn non nớt kinh nghiệm, cũng đưa ra các lựa chọn kỹ thuật kém chất lượng làm cho việc cập nhật thiết kế trở nên khó khăn. Điều này có thể không thể hiện ngay lập tức, nhưng sau ba năm, mọi người sẽ bị thất vọng. Nợ kỹ thuật là một con quái vật, và sự thiếu kinh nghiệm của một kỹ sư khiến nó tăng gấp mười lần nhanh chóng hơn.

Nhà thiết kế không kinh nghiệm cũng có thể là một tai họa.

Nếu họ không xem xét cẩn thận cách thiết kế của họ mở rộng và thực hiện trong dài hạn, có rất ít nhà phát triển có thể làm để sửa chữa lỗi của họ. Điều này liên quan lại đến sự thiếu kiến thức kỹ thuật của một số nhà thiết kế. Tất nhiên, họ không cần phải biết mọi thứ về kỹ thuật phần mềm — điều đó sẽ khiến nhà phát triển trở nên lạc hậu — nhưng một chút hiểu biết cũng giúp nhà thiết kế truyền đạt ý tưởng của họ một cách chi tiết hơn.

Một nắp cửa wireframe, dù đẹp đẽ nhưng không thể thay thế được giá trị của một mẫu nguyên bản chi tiết, linh hoạt và được tạo ra với những công nghệ cơ bản và những thách thức của chúng trong tâm trí.

Moral của câu chuyện là: Có vô số cách để làm phật lòng một nhà thiết kế nếu bạn là một nhà phát triển. Và nếu bạn là một nhà thiết kế, có nhiều cách như số lượng cá trong biển để khiến một nhà phát triển nổi giận.

Về cơ bản, nó thuộc về điều này: Nhà thiết kế và nhà phát triển nói những ngôn ngữ khác nhau.

Nhà thiết kế nói từ hướng của người dùng. Họ biết chính xác sản phẩm nên trông như thế nào, cảm nhận như thế nào và ứng xử như thế nào. Nhưng họ không biết cách thực hiện điều đó. Ngược lại, nhà phát triển biết về tất cả các công nghệ để xây dựng thứ gì đó. Oke, không phải tất cả. Nhưng ít nhất là một số. Nhà phát triển nói bằng code. Nhưng nhà phát triển không thể thành công một mình vì họ không nói được ngôn ngữ của người dùng.

Làm thế nào để ngăn nhà phát triển và nhà thiết kế không bị lạc lõng trong dịch thuật

Có lẽ nên thuê một người phiên dịch? Đừng lo, điều đó sẽ không cần thiết.

Ở một số công ty — những công ty cổ điển vẫn làm việc trực tiếp ít nhất — nhà thiết kế sản phẩm và nhà phát triển ngồi cùng một bàn. Điều này giúp rất nhiều vì cả hai đội có thể nhìn thấy nhau làm việc trực tiếp và học cách đánh giá những thách thức khác nhau mà họ đối mặt.

Ngoài ra, điều này làm tối đa hóa các cuộc trò chuyện qua vai và giảm thiểu nhu cầu cho những cuộc họp chính thức, rườm rà và tốn thời gian với tất cả mọi người. Nếu nhà thiết kế sản phẩm Dave không chắc chắn liệu một tính năng có khả thi kỹ thuật hay không, anh ấy có thể nhanh chóng hỏi một nhà phát triển.

Tương tự, nếu một nhà phát triển có câu hỏi về tại sao một tính năng cụ thể là cần thiết, họ có thể nhanh chóng gọi một nhà thiết kế có trách nhiệm. Điều này cũng áp dụng khi làm việc từ xa. Để làm cho các cuộc thảo luận không chính thức hiệu quả hơn, một số công ty ghép mỗi nhà thiết kế với một nhà phát triển. Cả hai có thể thảo luận bất cứ điều gì họ muốn. Loại động lực không chính thức này giải quyết vấn đề trước khi nó xảy ra.

Nếu việc ghép các nhà phát triển và nhà thiết kế không phải là một lựa chọn và làm cho cả hai đội làm việc ở cùng một bàn là không thể, lên kế hoạch kiểm tra định kỳ có thể hoạt động. Điều này mang lại cơ hội cho nhà phát triển để xem xét thiết kế và nhà thiết kế để đưa ra phản hồi về cách phát triển đang diễn ra.

Lên kế hoạch cho các cuộc họp đều đặn (và thường là dài) làm giảm thời gian sản xuất không phải là sở thích của tất cả mọi người. Nếu các đội có thể tổ chức những cuộc họp như vậy một cách thoải mái, không có gì cản trở. Nhưng sự thành công của những cuộc họp như vậy phụ thuộc nhiều vào các đội và văn hóa tổng thể của công ty.

Cuối cùng, nhà phát triển và nhà thiết kế nên học một chút về nghệ thuật của nhau. Điều này có nghĩa là nhà phát triển có thể muốn đăng ký khóa học thiết kế phần mềm. Nhà thiết kế có thể muốn tìm hiểu thêm về kiến trúc phần mềm và ngôn ngữ lập trình mà nhà phát triển đang sử dụng trong đội. Nhà thiết kế và nhà phát triển nói những ngôn ngữ khác nhau. Nhưng nếu họ giữ gần nhau đủ, họ bắt đầu hiểu nhau.

Công cụ phần mềm để nối những khoảng trống

Đối với nhà phát triển, việc nhận một bản vẽ wireframe nhỏ cho một dự án phức tạp và phải viết mã tất cả các chi tiết từ đầu sẽ mất nhiều hơn một ca làm việc qua đêm. Đối với nhà thiết kế, việc tưởng tượng mã máy tính trong công việc hàng ngày là một thách thức. May mắn thay, có các công cụ phần mềm cứu hộ.

Anima
Anima là một nền tảng thiết kế thành mã nơi mà nhà thiết kế (và nhà phát triển!) có thể phát triển mẫu và xuất mã thân thiện với nhà phát triển cuối quá trình. Đối với nhà phát triển, mã này có sẵn trong các framework phổ biến như React, vue.js và html. Ngoài ra, nhà thiết kế có thể làm cho mẫu của họ sống động hơn so với các công cụ thiết kế truyền thống hơn vì họ có thể thêm các hiệu ứng tương tác như hiệu ứng hover, animation đầu vào, GIF và nhiều hơn nữa.

Framer X
Framer tích hợp với Figma và, giống như Anima, giúp nhà thiết kế làm cho các yếu tố tĩnh trở nên sống động và động. Nói về điều đó, Anima cũng tích hợp với Figma. Cho dù bạn sử dụng một cái hay cái kia thực sự phụ thuộc vào sở thích cá nhân của bạn.

Handoff, Visly, Modulz, và nhiều hơn nữa
Còn rất nhiều công cụ thiết kế khác nhau có thể chuyển đổi mẫu thành mã. Tuy nhiên, hầu hết chúng đều có một vấn đề: Chúng không giải quyết phần động của mẫu như Anima và Framer. Điều này để lại nhiều điều cho trí tưởng tượng của nhà phát triển đang kiểm soát. Nói cách khác, nó để lại nhiều tiềm năng xung đột trên bàn làm việc.

Tuy nhiên, sức mạnh của công cụ phần mềm có giới hạn. Chúng có thể giúp đỡ, nhưng không thể giải quyết tất cả những sự ma sát nảy sinh giữa con người.

Mục tiêu cuối cùng: Công cụ tốt, những người tốt, văn hóa tốt

Cuối ngày, chúng ta đều mong muốn có các đội ngũ hạnh phúc, năng suất mang đến sản phẩm chất lượng cao và mang lại giá trị cho khách hàng. Nhưng điều này chỉ hoạt động nếu các đội tốt trong việc giao tiếp với nhau, có các công cụ phù hợp để làm việc và được tích hợp trong văn hóa công ty tốt.

Âm nhạc này nghe có vẻ tẻ nhạt, tôi biết.

Nhưng quá nhiều nhà thiết kế sản phẩm và nhà phát triển có câu chuyện kinh dị để kể. Sự không đồng nhất là phổ biến vì các đội nói bằng những ngôn ngữ khác nhau và hoạt động từ các quan điểm khác nhau. Cả hai ngôn ngữ và quan điểm đều cần thiết. Để làm cho chúng hoạt động cùng nhau, họ cần tham gia vào quy trình của nhau. Chỉ khi đó họ mới có thể bắt đầu hiểu nhau.

Thiết kế và phát triển phần mềm hiếm khi có thể được thực hiện bởi một đội duy nhất. Nếu thế giới này không hiểu điều đó, đó không phải là vấn đề của bạn. Nhưng có lẽ bạn sẽ muốn nói chuyện với quản lý của anh ấy trước khi anh ấy nói chuyện với bạn.

Bài viết này được viết bởi Ari Joury  và được xuất bản ban đầu trên UX Collective. Bạn có thể đọc nó tại đây. Cảm ơn đặc biệt Ofir Sever đã đề xuất ý tưởng cho câu chuyện này.