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, Anh hãy giới thiệu đôi chút về bản thân mình.
Mình 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 mình tham gia vào chuyên mục ngày hôm nay, hi vọng những chia sẻ của mình 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ái việc của tôi thì mang tính định hướng, quản lý nhiều hơn, thế nên ở cái việc vất vả mà tốn nhiều thời gian của các bạn senior trực tiếp tham gia vào nhiều hơn. Về day tool, day work sẽ thiên về cái chuyện là tôi cập nhật thông tin cho các bạn, hằng ngày thì tôi sẽ có daily meeting với cả team của Be, để nắm tình hình với cả vấn đề đang nằm ở đâu, vấn đề gì. Với cái team cũng phải linh hoạt, các bạn cũng phải có cá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?
Bên tôi đ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 cái protocol làm việc, giống như là mọi người sẽ có những cái đầu việc phải làm trong mỗi ngày. lúc đó tôi sẽ dùng Jira để bọn tôi quản lý việc đấy. Khi mọi người bắt đầu làm việc, công việc nào đấy thì bắt đầu đưa vào để mọi người cùng thảo luận tức là cái người làm cái việc nào thì họ (gọi là person in charge) nhưng mà team cùng support để làm thì tôi cũng ở trong cái việc support cả ngày. Và tụi tôi support qua chat, lúc đấy thì cả ngày mọi người đều support công việc lẫn nhau, nên biết được là khó khăn ở đâu, đang gặp vấn đề gì, đấy thì cái tiến độ ấy tới đâu, cái quality tới đâu, toàn bộ công việc ấy thì tôi là người observe toàn bộ team.
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 ?
Đây thực ra là câu hỏi tranh cãi thôi, nhưng mà 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 mà 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 thường gặp thường xuyên. Để đo lường 1 cách hiệu quả, em 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 cái tính năng, của cái sản phẩm. Lúc này mình phải đánh đổi ở mức độ là từ từ thay đổi dần để phù hợp, hoặc là từ từ mình tìm cách để mà đ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 ra thì sẽ bị mất rất nhiều cơ hội. mình cũng đủ linh hoạt để tiếp cận những cơ hội mà thị trường đang mở ra cho mình.
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át thảo được cái ý tưởng đấy rồi có 1 ban đồ họa sẽ giúp bạn cái chuyện đó.
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ị vê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í thôi, đơ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 cái chuyện là 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 nó 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 cá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?
Thì thực ra outcome, cái kết quả đầu ra của 2 người này là khác nhau. Ông UX kỳ vọng đưa ra giải pháp sáng tạo, ông UI có kỳ vọng là giao diện người dùng, đấy là 2 cái kỳ vọng khác nhau, với mục tiêu theo đuổi của 2 ông cũng khác nhau. nhưng về cái hữu hình: giao diện người dùng tức là cái chạm vào người dùng nhiều nhất thế nên là cỡ nào ông UX cũng đi qua ông UI thì mới đến được tới người dùng, không thì chỉ dừng lại ở vài cái suy nghĩ, vài cá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ốt chất để cần thiết nhất của người làm trong ngành này?
Thực ra là kỹ năng cần thiết là kỹ năng lắng nghe, vì cái 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 cái vấn đề này, để đưa ra giải pháp thì ông phải biết vấn đề nằm ở đâu. Cái kỹ năng 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. Sau đấy đưa ra giải pháp, ông 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 là những người vận hành, đôi khi là những người tiếp xúc với khách hàng thường xuyên, đôi khi là những cái ông 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, lắng nghe nhiều sẽ giúp mình 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. Nên lắng nghe rất quan trọng với người làm UX design.
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ụ mình bắt đầu từ define vấn đề xong rồi xác định người dùng, vân vân. Rồi sau đó đưa ra giải pháp, kiểm thử giải pháp ấy xem nó có phù hợp không; thì việc đấy như 1 cái kỹ năng mà khi tụi tôi apply ở công việc. 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.
Đưa ra giải pháp thì bọn tôi mới bàn là ‘chúng ta làm cái này cho ai?’, cái thứ 2 là “chúng ta làm cái này để phục vụ mục đích gì?” giống như là 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 mấy cái 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 1 cái giải pháp đấy mà không dev được, ví dụ thế, đưa ra giải pháp ấy 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 họ sử dụng. Tại vì để 1 sản phẩm, 1 tính năng nó ra thì cần rất nhiều yếu tố, với chuyện là dev được và chuyện vận hành được rồi mới tới người dùng được, còn nếu không ra thì không đến tay người dùng sử dụng.
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ì? Vậy cần những người vớ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, thì đấy là chuyện chung chung mọi người cần. Để có 1 con đường thì nó sẽ xuất phát từ cái chuyện là xuất phát điểm ở đâu và đích đến mình là ở đâu. Đích đến của UX designer và UI designer là khác nhau. Ông 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 em 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 cái 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, và bạn phải lắng nghe nhiều hơn và bạn đẩ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à thông minh, 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.
Em thấy là anh Quang hay tham gia các công ty ở giai đoạn đầu? Có phải anh thuộc tiếp người thích khai phá?
Thực ra tính tôi thích quản giao, thích nói chuyện với mọi người, nên khi trong giai đoạn đầu thì nó 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 thì rất ít khi nói chuyện với chị kế toán hay với 1 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 chửi 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ái chuyện design thôi. 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ế. Thành ra khi việc đi làm, thì 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, cái art riêng gì đó. Cái cá nhân thì mình tôn trọng tuy nhiên do trong môi trường thường xuyên nên bạn đề cao cái tôi của mình nhiều quá. Khi mà để giải quyết cái 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 đấy. 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. Nên tạo ra 1 cái gọi là không thể dev được, không thể vận hành được. Và 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?
Thật ra là 50-50, tùy theo hoàn cảnh, 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ì đấy là cái mà họ đưa ra. Thực ra mình copy họ không phải là cái gì đó sai cả, như cái bánh xe, mình không đi sáng tạo cái bánh xe làm gì cả.
Nhưng mà ở đấy là 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, thế nên là mình để ý khách hàng của mình hơn, thì sau đó thì mình sẽ có những cái nó khác biệt, nó tối ưu so với cả đối thủ.
Thứ nhất đầ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 là mình sử dụng thường xuyên, và khi mình sử dụng thường xuyên nó sẽ sinh ra nhiều vấn đề và sau đấ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 như thế 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.
Nếu 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ử em 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, bắt đầu lại từ đầu. Thực ra 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 cái bản design này mới lên 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. Mình 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ì ông dev nó đi, ông vận hành nó đi hay ông đ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 như độ 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. Thực ra 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à mình 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, một là 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à”, ông 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 ông ấy 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 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, tôi 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 xuất phát từ Bách Khoa và 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 mình 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*
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?