Trong suốt hành trình đến thời điểm là 1 Product Designer ở BraveBits, mình đã từng đứng trước rất nhiều lựa chọn. Từ lựa chọn trở thành designer sau khi tốt nghiệp 1 chuyên ngành đại học không liên quan, đến lựa chọn sẽ tập trung vào UI/UX sau khi đã trải qua nhiều vị trí khác nhau trong nghề thiết kế. Tuy nhiên, khi danh sách dự án ngày một nhiều, hiểu hơn những điểm mạnh của bản thân, khi cảm giác thuộc về một lĩnh vực rõ ràng hơn, những câu hỏi về hành trình sáng tạo của mình lại tiếp tục xuất hiện: “Tại sao mình cứ liên tục mất năng lượng sau các dự án thú vị?”, “Tại sao hiểu được nguồn gốc mâu thuẫn giữa designer và stakeholders mà vẫn phải thoả hiệp và vẫn thất vọng?”, “Tại sao mình không cảm thấy thoả mãn khi dự án hoàn tất?”, “Tại sao mình không dám khoe với mọi người đây là website mình làm?”

Bài học đầu tiên ở lớp học design của mình không phải các nguyên tắc thiết kế hay cách sử dụng công cụ, mà là ý thức về bản thân trong ngành sáng tạo. Ngày ấy, mình đã quyết định là mình muốn trở thành người làm sáng tạo 1 cách “bền vững”. Mình chọn thiết kế là công việc, và để duy trì sự làm việc lâu dài và không nản, mình muốn chọn công việc giúp mình duy trì cảm hứng với những khai phá sáng tạo, đồng thời vẫn giữ được tư duy độc lập của bản thân trước sự chi phối của hiện thực khách quan xung quanh. Những câu hỏi trên hiện ra khi tiềm thức mình phát hiện bản thân đang đi ngược lại ý muốn ban đầu, sự bối rối đến từ việc bản năng mình thấy có gì đấy sai sai mà lý trí thì chưa kịp nhận ra.

Từ thiết kế dịch vụ…

Ở thời điểm ấy, mình đang là UI/UX designer trong 1 công ty outsourcing. Đặc điểm các đầu việc của mình là “nhận đơn đặt hàng theo yêu cầu”: chủ yếu thực hiện các yêu cầu thiết kế cụ thể do khách hàng hoặc các bên liên quan nội bộ cung cấp mà không có chút thông tin nào về đầu vào hoặc chiến lược, định hướng sản phẩm tổng thể. Đây là đặc thù của công ty outsourcing – tập trung vào việc cung cấp dịch vụ cụ thể cho khách hàng, ưu tiên sự hài lòng của khách và đáp ứng deadline dự án hơn là bản thân sản phẩm. Định hướng này không sai, nó chỉ có vấn đề khi không song hành được với mong muốn ban đầu của mình – được làm design 1 cách bền vững, được nuôi lớn sản phẩm thật sự, hay nói cách khác, mình muốn có ownership với sản phẩm mình làm.

Thế nên mình quyết định chuyển sang làm Product Designer, ở 1 công ty làm SaaS, là BraveBits.

…đến thiết kế sản phẩm

Quãng thời gian làm Product Designer ở BraveBits thực sự đã cho mình nhiều cơ hội được thử nghiệm và đứng ở nhiều góc nhìn thú vị, trong đó có góc nhìn đặc biệt về ownership. Mình muốn ghi lại những dấu ấn trong góc nhìn đó và chia sẻ trong bài viết này trải nghiệm cá nhân của mình về hành trình chuyển đổi mindset từ thiết kế dịch vụ sang làm sản phẩm.

Khác biệt lớn nhất

