UX/UI Design cần kỹ năng nào? Vai trò của designer trong công ty
UX kỳ vọng đưa ra giải pháp sáng tạo, UI kỳ vọng về giao diện người dùng. Tuy nhiên giao diện người dùng là cái chạm vào người dùng nhiều nhất, thế nên UX thể nào cũng phải đi qua UI thì mới đến được tới người dùng không thì chỉ dừng lại ở vài suy nghĩ, vài ý tưởng về concept.
Trong chuyên mục “Chuyên gia nói” hôm nay, cùng TopDev trò chuyện với anh Lê Anh Quang, hiện đang đảm nhận khâu UX/UI tại Be Group, để hiểu hơn sự khác nhau trong vai trò của UX/UI trong tổ chức, liệu rằng product có thật sự đối ngược với designer? Và cùng tranh luận rằng “thế nào là copy và có phải copy là luôn sai?”.
* Chào anh Quang, xin hãy giới thiệu đôi chút về bản thân mình.
Tôi là Quang, hiện tại đang là Head of UX/UI tại Be Group, hiện tại có 1 sản phẩm đang chạy trên thị trường là ứng dụng gọi xe Be. Rất cảm ơn TopDev đã mời tôi tham gia vào chuyên mục ngày hôm nay, hi vọng những chia sẻ của tôi sẽ giúp các bạn có thêm những cái góc nhìn, có cái trả lời của những cái thắc mắc về lĩnh vực UX/UI và sản phẩm.
* Đảm nhiệm vị trí Head of UI/UX | Be Group thì công việc hằng ngày của anh như thế nào? Anh có thể chia sẻ đến mọi người các task của 1 Head ở tập đoàn lớn không?
Thật ra công việc của tôi mang tính định hướng, quản lý nhiều hơn. Về day tool, day work sẽ thiên về những việc tôi cập nhật thông tin cho các bạn. Hằng ngày tôi sẽ có daily meeting với cả team của Be, để nắm tình hình, biết được vấn đề đang nằm ở đâu và là vấn đề gì. Hơn nữa, các bạn phải chủ động công việc của mình, thay vì giao việc để các bạn làm thì các bạn biết sẽ phải làm gì.
* Với sự chủ động như vậy thì anh đo lường năng suất và hiệu quả công việc như thế nào?
Be đo lường thông qua kết quả chứ không đo lường giờ làm. Trong quá trình làm tôi sẽ áp dụng những protocol làm việc, giống như là mọi người sẽ có những đầu việc phải làm trong mỗi ngày. Lúc đó tôi sẽ dùng Jira để quản lý việc đấy. Khi mọi người bắt đầu làm một công việc nào đấy thì bắt đầu đưa vào để cùng thảo luận, tức là người đảm nhận chính công việc nào (gọi là person in charge) thì họ phải làm không bàn cãi, thế nhưng khi cả team cùng support (hỗ trợ) để làm thì tôi cũng ở trong cái việc support ấy cả ngày. Lúc đấy mọi người sẽ cùng biết được là khó khăn ở đâu, đang gặp vấn đề gì, tiến độ tới đâu, quality tới đâu. Toàn bộ công việc trên thì tôi là người observe.
* Có bao giờ anh cho rằng thiết kế UX đang kìm hãm sự sáng tạo của mình? Tức là mình phải chọn giữa cái đẹp và cái tiện dụng?
Đây thực ra là câu hỏi tranh cãi thôi, nhưng cuối cùng thì mình phải trả lời câu hỏi: Làm cái đấy để đạt cái mục đích gì? Đâu là cái quan trọng nhất? để mọi người thống nhất với nhau, nếu không sẽ có những quan điểm khác nhau. Khi sản phẩm sinh ra đẹp để phục vụ những cái mục tiêu kinh doanh thì nên chọn đẹp, còn nếu tiện tốt cho mục tiêu kinh doanh thì chọn tiện. Cuối cùng, khách hàng hay những đối tác là người trả tiền cho mình, nên họ là người quyết định thôi. Còn cái đẹp hay tiện nó chỉ là cái phương tiện, công cụ để mình hướng tới.
* Công cụ phân tích và KPIs nào để anh sử dụng nâng cao chất lượng thiết kế của mình hay của team? Và có thách thức gì không khi mà mình phải làm việc từ xa như vậy?
Bọn tôi gặp thường xuyên. Để đo lường 1 cách hiệu quả, bạn cần phải có những bộ matrix đầy đủ và thu thập dữ liệu đầy đủ. Tuy nhiên vấn để ở chỗ để thu thập dữ liệu đầy đủ cần phải tốn thời gian triển khai nhất định, và việc đó sẽ làm chậm thời gian ra mắt thị trường của 1 tính năng/ sản phẩm. Lúc này phải đánh đổi ở mức độ là từ từ thay đổi dần để phù hợp, hoặc từ từ tìm cách để đo lường trực tiếp hay gián tiếp, để biết được là KPI, hiệu quả tới đâu. Còn nếu cứ nhất thiết, cứng nhắc là tôi phải đầy đủ hết trước khi cho ra mắt thì sẽ bị mất rất nhiều cơ hội.
* Anh nghĩ sao về quan điểm “UX Designer không cần tới khả năng đồ họa nhưng phải có kỹ năng giải quyết vấn để sáng tạo (creative problem solving)”?
Thực ra cũng vừa đúng vừa sai, bởi vì outcome của công việc UX design được gọi là giải pháp sáng tạo. Tuy nhiên thực ra là cái giải pháp sáng tạo đấy, nó muốn được visual line, bạn cũng cần kỹ năng đồ họa nhất định, tùy theo tình huống vào team. Nếu thế mạnh của bạn không phải là đồ họa, bạn chỉ việc làm sao phác thảo được ý tưởng, rồi sẽ có 1 bạn đồ họa giúp bạn chuyện tiếp theo.
Tuy nhiên, đôi khi ý của bạn là 1 và của bạn đồ họa kia là 2, thành ra sẽ bị chênh nhau, nên tốt nhất là bạn nên tự đảm nhiệm 2 vị trí. Tuy nhiên để làm được cả 2 việc không dễ, mình cũng nên liệu cơm gắp mắm thôi. Có công ty thì chỉ có 1 vị trí, đơn giản là UX/UI designer, thì bạn vừa phải đưa ra giải pháp sáng tạo, đồng thời bạn cũng có khả năng đưa ra UI design cuối cùng. Chứ không thì dừng lại ở việc giao 1 cái wireframe, 1 cái giải pháp vấn đề sáng tạo và những cái gạch đầu dòng thôi, và những cái gạch đầu dòng ấy đến bản design thì lại bước qua 1 công đoạn nữa. Thí dụ như team có đông người thì có thể làm được việc này, vị trí UX design thường sẽ xuất hiện từ những công ty có nhiều người. Còn những công ty startup thì nên vẫn có những người bạn đa năng nhiều hơn để tiết kiệm headcount, làm những công chuyện khác quan trọng hơn.
* Hiện tại mọi người thường hay đánh đồng 2 chức vụ UX/ Product designer và UI/ Graphic designer là như nhau, anh có phân biệt gì về chức năng của hai vị trí này?
Kết quả đầu ra của 2 người này là khác nhau. UX kỳ vọng đưa ra giải pháp sáng tạo, UI kỳ vọng về giao diện người dùng; mục tiêu theo đuổi của 2 người này cũng khác nhau. Nhưng về hữu hình: giao diện người dùng là cái chạm vào người dùng nhiều nhất, thế nên UX thể nào cũng phải đi qua UI thì mới đến được tới người dùng, không thì chỉ dừng lại ở vài suy nghĩ, vài ý tưởng về concept thôi. Đây là cách phân biệt 2 loại và trong 1 số team thì kết hợp cả 2 vào 1 vị trí cũng được.
* Trong khi mỗi ngành trong lĩnh vực UX/UI có khác nhau đôi chút, nhưng theo anh đâu là những kỹ năng và tố chất cần thiết nhất của người làm trong ngành này?
Cần thiết nhất là kỹ năng lắng nghe, vì outcome công việc UX design là đưa ra giải pháp cho 1 vấn đề, nếu sáng tạo thì càng tốt. Tuy nhiên để đưa ra giải pháp thì phải biết vấn đề nằm ở đâu. Phải chịu khó lắng nghe từ những bộ phận khác, từ phía người dùng, những nguồn thông tin khác nhau để xem vấn đề nằm ở đâu.
Đến phần đưa ra giải pháp, UX design chưa phải là người thông minh nhất, đưa giải pháp tốt nhất. Đôi khi những người vận hành, những người tiếp xúc với khách hàng thường xuyên, hay engineer lại là người đưa ra giải pháp tốt nhất. Thế nên kỹ năng lắng nghe rất quan trọng với người làm UX, lắng nghe nhiều sẽ giúp chúng ta có nhiều giải pháp hơn, hơn là cái việc mình nghĩ mình là người giỏi nhất, là người thông minh nhất, tất cả mọi người phải đi theo phương án của mình.
* Nhắc đến UX/UI thì mọi người sẽ nghĩ ngay đến người dùng, và nhắc đến người dùng thì sẽ có khái niệm về “Design thinking”. Anh nghĩ gì về cụm từ trên? Nó có ý nghĩa như thế nào với anh? Và anh vận dụng chúng như thế nào trong công việc?
Design thinking hay framework, thật ra là mình học cách suy nghĩ thôi. Ví dụ bắt đầu từ định nghĩa vấn đề, sau đó là xác định người dùng, v.v..., tiếp theo là đưa ra giải pháp, kiểm thử giải pháp ấy xem có phù hợp không. Translate 1 quy trình gồm 2 phần, đầu tiên là đưa ra giải pháp và thứ 2 là tìm thử giải pháp ấy.
Để 1 sản phẩm/ tính năng ra đời thì cần rất nhiều yếu tố, dev được, vận hành được rồi mới tới người dùng được.
Đưa ra giải pháp bắt đầu bằng “làm cho ai?”, cái thứ 2 là “để phục vụ mục đích gì?” và giống như thông tin ban đầu, thứ 3 là “làm trong hoàn cảnh như thế nào?” (hoàn cảnh này giúp cho mình nắm được vấn đề về thông tin xoay quanh); sau đấy mới đi tìm các giải pháp xung quanh để giải quyết vấn đề trong mục đích tới.
Sau thời gian tìm giải pháp rồi thì tiến hành tra giải pháp này có phù hợp hay không. Phù hợp ở đây nó có rất nhiều yếu tố. Bạn đưa ra giải pháp mà người vận hành họ không vận hành được, theo cái cách mà bạn đưa ra thì đấy là những cái mà mình đi kiểm thử trước, trước khi mình ra cho người dùng sử dụng. Tại vì để 1 sản phẩm/ tính năng ra đời thì cần rất nhiều yếu tố, dev được, vận hành được rồi mới tới người dùng được.
* UX/UI là 1 ngành nghề rất sinh động, kể cả Designer hay Developer cũng có thể phát triển thêm kỹ năng hoặc định hướng hẳn sang ngành này, vậy theo anh career path thích hợp nhất cho các đối tượng trên là gì? Đối với những người xuất phát điểm từ con số 0 thì sao?
Nó cũng xoay quanh 2 kỹ năng, là lắng nghe và thứ 2 tạm gọi là phân tích. Để có 1 con đường thì nó sẽ xuất phát từ xuất phát điểm ở đâu và đích đến là ở đâu. Đích đến của UX designer và UI designer là khác nhau. UI đưa ra giao diện thân thiện người dùng, tạm gọi là chế độ thân thiện người dùng, dễ hiểu dễ sử dụng, rồi đến giao diện đẹp đẽ hấp dẫn, còn UX thì bước cuối cùng là đưa ra 1 giải pháp trong vấn đề nào đấy, 2 đích đến khác nhau.
Và bắt đầu thì UI cần kỹ năng về thiết kế giao diện người dùng, đồ họa, cần phải sử dụng kỹ năng thành thạo phần mềm thiết kế, 2 là cũng phải phần nào đấy hiểu được người dùng, cách họ sử dụng, tương tác. Giả sử mình đang là 1 người về graphic design, kỹ năng mình có là sử dụng phần mềm thiết kế, lại bị thiếu cái việc là hiểu người dùng: họ sử dụng 1 ứng dụng như thế nào, các bước họ sử dụng, tương tác của họ với sản phẩm ra sao, lúc đấy thì cần bổ sung cái đó.
Với 1 bạn developer thì bạn ấy lại không có kỹ năng sử dụng phần mềm thiết kế, bạn ấy cũng không hoàn toàn hiểu người dùng. Thí dụ trong cuộc sống, cùng hoàn cảnh thì bạn cũng là 1 người dùng thường xuyên, bạn làm 1 sản phẩm thiết kế UI cho 1 ID, 1 công cụ lập trình chẳng hạn, thì bạn cũng sẽ hiểu người dùng phần nào, tuy nhiên đa số các trường hợp thì bạn không phải là người sử dụng, nên bạn phải học cả 2, học về kỹ năng sử dụng phần mềm thiết kế lẫn cái việc bạn hiểu người, hiểu cách người dùng tương tác, với cả 1 cái sản phẩm thế nào.
Đích đến thứ 2 UX designer, đối với 1 bạn graphic designer thì nó sẽ hơi xa, là bạn ấy phải đi học lại kỹ năng lắng nghe, thường xuất phát điểm của các bạn graphic designer là trường nghệ thuật, và cái tôi của bạn rất lớn nên bạn ấy phải đi thay đổi, phải bỏ cái tôi của mình đi, phải lắng nghe nhiều hơn và đẩy cái ta lên.
Đối với 1 bạn developer thì bạn ấy lại làm rất tốt trong việc đưa ra giải pháp vì thường những bạn dev khá là nhanh nhạy, sau đấy bạn giỏi đưa ra giải pháp rồi, phân tích vấn đề rất tốt, chủ yếu là bạn tập thêm kỹ năng lắng nghe thôi, bạn lắng nghe nhiều người hơn, và để lắng nghe tốt bạn cũng cần có những kỹ năng mềm, quản giao hơn. Và đó cũng là trở ngại của 1 bạn developer, vì thường bạn ấy sống trong thế giới riêng của mình, các bạn hướng nội nhiều hơn. Nhưng khi vượt qua được những trở ngại ban đầu đấy thì mọi chuyện sẽ thuận lợi hơn về hướng UX designer. Bản thân tôi background cũng là developer đi theo hướng UX design.
* Có thể thấy anh Quang hay tham gia các công ty ở giai đoạn đầu, có phải anh thuộc tuýp người thích khai phá?
Thực ra tính tôi quản giao, thích nói chuyện với mọi người, nên khi trong giai đoạn đầu thì sẽ có 1 cái hay là do công ty không quá nhiều người, nên mình sẽ có cơ hội được nói chuyện với tất cả mọi người ở từng bộ phận khác nhau.
Tôi rất ít khi nói chuyện với chị kế toán hay với bạn lễ tân, nhưng mà 1 công ty nhỏ hơn, thì mọi người đều biết nhau, mọi người đều hỗ trợ công việc của nhau, đều support nhau cả trong công việc lẫn ngoài đời. Tôi thích chuyện đấy hơn là mọi người cứ lên làm việc xong đi về. Nên tôi tham gia ở giai đoạn đầu thì sẽ nói chuyện với nhiều người hơn, với nhiều bộ phận khác nhau hơn, và mình sẽ có nhiều góc nhìn hơn, không chỉ vì mỗi chuyên môn của mình thôi mà mình biết cả kế toán họ hoạt động ra sao, có khó khăn gì không, hay những bạn chăm sóc khách hàng, các bạn nghe khách hàng khiếu nại, than phiền nhiều, thì lúc đấy các bạn có nỗi khổ riêng không. Bình thường công ty lớn rất ít khi đôi bên phàn nàn với nhau công việc của mình, đó cũng là việc đương nhiên, đi làm phải chấp nhận việc đấy, nhưng công ty nhỏ thì mình dễ chủ động, có cơ hội tiếp chuyện với họ hơn, hiểu công việc, khó khăn của họ và mình giúp đỡ họ trong công việc tốt hơn.
* Theo nhận xét của cá nhân anh thì thường designer sẽ hay mắc phải những sai lầm nào?
Nó xuất phát từ câu chuyện design. Thường các bạn designer được đào tạo design trong môi trường nghệ thuật, như bây giờ có những trường art school như là Arena, DPI, ĐH Mỹ thuật, ĐH Kiến trúc. Những ngành về nghệ thuật thì vấn đề lớn nhất trong việc đào tạo là hệ giá trị của mỹ thuật, nghệ thuật nó sẽ khác với giá trị thiết kế, bởi vì nghệ thuật thì đề cao cái tôi cá nhân nhiều, thể hiện cái bên trong của mình. Còn design thì lại khác, tôi tìm 1 cái giải pháp, nhưng nó chỉ thể hiện cái cá nhân tôi thì cũng không ổn, mà phải làm sao đáp ứng số đông sẽ tốt hơn.
Đấy là vì hệ giá trị nó khác nhau, nên thành ra là sẽ có những mâu thuẫn trong việc thiết kế. Khi đi làm, cái tôi của các bạn designer rất lớn, nếu để ý thì các bạn ấy sẽ mặc đồ style, thích đi sớm về muộn, gu âm nhạc riêng, art riêng... Để giải quyết câu chuyện là chúng ta thiết kế cho ai, để làm cái gì, thì bạn hay bị xa rời những cái câu hỏi ban đầu. Thường thì các bạn thích thì các bạn thiết kế ra như thế thôi, không cần biết cho ai, để làm gì, trong hoàn cảnh nào. Hậu quả đôi khi tạo ra 1 cái gọi là không thể dev được, không thể vận hành được, cũng không phải là cái người dùng mong muốn.
* Có phải để có UX tốt thì chính mình cần phải là user thường xuyên của app cùng loại? Hoặc chỉ đơn giản là copy trước, tối ưu sau?
Tùy theo hoàn cảnh, có thể là 50-50, nhưng tôi nghĩ 2 vế này là đều bổ trợ cho nhau. Việc copy 1 app cùng loại thì ưu điểm đó là họ cũng có team UX design, họ đã có những kinh nghiệm vận hành thị trường, thị trường họ đã trải qua như thế và những khó khăn tương tự. Sau đó sửa đi sửa lại cho tới cái bản hiện tại thì cái mà họ đưa ra sẽ mang ý nghĩa hoàn thiện hơn phiên bản cũ rất nhiều lần.
Nếu chúng ta để ý khách hàng của mình nhiều hơn, khi đó chúng ta sẽ tự động nảy ra những cái khác biệt, tối ưu hơn so với đối thủ.
Như vậy mình sẽ tiết kiệm được nhiều thời gian, thị trường và những thứ đi trước, tuy nhiên thì nếu như thế thì mình luôn luôn là người đi sau, thí dụ họ ra cái gì mình copy cái đấy, và khách hàng của mình luôn luôn kém hài lòng hơn khách hàng của họ vì họ luôn đi trước mình. Vì thế nếu chúng ta để ý khách hàng của mình nhiều hơn, khi đó chúng ta sẽ tự động nảy ra những cái khác biệt, tối ưu hơn so với đối thủ.
Đầu tiên là mình bám vào lưng họ, để mình biết cái đề xuất điểm nó nhanh hơn, thay vì là mình tự làm lại từ đầu, sau đấy thì mình sẽ tối ưu cái của mình với việc sử dụng thường xuyên, và khi đó sẽ phát sinh ra nhiều vấn đề. Như vậy mình biết vấn đề nằm ở đâu, cái này không tiện, cái này có lỗi chằng hạn thì sẽ biết đường mà sửa. Chứ chỉ copy thì mình cứ copy những thứ họ đang làm thôi, và mình không biết tại sao họ làm thế cả, nên dần dần mình dùng nhiều thì mình sẽ hiểu người dùng mình nhiều hơn.
* Khi một designer không có tư duy của dev thì khâu development sẽ gặp vấn đề gì?
Lúc này designer sẽ phải sửa đi sửa lại rất nhiều. Giả sử bạn design một thành phẩm, sau đó dev bảo “không làm được”, thì mình phải làm lại từ đầu.
Designer không cần có tư duy của dev nhưng bạn ấy phải giữ tinh thần luôn lắng nghe. Những bản design cần được bên developer develop nữa mới lên được thành sản phẩm. Sản phẩm này đến tay người dùng, sau đó một số đưa tới bộ phận vận hành (ví dụ như phần mềm chăm sóc khách hàng thì người vận hành là những bạn CSKH) hay mang đi bán.
Nếu thiết kế ra một sản phẩm mà mình không bán được, thì đơn giản là mình phải lắng nghe nhiều hơn. Ngay từ đầu mình đưa bản thô sơ để xem có thể dev được không, lúc đấy mình đã biết mình có nên đi theo hướng này hay không. Ngoài ra cũng phải có những câu hỏi khéo léo để thu thập thông tin, chủ động đi hỏi người này người kia, và lắng nghe họ để phản biện cho chính thiết kế của mình. Chứ không phải là “tôi thiết kế này ra thì bạn phải dev nó, vận hành nó hay đi bán nó đi”, mà là mọi người tương hỗ với nhau để mang lại lợi ích lớn nhất cho công ty.
* Vậy thế nào là một phiên bản UX thành công? Làm thế nào để số hóa các chỉ số và tạo ra các thước đo cho UX Designer đánh giá?
Dựa trên cảm quan mỗi người thì chuyện đánh giá UX thành công hay không. Việc số hóa sẽ giúp mọi người có chung một tiếng nói. Mình sẽ cần một số chỉ số để đánh giá sự thành công của một UX. Tùy theo dạng công ty mà mình có bộ chỉ số khác nhau xoay quanh độ hài lòng của khách hàng, tỷ lệ trung thành của khách hàng, tỷ lệ người dùng hoàn thành công việc nào đó…
* Theo đó thì mình có cần sử dụng A/B Testing không?
Một số sản phẩm rất khó để A/B testing. Trước đây tôi cũng từng AB Testing và có một số thất bại do tôi test nhiều variation cùng lúc và không tách rõ ràng. AB Testing có thể hiểu đơn giản là test phiên bản A và phiên bản B trong cùng thời điểm. Tuy nhiên có nhiều tính năng chen vào một lúc cho nên kết quả cho ra do một tính năng khác ảnh hưởng lên tính năng tôi muốn test. Cho nên mình nên tính toán để tách bạch, không để trộn lẫn với nhau. Những sai lầm của tôi là đo những cái quá chung, ví dụ như tăng tỷ lệ chuyển đổi, nguồn hàng của hàng hóa không có, tính năng search bị lỗi cũng ảnh hưởng tỷ lệ chuyển đổi…
* Theo anh các doanh nghiệp lớn có đội dev khủng rất hay gặp vấn đề với UX/UI thì giải pháp cho họ là gì khi chưa tuyển được người phù hợp?
Ở đây chỉ có 2 giải pháp: tìm bạn UXD phù hợp với team dev hay là team dev phù hợp với UXD của team? Ở đây mình phải xem công ty cần cái gì và đang ưu tiên vấn đề gì? Giả sử công ty đang rất thiếu dev thì rõ ràng phải tuyển và giữ dev bằng mọi giá. Dev thì không có khả năng thay đổi đủ nhanh nên phải tìm bạn designer phù hợp tại thời điểm đó. Nhưng giả sử công ty có dev thay đổi đủ nhanh và việc dev thay đổi theo design mang lại hiệu quả kinh doanh cho công ty tốt hơn thì lúc này có thể tuyển dev thay thế, hay training dev…
Tùy theo tình hình công ty nhiều hơn là mình tự ra quyết định. Role của dev và design sẽ va chạm với nhau. Ví dụ UXD đưa ra giải pháp mà chưa chắc giải pháp này technical stack hay công nghệ hiện đại đáp ứng được. Nếu hai bên không tìm được sự đồng thuận thì sẽ dẫn đến mâu thuẫn lẫn nhau, ảnh hưởng rất nhiều thứ. Ví dụ với website của TopDev, tôi là UXD bảo phải thay đổi cái này cái kia, ảnh hưởng đến hệ thống, website sập, chậm... thì rõ ràng hai bên chưa có tiếng nói chung với nhau. Cuối cùng hai bên phải đưa ra mình muốn cái gì? Tốt cho công ty hay tốt cho bản thân mình? Chủ yếu vấn đề là ăn khớp với nhau hơn là giữ cái tôi cá nhân.
* Theo anh những người nào sẽ thích hợp làm product? Có phải product là cầu nối giữa những phòng ban hay không?
Trong công ty, product là những người có thể nói nhiều ngôn ngữ khác nhau, ngôn ngữ người dùng, ngôn ngữ kinh doanh, nói chuyện với stakeholder, ngôn ngữ công nghệ (để nói chuyện với team dev). Giả sử công ty không có product, thì bên business sẽ nói “gà”, dev sẽ hiểu “vịt”. Khi đó hai bên không có tiếng nói chung khi triển khai sẽ có rất nhiều khó khăn ở giữa. Bộ phận product nằm ở giữa, hiểu cả hai bên để giúp quá trình truyền đạt thông tin hiệu quả hơn. Về tố chất, thứ nhất họ cần phải nhanh trí. Xuất phát điểm không phải cái gì cũng biết, thì họ phải nhanh trí để học hỏi bổ sung những điều cần thiết. Thứ hai là kỹ năng mềm, giao tiếp tốt, về đàm phán để cân đối timeline cho phù hợp.
* Sự khác nhau giữa Product Manager và Project Manager? Anh nghĩ thế nào về câu nói “Product manager giống như một CEO của sản phẩm”?
Về tính chất, project được định nghĩa là sẽ có ngày kết thúc, tôi làm project 2 năm, 3 tháng, 6 tháng… Trong quá trình này, Project Manager sẽ tập trung làm sao để dự án thành công. Nhưng Product thì khác, nó liên tục từ 10 năm thậm chí 20 năm không hết, và mọi người vẫn cần thay đổi và cải tiến nó chứ không có một cái kết thúc như Project.
Về quan điểm trên thì vừa đúng vừa sai. Đúng ở đây về việc Product là người trực tiếp đưa ra quyết định trên sản phẩm ấy, và là người hiểu sản phẩm nhất. Tuy nhiên, Product không chịu những vấn đề nặng nề như CEO, ví dụ như trả lương, chi phí hay headcount. Đa số trường hợp Product Manager không chịu trách nhiệm những vấn đề liên quan đến tài chính hay pháp lý nhiều.
* Có ý kiến cho rằng Product phải thay đổi tối ưu hàng ngày nên cần tố chất uyển chuyển linh hoạt và quan sát, còn Project thì ngược lại cần đảm bảo đúng quy trình, anh nghĩ sao về ý kiến này?
Ý kiến này không hoàn 100%. Project Manager có hạn kết thúc và cái thành công hay thất bại của dự án đấy sẽ được đưa ra để mổ xẻ nên việc dự án bám theo quy trình sẽ tăng tỷ lệ thành công của dự án đấy lên. Product thì đôi khi đi theo biến động của thị trường. Ví dụ bây giờ đang có dịch COVID-19 thì sản phẩm về du lịch phải ứng phó như thế nào. Project thì không đủ linh hoạt mà phải làm theo quy trình các bước, nhưng trong mùa này mình phải linh hoạt và tìm các phương án khác nhau. Ví dụ như Be với 1 dòng sản phẩm mới mất ít nhất là 3 tháng, nhưng tính năng Be đi chợ (nhờ bác tài xế đi siêu thị) chỉ lên trong 3 tuần, cắt rất nhiều quy trình so với dự án truyền thống. Tất nhiên có rất nhiều vấn đề nhưng cái ưu tiên là linh hoạt ra sản phẩm đúng thời điểm phù hợp.
* Anh có nhắc đến UX và Product là 2 vị trí trái ngược nhau, anh có thể chia sẻ rõ hơn được không?
Ưu tiên lớn nhất của UX là sự hài lòng của khách hàng, đó là thước đo của trải nghiệm người dùng tốt. Tuy nhiên Product nghiêng về cân bằng hơn, sự hài lòng của khách hàng không đi kèm với sản phẩm thành công. Tùy tình huống mà mình phải cân đối cho phù hợp tài chính của công ty. Ví dụ như Be, thời điểm ra mắt có khoảng 500 bug, tuy nhiên nếu chờ thời điểm fix bug xong và ra mắt muộn hơn 1 năm thì thị trường đã chia xong hết và cơ hội tiến vào thị trường của Be rất nhỏ để có thể cạnh tranh. Đôi khi mình phải chấp nhận trải nghiệm người dùng chưa được tốt lắm, sau đó mình sẽ cải thiện dần dần. Product phải cân đối nhiều thứ hơn là chỉ trải nghiệm người dùng không thôi.
* Em tò mò không biết anh có code không và kỹ năng đó giúp ích gì cho công việc hàng ngày?
Tôi có thể lập trình. Bây giờ thì tôi không còn lập trình quá nhiều tuy nhiên nó giúp tôi trong cách suy nghĩ. Lập trình viên có kỹ năng giải quyết vấn đề rất tốt nên giúp rất nhiều công việc của tôi hiện tại.
Tôi vẫn nghĩ mình là người đang đi học, có rất nhiều mảng khác nhau mình cần học, được học hỏi mở rộng vốn hiểu biết của mình, để có thêm các góc nhìn khác nhau và mở rộng vốn hiểu biết của mình.
* Xin được cảm ơn anh Quang cùng những chia sẻ rõ nét về ngành UX/UI cũng như những kỹ năng mềm thiết thực mà designer nào cũng nên có.
Hy vọng độc giả đã hiểu hơn hay mở rộng ý kiến về ngành nghề thú vị này, và đừng quên đón đọc những số tiếp theo không kém thú vị tại TopDev nhé.
* Nguồn: TopDev Blog