JTBD – Jobs To Be Done là gì và ứng dụng trong UX Design
Định nghĩa
Jobs To Be Done – thường viết tắt là JTBD – là một framework giúp hiểu tại sao người dùng thực sự sử dụng một sản phẩm, không phải họ là ai hay họ dùng nó như thế nào.
Câu hỏi trung tâm của JTBD là: “Người dùng đang ‘thuê’ sản phẩm này để làm việc gì?”
Ẩn dụ “thuê” (hire) là cốt lõi của framework này – ý tưởng do Clayton Christensen phổ biến: người ta không mua sản phẩm vì những tính năng của nó, mà vì họ có một “công việc” cần hoàn thành trong cuộc sống, và họ “thuê” sản phẩm để làm công việc đó. Khi sản phẩm làm tốt công việc đó, người dùng tiếp tục dùng. Khi có thứ khác làm tốt hơn, họ “sa thải” sản phẩm cũ và “thuê” cái mới.
Ví dụ kinh điển của Christensen: McDonald’s muốn tăng doanh số milkshake buổi sáng. Họ khảo sát khách hàng, cải thiện hương vị, điều chỉnh kích cỡ – doanh số không tăng. Sau đó team nghiên cứu quan sát thực tế và phát hiện: phần lớn milkshake được mua vào buổi sáng bởi người đi làm một mình. “Công việc” của milkshake không phải là “làm đồ uống ngon” – mà là “giữ tôi đỡ buồn mồm và no trong suốt chuyến đi dài, chỉ cần một tay.” Khi hiểu đúng job, họ mới biết cần cải thiện gì: làm milkshake đặc hơn để uống lâu hơn, không phải ngon hơn.
JTBD khác gì so với User Persona và User Story?
Ba công cụ này thường bị nhầm lẫn vì cùng hướng đến việc “hiểu người dùng” – nhưng chúng trả lời ba câu hỏi khác nhau hoàn toàn.
User Persona trả lời: Người dùng là ai? – tuổi tác, nghề nghiệp, hành vi, mục tiêu. Persona mô tả đặc điểm của người dùng.
User Story trả lời: Người dùng muốn làm gì trong sản phẩm? – “Với tư cách là [vai trò], tôi muốn [hành động] để [lý do].” User Story mô tả tính năng từ góc nhìn người dùng.
JTBD trả lời: Tại sao người dùng cần giải quyết điều đó? – bối cảnh sâu hơn, động lực thực sự đằng sau hành động, và tiến trình họ đang cố gắng đạt được trong cuộc sống.
Ví dụ cụ thể với một app nghe nhạc:
- Persona: “Minh, 25 tuổi, nhân viên văn phòng, thích nghe nhạc khi di chuyển.”
- User Story: “Với tư cách là người dùng, tôi muốn tạo playlist để nghe nhạc theo tâm trạng.”
- JTBD: “Khi tôi đang làm việc trong môi trường ồn ào và cần tập trung, tôi muốn tạo ra một không gian tinh thần riêng để có thể hoàn thành công việc hiệu quả hơn.”
JTBD cho thấy người dùng không thực sự “cần một playlist” – họ cần “tạo ra không gian tập trung”. Điều này mở ra những hướng giải pháp khác nhau hoàn toàn: focus mode, ambient sound, timer tích hợp – những thứ một playlist đơn thuần không thể làm được.
Hai trường phái JTBD phổ biến
JTBD không có một chuẩn duy nhất – có hai cách tiếp cận chính, phù hợp với mục đích khác nhau:
Trường phái Christensen (Outcome-driven) – tập trung vào “job” như một đơn vị phân tích ổn định theo thời gian. Job không thay đổi, chỉ có giải pháp thay đổi. Người ta luôn cần “di chuyển từ điểm A đến điểm B nhanh chóng” – xe ngựa, ô tô, Grab đều là giải pháp khác nhau cho cùng một job. Trường phái này phổ biến trong innovation strategy và product-market fit.
Trường phái Ulwick (ODI – Outcome-Driven Innovation) – cụ thể hóa hơn, dùng JTBD để xác định “desired outcomes” – những tiêu chí mà người dùng dùng để đánh giá xem job có được hoàn thành tốt hay không. Từ đó đo lường mức độ underserved của từng outcome để ưu tiên cải tiến sản phẩm.
Trong thực hành UX Product hàng ngày, trường phái Christensen thường dễ áp dụng hơn vì định tính và không yêu cầu bộ dữ liệu lớn. Trường phái Ulwick phù hợp hơn khi cần ra quyết định ưu tiên tính năng có căn cứ định lượng.
Cấu trúc của một Job Statement
Một JTBD được viết rõ ràng thường có dạng:
“Khi [bối cảnh/tình huống], tôi muốn [hành động/tiến trình], để tôi có thể [kết quả mong muốn].”
Khác với User Story, Job Statement nhấn mạnh vào bối cảnh (khi nào, trong tình huống gì) và kết quả cuộc sống (không phải kết quả trong sản phẩm). Nó không đề cập đến giải pháp cụ thể hay tính năng – chỉ mô tả tiến trình người dùng đang cố gắng hoàn thành.
Ví dụ so sánh:
| Không phải JTBD | JTBD đúng |
|---|---|
| “Tôi muốn tìm nhà hàng gần đây” | “Khi tôi đang đón khách từ xa đến và muốn tạo ấn tượng tốt, tôi muốn tìm được chỗ ăn phù hợp nhanh chóng mà không cần phải nghiên cứu nhiều, để buổi gặp gỡ diễn ra tốt đẹp.” |
| “Tôi muốn đặt lịch nhắc nhở” | “Khi tôi đang bận và biết mình sẽ quên điều quan trọng, tôi muốn được nhắc đúng lúc và đúng ngữ cảnh, để tôi không bỏ lỡ thứ gì ảnh hưởng đến người khác.” |
Các bước thực hiện JTBD research
Bước 1: Xác định scope
Bắt đầu bằng cách xác định rõ: bạn đang nghiên cứu job ở cấp độ nào? Job lớn (main job) hay job nhỏ hơn trong một bước cụ thể của hành trình (micro job)?
Ví dụ với app quản lý tài chính cá nhân:
- Main job: “Kiểm soát tài chính để không lo lắng về tiền bạc vào cuối tháng”
- Micro job: “Khi tôi vừa chi tiêu, tôi muốn ghi lại ngay lập tức để không quên”
Bắt đầu từ main job cho direction chiến lược; dùng micro job để ra quyết định tính năng cụ thể.
Bước 2: Switch Interview – phỏng vấn về thời điểm chuyển đổi
Đây là phương pháp research đặc trưng của JTBD, khác với user interview thông thường. Thay vì hỏi người dùng hiện tại về trải nghiệm của họ, bạn tìm người vừa chuyển sang dùng sản phẩm của bạn (hoặc vừa bỏ sản phẩm cũ) và hỏi về quá trình ra quyết định đó.
Câu hỏi theo framework “Four Forces”:
Về lực đẩy (push từ sản phẩm cũ):
- “Bạn đang dùng gì trước khi chuyển sang đây?”
- “Điều gì khiến bạn bắt đầu tìm giải pháp khác?”
- “Khoảnh khắc nào là giọt nước tràn ly?”
Về lực kéo (pull từ sản phẩm mới):
- “Điều gì khiến bạn chọn cái này thay vì các lựa chọn khác?”
- “Bạn kỳ vọng nó sẽ giúp bạn làm được gì?”
Về lực cản (anxiety – lo ngại khi chuyển):
- “Bạn có băn khoăn gì trước khi quyết định dùng thử không?”
- “Điều gì suýt khiến bạn không chuyển sang?”
Về lực giữ (habit – thói quen cũ):
- “Bạn có thứ gì đang hoạt động tốt với giải pháp cũ mà bạn lo sẽ mất không?”
Bước 3: Tổng hợp và xác định Job
Sau khi có dữ liệu từ 8–12 switch interview, tổng hợp theo pattern:
- Bối cảnh nào xuất hiện nhiều nhất khi người dùng quyết định chuyển?
- Kết quả nào họ thực sự muốn đạt được (không phải tính năng họ nhắc đến)?
- “Đối thủ” thực sự của sản phẩm là gì – không phải competitor trực tiếp mà là những gì người dùng dùng thay thế trước đây (kể cả Excel, giấy tờ, hay không làm gì cả)?
Viết Job Statement dựa trên ngôn ngữ thực tế của người dùng, không phải ngôn ngữ team nội bộ.
Bước 4: Phân tích “Job executor” và “Job map”
Sau khi có job chính, phân tích thêm:
Job executor: Ai là người thực sự thực hiện job? Trong sản phẩm B2B, người mua (buyer) và người dùng (user) có thể khác nhau và có jobs khác nhau.
Job map: Chia job thành các bước nhỏ theo thứ tự – từ lúc người dùng nhận ra nhu cầu đến lúc job được hoàn thành. Mỗi bước là cơ hội để sản phẩm hỗ trợ hoặc cản trở.
Bước 5: Map với sản phẩm hiện tại
Đối chiếu job map với sản phẩm: bước nào đang được hỗ trợ tốt, bước nào còn friction, và bước nào sản phẩm hiện tại không hỗ trợ gì cả. Khoảng trống đó là cơ hội.
Ý nghĩa JTBD mang lại
Thoát khỏi bẫy “tính năng theo yêu cầu”
Khi không có JTBD, roadmap sản phẩm thường bị chi phối bởi những feature request từ stakeholder và người dùng – những người nói “tôi muốn X” mà không biết tại sao họ muốn X. JTBD giúp team đặt câu hỏi đúng: “Tính năng này phục vụ job gì?” Nếu không trả lời được câu đó, tính năng đó không nên được xây.
Mở rộng góc nhìn về “đối thủ cạnh tranh”
JTBD thay đổi cách nhìn về competition. Nếu job của Grab là “đến đúng chỗ, đúng giờ, không stress”, thì đối thủ của Grab không chỉ là Gojek – mà còn là xe buýt, ô tô cá nhân, và quyết định “không đi nữa”. Insight này dẫn đến những quyết định product và marketing rất khác so với chỉ so sánh feature với Gojek.
Giúp thiết kế đúng khoảnh khắc, không chỉ đúng tính năng
JTBD nhấn mạnh bối cảnh – “khi nào” quan trọng không kém “cái gì”. Một notification được gửi đúng lúc người dùng cần làm job đó sẽ hiệu quả hơn hàng chục tính năng được build thêm vào. Designer hiểu job của người dùng có thể thiết kế trigger, onboarding, và empty state phù hợp với đúng bối cảnh thay vì thiết kế generic.
Tạo alignment giữa các team
Job Statement là ngôn ngữ chung mà cả Product Designer, PM, Engineer, và Marketing đều có thể đồng ý – vì nó mô tả kết quả người dùng muốn, không phải giải pháp cụ thể. Khi cả team đồng ý về job, cuộc thảo luận về tính năng có căn cứ hơn: “Cách nào giúp người dùng hoàn thành job này tốt hơn?” thay vì “Chúng ta nên thêm tính năng này hay tính năng kia?”
Ví dụ ứng dụng JTBD trong thực tế
Ví dụ 1: App học ngoại ngữ
Research thông thường sẽ cho ra persona: “Người học tiếng Anh 22–35 tuổi, muốn cải thiện kỹ năng giao tiếp.” Và tính năng theo yêu cầu: thêm nhiều bài học hơn, thêm từ vựng hơn, thêm gamification.
JTBD switch interview phát hiện một pattern bất ngờ: nhiều người download app ngay sau khi nhận được email thông báo họ vừa được mời phỏng vấn ở công ty nước ngoài. Job thực sự không phải “học tiếng Anh” – mà là “chuẩn bị đủ tự tin cho một cuộc phỏng vấn quan trọng trong 2 tuần tới.”
Insight này dẫn đến thiết kế khác hoàn toàn: onboarding hỏi về mục tiêu cụ thể và timeline, curated track ngắn hạn tập trung vào interview vocabulary, progress indicator theo ngày đếm ngược. Thay vì một app “học ngôn ngữ toàn diện”, sản phẩm trở thành “coach chuẩn bị interview” – và retention cải thiện đáng kể.
Ví dụ 2: Công cụ quản lý project
Team nhận ra sản phẩm của họ đang thua Notion dù có nhiều tính năng project management hơn. Switch interview với người vừa rời sản phẩm tiết lộ: job của nhiều người không phải “quản lý project” – mà là “luôn biết mình cần làm gì tiếp theo mà không cần suy nghĩ nhiều.” Họ rời vì sản phẩm quá phức tạp – quá nhiều tùy chọn khiến việc quyết định “task nào tiếp theo” trở nên mệt mỏi hơn là dễ hơn.
Redesign tập trung vào một màn hình duy nhất: “Today’s focus” – ba task quan trọng nhất cho hôm nay, được gợi ý tự động dựa trên deadline và priority. Không cần thêm tính năng, chỉ cần làm rõ job.
Ví dụ 3: E-commerce
Một trang thương mại điện tử thấy tỷ lệ abandon cart cao ở bước chọn size quần áo. Hypothesis ban đầu: UI size chart không rõ. Sau khi làm JTBD interview, insight khác xuất hiện: người dùng không uncertain về size của mình – họ uncertain về việc size đó có fit với body họ cụ thể không, vì cùng một size từ brand khác nhau thì khác nhau. Job thực sự: “Tôi muốn tự tin rằng đồ này sẽ vừa với tôi trước khi đặt hàng, để tôi không phải mất công đổi trả.”
Giải pháp không phải là cải thiện UI size chart mà là thêm tính năng so sánh measurements thực tế của sản phẩm với measurements cơ thể người dùng, và hiển thị feedback từ người có cùng số đo. Conversion tăng, return rate giảm.
Kết luận
JTBD không phải công cụ để thay thế Persona hay User Story – mà là lens bổ sung giúp nhìn sâu hơn vào lý do đằng sau hành vi người dùng.
Điều JTBD làm tốt nhất là phá vỡ những giả định mà team đang có về “người dùng muốn gì” bằng cách buộc mọi người trả lời một câu hỏi khó hơn: tại sao người dùng thực sự cần giải quyết điều đó, trong bối cảnh cuộc sống của họ là gì, và sản phẩm của bạn đang được “thuê” để làm gì?
Khi team đồng ý về câu trả lời cho câu hỏi đó, mọi quyết định về tính năng, thiết kế, và ưu tiên đều trở nên rõ ràng hơn – không phải vì JTBD cho bạn đáp án, mà vì nó cho bạn đúng câu hỏi để hỏi.
Học để trở thành một UI/UX Designer có khi bị hiểu nhầm là học để vẽ ra những màn hình thật đẹp hoặc giao diện thật ấn tượng là đủ. Kỳ thực, thẩm mỹ và sáng tạo về mặt hình ảnh chỉ là phần nổi của một quá trình khoa học & khuôn khổ hơn. Điều đó không khiến cho thiết kế của bạn trở nên bó buộc hơn mà trái lại, nó khiến sản phẩm của bạn có lý lẽ hơn, giá trị hơn và ít nhất là bạn cũng biết bạn đang thiết kế vì điều gì.
Các thuật ngữ như JTBD, Usability, Double Diamond đều là một phần hết sức quan trọng trong hành trình làm nghề, sẽ được mang đến cho các bạn qua lộ trình đào tạo UI/UX Designer tại TELOS Academy. Nếu bạn quan tâm và muốn nghiêm túc trở thành một UI/UX Designer hãy đăng ký ngay tại form này.