Ở công ty outsourcing, sản phẩm của mình là những dịch vụ thiết kế, mục tiêu tập trung chính của mình là khách hàng – người trả tiền cho dịch vụ, chứ không phải người dùng cuối cùng. Đa phần khách hàng mình từng gặp không biết chính xác họ muốn gì, và brief được cung cấp chi tiết đến đâu tuỳ thuộc rất nhiều vào đặc điểm và quy trình làm việc nội bộ của doanh nghiệp khách. Các dự án thường ngắn hạn, có ngày bắt đầu và kết thúc rất rõ ràng và nghiêm ngặt. Chưa kể, trong 1 khoảng thời gian, mình thường ôm nhiều dự án khác nhau, nhảy từ khách hàng này sang khách hàng khác, domain này sang domain khác. Một mặt, điều này giúp mình trải rộng kinh nghiệm về domain và làm việc với các đối tượng khách hàng khác nhau, nhưng mặt khác, nó giới hạn khả năng của designer trong việc thực hiện cũng như đánh giá giá trị của sản phẩm mình làm. Mình mất rất nhiều thời gian để biết khách thực sự cần gì, bởi trước khi đến với mình, yêu cầu ấy đã qua rất nhiều lớp lọc từ BA và Account – những vai trò có góc nhìn và ưu tiên khác với designer. Mình cũng không có ownership với sản phẩm ấy, sau khi bàn giao website cho khách hàng, họ có thể sử dụng nó theo cách họ muốn và mình không thể can thiệp vào cho dù sản phẩm chạy tốt hay tệ.

Ví dụ, mình từng tham gia một dự án thiết kế website cho một công ty chuyên cung cấp dịch vụ nhà cửa. Khách hàng là 1 doanh nghiệp khá đặc biệt, và mình chỉ được cung cấp một bản brief ngắn gọn về các yêu cầu cơ bản và deadline hoàn thành trong 1 tháng. Khách hàng là 1 doanh nghiệp khá đặc biệt, và mình không có cơ hội trao đổi trực tiếp để làm rõ yêu cầu, tìm hiểu sâu về người dùng cuối của họ hay chiến lược kinh doanh dài hạn. Kết quả là team vẫn hoàn thành được website, nhưng phải mất rất nhiều thời gian chỉnh sửa, thậm chí là đập đi xây lại bởi vì mỗi lần present với khách hàng thì lại ra 1 vấn đề mới. Đương nhiên timeline dự án cũng bị kéo dài ra, và không nghiệm thu được đúng hạn như kỳ vọng ban đầu. Việc OT và stress kéo dài mà không giải quyết được vấn đề gốc rễ khiến mình nhận ra rõ ràng có gì đó sai sai ở đây, ít nhất là không đúng với bản thân mình.

Khi chuyển sang BraveBits làm thiết kế sản phẩm, mình được (và phải) quan tâm nhiều hơn đến những giá trị lâu dài của sản phẩm. Mình chỉ tập trung vào 1 product, và có những chỉ số đo lường cụ thể để quan sát hiệu quả của giải pháp. Ở BraveBits, các Product Designer như mình mình chịu trách nhiệm về giải pháp mình đề xuất, và cả những tác động mà giải pháp tạo ra. Nhờ đó, mình được chứng kiến và định hình quá trình phát triển của sản phẩm theo thời gian.

Không giống như các sản phẩm thiết kế dịch vụ có quy trình giải quyết vấn đề khá linh hoạt, phụ thuộc nhiều vào đối tượng khách hàng và yêu cầu dự án, ở BraveBits, mình cần phải làm chủ quy trình tạo ra giải pháp. Về mặt lý thuyết, khi xử lý vấn đề, mình phải hình dung việc thực hiện những bước sau:

1. Làm rõ vấn đề, hiểu được tại sao cần phải đưa ra giải pháp để giải quyết nó
2. Thu thập insights từ người dùng, doanh nghiệp, thị trường và phân tích sản phẩm
3. Brainstorms, đưa ra các ý tưởng về giải pháp giải quyết vấn đề
4. Chọn ý tưởng trong đống ý tưởng, biến nó thành thiết kế
5. Viết spec – bản liệt kê những yêu cầu của Designer về cấu trúc và cơ chế hoạt động, giải thích chi tiết về giải pháp
6. Bàn giao giải pháp hoàn chỉnh tới cho developers, hỗ trợ developers xây dựng giải pháp một cách chính xác.
7. Đảm bảo giải pháp đầu ra làm việc đúng như thiết kế
8. Theo dõi các chỉ số sau khi giải pháp được ra mắt để có thể nâng cấp giải pháp

