Dạo gần đây, tôi dành khá nhiều thời gian để phát triển một ứng dụng theo dõi chi tiêu cá nhân. Tuần vừa rồi, tôi làm lại giao diện cho web app, đồng thời thử build thêm một phiên bản iOS để xem giữa hai nền tảng có gì khác nhau.
Với sự hỗ trợ của AI, việc biến một ý tưởng thành một ứng dụng có thể sử dụng được trở nên dễ dàng hơn rất nhiều. Tôi có thể thử nghiệm giao diện, bổ sung tính năng và điều chỉnh cách hoạt động của ứng dụng nhanh hơn trước. Đó cũng là lý do tôi ngày càng thích vibe coding, cảm giác khá giống những ngày đầu mới học lập trình, khi mỗi ý tưởng mới đều khiến mình muốn bắt tay vào làm ngay.
Tuy nhiên, trong quá trình phát triển ứng dụng, tôi nhận ra một điều khá thú vị: build một ứng dụng chạy được là một chuyện, xây dựng một sản phẩm thực sự hữu ích lại là chuyện khác.
Và bài học này đến từ chính những người dùng đầu tiên của tôi: vợ và các con.
AI bị sử dụng sai mục đích
Tôi có tích hợp một tính năng AI vào ứng dụng theo dõi chi tiêu, với mục đích hỗ trợ người dùng hỏi đáp về tài chính cá nhân và dữ liệu chi tiêu của họ.
Mọi thứ hoạt động khá ổn theo những gì tôi hình dung. Nhưng rồi một hôm, con gái lớn kể rằng em Bống nhận xét Mokey AI của bố giống ChatGPT, có thể hỏi bài tập cũng được.
Nghe xong, tôi vừa buồn cười vừa nhận ra một vấn đề.
Tôi xây dựng AI để phục vụ một mục đích cụ thể, nhưng người dùng đâu nhất thiết phải sử dụng nó theo cách tôi mong muốn. Có một ô chat, có thể nhập câu hỏi và nhận câu trả lời, vậy thì tại sao không thử hỏi những thứ khác?
Với những đứa trẻ, đó đơn giản chỉ là sự tò mò. Chúng không quan tâm tôi đã thiết kế prompt thế nào, sử dụng model gì hay ứng dụng được định hướng cho mục đích nào. Chúng chỉ muốn biết con AI này có thể làm được những gì.
Nhưng với người xây dựng sản phẩm, câu chuyện lại khác. Những câu hỏi không liên quan có thể làm tăng chi phí sử dụng AI, tiêu tốn token và khiến ứng dụng hoạt động lệch khỏi mục đích ban đầu.
Sau bữa cơm hôm đó, tôi lại lên tầng và tiếp tục vibe code, lần này để bổ sung các quy tắc giới hạn phạm vi hoạt động của AI, giúp nó tập trung vào những câu hỏi liên quan đến tài chính.
Tất nhiên, việc giới hạn không đơn giản chỉ là thêm một câu vào prompt rồi hy vọng mọi thứ sẽ ổn. Còn phải tính đến những trường hợp người dùng hỏi chưa rõ ý, những câu hỏi nằm giữa hai phạm vi khác nhau và cách từ chối sao cho không ảnh hưởng đến trải nghiệm sử dụng.
Nhưng ít nhất, tôi đã có một tình huống thực tế để kiểm tra thay vì chỉ ngồi tưởng tượng xem người dùng có thể làm gì.
User không sử dụng sản phẩm theo cách dev nghĩ
Thực ra, chuyện AI bị hỏi bài tập chỉ là một phần nhỏ.
Trong quá trình đưa ứng dụng cho vợ sử dụng, tôi còn nhận ra một số tính năng khác cũng chưa thực sự thân thiện.
Tôi dùng ứng dụng mỗi ngày nên biết rõ từng chỗ cần bấm, từng bước cần thực hiện và lý do tại sao nó hoạt động như vậy. Với tôi, mọi thứ đều khá tự nhiên.
Nhưng vợ tôi lại không nghĩ thế.
Có những chỗ cô ấy không biết phải làm gì tiếp theo, có những tính năng phải hỏi lại cách sử dụng, thậm chí có những vấn đề liên quan đến email mà tôi nghĩ mình đã xử lý ổn.
Lúc đó, tôi mới thấy rõ khoảng cách giữa người xây dựng sản phẩm và người sử dụng nó.
Developer thường có xu hướng đánh giá sản phẩm dựa trên cách mình hiểu nó. Chúng ta biết tính năng nằm ở đâu, hiểu logic phía sau và biết phải làm gì để hoàn thành một tác vụ. Vì thế, rất dễ mặc định rằng người khác cũng sẽ hiểu như vậy.
Nhưng người dùng không nhìn thấy code của chúng ta. Họ không biết vì sao phải đi qua ba bước để hoàn thành một thao tác, tại sao trường dữ liệu này bắt buộc, hay tại sao một tính năng được thiết kế theo cách đó.
Họ chỉ muốn giải quyết vấn đề của mình.
Một tính năng có thể chạy hoàn toàn chính xác về mặt kỹ thuật nhưng vẫn gây khó chịu cho người dùng. Một giao diện có thể trông rất đẹp trong mắt developer nhưng lại khiến người khác không biết bắt đầu từ đâu.
Và đôi khi, thứ chúng ta gọi là lỗi người dùng thực chất lại là vấn đề trong cách thiết kế sản phẩm.
Biết làm phần mềm chưa chắc đã biết làm product
Tôi đã làm phần mềm nhiều năm, từ WordPress, PHP đến những hệ thống có logic nghiệp vụ khá phức tạp. Tôi vẫn tự tin vào khả năng phân tích vấn đề và tìm ra giải pháp kỹ thuật của mình.
Nhưng khi tự xây dựng một sản phẩm từ đầu, tôi nhận ra kinh nghiệm lập trình không tự động biến mình thành một người làm product giỏi.
Chúng ta thường nghe những lời khuyên quen thuộc: phải hiểu khách hàng, xác định đối tượng sử dụng, tìm đúng pain point và xây dựng tính năng giải quyết vấn đề thực tế.
Tôi cũng biết những điều đó. Nhưng biết là một chuyện, còn làm tốt lại là chuyện khác.
Khi tự phát triển sản phẩm, tôi có thể dành hàng giờ để hoàn thiện một tính năng mà mình cho là hữu ích. Nhưng nếu người dùng không hiểu cách sử dụng, không có nhu cầu thực sự hoặc tìm được cách giải quyết đơn giản hơn, công sức đó chưa chắc tạo ra giá trị như mong đợi.
Đây cũng là điểm tôi thấy cần lưu ý khi sử dụng AI để phát triển phần mềm.
Trước đây, thời gian triển khai có thể là một trong những rào cản lớn. Một ý tưởng cần nhiều giờ lập trình, kiểm thử và chỉnh sửa mới có thể trở thành sản phẩm dùng được.
Giờ đây, AI giúp rút ngắn đáng kể khoảng thời gian đó. Nhưng khi việc triển khai trở nên dễ dàng hơn, chúng ta cũng dễ rơi vào cái bẫy làm quá nhiều tính năng trước khi thực sự kiểm chứng xem chúng có cần thiết hay không.
AI giúp chúng ta viết code nhanh hơn, nhưng không tự động giúp chúng ta hiểu người dùng tốt hơn.
Với một website WordPress, điều này cũng không khác biệt. Chúng ta có thể dùng AI để tạo một plugin, viết một custom element cho Bricks Builder, bổ sung tính năng cho WooCommerce hay xây dựng một hệ thống quản lý nội dung riêng.
Nhưng nếu khách hàng không biết cách sử dụng, quy trình quá phức tạp hoặc tính năng không giải quyết đúng vấn đề, thì việc hoàn thành code nhanh hơn cũng không làm sản phẩm tốt lên.
Những người dùng đầu tiên
Điều tôi thích nhất trong trải nghiệm lần này là những phản hồi đến từ những người không có kiến thức kỹ thuật.
Vợ và các con không quan tâm ứng dụng được viết bằng ngôn ngữ gì, sử dụng framework nào hay tôi đã mất bao nhiêu giờ để hoàn thiện nó. Chúng chỉ quan tâm có dùng được hay không, có giúp giải quyết việc của mình hay không.
Chính vì vậy, những phản hồi của họ đôi khi rất trực tiếp và thực tế.
Tôi không cần phải tổ chức một buổi kiểm thử phức tạp để phát hiện ra rằng một tính năng khó hiểu. Chỉ cần quan sát cách vợ sử dụng ứng dụng, nghe những câu hỏi cô ấy đặt ra và xem con tôi thử hỏi AI những gì, tôi đã có thêm những tình huống mà trước đó mình chưa nghĩ đến.
Dĩ nhiên, gia đình không thể đại diện cho toàn bộ nhóm khách hàng mục tiêu. Nhưng với một sản phẩm đang trong giai đoạn thử nghiệm, đây là điểm khởi đầu tốt để phát hiện những vấn đề cơ bản.
Sau đó, khi sản phẩm phát triển hơn, mình vẫn cần kiểm thử với những người dùng thực sự thuộc nhóm khách hàng mục tiêu, theo dõi cách họ sử dụng và điều chỉnh dựa trên dữ liệu thực tế.
Điều quan trọng là đừng chỉ kiểm tra xem tính năng có hoạt động đúng như code hay không. Hãy kiểm tra xem người dùng có thể hoàn thành công việc họ cần làm hay không.
Lời kết
Tôi vẫn rất thích vibe coding và sẽ tiếp tục sử dụng AI để phát triển những ý tưởng của mình. Khả năng biến một ý tưởng thành ứng dụng thực tế trong thời gian ngắn là điều rất đáng giá, đặc biệt với những developer tự làm sản phẩm mà không có một đội ngũ lớn phía sau.
Nhưng trải nghiệm tuần này nhắc tôi rằng, code chỉ là một phần của quá trình xây dựng sản phẩm.
Một sản phẩm tốt không nhất thiết phải có thật nhiều tính năng, giao diện thật đẹp hay sử dụng những công nghệ mới nhất. Nó cần giải quyết được vấn đề của người dùng, dễ sử dụng và hoạt động đáng tin cậy trong những tình huống thực tế.
Đôi khi, bài học đáng giá nhất không đến từ một công nghệ mới hay một kỹ thuật lập trình phức tạp, mà đến từ việc nhìn một người khác sử dụng chính sản phẩm mình đã xây dựng.
Với tôi, đó cũng là một trong những điều thú vị nhất khi làm phần mềm: mỗi lần đưa sản phẩm ra sử dụng thực tế, mình lại có thêm cơ hội học hỏi và làm tốt hơn.
AI có thể giúp chúng ta xây dựng nhanh hơn. Nhưng để xây dựng đúng thứ người dùng cần, có lẽ chúng ta vẫn phải tự mình quan sát, lắng nghe và học hỏi mỗi ngày.