Trên thực tế, mình phải tự soi chiếu quy trình trên với khả năng và giải pháp mà mình chọn, từ đó tự tìm ra cách thực hiện phù hợp với bản thân để thực hiện những đầu việc nói trên: những phần nào nên do mình làm và những phần nào nhờ sự hỗ trợ của người khác. Từ đó thực hiện nó một cách kịp thời và tiếp tục theo dõi kết quả để cải thiện hoặc thay đổi giải pháp khi cần thiết.

Việc được trao quyền (và trách nhiệm) một cách toàn diện với các giải pháp của bản thân khiến mình hiểu rõ hơn rất nhiều tại sao ngày xưa mình luôn cảm thấy “không thoả mãn”, tại sao mình luôn thất vọng khi phải thoả hiệp – ấy là bởi vì mình biết mình có thể tạo ra giải pháp tốt hơn nhưng không có quyền làm như thế. Ở BraveBits, mình được “sở hữu” thứ mình làm, phải tự làm việc với các stakeholders của dự án để hiểu được cái Why to nhất của vấn đề. Bởi vì không cần qua lớp lọc từ Account hay BA, đề bài mà mình nhận được sẽ là thứ mình cần biết nhất, tránh được những trường hợp thông tin không thông suốt trong suốt.

Cảm giác “sở hữu” sản phẩm

Sự đầu tư về mặt cảm xúc

Việc chuyển từ vai trò UI/UX Designer sang Product Designer với mình không chỉ là câu chuyện về đổi title, nó chuyển đổi cả về trách nhiệm và cảm xúc. Mình gọi những sự chuyển giao đó là quá trình hình thành cảm giác “sở hữu” sản phẩm – sense of ownership.

Việc được tham gia vào quá trình hình thành định hướng và mục tiêu của sản phẩm khiến mình, một Product Designer, có cảm giác “trách nhiệm” và “tự hào”: Không chỉ đơn thuần tạo ra các giao diện đẹp, mình còn đang xây một sản phẩm có ảnh hưởng đến cuộc sống của người khác. Nghe hơi giống các triết lý trên mạng, nhưng sự thật là, khi được tham gia vào các cuộc thảo luận về định hướng sản phẩm, hợp tác với các team khác trong quá trình phát triển, và được góp ý vào các khía cạnh nằm ngoài phạm vi “thiết kế trên Figma”, tất cả những điều đó tạo ra cảm xúc “mình có ích”. Là 1 người làm việc hàng ngày với trải nghiệm – mình hiểu rõ cảm xúc có thể thúc đẩy con người vượt lên trên và vượt xa những động lực như “được khách hàng ký nghiệm thu” như thế nào.

Những viên đá cản đường

Tất nhiên, hành trình chuyển đổi mindset của mình cũng không diễn ra dễ dàng trong 1 câu nói. Qua một khoảng thời gian dài làm việc với mindset “vạn sự tuỳ client”, mình bị ảnh hưởng kha khá vào thói quen làm việc, cho dù đã có nhận thức và ý thức thay đổi đó.

Khi đi làm outsourcing, mình không cần phải viết spec, không cần phải giải thích với dev nút này có chức năng gì và dẫn đến màn nào. Mình thuộc lòng những giới hạn kỹ thuật mà nền tảng không làm được, biết những chỗ nào dev sẽ không chịu tuỳ chỉnh code nên sẽ chỉ “được” vẽ theo mặc định. Nếu cần giải thích chi tiết, dev sẽ tìm đến tài liệu yêu cầu phần mềm – SRS (Software Requirements Specification) của BA, và khi có mâu thuẫn xảy ra, BA và dev sẽ là người quyết định, tiếng nói của designer xếp sau cùng.

Quy trình làm việc như này khiến mình bị nhiễm thói quen giải bài toán theo lối mòn, ngay cả khi đã sang làm product, có nhiều quyền hơn về sản phẩm. Lúc mới làm product, mình vẫn quen xu hướng tìm những câu trả lời an toàn, đã từng được nhiều người sử dụng rồi. Thật ra đây không hẳn là một điều xấu, nó có thể đảm bảo chất lượng của giải pháp đạt mức chấp nhận được (bởi đã có nhiều người dùng và chứng minh). Tuy nhiên, điều này giới hạn rất nhiều khả năng xử lý vấn đề và sự tự tin khi sử dụng ownership của bản thân mình. Bởi vì không quen với việc “tiếng nói của designer được công nhận”, khi phải tự viết spec cho sản phẩm, mình bị không tự tin và không tin là giải pháp của mình sẽ đúng.

Ở giai đoạn đầu khi mới vào BraveBits, mình thường không có thói quen nghiên cứu kỹ đề bài, hoặc đào sâu hơn vào đề bài rồi nhưng vẫn bối rối không biết đến mức này đã đủ sâu chưa, đây có phải là cái Why to nhất chưa. Nguyên nhân của việc này là do mình quen xử lý những vấn đề đã được define cụ thể từ trước, và không có quyền hỏi lại “Why”. Cho đến giờ khi đã được trải nghiệm trong môi trường product có ownership cao hơn, mình vẫn cảm thấy khó khăn nhất trong các bước tìm ra vấn đề và chọn giải pháp để giải quyết vấn đề đó.

Mình nhận ra các vấn đề này khi soi chiếu lại hành trình của bản thân và nhận feedback từ manager, và vẫn cố gắng hàng ngày để thay đổi. Chủ động tìm kiếm những bài toán khó mà mình chưa giải bao giờ, thử những giải pháp mới, vượt ra ngoài vùng an toàn, và hơn hết, là đọc và học nhiều hơn để có thêm sự tự tin sử dụng ownership của chính mình. Mình cũng học cách hỏi tại sao nhiều hơn, hỏi đến mức mọi người thấy phiền thì thôi. Nhìn mọi thứ 1 cách tổng thể, thay vì chỉ là các đầu việc chi tiết để tìm ra cái Why to nhất. Mình vẫn còn những kĩ năng cần cải thiện và những vấn đề cần khắc phục để làm product tốt, nhưng trên hết, mình thích quá trình học hỏi và nhận ra mình học được những gì sau mỗi ngày, đây là 1 trong những điều hiện tại mà mình rất enjoy trong quá trình làm Designer ở BraveBits.

Tổng kết

Việc làm sản phẩm ở BraveBits thực sự đã cho mình những trải nghiệm thú vị về ownership dưới vai trò của một Product Designer. Đâu đó trên hành trình này, mình bớt thấy bối rối hơn vì những thứ đang làm không còn mâu thuẫn với ý thức ban đầu của bản thân – được trao quyền để giải các bài toán mới hàng ngày, duy trì cảm hứng sáng tạo, được trao trách nhiệm để hình thành và bảo vệ tư duy độc lập của bản thân, tự tin trước những thay đổi nhanh chóng của công việc thiết kế nói riêng và lĩnh vực công nghệ nói chung.

Mong rằng bài viết này cũng mang lại góc nhìn hữu ích cho những designer đang có ý định chuyển đổi từ các mô hình thiết kế dịch vụ sang làm sản phẩm. Nếu có 1 lời khuyên cho việc cần chuẩn bị gì trước khi đổi môi trường làm việc, thì đấy chính là đừng ngại thử những trải nghiệm mới. Việc được “sở hữu” 1 sản phẩm không chỉ là trách nhiệm mà còn là một cơ hội để phát triển bản thân. Dù sẽ vẫn có những điều không giống kỳ vọng, bởi không có con đường nào toàn là hoa hồng, nhưng chắc chắn việc làm Product Designer ở 1 nơi mà được trao quyền sở hữu cao với sản phẩm là một trải nghiệm thú vị đáng để thử.