Người Dùng Ngân Hàng Châu Á Không Nên Được “Phân Khúc” Mà Cần Được “Mô Hình Hóa”

Vấn đề với cách làm truyền thống

Phần lớn các ngân hàng bán lẻ ở châu Á vẫn đang chia khách hàng theo một trục quen thuộc:

Mass

→ Upper Mass

→ Mass Affluent

→ Affluent/Premier

→ High Net Worth

→ Private Banking

Đây là một hệ thống hợp lý — nhưng chỉ hợp lý cho business, không hợp lý cho product. Nó trả lời tốt câu hỏi “khách hàng này đáng giá bao nhiêu, nên phục vụ ở tier nào”, nhưng gần như vô dụng khi đội thiết kế cần trả lời câu hỏi thực dụng hơn: “màn hình chủ nên hiển thị gì cho người này, và tại sao lại khác với người kia?”

Lý do đơn giản: hai khách hàng cùng nằm trong nhóm Mass Affluent có thể khác nhau hoàn toàn về mức độ hiểu biết tài chính, mức độ sẵn sàng tự quyết định, kênh giao tiếp ưa thích, và số lượng mối quan hệ ngân hàng họ đang duy trì song song. Wealth tier không dự đoán được hành vi số.

Ba lớp câu hỏi, không phải một

Cách tiếp cận đáng tin cậy hơn tách vấn đề thành ba lớp câu hỏi riêng biệt, thay vì cố nhồi tất cả vào một persona duy nhất:

1. Vị trí trong customer base — Đây là khách hàng thuộc phân khúc kinh tế/quan hệ nào?

2. Cách họ ra quyết định tài chính — Họ hành xử, học hỏi, và chấp nhận rủi ro như thế nào?

3. App cần biết gì để phản ứng khác đi — Trạng thái hiện tại của họ là gì, và điều đó nên thay đổi trải nghiệm ra sao?

Ba lớp này tương ứng với ba giai đoạn: Segmentation (A) → Behavioral Model (B) → Digital User Model (C). Bỏ qua giai đoạn B — tức là đi thẳng từ segmentation sang UX — là lỗi phổ biến nhất, vì nó khiến thiết kế mặc định rằng “giàu hơn = cần trải nghiệm phức tạp hơn”, một giả định thường sai.

Share

Nguyên tắc chọn biến: bài kiểm tra bắt buộc

Không phải biến phân khúc nào cũng đáng đưa vào mô hình thiết kế. Có một phép thử rất rõ ràng để lọc:

Khi giá trị của biến thay đổi, ít nhất một quyết định sản phẩm/thiết kế cũng phải thay đổi theo.

Ví dụ: biến “độ tuổi” thường không qua được bài test này — hai người 25 tuổi và 45 tuổi có thể có cùng mức độ tự chủ tài chính, cùng khẩu vị rủi ro. Ngược lại, biến “mức độ tinh vi tài chính” (financial sophistication) luôn qua được test, vì nó trực tiếp quyết định mật độ thông tin, thuật ngữ, và mức độ hướng dẫn cần hiển thị.

Đây là lý do các mô hình phân khúc nhân khẩu học (tuổi, giới tính, khu vực địa lý) chỉ nên đóng vai trò “context” ở mức ưu tiên thấp, trong khi behavioral segmentation, financial maturity, và transaction data (hành vi quan sát được) mới là xương sống thực sự.

Từ hồ sơ tĩnh sang trạng thái động

Điểm quan trọng nhất mà nhiều mô hình user bỏ sót: một người không hành xử giống nhau ở mọi tình huống. Cùng một khách hàng:

• Kiểm tra lương về → hành vi thường lệ, tự tin, thao tác nhanh

• Chuyển khoản nhỏ → tự chủ hoàn toàn, không cần giải thích

• Đầu tư một khoản lớn lần đầu → tìm kiếm thông tin, cần tư vấn, chậm rãi

• Thẻ bị khóa → khẩn cấp, cần hỗ trợ con người ngay lập tức

Đây chính là lý do khái niệm “persona” — vốn tĩnh và mô tả một con người cố định — không đủ sức làm nền tảng cho thiết kế trải nghiệm ngân hàng số. Cần công thức:

Persistent Profile (chậm thay đổi) + Current State (thay đổi nhanh) → Product Response

Hồ sơ tĩnh gồm: wealth tier, mức độ trưởng thành trong quan hệ với ngân hàng, mức độ tinh vi tài chính, kênh ưa thích, khẩu vị rủi ro. Trạng thái động gồm: ý định hiện tại, bối cảnh giao dịch, sự kiện đời sống vừa xảy ra (life event), mức độ khẩn cấp, tín hiệu rủi ro.

Cùng một persona, nhưng khi state đổi từ “thanh toán thường lệ” sang “chuyển khoản bất thường giá trị lớn”, trải nghiệm bắt buộc phải đổi — từ shortcut một chạm sang xác thực bổ sung và cảnh báo gian lận.

Leave a comment

Bộ khung thực dụng cho bối cảnh châu Á ( recommended )

Với các thị trường như Việt Nam, Thái Lan, Indonesia — nơi mức độ đa dạng về digital adoption và mức độ chồng lấn giữa ngân hàng truyền thống, ví điện tử, và fintech rất cao — ba trục nên được ưu tiên nghiên cứu sâu nhất là:

• Needs-based segmentation — cầu nối trực tiếp từ business sang UX, vì nó mô tả outcome khách hàng muốn đạt được (không phải sản phẩm họ mua)

• Behavioral segmentation — dự đoán hành vi tốt hơn bất kỳ biến nhân khẩu học nào

• State modelling — nền tảng bắt buộc cho cá nhân hóa thời gian thực

Wealth, life-stage, và product holding vẫn có giá trị, nhưng nên đóng vai trò biến hỗ trợ (supporting variables) chứ không phải trục chính.

Nếu một engagement thiết kế chiến lược dành 60-70% thời gian cho market segmentation kiểu truyền thống (thứ vốn thuộc về business/marketing), phần còn lại cho behavioral model và digital user model sẽ không đủ sâu để tạo ra experience rules thực sự khác biệt. Tỷ lệ hợp lý hơn nghiêng hẳn về phía B và C — vì đây mới là phần trực tiếp quyết định app sẽ trông và hành xử ra sao.

Có thể mô hình này bạn thấy không quen, nhưng nếu bạn đang tiến đến xây dựng “conversational design” hay “contextual design” hay “AI-assisted financial advisor” thì đây là cái base bạn nên biết để hiểu và framing kịch bản.

Chốt lại là …

Câu hỏi cuối cùng không phải là “khách hàng này thuộc segment nào”, mà là:

Khi người dùng khác nhau hoặc trạng thái của họ thay đổi, sản phẩm nên phản ứng khác nhau như thế nào?

Một mô hình người dùng ngân hàng số hữu ích phải trả lời được câu hỏi này ở cấp độ từng quyết định thiết kế — home screen hiển thị gì, có đưa RM vào hành trình không, transfer flow cần bao nhiêu friction — chứ không dừng lại ở việc mô tả một nhóm khách hàng trông như thế nào.

Bài này được viết trong thời gian khá critical với tôi. Nó cũng là thai nghén từ rất nhiều cuộc tranh cãi từ hồi ở cty CX và đến h là UX. Hy vọng nó sẽ giúp con đường nghiên cứu người dùng của bạn chính xác hơn và rõ ràng kết nối với business impact hơn.

Reference: https://www.mckinsey.com/vn/our-insights/wealth-management-in-vietnam-a-600-billion-wealth-market-by-2027?utm_source=chatgpt.com#segments

Khi tôi nhìn lại những lần người dùng bỏ ngang một flow, né tránh một form, hoặc không tin một lời mời gọi trong sản phẩm, tôi nhận ra rằng hành vi hiếm khi bắt đầu từ chính hành động. Người dùng không “tự nhiên” bấm, thoát, trì hoãn, né tránh, tin tưởng, hay hợp tác. Trước khi hành động xuất hiện, họ đã đánh giá tình huống theo một cách nào đó. Họ tự hỏi, dù rất nhanh và đôi khi không ý thức rõ: “Việc này có liên quan gì đến tôi không?”, “Nó có nguy hiểm không?”, “Nó có đáng công không?”, và “Tôi có đủ khả năng để xử lý không?”.

Thiết kế hành vi là thiết kế cách người dùng diễn giải tình huống.

Cách hiểu này gần với lý thuyết appraisal ( Appraisal Theory ) của Richard Lazarus. Theo hướng tiếp cận này, cảm xúc không chỉ là phản ứng bộc phát, mà là kết quả của việc con người đánh giá mối quan hệ giữa bản thân và hoàn cảnh. Appraisal sơ cấp giúp một người xác định sự kiện có liên quan đến mục tiêu, nhu cầu, hay sự an toàn của họ hay không. Appraisal thứ cấp giúp họ ước lượng khả năng ứng phó, nguồn lực, trách nhiệm và hệ quả tiếp theo. Nói đơn giản hơn, người dùng không chỉ phản ứng với màn hình; họ phản ứng với ý nghĩa mà màn hình đó tạo ra trong đầu họ.

Đối với UX designer, điểm này có ý nghĩa gì? Một thông báo lỗi có thể được người dùng đánh giá là “mình làm sai”, “hệ thống đang trách mình”, hoặc “mình vẫn có thể sửa được”. Ba cách đánh giá đó dẫn đến ba cảm xúc và ba hành vi khác nhau. Nếu người dùng thấy mình bị phán xét, họ có thể né tránh. Nếu họ thấy vấn đề có thể xử lý, họ có thể tiếp tục. Vì vậy, thiết kế hành vi không chỉ là sắp xếp CTA, giảm số bước, hay làm giao diện đẹp hơn.

Sau appraisal, hệ động lực của con người bắt đầu kéo hành vi theo hai hướng lớn: tiếp cận hoặc né tránh.

• Hệ tiếp cận được kích hoạt khi con người thấy một kết quả đáng muốn, chẳng hạn như lợi ích, sự công nhận, phần thưởng, sự tiến bộ, hoặc cảm giác hoàn tất.

• Hệ né tránh được kích hoạt khi con người thấy rủi ro, mất mát, xấu hổ, bị đánh giá, bị lừa, hoặc phải bỏ quá nhiều công sức.

Trong khoa học thần kinh, các nghiên cứu về reward thường nhắc đến vai trò của dopamine, ventral striatum và các vùng liên quan đến động lực, học từ phần thưởng và hành vi tiến tới mục tiêu. Tuy nhiên, reward không nên bị hiểu hẹp là “khoái cảm”. Reward còn là tín hiệu khiến một hành động trở nên đáng theo đuổi.

Với sản phẩm số, cùng một tính năng có thể kích hoạt hai hệ này cùng lúc. Một nút “nâng cấp gói” có thể gợi ra lợi ích rõ ràng, nhưng nó cũng có thể gợi ra nỗi sợ bị trừ tiền, bị khóa tính năng, hoặc bị mắc kẹt trong cam kết. Một form đăng ký có thể mở ra giá trị, nhưng nó cũng có thể làm người dùng thấy mình đang giao dữ liệu cá nhân cho một tổ chức chưa đủ đáng tin. Nếu designer chỉ tối ưu phần thưởng mà bỏ qua nỗi sợ, flow vẫn có thể thất bại. Người dùng không chỉ hỏi “tôi được gì?”, họ còn hỏi “tôi có thể mất gì?”. Đây có thể chính là những câu hỏi chúng ta cần ghi nhận khi làm user interview. Đôi khi cách chúng ta nghĩ và cách khách hàng đánh giá không như nhau. Ta đâu có biết họ lựa chọn vì động lực gì trong context cá nhân ntn.

Cảm xúc nằm ở giữa quá trình đó như một cơ chế điều phối

Cảm xúc không chỉ là thứ xuất hiện sau hành vi, cũng không chỉ là “màu sắc” của trải nghiệm. Cảm xúc tổ chức sự chú ý, trí nhớ, kỳ vọng và phản ứng cơ thể để giúp con người xử lý một vấn đề thích nghi. Sợ hãi làm con người chú ý tới nguy cơ. Xấu hổ khiến con người quan tâm tới chuẩn mực xã hội. Tự hào củng cố cảm giác năng lực. Tin tưởng làm giảm chi phí tâm lý của việc hợp tác. Vì vậy, khi một sản phẩm tạo ra cảm xúc, sản phẩm đó cũng đang định hướng sự chú ý và hành động của người dùng.

Điểm này giúp tôi thận trọng hơn khi nói về “thiết kế cảm xúc”. Thiết kế cảm xúc không phải là làm cho người dùng vui mọi lúc. Một trải nghiệm tốt có thể cần sự nghiêm túc, cảm giác kiểm soát, sự yên tâm, hoặc một chút ma sát đúng chỗ. Ví dụ, trong luồng chuyển tiền, sự trơn tru tuyệt đối có thể làm tăng rủi ro. Một bước xác nhận rõ ràng có thể làm chậm người dùng, nhưng nó giúp họ đánh giá rằng hệ thống đang bảo vệ họ. Khi cảm xúc phù hợp với ngữ cảnh, hành vi mong muốn sẽ có nền tảng bền hơn.

Cultural Display rules - Yếu tố văn hoá tác động đến hành vi của con người

Tầng tiếp theo là văn hóa. Con người không biểu lộ cảm xúc trong khoảng trống. Họ học từ gia đình, trường học, nơi làm việc và cộng đồng về việc khi nào nên thể hiện, khi nào nên kiềm chế, và khi nào nên che giấu cảm xúc. Nghiên cứu về display rules cho thấy các quy tắc biểu lộ cảm xúc khác nhau giữa các nền văn hóa, nhóm xã hội và bối cảnh quan hệ. Một nghiên cứu quy mô lớn của Matsumoto, Yoo và Fontaine với hơn 5.000 người ở 32 quốc gia cho thấy con người thường biểu lộ khác nhau với người trong nhóm và ngoài nhóm, đồng thời văn hóa cá nhân chủ nghĩa và tập thể chủ nghĩa có khác biệt về chuẩn mực biểu đạt cảm xúc. Điều này nhắc designer rằng người Việt không phải là một “persona văn hóa” đơn giản, nhưng bối cảnh Việt Nam vẫn có những động lực xã hội cần được tôn trọng.

Trong trải nghiệm dành cho người Việt, những yếu tố như thể diện, sự tin cậy, quan hệ quen biết, trách nhiệm với gia đình, và cảm giác “đừng làm phiền người khác” có thể ảnh hưởng mạnh đến hành vi. Một người dùng có thể không đặt câu hỏi trong nhóm hỗ trợ vì họ sợ bị xem là thiếu hiểu biết ( đây cũng là lý do những người bị cô lập, người già trở thành đối tượng bị lừa đảo nhắm tới nhiều nhất ). Một nhân viên có thể không dùng tính năng phản hồi ẩn danh nếu họ nghi ngờ danh tính của mình vẫn bị lộ. Một phụ huynh có thể quan tâm đến lợi ích cá nhân, nhưng họ dễ bị thuyết phục hơn khi sản phẩm cho thấy lợi ích đó kết nối với sự an tâm của gia đình. Vì vậy, thiết kế cho người Việt cần hiểu động lực xã hội, chứ không chỉ dịch lại pattern từ các sản phẩm phương Tây.

Từ các lớp lý thuyết này, tôi rút ra một khung thực hành cho UX design. Khi muốn thiết kế một hành vi, tôi sẽ không bắt đầu bằng câu hỏi “làm sao để người dùng bấm?”. Tôi sẽ bắt đầu bằng bốn câu hỏi sâu hơn:

• Người dùng đang đánh giá tình huống này như thế nào?

• Họ thấy phần thưởng nào đủ đáng để tiến tới?

• Họ thấy rủi ro nào khiến họ né tránh?

• Và bối cảnh xã hội hoặc văn hóa nào đang định dạng cách họ biểu hiện nhu cầu thật?

Nếu câu trả lời cho bốn câu hỏi này rõ ràng, giải pháp thiết kế thường trở nên chính xác hơn ( hoặc ít nhất lúc report nghe nó không bị chung chung ):

• Designer có thể viết microcopy giúp người dùng tái đánh giá lỗi như một việc có thể sửa.

• Designer có thể làm rõ lợi ích để kích hoạt hệ tiếp cận.

• Designer có thể giảm bất định, tăng minh bạch và cho phép kiểm soát để giảm hệ né tránh.

• Designer cũng có thể chọn cách kể chuyện phù hợp với văn hóa, chẳng hạn nhấn mạnh sự an tâm, trách nhiệm, cam kết, hoặc lợi ích cho những người quan trọng quanh người dùng.

Tôi cho rằng thiết kế hành vi tốt không phải ( hoặc không chỉ, haha, đoạn này tôi cũng tà đạo lắm ) là thao túng người dùng. Thiết kế hành vi tốt là làm cho tình huống trở nên dễ hiểu hơn, an toàn hơn, có ý nghĩa hơn và phù hợp hơn với đời sống thật của con người. Khi designer hiểu appraisal, động lực tiếp cận và né tránh là gì, cảm xúc và văn hóa của người dùng, họ sẽ bớt nhìn người dùng như một chuỗi click. Họ sẽ bắt đầu nhìn người dùng như một con người đang liên tục diễn giải thế giới, bảo vệ bản thân, tìm kiếm giá trị, giữ gìn quan hệ và cố gắng hành động theo cách có lý trong hoàn cảnh của họ.

Share

Nguồn nghiên cứu:

• Về 7 Unniversal emotion https://www.paulekman.com/universal-emotions/

• Về Appraisal Theory of emotion https://www.researchgate.net/publication/315311200_Appraisal_Theory_of_Emotion

“Mình nên dùng Interview hay Usability Test?” Đây có lẽ là câu hỏi phổ biến nhất của những người mới học UX Research. Nhưng thực tế, đây lại là câu hỏi khiến rất nhiều dự án đi sai hướng ngay từ đầu.

UX Research không phải là cuộc thi xem ai biết nhiều method hơn

Trong nhiều khóa học, UX Research được dạy như một danh sách/ cheat sheet để tìm ra painpoint của người dùng:

• Interview

• Survey

• Usability Test

• Diary Study

• Card Sorting

• Tree Test

• A/B Testing

• Analytics

Điều đó khiến nhiều người hình thành một thói quen rất nguy hiểm:

Có vấn đề → Chọn một method.

Trong khi những researcher giàu kinh nghiệm lại làm ngược lại.

Họ không hỏi:

“Method nào tốt nhất?”

Họ hỏi:

“Chúng ta sắp đưa ra quyết định gì?”

Đằng sau lựa chọn của 1 senior researcher là ti tỉ kiến thức về cognitive science, tâm lý học ứng dụng, customer behavior hay behavioral science,… Tôi cũng mất một thời gian loay hoay và nghi ngờ vào những công cụ mình đang nghiên cứu:

• Tại sao trong trường hợp này dùng interview lại chỉ cho ra kết quả hời hợt, thậm chí đoán được từ đầu?

• Phương pháp nghiên cứu này có cung cấp đủ dữ liệu báo cáo không?

• Tại sao UX research bị coi rẻ, thậm chí trong JD thì ghi có phải làm UX research nhưng kết quả sử dụng thật thì UX research không được coi trọng, thậm chí không có nhiều impact, evidence luôn bị chất vấn độ tin cậy?

Sau thời gian loay hoay thì tôi cũng ngờ ngợ ra vài điều:

1. Những người nghi ngờ chất lượng nghiên cứu thật ra rất cần nghiên cứu. Họ cần 1 sự bảo chứng thành công cho việc họ sắp làm hơn là biết nội dung nghiên cứu là gì. Đôi khi câu key output là “ làm theo hướng này 80% conversion rate sẽ tăng “ hơn là 1 insight “ người dùng không hoàn toàn tự tin việc mua sắm được đảm bảo chất lượng do hình ảnh tệ “.

2. Không bao giờ dự án nghiên cứu có được điều kiện lý tưởng. Luôn là 1 yêu cầu nghiên cứu trong 1 thời gian hữu hạn đến mức cực đoan/vô lý với nhu cầu nghiên cứu mập mờ, thậm chí không chỉ rõ behavior nào cần được focus.

3. Sự lựa chọn phương pháp nghiên cứu không phải là đầu ra của 1 research plan. Khi lập plan nghiên cứu, chúng ta còn phải định nghĩa cả phương pháp xử lý raw input đến khi ra refined report là gì, evidence nào cần được tìm ra.

4. Mọi sự nghiên cứu đều phải làm rõ giới hạn của nó. Giới hạn này chính là 1 điểm để người đọc nghiên cứu biết họ nên tin ở mức độ nào thay vì chất vấn người làm nghiên cứu. Nếu sợ trách nhiệm thì có lẽ không nên làm ngành product ( vì nó làm bạn đau tim và stress lắm , không ai đảm bảo cho bạn 100% auto win đâu).

Share

Mọi nghiên cứu đều tồn tại để giảm rủi ro cho một quyết định

Giả sử Product Team đang chuẩn bị redesign màn hình thanh toán. Bạn có thể nghĩ ngay đến việc tổ chức một usability test. Nhưng hãy dừng lại một chút.

Điều nhóm cần biết thực sự là gì?

• Người dùng không hiểu trạng thái thanh toán?

• Người dùng sợ mất tiền?

• Người dùng không tin hệ thống?

• Hay chỉ đơn giản là họ không tìm thấy nút xác nhận?

Đây là bốn vấn đề hoàn toàn khác nhau, mỗi vấn đề sẽ cần những loại bằng chứng khác nhau. Nếu xác định sai câu hỏi nghiên cứu, mọi dữ liệu thu được đều có thể trở nên vô nghĩa.

Method chỉ là công cụ. Evidence mới là mục tiêu.

Một framework research tốt sẽ đi theo trình tự như sau:

1. Xác định quyết định cần đưa ra.

2. Chuyển quyết định thành câu hỏi nghiên cứu.

3. Xác định cơ chế hành vi cần hiểu.

4. Xác định loại bằng chứng cần thu thập.

5. Chọn research method phù hợp.

6. Tổng hợp insight.

7. Chuyển insight thành requirement.

8. Thiết kế giải pháp.

9. Kiểm chứng trước khi ra quyết định.

Điểm quan trọng là bạn không “chọn Interview” → Bạn chọn loại bằng chứng mà Interview có khả năng tạo ra. Để bạn không phải loay hoay như tôi đã từng, gửi bạn cheatsheet tôi nghiên cứu được. Tất nhiên nó không phải 1 cái bible gì cả, chỉ là 1 thứ tôi ngậm ra được và sử dụng bấy lâu hiệu quả.

Research method cheatsheet

Mục tiêu: chọn đúng hình thức UX research và UX design validation dựa trên bối cảnh, nhu cầu hiểu biết, loại hành vi cần quan sát, mức rủi ro của quyết định, và kết quả cần có.

Bước 1 - Xác định câu hỏi nghiên cứu

Trong thực tế, PM hay stakeholder thường quăng ra 1 combo thay vì 1 câu hỏi cụ thể. Tuỳ vào điều kiện hoàn cảnh, ta có thể thương lượng và đặt lại câu hỏi nghiên cứu theo 1-2 loại. ( best là 1, tham thì thâm mà :)) )

Bước 2 - Xác định phương pháp

Kiểu 1: Map từ Dấu hiệu → behavior mechanism cần hiểu → Method

Việc map với behavior mechanism có lợi thế nếu thông tin không có quá nhiều, bạn có thể áp dụng các phương thức hoạt động từ tâm lý học hành vi để thiết kế hành vi mới. Tuy lý thuyết nhưng còn hơn đoán mò.

Kiểu 2: Map từ loại Evidence cần có → Method

Note: Có lẽ bước này cần sự cân nhắc của cả team nhất để lựa chọn ra method phù hợp với context của research hay năng lực của team nhất. Làm 1 mình cũng không sao nhưng sẽ cần rất nhiều kỹ năng để đào ra các vấn đề ẩn sâu dưới lớp behavior bề mặt / dấu hiệu.

Kiểu 3: Map theo giai đoạn design → Method

Giải đoạn problem framing → Concept testing rất quan trọng. Thường thì các PM sẽ làm cùng cái này, outcome của product là của chung nên designer cần học cách collab với BA, PM để có outcome có impact nhất. Lưu ý văn phong trong report, bước này là bước validate, còn decision không nằm trong tay designer. No pressure!

UX Research không chỉ nghiên cứu hành vi

Một trong những điểm thường bị bỏ qua là:

Hành vi chỉ là phần nổi của tảng băng.

Bên dưới còn có:

• Context

• Trigger

• Cách người dùng diễn giải tình huống

• Cảm xúc

• Nhu cầu

• Quyết định

Ví dụ:

Người dùng dừng lại ở màn hình thanh toán. Điều đó không có nghĩa họ “không biết dùng”. Có thể họ đang tự hỏi:

“Tiền đã bị trừ chưa?”

“Nhấn thêm lần nữa có mất tiền hai lần không?”

“Tôi có thể hoàn tiền không?”

Nếu chỉ đo thời gian hoàn thành tác vụ, bạn sẽ không bao giờ nhìn thấy những nỗi lo này.

Validation cũng cần đúng loại bằng chứng

Sau khi thiết kế xong, nhiều đội nhóm chỉ hỏi:

“Người dùng có thích không?”

Nhưng đó hiếm khi là câu hỏi quan trọng nhất. Thay vào đó, hãy hỏi:

• Họ có hiểu không?

• Họ có làm được không?

• Họ có đủ tự tin để tiếp tục không?

• Họ có biết cách phục hồi khi gặp lỗi không?

• Hệ thống đã giảm rủi ro cho quyết định release chưa?

Đó mới là mục tiêu của UX Validation.

Một researcher giỏi không phải là người dùng nhiều method nhất

Mà là người biết:

• Quyết định nào đang được đưa ra.

• Loại bằng chứng nào đủ mạnh để hỗ trợ quyết định đó.

• Giới hạn của từng phương pháp.

• Điều gì vẫn còn chưa biết sau nghiên cứu.

Research không tạo ra sự chắc chắn tuyệt đối. Research giúp đội ngũ giảm sự không chắc chắn trước khi đầu tư thời gian, tiền bạc và nguồn lực.

Đó mới là giá trị thực sự của UX Research.

Kể chuyện nè, đã bao giờ gặp kiểu thế này khi thiết kế UI chưa? Có một ví dụ trong luồng mở tài khoản trực tuyến cho ngân hàng. Nó dạy tôi một bài học theo cách khá... vòng vèo.

Cái nút bấm xong rồi... và khách hàng vẫn ngồi chờ

Đội thiết kế làm cẩn thận từ nghiên cứu, lên ý tưởng, ra wireframe rồi UI. Rút từ 12 bước xuống còn 6 bước. Thời gian hoàn thành giảm gần một nửa. Usability testing cho kết quả tích cực, người dùng hoàn thành nhanh hơn, ít nhầm lẫn hơn, ai cũng gật đầu hài lòng. Cả đội khá tự tin.

Rồi vài tháng sau khi triển khai, phản hồi thực tế bắt đầu về.

“Đăng ký xong rồi mà chẳng thấy ai liên hệ.”

“Hồ sơ gửi từ hôm qua, vẫn chưa biết đang ở đâu.”

“Tôi không biết mình có phải làm lại hay chỉ cần ngồi chờ.”

Ừ thì... ngồi nghe xong cũng hơi chạnh lòng một chút.

Nhưng mà nhờ đó, cả đội nhận ra một điều khá thú vị: khách hàng không đánh giá trải nghiệm dựa trên thời gian họ dùng giao diện. Họ đánh giá trải nghiệm dựa trên thời gian hoàn thành mục tiêu. Và phần lớn khoảng thời gian đó nằm ngoài màn hình, ở một chỗ mà không có wireframe nào chạm tới được.

Khi UX không còn là câu chuyện của UI

Hồi mới vào nghề, nhiều Designer, kể cả tôi, tin rằng trải nghiệm được tạo ra bởi những thứ chúng ta thiết kế: flow, wireframe, content, interaction, visual hierarchy.

Điều đó đúng. Nhưng chỉ đúng một phần.

Khi sản phẩm bắt đầu liên quan đến nhiều bộ phận khác nhau, trải nghiệm không còn được quyết định bởi giao diện nữa. Nó được quyết định bởi cái hệ thống vận hành phía sau mà khách hàng không bao giờ nhìn thấy, nhưng ngày nào cũng cảm nhận được.

Một form đăng ký chỉ mất 5 phút để điền, nhưng nếu hồ sơ phải chờ 72 giờ mới được duyệt, thì trải nghiệm thực tế kéo dài 3 ngày.

Một chatbot có thể trả lời ngay lập tức, nhưng nếu khách hàng vẫn phải đợi thêm 48 giờ để yêu cầu được xử lý, thì cảm nhận cuối cùng vẫn là “dịch vụ chậm”.

Thế là UX bắt đầu chạm vào một khái niệm vốn được nhắc nhiều trong Operations hơn là Design.

Khái niệm đó là SLA.

SLA là gì, và tại sao Designer nên để ý?

SLA — Service Level Agreement — là cam kết về mức độ dịch vụ giữa các bên tham gia vào một quy trình.

Nói nôm na, SLA trả lời những câu hỏi rất thực tế:

• Ai chịu trách nhiệm xử lý?

• Bao lâu phải phản hồi?

• Bao lâu phải hoàn thành?

• Chất lượng tối thiểu cần đạt là gì?

Ví dụ cho dễ hình dung: 80% cuộc gọi được bắt máy trong vòng 20 giây. Khiếu nại được phản hồi trong 24 giờ. Hồ sơ vay vốn xử lý trong 3 ngày làm việc. Từ góc nhìn vận hành, SLA là công cụ quản lý hiệu suất. Khô khan, số liệu, bảng tính.

Từ góc nhìn trải nghiệm khách hàng, SLA lại chính là thứ tạo ra cảm nhận: nhanh hay chậm, được quan tâm hay bị bỏ quên, đáng tin hay không đáng tin. Khách hàng không nhìn thấy SLA. Nhưng họ cảm nhận hậu quả của nó mỗi ngày.

Vậy có bao nhiêu loại SLA? Nếu đứng từ góc độ vận hành doanh nghiệp, ITSM và Service Design, SLA thường được chia thành 3 loại chính.

Bạn có thể đọc tham khảo định nghĩa của các hãng lớn về SLA:

• Amazon AWS: https://aws.amazon.com/vi/what-is/service-level-agreement/

• SLA trong contact center: https://alohub.vn/sla-trong-contact-center-la-gi/

• SLA trong dịch vụ giao nhận, cụ thể là từ GHN: https://ghn.vn/blogs/tip-ban-hang/sla-la-gi

  

[ Tips ] Một số câu hỏi đáng hỏi về SLA dành cho UX design khi tìm hiểu 1 sản phẩm dịch vụ

Không cần biến mình thành chuyên gia vận hành. Nhưng có một vài câu hỏi khá đáng để bỏ túi:

• Về trách nhiệm: Bước này thuộc bộ phận nào? Ai là người chịu trách nhiệm cuối cùng? Có trường hợp nào phải chạy qua nhiều phòng ban không?

• Về thời gian: Thời gian xử lý trung bình là bao lâu? SLA cam kết là bao lâu? Bao nhiêu phần trăm trường hợp đang đạt được SLA đó?

• Về năng lực: Mỗi ngày đội ngũ xử lý được bao nhiêu yêu cầu? Điểm nghẽn lớn nhất nằm ở đâu? Mùa cao điểm có khác gì không?

• Về kỳ vọng khách hàng: Khách hàng đang kỳ vọng bao lâu? SLA hiện tại có đáp ứng được kỳ vọng đó không? Nếu không, doanh nghiệp đang xử lý khoảng cách đó như thế nào?

  Share

Designer không thay đổi được SLA nhưng không phải là bất lực

Thẳng thắn mà nói: Designer hiếm khi có quyền tuyển thêm người, mở rộng đội vận hành, hay thay đổi KPI của các phòng ban khác. Nhưng điều đó không có nghĩa là không làm được gì. Designer thường là người đầu tiên nhìn thấy tác động của SLA lên trải nghiệm. Và từ vị trí đó, chúng ta có thể làm một việc rất cụ thể: không rút ngắn thời gian chờ, nhưng làm cho thời gian chờ trở nên dễ hiểu hơn.

Thử so sánh hai thông báo này:

“Vui lòng chờ xử lý.”

so với

“Hồ sơ đang được thẩm định. Thời gian dự kiến hoàn thành trong vòng 24 giờ.”

Thời gian thực tế giống nhau. Nhưng trải nghiệm hoàn toàn khác nhau.

Con người chấp nhận chờ đợi tốt hơn rất nhiều khi họ biết mình đang ở đâu, điều gì đang diễn ra, ai đang xử lý, và bao giờ thì có kết quả. Đó là lý do những hệ thống theo dõi đơn hàng, theo dõi hồ sơ hay theo dõi yêu cầu hỗ trợ lại có giá trị lớn đến vậy. Chúng không làm quy trình nhanh hơn. Chúng làm quy trình minh bạch hơn.

Nhưng rồi có một điểm mà bạn bắt đầu thấy một điều lạ. Bạn làm rất nhiều research, nhưng sản phẩm vẫn đi sai hướng. Hoặc tệ hơn, research của bạn không còn được hỏi tới trong các quyết định quan trọng.

Đó là lúc khoảng cách giữa beginner và advanced researcher bắt đầu lộ ra. GAP ở đây là IMPACT!

Không nằm ở việc bạn biết bao nhiêu method, Nó nằm ở việc bạn đang trả lời câu hỏi nào cho tổ chức. Việc trả lời câu hỏi đó giúp tổ chức tránh được bao nhiêu rủi ro hoặc tạo ra bao nhiêu cơ hội kinh doanh tiềm năng. Và đó là Impact!

Khi research không bắt đầu từ “đúng câu hỏi”

Có hai dự án research diễn ra với cùng một vấn đề: người dùng không hoàn thành một bước quan trọng trong hành trình.

Ở dự án thứ nhất, team phát hiện tỷ lệ drop cao trong flow đăng ký. Researcher được mời vào, thiết kế usability testing, quan sát người dùng thao tác và ghi nhận các điểm vướng. Report sau đó khá rõ ràng: user mất thời gian ở một số bước, label chưa rõ, bố cục gây nhầm lẫn. Đề xuất tập trung vào việc “chỉnh sửa giao diện thế nào để giúp thao tác mượt hơn?”. Team triển khai nhanh, kết quả có cải thiện nhưng không đáng kể.

Ở dự án thứ hai, vấn đề cũng là người dùng không hoàn thành hành động. Nhưng researcher bắt đầu từ một câu hỏi khác: “Điều gì khiến họ quyết định dừng lại?” Họ không chỉ nhìn vào màn hình, mà kết hợp dữ liệu hành vi và phỏng vấn để hiểu bối cảnh. Kết quả cho thấy người dùng dừng lại khi phải thực hiện một bước họ chưa thực sự hiểu hoặc chưa thấy cần thiết. Vấn đề không nằm ở thao tác, mà nằm ở cách trải nghiệm được cấu trúc.

Thay vì sửa UI, team thay đổi cách tổ chức toàn bộ flow, làm rõ từng bước và giảm phụ thuộc vào việc người dùng phải tự suy đoán. Sau đó, tỷ lệ hoàn thành tăng rõ rệt.

Hai cách làm, hai kết quả. Một bên tối ưu những gì nhìn thấy. Một bên đặt lại cách hệ thống hoạt động.

Thực tế, case thứ hai chính là cách Airbnb từng xử lý trải nghiệm check-in, khi họ nhận ra việc host phải nhắn tin liên tục không phải lỗi giao tiếp, mà là dấu hiệu của một thiết kế thiếu cấu trúc.

Còn case đầu tiên là hình ảnh rất quen thuộc của một beginner researcher: làm đúng các bước được học, nhưng chưa đủ sâu để thay đổi hướng đi.

Khi dữ liệu không đủ để tạo ra sự thay đổi

Một beginner có thể mang về rất nhiều dữ liệu. Họ có quote của user, có pain point, có bảng tổng hợp rất đẹp. Nhưng khi đưa vào phòng họp, mọi người vẫn hỏi một câu quen thuộc: “Rồi sao nữa?”

Vấn đề nằm ở chỗ dữ liệu chưa trở thành insight.

Trong một ứng dụng đặt đồ ăn, user thường phàn nàn rằng “app khó dùng” hoặc “chờ lâu”. Nếu dừng ở đây, team sẽ nghĩ đến việc cải tiến UI hoặc tối ưu tốc độ. Nhưng một advanced researcher sẽ đào sâu hơn. Họ quan sát cách user đọc thông tin, cách họ hiểu thời gian hiển thị, và nhận ra một điều quan trọng: người dùng đang hiểu sai.

Họ nghĩ thời gian hiển thị là thời gian giao hàng, trong khi thực tế đó là thời gian chuẩn bị. Sự lệch pha này tạo ra cảm giác chờ đợi lâu, dù hệ thống vận hành đúng.

Insight ở đây không phải là “user thấy chậm”.

Insight là “user có kỳ vọng sai về thời gian”.

Và từ đó, giải pháp không phải là làm nhanh hơn, mà là thiết kế lại cách truyền đạt thông tin. Một insight đúng có thể thay đổi hướng đi của cả sản phẩm. Một bảng tổng hợp dữ liệu thì không.

Share

Khi “làm đúng” lại trở thành rào cản

Nhiều người học research theo một chuẩn khá rõ ràng. Phải có research plan, phải recruit đúng persona, phải đủ số lượng user, phải chọn đúng method. Điều này tạo ra một cảm giác an toàn. Bạn biết mình đang làm đúng.

Nhưng thực tế hiếm khi cho bạn điều kiện lý tưởng.

Trong các hệ thống enterprise, đặc biệt là trong ngành ngân hàng hoặc phần mềm nội bộ, việc tiếp cận user thật rất khó. Data bị giới hạn, thời gian bị ép, stakeholder muốn có câu trả lời nhanh. Một beginner thường mắc kẹt ở đây. Họ biết mình cần làm gì, nhưng không thể làm được “đúng cách”.

Advanced researcher nhìn vấn đề khác đi. Họ không hỏi “cách đúng là gì”. Họ hỏi “cách nào đủ tốt để ra quyết định trong bối cảnh này”.

Họ có thể phỏng vấn internal user thay vì khách hàng thật. Họ có thể dùng log data thay cho survey. Họ có thể chạy một study nhỏ, chấp nhận độ chính xác thấp hơn nhưng đủ để định hướng.

Ở level này, research không còn là một quy trình cứng. Nó là một hệ thống các lựa chọn có tính đánh đổi. Advanced researcher sẽ là người nói ra chiến lược thay vì chăm chăm làm theo 1 kịch bản có sẵn.

Khi câu hỏi nghiên cứu không còn là trung tâm

Một trong những kỹ năng đầu tiên của researcher là đặt câu hỏi khi phỏng vấn hay nghiên cứu định lượng. Nhưng khi bạn đi xa hơn, bạn sẽ nhận ra câu hỏi không phải là thứ quan trọng nhất.

Thứ quan trọng là cách người dùng nghĩ.

Trong các sản phẩm tài chính hoặc đầu tư, nếu bạn hỏi người dùng “bạn có tin tưởng ứng dụng này không”, câu trả lời thường không đáng tin. Họ sẽ nói có hoặc không, nhưng không phản ánh đúng hành vi thật.

Một advanced researcher sẽ quan sát những khoảnh khắc người dùng dừng lại. Họ sẽ xem khi nào người dùng mở thêm một tab khác để kiểm tra thông tin, khi nào họ chần chừ trước khi bấm xác nhận. Những hành vi này tiết lộ mức độ tin tưởng thực tế.

Trong ngành xe tự lái, điều này còn rõ hơn. Người dùng có thể nói họ sẵn sàng dùng, nhưng hành vi thật lại cho thấy họ luôn giữ tay gần vô lăng, luôn sẵn sàng can thiệp. Nghiên cứu lúc này không còn là thu thập ý kiến. Nó là hiểu cảm giác kiểm soát và nỗi sợ.

Ở đây, sự khác biệt nằm ở việc bạn có đang nghe lời người dùng nói, hay đang hiểu cách họ vận hành thế giới.

Khi UX không nói được ngôn ngữ của business

Một trong những lý do khiến research bị bỏ qua là vì nó không kết nối được với business. Nguyên nhân có thể tới ngay từ sự hiểu biết của người làm product và business không giống nhau.

Trong research từ một beginner thường báo cáo rằng form quá dài, user thấy mệt, hoặc trải nghiệm chưa tốt. Những điều này đúng, nhưng chưa đủ để tạo ra ưu tiên hay để ra quyết định.

Một advanced researcher sẽ đi thêm một bước. Họ liên kết trải nghiệm với hành vi, và hành vi với chỉ số. Ví dụ, một form dài không chỉ gây khó chịu. Nó làm tăng tỷ lệ bỏ dở. Tỷ lệ bỏ dở này ảnh hưởng trực tiếp đến số lượng khách hàng mới. Và điều đó ảnh hưởng đến doanh thu.

Khi insight được đặt trong ngữ cảnh của business, nó không còn là một góp ý. Nó trở thành một lý do để hành động.

Trong ngành F&B, việc khách hàng cảm thấy chờ lâu không chỉ là trải nghiệm tệ. Nó làm giảm khả năng họ quay lại. Một thay đổi nhỏ trong cách hiển thị thời gian có thể ảnh hưởng đến tần suất mua hàng. Đây là thứ mà business quan tâm.

Research chỉ có giá trị khi nó chạm được vào những điểm như vậy.

Khi research không còn là từng project riêng lẻ

Ở level beginner, research thường gắn với từng project. Mỗi lần làm là một lần bắt đầu lại. Persona được tạo cho dự án này, rồi bị bỏ quên ở dự án khác. Insight không được tích lũy.

Advanced researcher nhìn research như một hệ thống tri thức.

Trong các công ty thương mại điện tử hoặc bán lẻ lớn, hành vi khách hàng không thay đổi hoàn toàn giữa các dự án. Có những pattern lặp lại theo mùa, theo nhóm khách hàng, theo bối cảnh. Khi những pattern này được lưu lại và sử dụng lại, tổ chức bắt đầu học nhanh hơn.

Research lúc này không chỉ tạo ra output. Nó tạo ra tài sản. Tiếc là nhiều công ty không nhận ra và cũng không bảo vệ tài sản này. Do đó khi advance researcher ra đi, hiểu biết của công ty về khách hàng lại như mới.

Túm lại là …

Điểm chuyển giữa beginner và advanced không phải là một kỹ năng cụ thể. Nó là một sự thay đổi trong cách bạn nhìn vai trò của mình. Bạn không còn là người “đi hỏi người dùng rồi báo lại”. Bạn trở thành người giúp tổ chức hiểu mình đang sai ở đâu, và nên đi hướng nào.

Beginner làm research để có câu trả lời.
Advanced làm research để tránh những quyết định sai mà tổ chức chưa nhìn ra.

Và khi bạn bắt đầu nghĩ theo cách đó, cách bạn đặt câu hỏi, cách bạn chọn phương pháp, và cách bạn nói chuyện với stakeholder sẽ tự động thay đổi.

Đó là lúc bạn thực sự bước ra khỏi level beginner.

Vì thị trường không tìm người như bạn nữa. Hoặc đúng hơn: thị trường đang giả vờ không cần.

Hai cực, một khoảng trống

Một buổi cà phê với vài người làm product, câu chuyện rẽ sang tuyển dụng lúc nào không hay. Bức tranh chúng tôi vẽ ra khi kể về các công ty mình biết có một số điểm trùng hợp bất ngờ: công ty đang chia làm hai phe rõ rệt. Một bên là những bạn mới ra trường, lương “dễ chịu”, học nhanh, không hỏi nhiều. Bên kia là những người đủ senior để “cầm lái”, vào việc là chạy. Chuyện 1 senior vừa gánh việc hàng ngày và gánh cả việc hướng dẫn junior vào guồng cùng lúc không phải hiếm ( và nó vãi cả mệt, gần như vắt kiệt thời gian và sự tập trung hơn nhiều so với senior solo ).

Ở giữa? Im lặng.

Không phải vì không tồn tại, mà vì không còn ai mặn mà tuyển. Nghe qua thì giống một chiến lược gọn gàng. Nhưng thực ra nó giống việc xây một cây cầu chỉ có hai đầu, còn phần giữa… hy vọng sẽ tự nối. :))

Đây không phải cảm nhận của riêng ai. Dữ liệu từ Revelio Labs, một trong những đơn vị phân tích thị trường lao động có độ tin cậy cao, chỉ ra kể từ năm 2022, tuyển dụng cho vị trí middle level designer và middle manager trên toàn cầu đã giảm 43%. Cùng giai đoạn đó, tuyển dụng entry-level chỉ giảm 14%. Khoảng cách này không phải tình cờ. Nó là một quyết định có chủ ý, dù nhiều công ty có lẽ chưa đặt tên được cho nó.

Câu chuyện kinh tế đơn giản

Tại sao lại như vậy? Câu trả lời ngắn gọn: bảng lương.

1. Junior rẻ. Ở thị trường Hà Nội, một fresher UX/UI dao động 7–12 triệu. Với một công ty đang cần người thực thi wireframe, resize banner, hoặc chạy usability test theo script có sẵn, mức đó là hợp lý. Nhất là khi AI đang giúp họ làm nhanh hơn đáng kể so với lứa junior cách đây 5 năm.

2. Senior thì đắt nhưng giải quyết được việc. Một Head of Design hay Senior Product Designer dày dạn ở thị trường Việt Nam hiện được trả 40–80 triệu tùy công ty và profile. Đắt, nhưng họ vào là chạy. Không cần giải thích tại sao cần research trước khi wireframe. Không cần được nhắc là stakeholder có quan điểm riêng.

3. Còn mid-level? Lương 18–30 triệu. Không đủ rẻ để tuyển số lượng lớn. Chưa đủ “đắt xắt ra miếng” để được tin hoàn toàn. Trong bảng tính của người phê duyệt headcount, đây là dòng khó biện minh nhất.

Kết quả: mid-level bị kẹt giữa hai bản ngân sách.

Share

Nhưng junior cũng không “lên ngôi” như tưởng

Cần nói thẳng một điều: bài toán không đơn giản là “thay mid bằng junior”. Thực tế phức tạp hơn và cũng đáng lo hơn.

Dữ liệu từ SignalFire, sau khi phân tích hơn 650 triệu hồ sơ chuyên gia, cho thấy số lượng vị trí mới dành cho người có dưới 1 năm kinh nghiệm tại các công ty tech lớn đã giảm 50% so với trước đại dịch. Riêng từ 2023 đến 2024, Big Tech cắt thêm 25% chỗ cho new grad. Revelio Labs ghi nhận tổng tin tuyển dụng entry-level tại Mỹ giảm 35% kể từ đầu 2023.

Cái đang thực sự tăng? Senior. Cả tuyển dụng lẫn mức lương ở nước ngoài.

Nói cách khác: thị trường không phải đang ưu ái junior. Thị trường đang thu hẹp toàn bộ, nhưng mid-level bị thiệt nhất, và senior là lớp duy nhất đang giữ giá, thậm chí tăng giá. Ở Việt Nam, câu chuyện có thể sẽ hơi khác nhưng sớm muộn gì nó cũng sẽ tiến tới kết quả này.

Ngành thiết kế - sản phẩm: bị ảnh hưởng trước và nặng hơn

Trong các ngành bị tác động bởi cấu trúc hiring lệch này, thiết kế và product là hai ngành cảm nhận sớm nhất — và rõ nhất.

Lý do: đây là những ngành mà vai trò mid-level vốn đã mơ hồ về định nghĩa. Ở nhiều công ty Việt, ranh giới giữa junior và senior đôi khi chỉ là... số năm ghi trên CV. Không có framework rõ ràng về seniority. Không có lộ trình phát triển thực chất. Không hiếm senior UX designer chỉ biết research định tính nhưng không biết cách phân bổ mẫu hay cách giải trình kết quả lên cấp trên để có approval. Kết quả là khi thị trường siết lại, tầng giữa bị cắt đầu tiên vì không ai chứng minh được giá trị của nó.

Thực tế quan sát được ở các team product tại Việt Nam: cấu trúc phổ biến hiện tại là 1 Head of Product hoặc Senior PD + 2–3 junior. Không có ai ở giữa để translate strategy thành execution, không có ai đủ context để mentor junior mà không làm senior quá tải.

Kết quả: senior bắt đầu làm việc của mid-level. Junior không được phát triển. Và sản phẩm chạy được, nhưng không lớn được.

Ai đang xóa cái thang mà mid-level đang leo? AI hay Business?

Có một lý do sâu hơn khiến mid-level bị thu hẹp: cái giai đoạn “học bằng cách làm” vốn là xương sống của quá trình lớn lên từ junior lên senior đang bị AI ăn mòn. Trước đây, một designer cần 2–3 năm làm thật để hiểu cách research, tổng hợp insight, viết brief, thử nghiệm concept, fail, rồi làm lại. Đó là giai đoạn tích lũy không thể nhảy cóc và nó chính là định nghĩa của mid-level.

Giờ thì khác. Burning Glass Institute theo dõi thị trường lao động Mỹ và ghi nhận: trong ngành software development, tỷ lệ việc làm yêu cầu dưới 3 năm kinh nghiệm đã giảm từ 43% (2018) xuống còn 28% (2024). Data analysis từ 35% xuống 22%. Những việc từng cần người “đủ dày” để làm ngay hoặc bị AI thay, hoặc được senior làm nhanh hơn với công cụ mới có AI.

Cái thang nghề nghiệp vẫn còn đó. Nhưng một vài bậc giữa đang bị tháo ra. Nói thật chứ các bạn middle level còn chưa đi hết các bậc, mà đã bị đứng trên cái thang lung lay, suốt ngày bị lăm le biến mất thì còn ai hào hứng với nghề nữa. Liệu các bạn còn cháy với cty không? các bạn còn tìm thầy để học nghệ cho ra tấm ra món không hay nhảy sang ngạch khác làm PO, PM,…?

Báo cáo Workforce 2025 của Korn Ferry — khảo sát 15.000 chuyên gia toàn cầu — ghi nhận: 37% nhân viên cho biết khi công ty cắt tầng middle management, họ cảm thấy mất phương hướng. Không phải vì thiếu người ra lệnh. Mà vì thiếu người hiểu — hiểu cả hai phía, biết chuyển ngôn ngữ từ chiến lược xuống thực thi.

Glassdoor thì ghi nhận một sự cố khác: sau các đợt layoff nhắm vào middle managers năm 2023, điểm satisfaction về work-life balance của nhóm này giảm mạnh nhất trong toàn bộ phổ nhân sự. Không phải vì họ lười. Mà vì họ bị kéo hai đầu: ép junior deliver hàng ngày, trong khi chính họ cũng là mục tiêu của dao cắt giảm biên chế.

Fortune dẫn lại một ví dụ không thể bỏ qua: một công ty cắt 70% engineering manager năm 2024, tiết kiệm được 3,2 triệu đô. Sáu tháng sau, kỹ sư senior giỏi nhất nghỉ việc. Lý do ghi trong exit interview: “Không ai biết tôi đang làm gì, hay tại sao nó quan trọng.” VP Engineering lúc đó đang quản lý 47 direct reports — phê duyệt quyết định qua Slack, không có ngữ cảnh, không có coaching.

3,2 triệu đô tiết kiệm được. Chi phí thay thế người đó, tuyển mới, mất momentum thì chưa ai tính.

Senior không tự mọc lên. Họ được nuôi bằng chính giai đoạn mid-level đó. Giai đoạn cho phép mid-level làm đủ nhiều, sai đủ nhiều, được mentor đủ để có judgment thực sự. Cắt giai đoạn đó đi, bạn không tiết kiệm chi phí. Bạn đang vay trước từ tương lai, với lãi suất cao hơn bạn nghĩ.

Dữ liệu của Deloitte ghi nhận một tín hiệu đáng lo: chỉ 6% Gen Z muốn trở thành senior leader. Không phải vì họ thiếu tham vọng. Mà vì họ đã quan sát đủ để hiểu rằng con đường qua tầng middle manager là con đường dẫn đến “bị xóa vì hiệu quả”.

Khi pipeline lãnh đạo nội bộ cạn kiệt, công ty sẽ phải thuê senior từ bên ngoài, với chi phí cao hơn đáng kể. Và những người không có context, không có văn hóa công ty, không có “bộ nhớ” tổ chức đó sẽ phải học lại từ đầu những thứ mà một mid-level tốt đáng ra đã nắm sẵn.

Mid-level không chỉ là một dòng chi phí. Họ là lớp hiểu :

• hiểu senior đang muốn gì

• hiểu junior đang cần gì

• biết cách nối hai thứ đó lại

• rồi sau đó, AI cần có người hiểu cái GAP đó để build cho đúng và đủ. Senior có thể chỉ là người phê duyệt

Thiếu lớp đó, tổ chức vẫn chạy được. Nhưng chạy như xe thiếu một bộ giảm xóc: ổn trên đường bằng, gãy ngay khi gặp ổ gà.

Và ngành thiết kế - sản phẩm tại Việt Nam, vốn đang phải xây tất cả từ đầu : methodology, culture, pipeline nhân sự — không có nhiều ổ gà nào để thử thách sự kiên nhẫn đó.

Trong nhiều năm qua, Customer Journey Map (CJM) gần như là “ngôn ngữ chung” của các đội CX, UX và sản phẩm trong ngân hàng. Từ phòng họp chiến lược đến workshop với chi nhánh, hành trình khách hàng luôn được vẽ ra như một chuỗi các giai đoạn quen thuộc: nhận biết, cân nhắc, đăng ký, sử dụng, duy trì/trung thành. Nhưng một nghiên cứu gần đây từ đội ngũ, với sự tham gia của các nhà nghiên cứu từ Revolut và NVIDIA, đang đặt ra một câu hỏi đáng suy nghĩ: liệu cách chúng ta đang mô tả hành trình khách hàng có còn phản ánh đúng thực tế?

Bài nghiên cứu này không trực tiếp bàn về CX hay CJM. Nó giới thiệu một mô hình AI có tên PRAGMA, một “foundation model” được huấn luyện trên 4 tỷ sự kiện hành vi của 25 triệu khách hàng ngân hàng Revolut. Tuy nhiên, chính cách mô hình này nhìn nhận dữ liệu đã vô tình mở ra một góc nhìn mới: hành trình khách hàng không phải là thứ cần “vẽ lại”, mà là thứ đã tồn tại sẵn trong dữ liệu, chỉ là trước đây chúng ta không có cách để nhìn thấy nó.

Từ bản đồ tĩnh đến dòng dữ liệu sống

Trong thực tế vận hành của một ngân hàng, hành trình vay tín dụng cá nhân không diễn ra theo một đường thẳng. Nếu đi sâu vào dữ liệu hệ thống, một khách hàng có thể trải qua chuỗi hành vi như sau:

Người dùng »

• [App] Mở ứng dụng vào buổi sáng, xem sản phẩm vay, rồi thoát ra

• [App] Quay lại vào buổi chiều, bắt đầu điền form nhưng dừng giữa chừng

• [Call Center-RM] Sau hai ngày, nhận cuộc gọi từ RM và quay lại hoàn tất hồ sơ

• [RM/Email] Bị yêu cầu bổ sung giấy tờ, chờ thêm vài ngày trước khi được phê duyệt

Nếu là CJM truyền thống, ta có thể vẽ một dòng tuyến tính từ trái qua phải : Nhận thức dịch vụ → Apply hồ sơ → nhận phê duyệt → được vay. Nhưng thực tế người dùng không trải nghiệm như vậy mà họ phải trải qua rất nhiều vòng lặp chỉ để thực hiện xong 1 giai đoạn.

Công cụ CJM đã làm một việc rất quan trọng: biến một hệ thống phức tạp thành một câu chuyện dễ hiểu. Nhưng cái giá phải trả là sự mất mát về chi tiết. Những yếu tố như thời gian chờ, số lần thử lại, hay sự gián đoạn trong hành vi, vốn có thể là nguyên nhân chính của “friction”, thường bị làm mờ hoặc bỏ qua hoàn toàn.

Khi AI không “tóm tắt” hành trình nữa

Điểm khác biệt cốt lõi trong cách tiếp cận của PRAGMA là nó không cố gắng tóm tắt hành trình khách hàng. Thay vào đó, mô hình này giữ nguyên toàn bộ chuỗi sự kiện (event sequence) theo cách chân thực nhất, bao gồm:

• [Key] Loại hành vi (giao dịch, tương tác app, communication…)

• [Value] Giá trị (số tiền, sản phẩm, trạng thái…)

• [Time] Thời gian (timestamp, khoảng cách giữa các sự kiện)

Mỗi khách hàng được biểu diễn như một chuỗi dữ liệu theo thời gian, thay vì một “stage” trong hành trình. Mô hình sau đó học cách nhận diện các pattern trong chuỗi này để phục vụ nhiều bài toán khác nhau như credit scoring, fraud detection hay product recommendation .

1. Pain point không còn là câu trả lời, mà là tín hiệu

Trong các dự án CX truyền thống, pain point thường được xác định thông qua phỏng vấn hoặc workshop. Một khách hàng có thể nói rằng họ “khó khăn khi upload giấy tờ”, và insight này sẽ được đưa vào CJM.

Tuy nhiên, trong hệ thống AI, pain point không còn đến từ lời nói, mà từ dữ liệu hành vi. Ví dụ, mô hình có thể phát hiện:

• 37% người dùng dừng lại ở bước upload

• Trung bình mỗi người thử lại 2–3 lần

• Thời gian giữa các lần thử tăng dần

Những con số này không chỉ mô tả vấn đề, mà còn cho phép dự đoán hành vi tiếp theo. Một người dùng có pattern tương tự có thể được xác định sớm là “có nguy cơ bỏ cuộc”, từ đó hệ thống có thể kích hoạt các hành động can thiệp.

2. Persona mất dần ý nghĩa trong môi trường dữ liệu dày đặc

Một trong những công cụ quen thuộc của CJM là persona. Nhưng khi dữ liệu hành vi trở nên chi tiết và phong phú hơn, persona bắt đầu bộc lộ giới hạn.

Hai khách hàng có thể giống nhau về độ tuổi, nghề nghiệp và thu nhập, nhưng hành vi tài chính lại hoàn toàn khác biệt. Một người có lịch sử giao dịch ổn định, trong khi người kia có các giao dịch bất thường với giá trị lớn. Trong hệ thống AI, sự khác biệt này được phản ánh ngay trong vector biểu diễn (embedding) của từng khách hàng.

Điều này dẫn đến một thay đổi quan trọng:

Thay vì thiết kế cho “nhóm người”, các hệ thống hiện đại đang dần chuyển sang thiết kế cho “pattern hành vi”.

3. Touchpoint không còn là điểm chạm độc lập

Trong CJM, touchpoint thường được xem như các điểm tiếp xúc riêng lẻ: app, chi nhánh, call center. Nhưng dữ liệu cho thấy giá trị thực sự không nằm ở từng điểm, mà ở mối quan hệ giữa chúng.

Ví dụ, một cuộc gọi từ RM không phải lúc nào cũng hiệu quả. Nhưng nếu cuộc gọi đó diễn ra sau khi khách hàng vừa bỏ dở hồ sơ trong vòng 48 giờ, tỷ lệ quay lại có thể tăng đáng kể. Điều này cho thấy “thời điểm” và “ngữ cảnh” quan trọng hơn bản thân touchpoint.

4. User behavior có thể được dự đoán, thay vì chỉ dừng ở mô tả.

Một trong những khác biệt lớn nhất giữa CJM và hệ thống AI là khả năng dự đoán. CJM giúp trả lời câu hỏi “điều gì đang xảy ra”, trong khi AI hướng tới “điều gì sẽ xảy ra tiếp theo”.

Trong nghiên cứu PRAGMA, mô hình có thể cải thiện đáng kể hiệu suất trong các bài toán như dự đoán khả năng vỡ nợ hay hành vi gian lận, nhờ vào việc học được các pattern từ dữ liệu lịch sử . Điều này mở ra khả năng can thiệp sớm, thay vì chỉ phản ứng sau khi vấn đề đã xảy ra.

5. Giới hạn của mô hình PRAGMA

Điều đáng chú ý là mô hình này không phải lúc nào cũng vượt trội. Trong bài toán chống rửa tiền (AML), PRAGMA hoạt động kém hơn so với các hệ thống truyền thống, với mức giảm hiệu suất đáng kể .

Nguyên nhân nằm ở bản chất của bài toán: AML phụ thuộc vào mối quan hệ giữa nhiều tài khoản, trong khi mô hình này chủ yếu phân tích hành vi của từng khách hàng riêng lẻ. Điều này cho thấy một giới hạn quan trọng: không phải mọi hành trình đều có thể được hiểu nếu chỉ nhìn ở cấp độ cá nhân.

Share

CJM và Persona sẽ thay đổi thế nào?

Trong các tổ chức ngân hàng hiện đại, nơi AI ngày càng đóng vai trò trung tâm trong việc phân tích và dự đoán hành vi, một khoảng trống mới đang dần lộ rõ :

Khoảng trống giữa cách máy hiểu khách hàng và cách con người diễn giải họ.

Các mô hình dữ liệu có thể nhận diện hàng trăm biến số, phát hiện pattern trong hàng triệu sự kiện, và dự đoán xác suất hành vi với độ chính xác cao. Nhưng những gì chúng trả về thường là các con số, vector, hoặc phân nhóm trừu tượng, những thứ không mang ý nghĩa trực tiếp với người làm sản phẩm, marketing hay vận hành chi nhánh. Ngược lại, con người lại có xu hướng hiểu khách hàng thông qua câu chuyện, ngữ cảnh và logic trải nghiệm. Chính sự lệch pha này tạo ra một vấn đề rất thực tế: hệ thống “biết” rất nhiều, nhưng tổ chức lại “hiểu” rất ít nếu thiếu một lớp diễn giải phù hợp. Ví dụ có thể xảy ra:

AI system nói:

• “Segment này có 65% churn risk”

• “Drop xảy ra sau event X”

Nhưng business cần:

• hiểu “chuyện gì đang xảy ra”

• thấy được “flow trải nghiệm”

Trong bối cảnh đó, Customer Journey Map (CJM) không biến mất, mà chuyển sang một vai trò khác. Nếu trước đây CJM là công cụ để khám phá insight, thì giờ đây nó trở thành công cụ để tổ chức và diễn giải insight từ hệ thống AI. Hành trình khách hàng vẫn là một cấu trúc cần thiết, không phải vì nó phản ánh chính xác thực tế, vốn phức tạp và phi tuyến tính, mà vì nó giúp con người định vị vấn đề và hành động. Khi một mô hình chỉ ra rằng một nhóm khách hàng có nguy cơ bỏ cuộc cao, CJM giúp trả lời các câu hỏi tiếp theo: họ đang ở bước nào, bị gián đoạn ở đâu, và đâu là điểm can thiệp hợp lý. Nói cách khác, CJM không còn là “bản đồ của thực tế”, mà là khung để quản lý và ra quyết định dựa trên thực tế đã được máy học rút trích.

Tương tự, Persona cũng cần được tái định nghĩa. Trong thời kỳ dữ liệu dày đặc, việc phân loại khách hàng chỉ dựa trên nhân khẩu học hay mô tả định tính không còn đủ để phản ánh hành vi thực tế. Tuy nhiên, loại bỏ persona hoàn toàn lại khiến tổ chức mất đi khả năng hình dung và thiết kế trải nghiệm. Cách tiếp cận phù hợp hơn là xây dựng persona dựa trên pattern hành vi và trạng thái trong hành trình, sau đó bổ sung các yếu tố bối cảnh (demographic, nghề nghiệp, thói quen) để tăng khả năng hiểu. Thay vì nói “nam, 30 tuổi, nhân viên văn phòng”, persona trong môi trường AI có thể được mô tả như:

• nhóm drop ở step KYC

• nhóm convert nhanh trong 1 session

• nhóm cần RM support mới hoàn tất

Đây không còn là một đại diện tĩnh của một nhóm người, mà là một biểu hiện có thể quan sát và đo lường được trong dữ liệu. Persona, theo nghĩa này, trở thành cầu nối giữa thế giới của mô hình và thế giới của con người, nơi mà hành vi được đặt lại trong một ngữ cảnh đủ rõ để có thể thiết kế và hành động.

• Doanh nghiệp tuyển Product Lead không phải để design, mà để ra quyết định và thiết kế hệ thống làm sản phẩm.

• Những kỹ năng quan trọng nhất ở level cao lại là những kỹ năng khó tự học nhất.

• Career path của Product Designer thực ra đi từ:

  • Design screen → Design product → Design system → Design organization → Design business.

Nghề Product Design nhìn từ góc độ Career Cycle và Learning & Development

Khi nói về nghề Product Design, nhiều người thường nghĩ đến UI, UX, research, design system, hoặc Figma. Nhưng nếu nhìn nghề này dưới góc độ career lifecycle và L&D (Learning & Development), bức tranh sẽ khác hẳn.

Thay vì nhìn nghề theo tool hay job title, ta nhìn theo chu kỳ phát triển sự nghiệp và năng lực cần có ở mỗi giai đoạn. Điều này giúp cả cá nhân lẫn doanh nghiệp hiểu rõ: người Product Designer nên học gì, phát triển gì và chuẩn bị cho vai trò tiếp theo như thế nào.

1. Bức tranh tổng quan nghề Product Design theo Career Lifecycle

Trong L&D, sự nghiệp thường được chia thành 4 giai đoạn lớn:

Vậy với nghề Product design thì chúng ta có gì? Bạn đang ở vị trí nào?

Điểm thú vị là:
Phần lớn tài liệu UX dạy kỹ năng cho giai đoạn Establishment, nhưng doanh nghiệp lại tuyển rất nhiều vị trí ở giai đoạn Maintenance (Lead/Head). Đặc biệt trong bối cảnh có AI, kỹ năng phải có sự pha trộn và cái bạn cần ship không chỉ là userflow full UI.

Năm 2023, tôi đã rơi vào khủng hoảng này. Có những job tôi không phải quản lý ai và vẫn chạy được full tất cả Design Ops của 1-2 SaaS, kiêm cả marketing /branding cho công ty. Phải, tôi rất productive và có đủ tool optimize quy trình làm việc cho mình, nhưng có cái gì đó không đủ để tự nhận mình là design lead. Như những tiền bối Lead / Manager ở Atlassian tôi từng làm việc, họ có một cái gì đó rất khác so với các senior.

Vậy khoảng trống năng lực thường nằm ở đâu?

2. Nhìn vào JD Product Lead hiện nay, Doanh nghiệp thực sự cần gì?

Nếu đọc các JD Product Lead / Head of Product Design hiện nay, ta sẽ thấy họ không còn tuyển một người “design giỏi”, mà tuyển một người có thể:

• Thiết kế kiến trúc sản phẩm

• Xây dựng design system

• Hiểu hệ thống và vận hành

• Làm research thực tế

• Làm việc với business và tech

• Dẫn dắt team

• Align design với business

Nói cách khác, họ không tuyển designer, mà tuyển người thiết kế cách sản phẩm và tổ chức hoạt động.

Năng lực cốt lõi của Product Lead

Nếu gom các yêu cầu trong JD lại, ta có thể nhóm thành bảng sau:

Ở bảng này, tôi phân những kỹ năng tự học và không nên tự học. Ví dụ kỹ năng leadership: bạn không thể học quản lý nhân sự nếu bạn không có nhân sự để quản lý → hoặc bạn sẽ phải quản lý theo “tổ tiên mách bảo”, hoặc bạn sẽ quay mòng mòng trong công việc bạn không được đào tạo để làm. Chỉ vì bạn có kỹ năng chuyên môn thiết kế hơn không có nghĩa bạn làm quản lý được.

Những kỹ năng cần sự tương tác, trải nghiệm thì không thể học qua sách vở. Tuy nhiên bạn vẫn có thể học qua coaching và mentoring, nó sẽ là shortcut cho bạn chứ không thay thế việc bạn phải tự trải nghiệm. Trong thế giới hỗn loạn thông tin, như vậy đã là quá tốt rồi.

Đoạn chuyển khó nhất là từ Senior lên Lead.

Đây chính là lý do nhiều Senior Designer rất giỏi nhưng không lên Lead được. Không phải vì họ design kém, mà vì:

• Chưa quen ra quyết định

• Chưa quen làm việc với stakeholder

• Chưa hiểu business

• Chưa nghĩ theo hệ thống

• Chưa từng quản lý team

• Chưa từng chịu trách nhiệm outcome

Vì lúc này:

• Không còn được đánh giá bằng màn hình đẹp

• Không còn được đánh giá bằng usability

• Mà được đánh giá bằng:

  • Quyết định đúng không

  • Team chạy ổn không

  • Stakeholder có nghe không

  • Product có impact không

  • System có scale được không

Đây là lúc nghề design bắt đầu giống:

• Consulting

• Product management

• Operations

• Leadership

Nhiều người không chuẩn bị cho giai đoạn này nên bị kẹt ở Senior rất lâu. Hoặc họ shift sang ngạch khác, trở thành PM, Operation Manager, Consultant/Tư vấn, sales,…

UI/UX là thứ có thể học qua tool.
Leadership, strategy và system thinking là thứ phải học qua con người.

3. Nâng cao năng lực Product Design trong thời đại AI

AI không làm designer biến mất. Nhưng AI đang làm những designer chỉ làm UI hoặc wireframe trở nên dư thừa.

Những thứ AI làm rất nhanh:

• Wireframe

• UI layout

• Icon

• Copywriting cơ bản

• User flow cơ bản

• Persona cơ bản

• Competitive analysis

• Heuristic review

• Design system component cơ bản

• Research summary

Những thứ AI chưa làm tốt:

• Hiểu tổ chức

• Hiểu chính trị nội bộ

• Trade-off giữa tech – business – ops

• Stakeholder alignment

• Quyết định roadmap

• Xây team

• Coaching team

• System thinking

• Service design

• Field research

• Change management

Vì vậy, nếu trước đây designer cạnh tranh bằng:

Ai vẽ đẹp hơn, ai làm wireframe nhanh hơn

Thì bây giờ designer sẽ cạnh tranh bằng:

Ai hiểu hệ thống tốt hơn, ai ra quyết định tốt hơn, ai dẫn dắt được team và sản phẩm.

Nghề design đang dịch chuyển từ:
Design Execution → Design Decision → Design Strategy → Design Organization.

Bảng sau tổng hợp các Do and Don’t theo năng lực cốt lõi đã nói bên trên để bạn dễ map.

Share

Nếu nhìn lại toàn bộ bài viết, có lẽ điều quan trọng nhất không phải là học thêm một tool mới, một framework mới hay một phương pháp research mới. Điều quan trọng hơn là hiểu nghề Product Design thực sự đang đi về đâu trong vòng đời sự nghiệp:

Lúc mới vào nghề, bạn thiết kế màn hình.
Vài năm sau, bạn thiết kế sản phẩm.
Về sau nữa, bạn thiết kế cách công ty làm sản phẩm.
Và cuối cùng, bạn thiết kế cách tổ chức hoạt động.

Rất nhiều designer bị kẹt lại ở giữa sự nghiệp không phải vì họ không giỏi, mà vì họ vẫn đang cố giỏi hơn ở level cũ, thay vì học kỹ năng của level tiếp theo.

Vì vậy, có lẽ câu hỏi quan trọng nhất cho bất kỳ Product Designer nào không phải là:

Tôi nên học thêm tool gì?

Mà là:

Tôi đang ở level nào trong career cycle, và để lên level tiếp theo thì tôi cần học cách suy nghĩ như ai?
Designer? Product Manager? Consultant? Manager? Hay Business Leader?

Khi trả lời được câu hỏi đó, con đường phát triển nghề nghiệp sẽ rõ ràng hơn rất nhiều.

BTW, nếu bạn có nhu cầu học hoặc được coaching để chuyển mình lên lead, Molly có thể giúp kết nối bạn với nguồn kiến thức / cao nhân phù hợp. Inbox for more.

1. Con số 5 user – 85% problem là model xác suất, không phải rule cứng

2. Nó chỉ áp dụng cho problem discovery

3. Nó chỉ tìm common problems, không tìm rare problems

4. Iterative testing quan trọng hơn sample size

5. UX research nên làm nhiều vòng nhỏ, không làm một study lớn

Trong lĩnh vực UX research, có lẽ không có con số nào được trích dẫn nhiều hơn câu:

“Testing with five users finds 85% of usability problems.”

Câu này thường được gắn với Jakob Nielsen và trở thành một quy tắc gần như mặc định trong usability testing. Tuy nhiên, khi xem lại các nghiên cứu gốc và các phân tích sau này từ MeasuringU, có thể thấy rằng con số này thường bị hiểu sai, và việc hiểu sai dẫn đến việc áp dụng sai trong UX research và qualitative research nói chung.

Bài viết này không nhằm phủ nhận quy tắc 5 users, mà nhằm làm rõ:
Nó thực sự có nghĩa gì, và quan trọng hơn, khi nào nên và không nên dùng nó.

Nguồn gốc của con số 85%

Mô hình “5 users – 85% problems” không đến từ một thí nghiệm đơn lẻ mà đến từ một mô hình xác suất về việc phát hiện usability problems.

Công thức thường được dùng là:

Problems found = 1 − (1 − p)^n

Trong đó:

• p là xác suất một người dùng gặp một vấn đề

• n là số người dùng tham gia test

Nếu trung bình một usability problem xảy ra với khoảng 30% người dùng, thì khi test 5 người, xác suất phát hiện vấn đề đó sẽ vào khoảng 80–85%.

Điều này dẫn đến kết luận nổi tiếng rằng 5 users có thể phát hiện khoảng 85% usability problems.

Nhưng có một chi tiết quan trọng thường bị bỏ qua:

Bạn không tìm được 85% tất cả vấn đề.
Bạn chỉ tìm được 85% các vấn đề phổ biến.

Các vấn đề hiếm, các edge case, hoặc các vấn đề xảy ra với một nhóm người dùng rất cụ thể gần như sẽ không được phát hiện nếu chỉ test 5 người.

Quy luật lợi ích giảm dần trong usability testing

Một trong những insight quan trọng nhất từ nghiên cứu của Nielsen không phải là con số 5, mà là quy luật diminishing returns trong usability testing.

Anh em có thể đọc full bài tại đây

Khi test usability:

• Người dùng đầu tiên phát hiện rất nhiều vấn đề

• Người thứ hai phát hiện thêm nhiều vấn đề khác

• Người thứ ba phát hiện ít hơn

• Người thứ tư và thứ năm chủ yếu xác nhận các vấn đề đã thấy

• Sau người thứ năm, số vấn đề mới phát hiện giảm rất mạnh

Điều này dẫn đến một kết luận mang tính kinh tế hơn là thống kê:

Sau khoảng 5 người dùng, chi phí để tìm thêm vấn đề mới bắt đầu lớn hơn lợi ích thu được.

Nói cách khác, con số 5 không phải là con số “đúng về mặt khoa học”, mà là điểm cân bằng hợp lý giữa chi phí và insight trong usability testing.

Sai lầm phổ biến khi áp dụng quy tắc “5 users…”

Vấn đề lớn nhất hiện nay không phải là quy tắc này sai, mà là nó bị áp dụng sai bối cảnh.

Quy tắc 5 users chỉ phù hợp cho:

• Usability testing

• Task-based testing

• Prototype testing

• Flow testing

• Navigation testing

• Form testing

• Interaction testing

Tức là các nghiên cứu có mục tiêu: Tìm usability problems.

Nhưng trong thực tế, rất nhiều team áp dụng quy tắc này cho:

• Persona research

• Customer journey research

• Behavior research

• Market research

• Feature validation

• Concept testing

• Segmentation

• Strategy research

Trong những trường hợp này, sample size 5 gần như không thể đại diện cho hành vi hoặc nhu cầu của người dùng.

Đây là sự nhầm lẫn giữa:

• Usability testing (tìm vấn đề giao diện và tương tác)

• Qualitative research (hiểu hành vi, động cơ, nhu cầu)

• Quantitative research (đo lường và so sánh)

Ba loại nghiên cứu này có mục tiêu khác nhau, nên sample size cũng khác nhau.

Share

Insight quan trọng hơn cả sample size: Iterative testing

Có một điểm rất thú vị: nếu đọc kỹ các nghiên cứu gốc, có thể thấy rằng Nielsen không thực sự khuyến nghị chỉ test 5 users.

Thay vào đó, ông khuyến nghị:

Test with 5 users, fix the problems, then test with another 5 users.

Tức là:

• Test 5 users

• Sửa thiết kế

• Test 5 users

• Sửa tiếp

• Test 5 users

Ba vòng test với 5 người hiệu quả hơn một vòng test với 15 người.

Điều này thay đổi cách chúng ta nhìn về UX research.
UX research không phải là một hoạt động diễn ra một lần để tìm “sự thật”, mà là một quá trình học lặp (iterative learning process).

Áp dụng đúng vào UX research và qualitative research

Nếu áp dụng đúng, quy tắc này dẫn đến một cách làm research rất khác khi làm Usability testing:

Không nên:

• Test 15 users

• Viết report

• Kết thúc

Nên:

• Test 5 users

• Fix design

• Test 5 users

• Fix design

• Test 5 users

Trong qualitative research, quy tắc 5 users không áp dụng trực tiếp cho interview hoặc behavior research. Đó là bởi mục tiêu không phải là tìm lỗi giao diện, mà là:

• Hiểu hành vi

• Hiểu động cơ

• Hiểu decision making

• Hiểu context sử dụng

• Xây persona

• Xây journey

Trong các nghiên cứu này, researcher thường cần:

• 10–15 interviews để bắt đầu thấy pattern

• 15–25 interviews để đạt saturation

• Nhiều hơn nếu có nhiều phân khúc user

Ở đây, khái niệm quan trọng không phải là 85%, mà là thematic saturation – khi các interview mới không còn insight mới nữa.

Share

Vậy nên ….

Quy tắc “5 users find 85% of usability problems” tồn tại hơn hai thập kỷ vì nó hữu ích. Nhưng nó hữu ích trong một bối cảnh rất cụ thể: usability testing.

Hiểu sai quy tắc này dẫn đến:

• Sample size quá nhỏ cho research chiến lược

• Insight không đủ đại diện

• Product decision dựa trên dữ liệu yếu

• Research bị mất uy tín trong tổ chức

Có lẽ cách diễn đạt chính xác hơn nên là:

Five users are usually enough to find most common usability problems in one round of usability testing, but they are not enough to understand users, markets, behaviors, or strategy.

Và đây là ranh giới rất quan trọng giữa testing a design và researching users. Cho nên, nếu bạn được giao cho việc nghiên cứu UX, hãy chắc chắn đề bài là nghiên cứu cái gì về người dùng : usability hay behavior? để tìm lỗi trong tương tác hay dựng persona? Quy mô research của bạn phụ thuộc rất nhiều vào điều này ( trừ khi bạn thấy khách hàng/cấp trên cũng ko care lắm về phương pháp luận mà chỉ nhằm vào số liệu và bạn cũng không care lắm về ethic nghề nghiệp ).

Nếu bạn mở vài ứng dụng phổ biến ra xem, vd: ngân hàng, mua sắm, học tập, đặt xe,… rất dễ có cảm giác chúng “na ná” nhau. Vẫn là thanh điều hướng phía dưới, nút bo góc, nền sạch, icon tối giản, font chữ quen thuộc.

Chưa đủ thuyết phục ư? Vậy bạn kể tôi có app hẹn hò nổi tiếng nào mà không dùng cái pattern quẹt trái quẹt phải như Tinder?

Nhiều người nhìn riết vào rồi kết luận: thiết kế bây giờ hết sáng tạo rồi.

Nhưng nói vậy thì hơi oan cho người làm UX. Sự giống nhau này không phải do lười, mà là kết quả của nhiều năm thử –> sai –» tối ưu. Ngành sản phẩm số đã trưởng thành hơn, và khi trưởng thành thì người ta có xu hướng dùng những gì đã chứng minh là hiệu quả. Vấn đề chỉ xuất hiện khi hiệu quả bị đẩy lên quá cao, đến mức mọi thứ trở nên an toàn và nhạt nhẽo.

TL:DR

• App giống nhau vì chuẩn đã chứng minh hiệu quả

• Người dùng thích cái quen hơn cái lạ

• Doanh nghiệp ưu tiên an toàn và ROI

• AI đang khuếch đại sự giống nhau

• Khác biệt nên nằm ở cảm xúc và narrative

• Phá chuẩn cần chiến lược, không phải để “trông ngầu”

Vì sao các app trông giống nhau?

Chuẩn mực được định hình bởi những ông lớn

Một lý do lớn nằm ở các hệ thống thiết kế và guideline từ những công ty như Apple hay Google. Các hệ thống này không sinh ra để làm đẹp mà để giảm lỗi và giúp đội ngũ làm việc nhanh hơn. Khi một mẫu thiết kế giúp người dùng hiểu nhanh, ít nhầm lẫn và dễ mở rộng, nó dần trở thành chuẩn. Mà đã là chuẩn thì an toàn. An toàn thì ít rủi ro. Và doanh nghiệp thì luôn thích ít rủi ro.

Nếu để đảm bảo UI pattern bạn dùng phù hợp với mass user, bạn có thể tham khảo UI patter từ các OS lớn:

• Apple HCD

• Google material design

• Microsoft - Fluent design

Hoặc bạn có thể tham khảo lịch sử DS. Nếu OS pattern giúp educate người dùng cách sử dụng device, thì các tool lớn như Figma hay sketch lại là công cụ shape cách chúng ta deliver DS. Để làm được thì bạn cần có hiểu biết cả 2.

“Đừng bắt tôi nghĩ!”

“Don’t make me think!”

Hẳn làm UX lâu năm thì bạn cũng từng nghe cái rule này.. Bản chất nó xuất phát từ nature của con người, vốn thích cái quen thuộc, cái đã từng thấy, từng dùng. Não của chúng ta không thích phải học lại từ đầu mỗi khi dùng một ứng dụng mới. Khi biểu tượng kính lúp nghĩa là tìm kiếm hay vuốt để xem tiếp, người dùng không cần suy nghĩ nhiều. Họ chỉ làm. Đó chính là UX tốt. Nếu mỗi app sáng tạo một kiểu điều hướng riêng, người dùng có thể thấy thú vị lúc đầu, nhưng rất nhanh sau đó sẽ thấy mệt.

10 năm trước, có thể có sai khác về cách hiểu icon hay term vì sự khác biệt vùng miền, văn hoá, ngôn ngữ. Nhưng sau nhiều năm thay đổi dạy dỗ khách hàng, các pattern đã rõ nét. App ở Ấn với app ở Trung Quốc có thể không hoàn toàn giống app ở Mỹ Âu, dù cũng chỉ là app chuyển tiền hay telco. Do đó, sáng tạo ra 1 pattern khác sẽ kèm theo rủi ro:

• Rủi ro thay đổi hành vi, khách hàng phải học lại pattern, hành vi gây lỗi,…

• Rủi ro về tech vì khách hàng thao tác sai theo thói quen

• Rủi ro khác ( cái này vô chừng lắm, tốt nhất là không làm khách hàng mất tiền oan :(( )

“Đừng sáng chế lại bánh xe!”

Câu này tôi nghe PM nói đi nói lại khá nhiều, nhất là lúc chúng tôi bị push deadline. Thật ra thì thị trường cũng học lẫn nhau. Khi Tinder thành công với thao tác vuốt trái - phải, rất nhiều sản phẩm khác áp dụng theo. Điều này không hẳn là sao chép mù quáng mà là học từ thứ đã chứng minh hiệu quả. Trong kinh doanh, ý tưởng mới đồng nghĩa với rủi ro, còn ý tưởng đã chạy tốt đồng nghĩa với an toàn. Phần lớn công ty sẽ chọn phương án an toàn.

Rồi còn áp lực kinh doanh. Designer có thể thích thử nghiệm, nhưng công ty phải sống bằng doanh thu. Họ quan tâm đến deadline, ngân sách và tỉ lệ chuyển đổi. Không nhiều lãnh đạo hỏi sản phẩm có “nghệ thuật” không, có “ đặc sắc” gì không? ; họ hỏi người dùng có trả tiền không. Nghe thực dụng nhưng đó là thực tế.

Tuy nhiên, cái này anh em làm B2C còn dễ chứ anh em làm B2B những con app đặc thù thì khó hơn. Các app exclusive muốn nhìn thấy cái “bánh xe” thằng khác đã làm thì có khi phải giả làm khách hàng, book meeting với sale chỉ để chạm đến demo UI, dù ai cũng biết mua về cấu hình có khi phức tạp hơn nhiều.

AI góp phần làm mọi thứ giống nhau hơn

Chắc hẳn ai cũng nhớ vụ AI của figma bị gỡ sau một thời gian thử nghiệm. Lý do rất đơn giản: các sản phẩm được generate ra quá giống/ quá generic với những app đã có, đặc biệt là các app đã thành thương hiệu như Apple Weather app. Bạn có thể đọc thêm case này ở đây .

AI học từ dữ liệu sẵn có. Nếu dữ liệu là hàng nghìn giao diện tương tự, kết quả nó gợi ý cũng tương tự. AI rất giỏi tối ưu cái đã tồn tại, nhưng chưa giỏi tạo ra cái chưa từng có.

Thật ra là ngược lại. UX ngày nay giúp sản phẩm dễ dùng hơn, ít lỗi hơn và tiếp cận được nhiều người hơn. Đó là tiến bộ. Chỉ là tiến bộ này có mặt trái: sản phẩm dễ thiếu cá tính và cảm xúc. Khi mọi thứ đều “ổn”, không ai thật sự nổi bật.

Làm khác đi mà không làm hỏng trải nghiệm bắt đầu từ tác động đúng chỗ

Sáng tạo trong UX không có nghĩa là phá hết mọi quy ước. Phần lớn người dùng không tìm kiếm sự bất ngờ khi họ đang chuyển tiền hay thanh toán. Họ tìm sự chắc chắn. Vì vậy, khác biệt hiệu quả thường nằm ở những lớp khác.

UX+UI là cánh tay nối dài của Brand position

Nhiều ứng dụng làm tốt điều này. Duolingo vẫn là app học ngôn ngữ, nhưng mang cảm giác vui nhộn và có mascot “có cá tính”. Headspace vẫn là thiền, nhưng hình minh hoạ và chuyển động tạo cảm giác nhẹ nhàng, an tâm. Airbnb vẫn là đặt chỗ ở, nhưng kể câu chuyện về trải nghiệm sống và con người. Cấu trúc quen, cảm xúc khác và người dùng nhớ cảm xúc lâu hơn layout.

Micro-interaction, điều kỳ diệu nằm trong motion

Một nơi khác để tạo dấu ấn là micro-interaction: chuyển động nhỏ, phản hồi khi bấm, âm thanh tinh tế. Những chi tiết này không làm người dùng phải học lại cách dùng, nhưng khiến trải nghiệm có “hồn”. Người dùng có thể không chỉ ra được vì sao họ thích, nhưng họ cảm nhận được.

Sự thú vị nằm ở lựa chọn vị trí người dẫn chuyện

Narrative của sản phẩm cũng quan trọng. Ứng dụng của bạn là một công cụ khô khan, hay là một người bạn đồng hành? Là huấn luyện viên hay là cố vấn? Khi vai trò không rõ, thiết kế dễ trở nên vô hồn. Khi câu chuyện rõ ràng, quyết định thiết kế có hướng đi nhất quán hơn.

Những điểm designer không nên mạo hiểm!

Quan trọng nữa là phá đúng chỗ. Phá sai chỗ thì khó dùng; phá đúng chỗ thì đáng nhớ.

Nên giữ chuẩn:

• Thanh điều hướng

• Thanh toán

• Form nhập liệu

• Thông báo lỗi

• Setting / profile

Có thể sáng tạo:

• Onboarding

• Trang giới thiệu

• Khoảnh khắc thành công

• Branding

Cuối cùng, khác biệt bền vững thường không đến từ việc xem thật nhiều mẫu đẹp trên mạng, mà đến từ việc hiểu người dùng thật. Khi insight khác, giải pháp tự nhiên sẽ khác.

Một suy nghĩ cuối

Những suy nghĩ này của tôi không phải là duy nhất. Có anh bạn này trên youtube còn chăm chỉ khám phá và phân tích hơn ( và nhiều hình mình hoạ hay ho hơn). Hãy cho anh bạn 1 like nếu bạn thích.

UX không phải sân khấu để designer thể hiện cái tôi. Nó là công cụ giúp người dùng đạt mục tiêu. Nhưng nếu chỉ tối ưu mà quên cảm xúc, sản phẩm sẽ đúng… nhưng nhạt. (Giống như ăn cơm trắng không vậy, no nhưng khó để lại ấn tượng 😄) .Emotional UI chưa bao giờ dễ dàng. Nó cần người làm hiểu người dùng + có năng lực interaction design, graphic design, motion design,… Bạn có các nhân tố này trong team chưa? Và nếu chuẩn bị propose 1 sự “mới mẻ” trên UI, các bạn đã sẵn sàng nắm các metrics đo lường hiệu quả chưa?

Subscribe now

Here are to top 25 ideas I found and understood last year. They will be divided into 3 categories: Life - Work - People

LIFE (9)

1. My energy drops when life has no structure.
   Loose days lead to mental fog. Simple routines bring clarity fast.

2. I don’t need extreme discipline. I need light constraints.
   Small rules work better than strict plans.

3. Skipping dinner works only when the afternoon snack is planned.
   When it’s not, stress eating shows up. Picking snack is as important as picking main meal ingredient.

4. My body reacts before My mind understands.
   Numb hands, blank mind, tight chest = early warning signs.

5. I think best when writing, not when talking.
   Writing is my main thinking tool. Talking comes second.

6. Health goals fail when framed as “fixing yourself.”
   They work when framed as “supporting future energy.” No fixing, I am perfect cause I am still alive and well functioning enough to do what I want.

7. I recover faster when you name the state, not the cause.
   Labeling “I’m overloaded” helps more than asking “why.”

8. Short cycles beat long promises.
   25 days > 6 months. Weeks > years.

9. Silence is not rest for me.
   Low-stimulus input (reading, walking, light music) restores me better.
   

   Share

WORK (9)

10. I thrive in system design, not constant execution.
    My best work happens when shaping frameworks, not doing repetitive tasks. So unlike 2018 when I was Be design manager, I left the work run a while instead forcing a strict rule to settle first. No rule works without understand the human working in it.

11. Low-maturity clients drain me more than hard problems.
    The issue isn’t complexity. It’s misaligned expectations. We spent more time clarifying demand, guessing jobs and running around the bush more than actual building something.

12. I do my best thinking one level above the task.
    Strategy → structure → execution. Skipping levels costs energy. But sometimes I can flip the order to get more input for another.

13. I need visible progress artifacts.
    Slides, tables, diagrams calm your mind. Vague progress doesn’t. Especially verbal request with unclear Definition of done or Commited deadline.

14. Teaching clarifies my thinking faster than solo work.
    Explaining = debugging your own logic. Explaining for the dumb even challending your logic and wisdom ( to control your emotion while dealing with emotional/unsync logic people ) And teaching can happen whenever I explain, make task or write document to pass my knowledge to another.

15. I underestimate how much context others need.
    What’s obvious to you often isn’t to the room. So whenever I assign task, it must be clear as you stand in an well organized room.

16. I work best when roles are explicit.
    Ambiguous ownership triggers over-responsibility. But actually when working as COO of this small company, people with multiple roles are clear. So my solution is in each project/task, specify people role clearly.

17. My motivation rises when work has a learning arc.
    Projects without growth quickly feel heavy. But it’s neccessary. Observe harder, test harder, play harder to find the bottle neck and once it’s clear what to be done, do it sharp and fast.

18. I am strongest when translating complexity into plain language.
    This is a core skill. It’s not “just communication.” Not just small talk or one way to solve all problem. Fighting against people ignorance must be done strategically.

PEOPLE (7)

This part I will take it from my point of view.

19. I over-function around capable people too.
    Not just weak ones. I stepped in before being asked. And this give me more unwanted task, drain out my energy more than it should.

20. I feel safest with people who think in systems.
    Shared mental models matter more than shared values. For people thinking messily, I can absorb your thought later.

21. I absorb emotional tone faster than facts.
    Crowded, tense rooms cost you more than you admit.

22. I don’t need frequent connection. I need clean connection.
    Clear boundaries > constant contact.

23. I hesitate to disappoint, even when it costs me a ton.
    This shows up in pricing, scope, and time.

24. I grow when challenged calmly, not emotionally.
    Sharp but respectful feedback helps. Emotional pressure shuts me down and I will run away regardless consequences.

25. I am not afraid of conflict. I am afraid of chaos.
    Structure makes hard conversations possible for me.

Share

And dear my all audiences, the cycle of learning will go on for you and me…

Perpetual learning is not about collecting more knowledge. It is about staying awake.

The world will keep changing. Tools will shift. Roles will blur. What matters is not how much you know, but how fast you can notice what no longer works and adjust.

A real learning culture is quiet. It shows up in small questions, in honest retros, in the habit of testing instead of defending. It’s not “I know.” It’s “Let me check.”

Perpetual learners don’t chase trends. They build the ability to unlearn, relearn, and decide again with clearer eyes. If we keep that habit, learning in small loops, reflecting without ego, and acting with intent, then every year becomes useful, even the hard ones.

That is the culture worth carrying forward.

Phía dưới là dòng cảm ơn khách hàng đã sử dụng dịch vụ, và lời mời “hãy cho chúng tôi biết đánh giá của bạn về dịch vụ bằng cách tham gia khảo sát sau.”

Ngắn gọn. Rõ ràng. Chuẩn chỉnh.
Nhưng tôi lại thấy… trống rỗng.

1. Khi “đúng chuẩn” chưa chắc đã “chạm”

Ở góc nhìn kỹ thuật, bản khảo sát này hoàn toàn đúng bài:

• Có lời cảm ơn.

• Có thang đo rõ ràng (1–5).

• Có nút “Tiếp theo” mạch lạc.

Nhưng với góc nhìn người làm trải nghiệm, ta thấy ngay một khoảng trống:
Câu chữ ấy không nói với con người — mà nói với “người dùng”.

“Trang khảo sát” là cụm từ vô cảm. Nó khiến hành trình của khách hàng dừng lại ở một hành động kỹ thuật, chứ không dẫn dắt một khoảnh khắc giao cảm.

Chúng ta hỏi “bạn có hài lòng không”, nhưng lại quên hỏi “bạn đang cảm thấy thế nào về mối quan hệ giữa bạn và chúng tôi”.

Tôi may mắn được mục sở thị những VoC của khách hàng. Sự thật là không ít bên dùng 1 loại template khảo sát ( combo NPS + CSAT + CES ) chung 1 bảng hỏi khiến không ít người dùng thuộc nhiều tập khách hàng khác nhau hoang mang. Thời điểm được hỏi hay bối cảnh được hỏi cũng không hoàn toàn phù hợp.

Ví dụ, nếu bạn mới sử dụng cây ATM và được hỏi “Bạn có đi giới thiệu cho bạn bè sử dụng dịch vụ này không? ( Ý là cây ATM )” → Có thể bạn đứng hình 2s và nghĩ đứa qué nào bạn mình cần cây ATM này nhỉ? Hoặc chỉ một lần kẹt thẻ, lỗi màn hình cũng đủ bạn cho cái NPS ấy xuống mức thảm hại. Nhưng khổ một nỗi, NPS là chỉ số đo perception của khách hàng về thương hiệu hoặc người được hỏi ít nhất gắn bó với dịch vụ/thương hiệu cụ thể trong 3-6 tháng liền mạch.

Vậy kết quả NPS của cây ATM đáng thương kia đóng góp gì cho người làm khảo sát? Kết quả khảo sát có thể không có ý nghĩa hoặc làm đánh giá sai với dịch vụ.

2. Best practice từ Qualtrics + NNG: không chỉ là câu hỏi, mà là trải nghiệm

Theo chuẩn Qualtrics XM (Experience Management), phần introduction của khảo sát — tức là tiêu đề và lời dẫn đầu tiên — là điểm chạm đầu tiên định hình cảm xúc người trả lời. Nói cách khác, người ta gọi phần mở đầu khảo sát là “first moment of truth” - Khoảnh khắc đầu tiên quyết định xem người dùng có muốn tiếp tục hay không. Bạn có thể tham khảo tại đây.

Còn Nielsen Norman Group (NNG) gọi nó là “UX friction point” — điểm mà não người dùng tự hỏi:

“Việc này có đáng để tôi dành thời gian không?”

Hai góc nhìn khác nhau, nhưng gặp nhau ở một điểm:

Một khảo sát tốt phải giảm rào cản nhận thức (cognitive load) và tăng giá trị cảm xúc (emotional relevance).

Qualtrics gợi ý 4 tiêu chí cho phần mở đầu:

1. Rõ ràng: Người đọc hiểu ngay ai hỏi, hỏi về điều gì và vì sao.

2. Mục đích: Giải thích vì sao phản hồi của họ có ý nghĩa.

3. Giọng điệu tin cậy: Không hành chính, không rập khuôn.

4. Nhẹ nhàng: Giảm tải nhận thức, dẫn dắt hành động tự nhiên.

Điều đáng chú ý: Qualtrics không xem lời mở đầu chỉ là “phần giới thiệu”.
Nó là “UX artifact” – một sản phẩm giao tiếp cần được thiết kế, thử nghiệm và tối ưu như bất kỳ màn hình nào khác.

Về mặt này, phía NNG cũng đề xuất 3 giải pháp để “humanize” phần intro:

1. Talk like you care – Viết như đang nói chuyện thật.

2. Make purpose visible – Nói rõ phản hồi này giúp gì cho họ.

3. Start with gratitude – Bắt đầu bằng cảm ơn, nhưng cảm ơn thật, không khuôn sáo.

Như vậy, ta có thể đặt các câu hỏi sau khi viết lời mở đầu survey:

• Liệu người dùng có biết vì sao họ được hỏi câu này không?

• Giọng văn có mang tính “thương hiệu” hay chỉ là mẫu copy chung?

• Sau khi họ trả lời, họ có cảm thấy “mình vừa giúp được điều gì đó” không?

• Nếu bạn là khách hàng, bạn có muốn trả lời khảo sát của chính mình không?

Nhưng nếu chỉ dừng ở “clarity & tone”, ta vẫn thiếu một mảnh quan trọng:

3. Tâm lý học trong từng chữ: vì sao người ta muốn trả lời?

Từ góc độ hành vi (behavioral psychology), để một người thực sự muốn trả lời khảo sát, 4 cơ chế tâm lý nhỏ cần được kích hoạt:

Đó là lý do vì sao một dòng tiêu đề như:

“Trải nghiệm của bạn giúp Vietcombank tốt hơn mỗi ngày”
luôn hiệu quả hơn hẳn “Trang khảo sát”.

Bởi nó đặt con người lên trước biểu mẫu.

Còn nêú bạn muốn nó kích thích người dùng làm khảo sát vì “có đi có lại”, bạn có thể thử:

Chỉ một phút để giúp Vietcombank phục vụ bạn tốt hơn

Và đây là kết quả:

Tất nhiên, tôi cũng sửa cả UI design để tăng sự dễ dàng khi sử dụng, nhưng cái đó không đáng kể so với content viết lại với chủ đích vượt ra sự khuôn phép, chạm đến con người.

Share

4. Đôi điều cho UX writer và các CX practitioner

Thứ nhất: Thiết kế trải nghiệm bắt đầu bằng thiết kế bối cảnh tạo ra thái độ.

UX Writer hay CX Practitioner đều có thể rơi vào cái bẫy “chuẩn hóa”.
Ta dùng cùng một template, cùng một câu cảm ơn, cùng một cách hỏi.
Nhưng người thật thì khác — họ cảm nhận được khi chữ viết thật sự có người trong đó.

Một vài ví dụ nhỏ:

• “Hãy giúp chúng tôi cải thiện dịch vụ” → lạnh và cơ học.

• “Chúng tôi muốn biết điều gì khiến bạn hài lòng nhất — để nhân đôi điều đó” → ấm và gợi hành động.

• “Trang khảo sát” → thông báo kỹ thuật.

• “Bạn đang giúp chúng tôi làm Vietcombank tốt hơn” → lời mời cộng tác.

Cùng một ý, nhưng khác một chữ, có thể thay đổi thái độ.

Thứ hai: Khi bạn thiết kế một bảng khảo sát, bạn thực sự đang thiết kế điều gì?

• Một biểu mẫu thu thập dữ liệu?

• Hay một khoảnh khắc giao tiếp giữa thương hiệu và con người?

Khi bạn viết một dòng tiêu đề, bạn đang viết cho người đọc, hay cho chuẩn nội bộ?
Và nếu chỉ cần một câu nói khác đi có thể khiến ai đó cảm thấy “mình được lắng nghe”, liệu bạn có dành thêm 30 giây để viết lại không?

Kết nè :D

Tôi nghĩ, “khảo sát” không phải là phần kết của hành trình trải nghiệm.
Nó là cơ hội cuối cùng để thương hiệu thể hiện mình có thật sự lắng nghe.

Câu chữ, khi được viết với sự quan tâm, sẽ luôn mang sức mạnh lớn hơn cả số điểm hài lòng.

Để lại một câu hỏi cho bạn – những người làm nghề thiết kế trải nghiệm:

Nếu một khảo sát có thể khiến khách hàng mỉm cười trước khi họ rời đi, bạn sẽ viết nó như thế nào?

Bắt đầu từ một buổi họp rất thường ngày

Một sáng thứ Hai, cả nhóm bước vào phòng họp với hy vọng “dashboard mới” sẽ tháo gỡ bế tắc. Sếp muốn nhìn thấy “mọi thứ trên một màn hình”. Team phân tích lại muốn chứng minh giá trị của dữ liệu. Khách hàng thì… kỳ vọng hơi quá rằng dashboard có thể “kể ra” luôn chân lý và câu chuyện đằng sau mọi con số. Thực tế, như tài liệu workshop viết thẳng: khách hàng thường over-expect vào dashboard, và đội nhà thì đôi khi under-deliver ở phần báo cáo—phần lẽ ra phải giúp họ hiểu và hành động.

Chính trong những tình huống giả định ( nhưng không hiếm, tôi đi làm ít nhất cũng nghe qua mấy lần) như vậy, câu hỏi cốt lõi bật lên: insight là gì, ở đâu trong bức tranh dữ liệu đang chạy hằng ngày, và làm sao “giao” đúng dữ liệu cho đúng người?

1. Insight: định nghĩa, phân biệt, và cách kiểm tra chất lượng

1.1 Định nghĩa gốc, rút gọn cho dễ dùng

Nếu cần một mỏ neo ngôn ngữ đáng tin, Cambridge Dictionary gọi insight là “sự hiểu biết rõ, sâu (đôi khi bất ngờ) về một vấn đề phức tạp”.

Về mặt nghề nghiên cứu, ESOMAR nhấn mạnh bản chất công năng: insight là “khả năng giúp con người diễn giải một thế giới ngày càng phức tạp để phục vụ quyết định.” [ESOMAR Standards]

Vàn đây là định nghĩa Rút gọn siêu dễ hiểu của thầy Nam:

Cách rút gọn này đi đúng tinh thần đề cao hiệu quả ngôn ngữ mà tác giả slide đang theo đuổi.

1.2 Mô hình tháp DIKW: từ dữ liệu đến quyết định

Có lẽ điều tôi thích ở cách tình bày workshop hôm đó là sự cô đọng, ngắn gọn trên slide nhưng đi kèm nhiều ví dụ được kể trực tiếp bởi presenter. Nam là một trong những người hiếm hoi tôi cảm nhận sự tận tâm với nghề ở mức chuẩn chỉnh ( level cực đoan cũng có, in ít thui ). Cách bạn đặt câu hỏi và giải thích cho khách hàng luôn khiến tôi học được cái gì đó mà rõ rằng trong mấy cái video NNG course không thực tế bằng. Với tinh thần đó, trong workshop, nhóm của Nam đã phân biệt rất rõ không chỉ 3 định nghĩa trên mà còn đặt nó trong 1 mô hình bao quát hơn:

Observation – Findings – Insight: đừng gọi nhầm tên

Nguồn gốc học thuật được slide ghi rõ: Russell Ackoff (1989)—tác giả nổi tiếng với hệ phân cấp từ dữ liệu đến trí tuệ, được nhiều tài liệu hàn lâm khai triển.

- Data: sự kiện/thực đo rời rạc, chưa có nghĩa.

- Information: data + bối cảnh để trở nên hữu dụng.

- Knowledge/Insight: thông tin đã hiểu về mặt văn hóa/ngữ cảnh để tạo ý nghĩa/insight.

- Wisdom/Decision: vận dụng tri thức tích lũy để ra quyết định.

Điểm mấu chốt: DIKW nhắc chúng ta rằng dashboard thường sống ở tầng Data/Information (theo dõi, cảnh báo, “đọc nhanh”), còn Report là chỗ để kể chuyện sâu, kết nối mảnh thông tin rời rạc thành ý nghĩa/insight nhằm chuẩn bị cho hành động. Để có được Insight, đội ngủ không chỉ thu thập data đơn lẻ mà còn phải đặt nó trong bối cảnh, khai thác hết các điểm liên kết trong 1 khoảng thời gian theo dõi đủ lâu, đủ để thấy insight đã đủ ổn định và trở thành wisdom tạm thời trước khi đưa ra hành động.

Vậy khi nào Insight đủ tốt?

1.3 Checklist một insight “đủ tốt”

Slide tham chiếu khung 3 tiêu chí của Human8:

• Relevance (Liên quan): nói đúng câu chuyện của đối tượng đích.

• Aha! (Bất ngờ mà hợp lý): quen thuộc nhưng vẫn mở ra góc nhìn mới.

• Emotion/Meaning (Ý nghĩa chạm cảm xúc): giúp lý giải vấn đề, truyền cảm hứng phát triển tiếp theo.

Self-note theo cách hiểu của tui:

• Relevance_ bảo đảm “đẹp mà dùng được”.

• Aha!_ là bài test “thay đổi khung nhìn”—nếu ai cũng biết sẵn, đó là fact.

• Emotion/Meaning_ đóng vai trò chiếc cầu từ hiểu biết sang hành động.

Như vậy 1 insight có thể giúp bạn/team hành động được thì nó phải có có ít nhất 2 yếu tố thúc đẩy chúng ta: logic + cảm xúc + tính mới mẻ

1.4 Ý tưởng viết template Insight

Từ những kiến thức trong slide, tôi nghĩ chúng ta có thể tạo cho mình công thức viết insight có giá trị, thay vì chỉ dừng lại ở observation hay findings:

Ví dụ: “Khách vay mới hay chọn gói có khuyến mãi vì ngại thủ tục, nên tỷ lệ sử dụng sau 30 ngày thấp ⇒ rút gọn giấy tờ + nhắc dùng in-app 7 ngày đầu.”

Mẫu này tôn trọng tinh thần “ngắn mà trúng” của tác giả slide, giúp nhóm soi lại [Relevance] – [Aha] – [Emotion] trước khi “đóng dấu” insight.

2. Dashboard hay Report? Cho ai? Tại sao cần?

Sau phần 1, ta đã chốt lại một điều rất giản dị:

Insight không phải con số, mà là cách hiểu “vì sao & như thế nào” đủ mới và đủ tác động để dẫn tới quyết định. Ta cũng phân biệt rõ Observation – Findings – Insight và có một template một dòng để viết insight cho gọn, đúng chỗ.

Quay lại buổi họp sáng thứ Hai: kỳ vọng “dashboard kể hết câu chuyện” chính là nhầm lẫn giữa hiển thị dữ liệu và giải thích ý nghĩa. Dashboard giỏi trả lời “điều gì đang diễn ra?”, còn insight cần kể chuyện có bằng chứng để dẫn đường cho hành động. Vậy bước kế tiếp là đặt mọi thứ vào đúng “vật chứa” và đúng người: khi nào dùng dashboard, khi nào cần report; đưa cho ai; và để làm gì trong dòng chảy vận hành hằng ngày.

Nói ngắn gọn: từ định nghĩa insight, ta đi thẳng vào quyết định chọn công cụ –> chọn người nhận –> chọn mục tiêu.

2.1 Dashboard hay Report? - chọn đúng “vật chứa” cho đúng nhu cầu

Tài liệu workshop đưa ra một nguyên tắc đúng nghề và cực thực dụng:

- Dashboard phải dễ tiêu thụ, chỉ giữ những gì cốt lõi cho thành công của end-user. Bố cục cần tập trung vào phần quan trọng và có thể hành động, tuân thủ UX best practices để “đọc cái hiểu ngay”. Nghe có vẻ đơn giản nhưng đây cũng là phần chúng tôi debate nhất. Tuỳ từng đối tượng, wisdom hoặc insight họ có sẵn, mà mức độ hành động khi nhìn vào Dashboard sẽ khác nhau. Phần này sẽ nói trong mục sau.

- Report được dùng khi cần storytelling sâu, ghép nối bằng chứng rời thành bức tranh toàn cảnh, giúp người đọc hình dung điều gì đang diễn ra và vì sao.

Cá nhân tôi đánh giá cao cách tác giả slide rút gọn vai trò của mỗi “vật chứa”: ngắn, thẳng, và đủ để nhóm kỹ thuật lẫn kinh doanh hiểu mình phải làm gì với cùng một bộ dữ liệu.

Chắc thầy Nam cũng trải qua nhiều đau thương mới ra được cái slide gãi đúng chỗ ngứa của những người design dashboard, dù từ hướng kỹ thuật phân tích hay UX/UI.

Self note:

Không ít lần tôi thấy lãnh đạo mong một dashboard “nói hộ” mình nguyên nhân – trong khi bản chất nó sinh ra để hiển thị nhanh dữ liệu/thông tin. Chúng ta hỏi nó câu “vì sao?”, nhưng nó giỏi câu “điều gì đang xảy ra/đã xảy ra?”. Còn “vì sao” là địa hạt của insight/storytelling—tức report, phỏng vấn, thử nghiệm, đối chiếu, phản biện. Slide đã nói thẳng: report là chỗ “kể chuyện sâu”, giúp người đọc _“hình dung chuyện gì đang diễn ra với những con số này”_. Tôi đồng tình: kỳ vọng sai ở “vật chứa” dẫn đến thất vọng không đáng có.

Có thể nói những người ở level lãnh đạo có nhu cầu đưa ra quyết định chính xác dựa trên nguồn dữ liệu được tổ chức khoa học, nhưng điều họ thiếu đôi khi chính là thứ không nằm trên báo cáo: Insight!. May mắn nếu họ có wisdom sẵn, nhưng tôi cho rằng phần lớn là không. Lý do: data luôn fresh và mang tính toàn cục hơn observation của 1 người. Chả thế mà việc lãnh đạo tập đoàn lớn lấy insight không chỉ từ 1 consulting firm. Họ thuê và đối chiếu các report, knowledge từ nhiều nguồn và biến nó thành wisdom của mình. Cách này chỉ có thể với tập đoàn lớn và tốc độ ra insight của các consulting firm nhanh hơn/ bắt kịp mức độ thay đổi của đối tượng nghiên cứu.

2.2 Ai cần data gì, và “giao” thế nào cho phù hợp?

Để deliver đúng data cho đúng người, đúng mục đích, có lẽ việc đặt ra nguyên tắc sẽ dễ hiểu hơn.

Nguyên tắc dùng khi quyết định “làm dashboard kiểu gì, cho ai”:

1. Decision-first: bắt đầu từ quyết định bạn muốn họ đưa ra, không phải từ dữ liệu sẵn có.

2. Role-first: thiết kế theo vai trò (ai dùng, quyền hành động đến đâu).

3. Simplicity-on-purpose: tối giản có chủ đích; bỏ mọi thứ không giúp ra quyết định.

4. Workflow-native: nhúng vào luồng công việc (công cụ họ đang dùng, thời điểm họ cần).

5. Container-fit: Dashboard trả lời “điều gì đang xảy ra?”; Report kể “vì sao & nên làm gì?”.

6. Action-tracking: đo hành động sau khi xem (playbook, người chịu trách nhiệm, hạn xử lý), không chỉ đo “lượt xem”.

Vậy những hành động gì cần thiết để có Dashboard/report ưng ý?

Trích trong Workshop, tôi thấy một số step đi từ nguyên tắc đến thao tác tìm ra câu trả lời cho mấy câu hỏi này:

1. Tailor to user goals (điều chỉnh theo mục tiêu & vai trò)

   • Căn theo chiến lược & mục tiêu kinh doanh; xác định bao nhiêu dashboard và cho vai trò nào.

   • Intake session để hiểu rõ nhu cầu, quy trình, chỉ số, công cụ đang dùng.

   • Tích hợp vào workflow: để người dùng tiếp cận ngay trong công việc hằng ngày.

   • Xây “design personas” cho nhóm tiêu thụ dữ liệu và cập nhật khi nhu cầu đổi

2. Make it simple (làm cho đơn giản)

   Chỉ đưa những thông tin cốt lõi ảnh hưởng trực tiếp đến thành công của end-user.

3. Organize for insights (tổ chức để nhìn ra điều quan trọng, lấy thông tin từ bước 1)

   Trình bày để mắt người dùng tự rơi vào những điểm then chốt có thể hành động; áp dụng best practice UX để hấp thụ nhanh.

Đây là phần tôi thích nhất ở slide: Một vài dòng chữ nhưng đủ để dựng quy trình product analytics & CX mà không lạc hướng. Ngắn gọn có chủ đích, không phải tối giản bừa. Tất nhiên là đối với 1 người nhiều kinh nghiệm soi data, còn tôi chắc phải học thêm mấy khoá nữa mới làm được.

Ví dụ

Ví dụ này lấy từ quan sát cá nhân để bạn tham khảo góc nhìn của tôi. Nếu bạn thấy chưa chính xác, vui lòng để lại comment. 3 Ví dụ từ 3 cấp quản lý khác nhau.

Cấp 1 — Lãnh đạo (CEO/GM)

• Mục tiêu ra quyết định: ưu tiên chiến lược, phân bổ nguồn lực.

• Dashboard nên có: 5–7 KPI cấp cao (doanh thu, lợi nhuận, tăng trưởng khách, CAC/LTV, CSAT/NPS, rủi ro chính), xu hướng + cảnh báo.

• Bố cục: một trang duy nhất; thước đo mục tiêu (target), sparkline theo thời gian, 1 ô “So what / Now what” tóm khuyến nghị.

• Tần suất: tuần; kèm one-pager report tháng khi cần “vì sao”.

• Tránh: bảng số dày đặc, quá nhiều bộ lọc.

Cấp 2 — Quản lý trung gian (Head of Product / Ops Lead)

• Mục tiêu ra quyết định: ưu tiên backlog, gỡ nghẽn vận hành.

• Dashboard nên có (chọn theo vai trò):

  • Product: funnel, cohort/retention, feature usage, NPS theo feature, kết quả A/B.

  • Ops: SLA theo bước, thời gian chờ, lỗi theo nguyên nhân, heatmap bottleneck.

• Bố cục: 2–3 khối chính + drill-down theo phân khúc/feature/bước quy trình; bộ lọc ít và rõ.

• Tần suất: ngày (Ops có thể gần real-time). Deep-dive report tháng để giải thích nguyên nhân.

• Tránh: nhảy vào giải pháp trước khi nhìn đủ bằng chứng; quá nhiều chỉ số vanity.

Cấp 3 — Tuyến đầu (CS/Agent/Branch)

• Mục tiêu ra quyết định: làm gì ngay bây giờ cho khách/nghiệp vụ.

• Dashboard nên có: 2–3 tín hiệu chính + Next Best Action (nút/tác vụ cụ thể), danh sách việc theo ưu tiên.

  • CS/Retention: nhóm khách rủi ro rời bỏ, lý do top, nút “liên hệ/ưu đãi”.

  • Quầy/Chi nhánh: hàng đợi hiện tại, SLA sắp trượt, ca/kíp cần tăng cường.

• Bố cục: thẻ (cards) lớn, biểu tượng trạng thái, chữ to; tối đa 1–2 bộ lọc.

• Tần suất: real-time hoặc theo ca.

• Tránh: đồ thị phức tạp; thông tin không dẫn tới hành động

Share

3 Lời kết: Ngắn gọn có chủ đích

Tôi thích cái cách tác giả slide “chốt luận” bằng vài dòng nhưng đủ sức dựng khung làm việc cho cả product lẫn CX. Ngắn không phải để giản lược ý nghĩa, mà là cách buộc người làm dữ liệu tập trung vào điều có tác động. Nếu phải gửi một thông điệp cho chính mình ở những buổi họp thứ Hai như mở bài:

1. Đừng bắt dashboard kể chuyện mà nó không sinh ra để kể.

2. Hãy để report làm việc của report: truy vết nghĩa – dẫn tới hành động.

3. Viết insight bằng một câu, soi Human8; nếu không qua nổi, đó chưa phải insight.

Data là một tài nguyên quý giá. Thu thập data có chủ đích và có ý nghĩa thì càng khó. Đã không ít lần nghe khách hàng mô tả hệ thống thu thập data đồ sộ nhưng insight trích ra phần lớn phục vụ báo số KPI (NPS, CES, CSAT,…), ít khi nói được painpoint hay behavior của người, có nói thì cũng không cảm thấy sự WOW từ phía người đang kể làm mình cũng thấy … phí!

Leave a comment

• Chia sẻ những điều cá nhân học hỏi được, đem ra anh em cùng mổ xẻ

• Có phần hơi lý thuyết hàn lâm nhưng tác giả cũng đã cố kéo về cách diễn tả “dân dã” nhất mà không đánh mất tính khoa học.

• Tập trung vào cách lấy sample size trong nghiên cứu UX và CX.

0. Tại sao lại là nghiên cứu UX và CX?

Để lý giải việc gộp nghiên cứu UX (User Experience) và CX (Customer Experience) vào chung một phần về sample size, ta cần nhìn vào cả mối liên hệ lý thuyết lẫn thực tiễn triển khai:

Về lý thuyết

Cùng bản chất khoa học xã hội: UX và CX đều là nghiên cứu hành vi con người, mục tiêu chung là hiểu cách người dùng/khách hàng trải nghiệm, cảm nhận và ra quyết định. Do đó, việc chọn mẫu luôn xoay quanh cùng một câu hỏi cơ bản:

Cùng nguyên tắc thống kê: Dù nghiên cứu một giao diện (UX) hay một hành trình đa kênh (CX), các công thức tính mẫu (ví dụ Cochran), khái niệm confidence level, margin of error, hay “điểm bão hòa” trong định tính đều áp dụng giống nhau.

Về thực tiễn triển khai

UX tập trung vào trải nghiệm với sản phẩm/dịch vụ (ví dụ: thao tác trên app, độ dễ dùng của một giao diện).

CX rộng hơn, bao gồm toàn bộ hành trình khách hàng với thương hiệu (quảng cáo, mua hàng, sử dụng dịch vụ, chăm sóc sau bán).

Thực tế, một nghiên cứu CX thường bao gồm các điểm chạm UX; ngược lại, một nghiên cứu UX tốt thường phải đặt trong bối cảnh CX tổng thể.

Doanh nghiệp cần nhìn tổng thể: Các công ty lớn (Google, Amazon, các ngân hàng số…) đều dùng kết hợp: usability test (UX) để tối ưu điểm chạm, survey NPS/CSAT (CX) để đo cảm nhận toàn hành trình. Nếu tách biệt hoàn toàn, sẽ thiếu cái nhìn hệ thống.

Về ý nghĩa khi gộp chung trong phần sample size

Tránh phân mảnh: Người đọc dễ hiểu bức tranh toàn diện hơn khi thấy rằng cả UX và CX, dù phạm vi khác nhau, đều phải giải quyết bài toán “bao nhiêu mẫu thì đủ?”.

So sánh để học hỏi lẫn nhau: UX thiên về định tính, mẫu nhỏ nhưng lặp nhiều vòng; CX thiên về định lượng, mẫu lớn và khái quát. Gộp hai loại nghiên cứu lại cho phép chỉ ra sự khác biệt này và cách bổ sung lẫn nhau.

Ứng dụng thực tế: Một dự án nghiên cứu tại doanh nghiệp thường kết hợp cả UX lẫn CX. Ví dụ: một ngân hàng số có thể vừa phỏng vấn 10 người dùng để tìm pain points trong app (UX), vừa chạy survey 400 khách hàng để đo #CSAT toàn hành trình (CX).

Hãy review một chút về lý thuyết trong phần 1, soi xét 1 ví dụ nghiên cứu khoa học của Việt Nam ở phần 2 và đi qua các best practice ở phần 3.

• Lưu ý: Best practice không phải Absolute theory.

1. Sampling và vị trí trong nghiên cứu khoa học

Trong nghiên cứu khoa học, đặc biệt là trong UX (User Experience) và CX (Customer Experience), sampling là cách ta chọn ra một nhóm nhỏ từ toàn bộ khách hàng hoặc người dùng để đại diện cho quần thể. Thay vì khảo sát hay quan sát tất cả mọi người – điều gần như bất khả thi – chúng ta chỉ cần một nhóm đủ lớn và đủ đa dạng để phản ánh đặc điểm chung. Vì vậy, **sample size** (kích thước mẫu) là một quyết định then chốt: nó ảnh hưởng trực tiếp đến độ tin cậy, khả năng khái quát và cả chi phí nghiên cứu.

Trong quy trình nghiên cứu tổng thể, chọn mẫu nằm ở giai đoạn thiết kế nghiên cứu, ngay sau khi đã xác định câu hỏi nghiên cứu và giả thuyết. Nếu bước này sai, kết quả thu được dù phân tích tinh vi đến đâu cũng khó có giá trị.

Về nguyên lý, cỡ mẫu cần cân bằng giữa “đủ để giảm sai số” và “không quá nhiều để lãng phí”. Một trong những công thức cơ bản và phổ biến nhất là Cochran (1963):

Trong đó:

• n0n_0n0​: số mẫu tối thiểu cần thiết (sample size).

• Z: giá trị Z trong phân phối chuẩn, được tra từ bảng Z theo mức độ tin cậy (confidence level).

  • Ví dụ: mức tin cậy 95% → Z = 1.96; mức tin cậy 99% → Z = 2.58.

• p: tỷ lệ ước lượng của quần thể có đặc điểm đang nghiên cứu. Nếu không biết chính xác thì thường chọn 0.5 (50%) để cho ra cỡ mẫu lớn nhất – cách an toàn nhất.

• (1−p): phần còn lại của quần thể (q).

• e: sai số chấp nhận (margin of error). Ví dụ thường dùng là ±5% (0.05).

Công thức này giúp nhà nghiên cứu có một con số tối thiểu đáng tin cậy. Tuy nhiên, nó cũng có hạn chế: giả định quần thể ngẫu nhiên, không tính đến sự khác biệt giữa các nhóm nhân khẩu học, và không loại bỏ được thiên lệch khi thu thập dữ liệu (ví dụ, khảo sát online thường bỏ sót nhóm ít sử dụng internet). Do đó, khi áp dụng, cần đi kèm với chiến lược chọn mẫu phù hợp hơn, như phân tầng (stratified sampling) hoặc hỗn hợp kênh thu thập.

2. Ví dụ từ một nghiên cứu CX tại Việt Nam

Một nghiên cứu năm 2024 đăng trên _International Journal of Science and Research Archive_ đã khảo sát trải nghiệm khách hàng trong lĩnh vực ngân hàng số tại Việt Nam.

Bối cảnh nghiên cứu:

Trong thời kỳ ngân hàng số bùng nổ, nhóm tác giả đặt câu hỏi: _chất lượng dịch vụ số ảnh hưởng như thế nào đến trải nghiệm khách hàng?_ Nghiên cứu này hướng tới định lượng, sử dụng mô hình SEM (Structural Equation Modeling) để kiểm định các mối quan hệ.

- Công đoạn chọn mẫu: Nhóm tác giả áp dụng công thức Cochran với độ tin cậy 95% và sai số ±5%. Kết quả yêu cầu tối thiểu 385 mẫu, họ phát 500 bảng khảo sát và thu về 392 phản hồi hợp lệ.

- Điểm mạnh:

- Áp dụng công thức chuẩn mực, được công nhận rộng rãi.

- Chọn p=0.5, đảm bảo mẫu không bị đánh giá thấp.

- Số mẫu thu về cao hơn yêu cầu tối thiểu, tăng độ tin cậy.

- Hạn chế:

- Khảo sát chỉ thực hiện ở Hà Nội và TP.HCM, thiếu đại diện cho khách hàng vùng nông thôn.

- Hình thức online loại bỏ nhóm ít sử dụng internet.

- Chính nhóm tác giả cũng thừa nhận kết quả “không phản ánh đầy đủ toàn bộ khách hàng ngân hàng số tại Việt Nam”.

Qua đó, có thể thấy rằng việc tính toán cỡ mẫu bằng công thức đã đảm bảo tính hợp lệ thống kê, nhưng chưa đảm bảo tính đại diện thực tiễn. Đây chính là ranh giới quan trọng: khoa học cần công thức, nhưng thực tế cần sự thích ứng.

Share

3. Best practice về sample size trong nghiên cứu UX, CX

Trong nghiên cứu UX và CX, việc xác định sample size không thể tách rời khỏi **tính chất của bài toán nghiên cứu**. Với mỗi phương pháp, mục tiêu đặt ra khác nhau, do đó yêu cầu về mẫu cũng thay đổi. Nếu usability testing nhằm phát hiện lỗi thiết kế, chỉ cần vài người tham gia để nhìn ra xu hướng lặp lại. Nếu khảo sát định lượng muốn đo lường mức độ hài lòng hay kiểm định mô hình, cần hàng trăm đến hàng nghìn phản hồi để có ý nghĩa thống kê. Phỏng vấn sâu hay diary study lại nhắm tới động cơ và cảm xúc, nên ưu tiên chiều sâu và đa dạng hơn là số lượng. Trong nghiên cứu hành trình khách hàng, người làm nghiên cứu cần cả dữ liệu rộng để đo lường tại các điểm chạm, lẫn dữ liệu sâu để giải thích nguyên nhân. Còn với A/B testing, yêu cầu cỡ mẫu gắn chặt với việc phát hiện sự khác biệt có thực sự đáng kể về mặt thống kê hay không. Nói cách khác, **sample size phải phục vụ cho mục tiêu nghiên cứu chứ không phải là một con số cố định**.

3.1. Usability testing (định tính, phát hiện vấn đề)

Usability testing là loại nghiên cứu phổ biến nhất trong UX, mục tiêu chính là tìm ra những lỗi thiết kế và điểm nghẽn trong quá trình người dùng thao tác với sản phẩm. Vì mục tiêu là “phát hiện vấn đề” chứ không phải “đo lường mức độ phổ biến”, số người tham gia không cần quá nhiều. Chỉ cần một vài người, những vấn đề chính sẽ nhanh chóng lặp lại và đủ để khẳng định đó là lỗi hệ thống chứ không phải trường hợp cá biệt. Chính vì vậy, sample size ở đây nhỏ nhưng vẫn đảm bảo giá trị nếu được tổ chức hợp lý.

- Cỡ mẫu khuyến nghị: 5 người/vòng test.( NNG recommended, nhưng highly recommend các bạn tìm nguồn để đọc lý do, cũng như có góc nhìn phản biện với “best practice” này. Dù sao thì con số 5 đó cũng do đo đạc và nhận ra nó khớp với điểm bão hoà trong nghiên cứu định tính )

- Ưu điểm: nhanh, tiết kiệm, phát hiện phần lớn (80%) lỗi chính.

- Hạn chế: không đại diện cho mọi phân khúc; khó phát hiện vấn đề hiếm gặp.

- Cách xử lý: tổ chức nhiều vòng test nhỏ (5–8 người), mỗi vòng cho một nhóm người dùng khác nhau.

Bạn có thể đọc kỹ hơn cái Myth này để thấy nó ko còn là Myth tại đây.

3.2. Khảo sát định lượng (survey CX)

Khảo sát định lượng hướng tới việc đo lường mức độ hài lòng, trải nghiệm hoặc ý định hành vi của khách hàng. Đây là loại nghiên cứu cần dữ liệu có độ tin cậy thống kê, tức là kết quả thu được phải đại diện cho toàn bộ quần thể khách hàng với một sai số chấp nhận được. Vì vậy, sample size phải đủ lớn để đáp ứng margin of error và confidence level. Càng nhiều phân nhóm cần so sánh (theo tuổi, giới tính, khu vực), số mẫu càng phải tăng thêm để mỗi nhóm đều có cỡ mẫu tối thiểu.

- Cỡ mẫu khuyến nghị: 200–400 cho phân tích cơ bản; 300–500 cho SEM; >1000 nếu phân tích nhiều phân nhóm. Hoặc nếu bạn lăn tăn có thể tự tính toán theo công thức của Cochran, W. G. (1963). Hoặc tìm công cụ tính sample survey ở đây

- Ưu điểm: dữ liệu có ý nghĩa thống kê, khái quát hóa được cho quần thể.

- Hạn chế: tốn kém, dễ bias nếu chỉ thu qua một kênh (ví dụ khảo sát online).

- Cách xử lý: dùng công cụ như Qualtrics Sample Size Calculator; áp dụng stratified sampling; tính trước tỷ lệ không trả lời để phát hành nhiều hơn số mẫu cần thiết.

3.3. Phỏng vấn sâu, nghiên cứu định tính

Phỏng vấn sâu và diary study được thiết kế để tìm hiểu động cơ, cảm xúc, và bối cảnh hành vi – những thứ khó lượng hóa bằng khảo sát. Vì mục tiêu là “đi sâu” chứ không phải “đi rộng”, số lượng người tham gia không cần lớn mà cần đa dạng và đủ để phản ánh nhiều chiều khác nhau. Khi các câu trả lời bắt đầu trùng lặp, nghiên cứu đã đạt đến “điểm bão hòa” – dấu hiệu rằng cỡ mẫu hiện tại đã đủ.

- Cỡ mẫu khuyến nghị: 10–15 người cho mỗi phân khúc; 5–10 người cho diary study.

- Ưu điểm: khai thác insight sâu về động cơ, kỳ vọng, cảm xúc.

- Hạn chế: khó khái quát; phân tích mất nhiều công sức.

- Cách xử lý: chọn mẫu đa dạng (tuổi, giới, trải nghiệm sản phẩm khác nhau); dừng khi đạt điểm bão hòa (không còn insight mới dù tăng mẫu )

3.4. Customer journey research (mixed method)

Nghiên cứu hành trình khách hàng đòi hỏi sự kết hợp của cả định tính và định lượng. Định tính giúp phác họa bản đồ hành trình, khám phá pain points và khoảnh khắc quan trọng. Định lượng bổ sung để đo lường mức độ nghiêm trọng, tần suất của những pain points đó trong quần thể. Vì yêu cầu vừa sâu vừa rộng, cỡ mẫu phải chia làm hai phần: mẫu nhỏ cho phỏng vấn, mẫu lớn cho survey.

- Cỡ mẫu khuyến nghị: 10–15 phỏng vấn sâu cho mỗi giai đoạn hành trình; 300–500 phản hồi survey.

- Ưu điểm: cung cấp cái nhìn toàn diện – vừa insight chi tiết vừa số liệu khái quát.

- Hạn chế: phức tạp, tốn ngân sách và thời gian. Hồi học SDN, phải học và làm project from the scratch mất 1 tháng hơn mới đủ data sang phần này. Nó thật sự khó.

- Cách xử lý: thực hiện hai giai đoạn – định tính trước để khám phá hành trình, định lượng sau để kiểm chứng mức độ phổ biến.

3.5. A/B testing và thí nghiệm

A/B testing và các thí nghiệm được dùng để xác định xem thay đổi trong sản phẩm hay dịch vụ có tạo khác biệt thực sự không. Vì kết quả cần có giá trị thống kê, sample size phụ thuộc trực tiếp vào độ lớn của hiệu ứng mong muốn phát hiện. Nếu thay đổi chỉ mang lại tác động nhỏ (ví dụ tăng 2% tỷ lệ click), cần hàng nghìn người để phân biệt với sai số ngẫu nhiên. Ngược lại, nếu hiệu ứng rõ ràng, chỉ vài trăm người cũng có thể đủ.

- Cỡ mẫu khuyến nghị: từ vài trăm đến vài nghìn, tùy độ lớn của hiệu ứng.

- Ưu điểm: đo trực tiếp tác động của thay đổi; hỗ trợ ra quyết định nhanh chóng.

- Hạn chế: dễ sai nếu sample nhỏ, hoặc nếu test diễn ra quá ngắn. Hơn nữa, một vấn đề khi set up hay thấy ở VN là A/B chứa quá nhiều sự khác biệt khiến kết quả cuối cùng, phần lesson learn bị nhiễu ( không rõ yếu tố nào làm nên sự khác biệt )

- Cách xử lý: tiến hành power analysis để xác định mẫu tối thiểu; duy trì test đủ lâu (ít nhất một chu kỳ hành vi người dùng).

Túm lại ý tôi là:

Không có một con số mẫu nào đúng cho tất cả các nghiên cứu.

- Với định tính, điều quan trọng là đạt đến điểm bão hòa thông tin

- Với định lượng, điều quan trọng là đủ lớn để đảm bảo ý nghĩa thống kê.

Một nghiên cứu tốt không nhất thiết phải có “sample size thật lớn”, mà phải có cỡ mẫu phù hợp với mục tiêu, phương pháp và bối cảnh, đồng thời luôn minh bạch về những hạn chế còn tồn tại. Như vậy, sample size vừa là một công cụ khoa học, vừa là một nghệ thuật cân bằng giữa chi phí, tính đại diện và độ tin cậy.

I design things people rarely think about. The spacing between two buttons. The shade of grey in a disabled dropdown. The number of milliseconds it takes for a tooltip to appear before a user gives up.

And sometimes, when I sit too long in Figma or inspect a failing prototype for the sixth time, I start to feel like the objects are alive.

No, not literally. Not blinking back at me with eyes or mouths. But there. With some kind of agency. Some kind of... mood.

Like a button that refuses to be clicked, no matter how clean the code. Or a modal that keeps vanishing like it’s shy. Or a menu that feels—there’s no other word—grumpy.

For a long time, I thought I was being overly poetic. That it was the side effect of too many late nights spent tweaking pixels and whispering just work to stubborn UI elements.

Then I found Object-Oriented Ontology—OOO for short. And suddenly, the way I saw the digital world made a strange kind of sense.

So, what is Object-Oriented Ontology?

In short, OOO is a philosophical movement that argues:

Objects exist independently of human perception.

They have their own reality, their own presence, their own inner life—regardless of whether we’re using them, looking at them, or thinking about them.

An object isn’t just what it does for you. It’s what it is—even if you’ll never fully understand it.

OOO breaks the habit we’ve developed, especially in tech and design, of treating everything as tools for human ends.

That button? It’s not just “for” submitting a form.
That app? It’s not just “for” users to scroll.
That coffee mug? It’s not just “for” holding coffee.

They are—with or without us.

Why does this matter for designers?

Because so much of design is about control.
Defining flows. Guiding behavior. Optimizing outcomes.

But when I started seeing objects as entities with their own presence—not just props in the human theater—it softened something in me.

It made space for mystery. For respect. For tension.

I began to notice the parts of a product that resist smoothness. The friction that isn’t failure, but identity. The tiny rebellion of an unexpected hover state. The quiet sadness of an error message rarely seen.

OOO invites us to design not just for utility, but for relationship.
Not with “users,” but with the things we make.

This isn’t about mysticism. It’s about humility.

As a woman in tech, I’ve often felt flattened into roles: make things work, make them pretty, make them intuitive, make them better.

But OOO reminds me: I am not just what I do for others.

Neither are my designs.

When I design with this awareness, I feel more honest. Less extractive. I stop trying to dominate the material. I start listening. Sometimes even asking:

What do you—object, interface, system—want to be?

So what now?

OOO won’t show up in your sprint backlog. It won’t boost conversion directly. But it might make you more thoughtful.
It might help you see—really see—the things we usually rush past.

Because when we stop treating objects like servants, we begin to treat the world with more care.

And honestly, that might be the most radical kind of design.

P.S. I’d love to hear from you—do you ever feel like your tools have a personality? Or that your designs have something they’re trying to say back to you? Hit reply. Let’s talk.

1. Kiến thức là gì?

Kiến thức là những điều con người chấp nhận là đúng, dựa trên trải nghiệm, quan sát, suy luận hoặc niềm tin. Trong nghiên cứu, kiến thức không chỉ đơn thuần là thông tin – mà là hệ thống lý giải có thể kiểm tra, lặp lại, và phản biện.

Các loại kiến thức thông thường ta hay gặp

2. Kiến thức khoa học là gì?

Kiến thức khoa học là loại kiến thức đặc biệt vì:

• Có cấu trúc chặt chẽ (logic)

• Có thể kiểm tra (testable)

• Có thể bác bỏ (falsifiable – theo Karl Popper)

Khác với trực giác hay truyền thống, kiến thức khoa học được xây dựng thông qua một phương pháp rõ ràng, cho phép người khác:

• Chất vấn

• Thử nghiệm lại

• Phản biện và tái tạo kết quả

👉 Chính nhờ những đặc điểm này mà kiến thức khoa học đáng tin cậy và ứng dụng rộng rãi hơn trong đời sống và hoạch định chính sách.

3. Vì sao kiến thức cần tính khoa học?

Trong bối cảnh nghiên cứu xã hội, con người dễ bị ảnh hưởng bởi định kiến cá nhân, văn hoá, cảm xúc. Nếu không có một hệ thống “khoa học hóa” quá trình tìm hiểu, kết quả nghiên cứu dễ bị sai lệch.

Tính khoa học mang lại:

• Sự minh bạch trong phương pháp và dữ liệu

• Tính lặp lại: người khác có thể kiểm tra lại bằng cùng quy trình

• Tính khái quát: kết quả có thể áp dụng ở quy mô lớn hơn

• Tính khách quan: giảm thiểu ảnh hưởng của định kiến cá nhân

4. Sự khác nhau giữa Giả thuyết và Lý thuyết

Ví dụ:

Giả thuyết: “Người dùng trẻ tuổi ít tin tưởng vào tính năng nhận diện khuôn mặt trong app ngân hàng.”
Nếu kiểm tra qua nhiều mẫu, nhiều bối cảnh và kết quả giống nhau, giả thuyết này có thể đóng góp vào lý thuyết lớn hơn về niềm tin công nghệ trong ngân hàng số.Khi nào một nghiên cứu định tính được xem là “khoa học”?

Một nghiên cứu định tính đạt tính khoa học khi nó: 

1. Có hệ thống triết học rõ ràng: Nêu rõ bạn đang nhìn hiện tượng theo lăng kính nào (VD: constructivist, interpretivist).

2. Lựa chọn phương pháp phù hợp: Không dùng phương pháp chỉ vì “phổ biến”, mà vì nó phù hợp với câu hỏi và triết lý nền.

3. Tái hiện được logic phân tích: Có ghi chép quá trình mã hóa, diễn giải, dẫn chứng rõ ràng từ dữ liệu gốc.

4. Cho thấy tính ứng dụng thực tế: Không dừng ở mô tả mà chỉ ra hướng cải tiến, gợi ý hành động, hoặc phản biện chính sách.

5. Mở ra khả năng đối thoại khoa học: Cho phép người khác kiểm tra, chất vấn, hoặc tiếp tục phát triển nghiên cứu.

Share

Nền tảng nghiên cứu định tính : Làm sao để khoa học, thực tiễn và được chấp nhận?

1. Giới thiệu: Nghiên cứu định tính là gì?

Nghiên cứu định tính (qualitative research) là phương pháp khám phá hành vi, suy nghĩ, niềm tin và trải nghiệm của con người trong bối cảnh cụ thể. Mục tiêu không phải là đưa ra con số hay xác suất, mà là hiểu sâu “ý nghĩa” và “diễn giải” hiện tượng xã hội từ góc nhìn của người trong cuộc.

Tuy nhiên, để được xem là một nghiên cứu khoa học đúng nghĩa, không chỉ “nghe kể chuyện”, mà phải có nền tảng triết học, phương pháp suy luận logic, và khả năng tái kiểm tra, ứng dụng trong thực tế.

2. Triết học nền tảng: Ba trụ cột cơ bản

Mọi nghiên cứu định tính cần đặt ra ba câu hỏi lớn:

3. Ontology – Bản thể luận: Thực tại tồn tại như thế nào?

Ontology là triết lý về tự nhiên của thực tại. Trong nghiên cứu định tính, ba hướng tiếp cận chính gồm:

✅ a) Objectivism – Chủ nghĩa khách quan

• Tin rằng các hiện tượng xã hội tồn tại độc lập với con người.

• Ví dụ: Hành vi “dùng thẻ tín dụng quá mức” được xem là có thật và có thể quan sát như một đối tượng khách quan.

✅ b) Constructivism – Thuyết kiến tạo

• Tin rằng thực tại là kết quả của sự tương tác xã hội.

• Ví dụ: “Nợ thẻ tín dụng” có thể được người này coi là rủi ro, người khác lại xem là đòn bẩy tài chính – cả hai cách nhìn đều là thật với họ.

✅ c) Pragmatism – Chủ nghĩa thực dụng

• Không cố gắng phân định đúng – sai trong bản thể, mà tập trung vào điều gì hiệu quả.

• Ví dụ: Nếu một niềm tin khiến khách hàng hành xử khác đi, thì nó có “giá trị thực tại” theo nghĩa ứng dụng.

🧭 Trong định tính, hướng constructivist và pragmatist thường được sử dụng, vì nó tôn trọng sự đa dạng của trải nghiệm và cho phép nghiên cứu gắn liền với thực tế đời sống.

4. Epistemology – Nhận thức luận: Kiến thức được tạo ra như thế nào?

Epistemology bàn về cách con người biết điều gì đó là đúng.

✅ a) Positivism – Chủ nghĩa thực chứng

• Tri thức phải có thể đo lường, kiểm nghiệm.

• Phù hợp hơn với nghiên cứu định lượng.

✅ b) Interpretivism – Chủ nghĩa diễn giải

• Tri thức đến từ việc hiểu ý nghĩa mà con người gán cho hiện tượng.

• Người nghiên cứu không đứng ngoài quan sát, mà tham gia phân tích cách người khác hiểu thế giới của họ.

• Ví dụ: Khi phỏng vấn người dùng về lý do không dùng mobile banking, nhà nghiên cứu không chỉ ghi lại “họ trả lời gì”, mà cần phân tích hệ quy chiếu, cảm xúc, niềm tin đằng sau câu trả lời.

Tuy nhiên, đây chỉ là một cách siêu đơn giản để phân loại Nhận thức luận. Sẽ có nhiều chiều / dimension để phân tích nhận thức luận tuy vào nhu cầu và khả năng nghiên cứu.

5. Cách xây dựng nghiên cứu có tính khoa học

Mục tiêu của nghiên cứu là tìm ra kiến thức có tính khoa học. Như vậy, để một nghiên cứu định tính hay định lượng có tính khoa học, cần tuần tự qua các lớp tư duy triết học – gọi là philosophical foundation:

Philosophy 
↓ 
Ontology (Thực tại là gì?) 
↓ 
Epistemology (Biết bằng cách nào?) 
↓ 
Methodology (Chiến lược nghiên cứu) 
↓
Collect data methods (Phỏng vấn, khảo sát, quan sát...) 
↓
Analysis method (Mã hoá chủ đề, so sánh, mô hình hoá...) 
↓
Knowledge (Tạo ra tri thức khoa học)

Một nghiên cứu định tính mang tính khoa học không phải vì “đúng” hay “đủ số lượng mẫu”, mà vì quy trình suy luận chặt chẽ, gồm:

Lưu ý: Nghiên cứu định tính không tìm “sự thật duy nhất” mà tìm “nhiều sự thật sống động, tương đối”. Vì vậy, độ tin cậy đến từ: tính nhất quán nội tại, tính minh bạch trong lập luận, và khả năng liên kết chặt chẽ giữa vấn đề – phương pháp – kết luận.

6. Ứng dụng thực tế: Phân tích một nghiên cứu định tính Hành vi người dùng ngân hàng trong đại dịch COVID-19

Lấy ví dụ phân tích 1 bài nghiên cứu về hành vi người dùng app ngân hàng trong thời đại dịch COVID. Nguồn tại đây

Mục tiêu nghiên cứu:
Nghiên cứu này nhằm tìm hiểu vì sao và bằng cách nào người dùng thay đổi hành vi sử dụng ngân hàng số trong bối cảnh giãn cách xã hội do COVID-19.

Câu hỏi nghiên cứu:

• Làm thế nào người dùng thích nghi với dịch vụ ngân hàng không tiếp xúc?

• Yếu tố nào thúc đẩy hoặc cản trở hành vi sử dụng ứng dụng ngân hàng?

Dữ liệu sử dụng/ cách thu thập thông tin :

• 18 cuộc phỏng vấn bán cấu trúc với người dùng tại 3 thành phố.

• Phân tích đánh giá ứng dụng (app review) trên cửa hàng Google/Apple.

• Nhật ký hành vi trong 14 ngày từ một nhóm nhỏ người tham gia.

Phương pháp phân tích:

• Phân tích chủ đề (thematic analysis) để mã hóa hành vi và cảm xúc.

• Dựa trên khung lý thuyết “Social Practice Theory”: hành vi được hình thành từ ba yếu tố – niềm tin, công cụ, và kỹ năng.

Phát hiện chính:

• Người dùng mới ban đầu không tin tưởng bảo mật của ứng dụng, nhưng vì bắt buộc (giãn cách), họ học dùng – sau đó lại duy trì thói quen.

• Những người lớn tuổi gặp khó khăn do thiếu kỹ năng, nhưng nếu có người hướng dẫn, họ dễ dàng chuyển đổi.

• Việc ứng dụng thiếu tính năng đơn giản (như thông báo rõ ràng sau chuyển khoản) gây lo lắng, ảnh hưởng đến niềm tin.

Giá trị ứng dụng:

• Gợi ý cải tiến giao diện người dùng (UX) tập trung vào thể hiện rõ ràng quy trình và xác nhận.

• Đề xuất triển khai chương trình “đồng hành hướng dẫn số” cho người cao tuổi.

• Cung cấp insight cho chiến dịch truyền thông nhấn mạnh tính an toàn và hỗ trợ khi gặp lỗi.

Có thể thấy, họ đã áp dụng một số nền tảng Triết học:

• Ontology: Constructivism – hành vi ngân hàng là kết quả của trải nghiệm xã hội và niềm tin.

• Epistemology: Interpretivism – hiểu qua diễn giải chủ quan của người dùng.

• Methodology: Phương pháp định tính, phỏng vấn sâu, quan sát nhật ký, phân tích phản hồi thực tế.

Đây là một ví dụ điển hình về nghiên cứu định tính có cấu trúc logic, rõ triết lý nền, và mang tính thực tiễn cao – đủ sức thuyết phục cả người làm UX, marketing lẫn nhà hoạch định sản phẩm ngân hàng.

When you join a new company as a UX designer, you're often handed a long list of requests:

• “We need a new onboarding flow.”

• “Can you polish this feature?”

• “Our app needs a redesign.”

STOP.

It’s tempting to jump in, say yes, and start moving pixels.
But that’s a mistake.

The first thing I always do instead?

👉 Assess the company’s UX maturity.

Why Start with UX Maturity Assessment?

UX maturity is a reflection of how well a company understands, invests in, and integrates user experience into its processes.
It’s not about judgment — it’s about understanding the terrain before you build on it.

The Nielsen Norman Group offers a research-based UX maturity model with 6 stages — from the chaotic “Absent UX” (Level 1) to the strategic and culture-driven “User-Driven” (Level 6). This is very important that the NN/g consultant service will charge organizations Up to $150.000 in 6 to 8 months. But you, a solo designer, can try to do it with simple stakeholder interviews.

By evaluating a company’s UX maturity, you uncover:

• What’s realistically possible given the team’s mindset and structure

• Where the real risks are before a design project starts

• How to adjust your process to fit the current culture and capacity

What UX Designers Can Do at Each Maturity Level?

🧱 Level 1: Absent

UX is not acknowledged. The focus is on building features or "making things look nice."

What you can do:

• Make quick UI fixes

• Spot broken experiences and clean them up

• Start informal conversations about user needs

How to add value:

• Share simple UX case studies showing business value

• Conduct 1–2 user interviews and highlight pain points

• Present small wins (like increasing click-through rates)

🕳️ Level 2: Limited

UX pops up occasionally, but there’s no structure, no dedicated roles, and no consistency.

What you can do:

• Run basic user research (5–10 interviews)

• Create simple personas or journey maps

• Run lightweight usability tests

How to add value:

• Suggest creating a UX budget (even a small one)

• Formalize a lightweight UX workflow

• Educate the team on consistent practices

🌱 Level 3: Emergent

UX roles exist, but practices vary across teams. Some processes, some buy-in, but not stable.

What you can do:

• Conduct regular user interviews and surveys

• Build low-fidelity prototypes for user feedback

• Collaborate with developers to act on insights

How to add value:

• Push for standardized UX practices across teams

• Propose a shared design system or research library

• Host internal workshops to level up non-UX colleagues

⚙️ Level 4: Structured

UX is part of the product development process. Dedicated teams and tools are in place.

What you can do:

• Run structured usability tests

• Build high-fidelity prototypes using design systems

• Track success metrics (like task success rate)

How to add value:

• Embed UX into cross-functional squads

• Use more advanced testing (like A/B testing)

• Advocate for UX as a shared responsibility across teams

🚀 Level 5: Integrated

UX drives product decisions. UX, product, and engineering work hand-in-hand. User insights shape priorities.

What you can do:

• Continuously research and iterate with users

• Use analytics and testing to refine experiences

• Align UX decisions with business goals (e.g. revenue, retention)

How to add value:

• Scale your UX team and tools

• Explore AI, personalization, or other emerging practices

• Position UX as a key business asset

🌐 Level 6: User-Driven

UX is embedded in the company’s DNA. The entire culture revolves around user needs. Design drives strategy.

What you can do:

• Define the product roadmap based on user insight

• Lead predictive research and deep usability programs

• Pioneer new methods (like AR/VR, inclusive design, behavior modeling)

How to add value:

• Mentor other teams internally

• Share your practices publicly

• Sustain a culture of innovation and excellence

Share

I also built a template that you can use to interview and investigate yourself. Message me to get it.

What This Looks Like in Practice

Once I understand a company’s maturity level, I stop guessing.

If the company is at Level 1–2:

• I focus on quick wins

• I keep deliverables light and actionable

• I avoid introducing complex UX research too soon

At Levels 3–4:

• I start building cross-team collaboration

• I introduce structured processes

• I guide decisions with lightweight research

At Levels 5–6:

• I help scale innovation

• I align UX with business strategy

• I grow team capabilities and research depth

The Real Benefit: Smarter Design with Fewer Surprises

Every design request — no matter how vague or rushed — becomes easier to manage when you know the UX maturity level.

It lets you:

• ✅ Prioritize efforts that match the team’s readiness

• 🛠️ Avoid wasting time on ideas the company can’t implement

• 🚩 Spot missing ingredients (like research gaps or lack of buy-in) before the project breaks down

UX Maturity Signals Are Everywhere — Even Before You Join

👀 In the Job Description

You can often detect UX maturity before applying:

• Vague tasks like “make it pretty” → low maturity

• No mention of research, metrics, or collaboration → UX is an afterthought

• Clear expectations, strategy, user testing → likely mid-to-high maturity

🎙️ In the Job Interview

Ask direct questions to uncover maturity levels:

1. How are design decisions made?

   • Do designers influence product decisions early?

2. What does your UX process look like?

   • Are research and testing built-in or ad hoc?

3. Who do designers collaborate with?

   • Mature orgs include PMs, devs, researchers — not just engineers.

4. How is UX success measured?

   • Look for real metrics like NPS, CSAT, retention, or task success — not “we just know.” If they say we cannot tell due to NDA, we can ask “ How many personas can you build out of those data?” then see how they answer.

Why This Matters Before You Say Yes

If you're a UX designer exploring new roles, don’t wait until your first day to find out what you’re walking into.

Assessing UX maturity during the hiring process helps you:

• ✅ Set realistic expectations

• ✅ Know what kind of impact you can actually make

• ✅ Choose a role where you’ll grow, not just survive

✨ Final Thoughts: For Designers Seeking More Than Just a Title

Not every UX job is created equal.

Some companies want a decorator.
Others want a strategic partner who can shape products and shift mindsets.

The difference? UX maturity.

If you’re looking for meaningful work, not just ticket-solving, start assessing maturity from the moment you spot a job post.

And if a company isn’t quite there yet? That’s okay — as long as they’re open to growth and you’re ready to help lead it.

Don’t just take the job that needs “a designer.”
Take the one that respects what UX can actually do.
That’s where you’ll do your best work — and enjoy doing it.

Một trong những cách hiệu quả để kết nối CX và UX là sử dụng dữ liệu từ CX để định hướng cải tiến UX. Trong bài viết này, chúng ta sẽ khám phá cách trích xuất dữ liệu từ CX.

Tôi vẫn nhớ buổi họp giữa Customer Excellence and Các phòng ban công ty ( Be group hồi 2018 -2019 ). Một file excel dài ghi lại các phản hồi từ khách hàng lẫn tài xế được đưa ra thảo luận. Hồi đó không rõ cách thức họ làm thế nào nhưng nội dung complaint đã giúp team UX có cái nhìn tổng quan về vấn đề người dùng gặp phải. Chúng tôi tiếp xúc với tài xế, đóng vai là người dùng đi làm hàng ngày nhưng input đó không đáng kể.

Hiểu về CX, UX và CSAT

Customer Experience (CX)

CX bao gồm tất cả các tương tác của khách hàng với một công ty, từ việc tìm hiểu sản phẩm, mua hàng, đến hỗ trợ sau bán hàng. CX không chỉ tập trung vào sản phẩm mà còn vào cảm nhận tổng thể của khách hàng về thương hiệu.

User Experience (UX)

UX tập trung vào trải nghiệm của người dùng khi sử dụng một sản phẩm số, đặc biệt là giao diện và tính năng. Một UX tốt đảm bảo rằng sản phẩm dễ sử dụng, trực quan, và đáp ứng nhu cầu của người dùng.

Customer Satisfaction (CSAT)

CSAT là một chỉ số đo lường mức độ hài lòng của khách hàng với một tương tác hoặc tính năng cụ thể. Cơ bản thì nó nằm trong bộ đo chỉ số của CX. Khách hàng thường được yêu cầu đánh giá trên thang điểm (ví dụ: từ 1 đến 5) sau khi hoàn thành một hành động, như chuyển khoản trong ứng dụng ngân hàng. CSAT là công cụ mạnh mẽ để xác định các điểm yếu trong giao diện, từ đó định hướng cải tiến UX. làm CSAT chỉ là 1 phần trong rất nhiều cách lắng nghe khách hàng theo hướng nghiên cứu khoa học về trải nghiệm khách hàng.

Tại sao tôi đặc biệt mention #CSAT:

• Đấy là báo cáo có ý nghãi và phổ biến nhất trong những nơi tôi từng làm

• Nếu so với NPS thì CSAT đem lại thông tin sâu hơn. Đọc CSAT ( dù làm tới cấp độ nào, sâu hay nông ) thì UX vẫn sẽ tìm được thông tin để improvement rõ hơn nếu chỉ có NPS.

• Dù có hay không, UX designer nên quan tâm tất cả nhưng thông tin mà các phòng ban hay nhóm trong công ty đang làm việc trực tiếp với khách hàng. Nếu họ nói không có thông tin, trace từ KPI của họ. Nếu KPI của họ chưa đủ rõ, hãy phỏng vấn họ về người dùng.

• Tìm kiếm thông tin vẫn luôn là kỹ năng tôi thích nhất khi làm việc với các designer khác.

Để có 1 cái nhìn tổng quan, bạn có thể tham khảo bảng tổng hợp của mình:

Để ví dụ cụ thể hơn, bạn có thể đọc case dưới đây. Case này có trên Medium.

Ví dụ: Nghiên cứu điển hình: Domino’s Pizza – Ứng dụng CSAT để cải tiến UX

Bối cảnh

Domino’s muốn nâng cao trải nghiệm người dùng trên ứng dụng di động của mình và đồng thời cải thiện sự hài lòng của khách hàng. Tuy nhiên, họ nhận thấy lượng phản hồi thu thập được còn ít và chưa đủ chi tiết để đưa ra quyết định thiết kế chính xác.

Cách Domino's ứng dụng CSAT để cải tiến UX

1. Tích hợp khảo sát CSAT trong ứng dụng

• Sau khi người dùng hoàn tất một hành động quan trọng như đặt hàng, thanh toán, hoặc theo dõi đơn hàng, ứng dụng sẽ hiển thị bảng hỏi nhanh (popup 1 câu):
  “Bạn hài lòng thế nào với trải nghiệm vừa rồi?”
  → Thang điểm từ 1 đến 5 (hoặc 1 đến 10 tùy phiên bản).

2. Gắn ngữ cảnh vào phản hồi

• Phản hồi được ghi lại kèm theo các thông tin hành vi:

  • Vị trí người dùng trong luồng (checkout, tìm món, tracking,...)

  • Loại thiết bị và tốc độ mạng

  • Thời gian thao tác trung bình

• Giúp nhóm UX hiểu rõ: CSAT thấp xảy ra ở đâu, lúc nào, với ai.

3. Phân loại phản hồi & gợi ý hành động UX

• Hệ thống phân loại tự động các phản hồi CSAT thành 3 nhóm: Thấp (1–2), Trung bình (3), Cao (4–5)

Mỗi nhóm có hành động UX tương ứng, như sau:

Kết quả ngoài mong đợi

Nhờ tích hợp báo cáo CSAT vào hành trình người dùng, Domino’s không chỉ cải thiện rõ rệt thiết kế UX mà còn nâng cao sự hài lòng và trung thành của khách hàng. Đây là ví dụ điển hình cho việc sử dụng dữ liệu CX một cách chiến lược để nâng cao trải nghiệm sản phẩm.

• Giảm 25% tỷ lệ bỏ giỏ hàng ở bước thanh toán

• Thời gian tìm món giảm trung bình 11% sau khi cải tiến UI

• Tăng 18% đánh giá 5 sao trên App Store trong vòng 3 tháng

• Tăng 3,5 lần tỷ lệ phản hồi CSAT & NPS: Việc khảo sát ngay trong ứng dụng giúp tăng đáng kể số lượng và chất lượng phản hồi.

• Rút ngắn thời gian xử lý hỗ trợ khách hàng: Nhờ hiểu rõ vấn đề qua phản hồi cụ thể, đội ngũ hỗ trợ có thể giải quyết nhanh và chính xác hơn.

• Giảm chi phí vận hành: Chuyển từ công cụ bên ngoài sang hệ thống nội bộ giúp tối ưu chi phí duy trì.

• Tăng khả năng giữ chân khách hàng: Người dùng đã phản hồi khảo sát có khả năng đặt hàng lại cao hơn 29%, trong đó 49% đặt lại trong vòng 30 ngày.

Đây là 1 case tôi thấy khá sát thực tế ở VN. Chuyện có 1 team được đào tạo bài bản, có sự hỗ trợ từ leader cao cấp để làm các báo cáo chuyên sâu, hiểu thực sự về người dùng là điều xa xỉ. Dưới đây là mô tả ngắn gọn của bạn làm project :

Thật sự mông lung nếu so sánh với các hệ thống nước ngoài. Nhưng người châu Á vốn không đợi mọi thứ suôn sẻ dựng sẵn rồi mới hoàn thiện con đường tới mục tiêu. Một khi mục tiêu rõ ràng, các công cụ đều có thể dùng được, kể cả tự xây.

Chung quy lại, bạn có thể nhớ như sau:

• Các chỉ số như NPS, CSAT, CES → giúp ưu tiên những gì cần sửa trước

• Các chỉ số như phàn nàn của khách hàng, tỷ lệ từ bỏ, chủ đề cuộc gọi → giúp chẩn đoán vấn đề về khả năng sử dụng

• Các chỉ số như phân tích hành trình, mô hình sử dụng → giúp tối ưu luồng, bố cục và khả năng tìm thấy thông tin

• Để tìm ra dữ liệu thực sự có ý nghĩa, UX lead hoặc designer cần hiểu rõ cách CX vận hành và lần ngược lại từ báo cáo để khai thác những insight giá trị nhất.

• Để xây dựng một hệ thống CX–UX liền mạch, cả hai bộ phận CX và UX cần đạt đến một mức độ trưởng thành nhất định — về mặt chiến lược, vận hành và văn hoá. Dưới đây là phân tích các điều kiện cần có ở cả hai phía để tích hợp thành một hệ thống hiệu quả, có tác động cao.
  

ISO/IEC/IEEE 24765:2017 (Systems and software engineering vocabulary) defines an error as:

"A human action that produces an incorrect result, such as software containing a fault."

In these standardized definitions, there's often a distinction between:

1. Error: The human mistake or action that leads to a problem

2. Fault (or defect/bug): The manifestation of an error in the software

3. Failure: The observable incorrect behavior of the software when a fault is executed

Why do designers need to know this?

If you remember this fire accident, you should know it was based on a complicated code that made humans slow in reaction. I hate oversimplified design by the West at this point. BUT look at this image of the Vietcombank app, you can be surprised by how the minimalist mind applied

No one knows what is this but it blocked my experience. No place to report this issue. In general, Error is a great test for how a considerate product development team handles wanted and unwanted flaws. Those replicate the unpredicted life we are living. So if you want to design the delight, you must be aware of your dark spots.

Subscribe now

Error handling - from understanding the standard, the language with dev, the operation protocol to give the right message for user.

As designers, ensuring that software handles errors effectively is crucial—not just to pass compliance checks, but also to deliver an intuitive user experience.

Let’s briefly look at necessary international standards to guide error handling:

• HTTP Status Codes (RFC 7231, RFC 6585): Help applications communicate clearly and consistently with users and other services.

• ISO/IEC 25010: Provides guidelines for reliability, usability, and clarity in error handling, emphasizing fault tolerance and ease of recovery.

• OWASP Guidelines: Promote secure handling of user input, error logging, and protecting sensitive user information.

• Logging Standards (Syslog, Common Log Format): Offer clear, standardized log formats to simplify error analysis and debugging.

• Exception Handling Best Practices: Encourage safe, language-specific methods to manage exceptions, ensuring sensitive information remains protected.

• Accessibility Standards (WCAG): Guide designers in crafting error messages that are clear, readable, and accessible to all users, especially those with disabilities.

While these standards are essential foundations, what's more impactful is how your team manages error handling through clear and user-centric protocols.

Team-Focused Error Handling Protocols

For designers, "protocol" means creating clear rules on how errors are identified, communicated, and resolved, prioritizing user understanding and recovery. Designer should understand the common ground that the whole organization to give the right message. Otherwise, well, the case in France is one of the worst example I can find: Error message was too cryptic that the security team took too long to handle the issue right. Think how much millions can be saved if the message was clear?

Then what might happen when an error appear?

And when the error response from user reach the team, here is how everyone collaborate together:

So can designers like us do something to minimize the damage from the error? I think we can do a lot but not cover all error at the time we launch the product:

1. Being a close friend of the QA team is a super advantage.

2. Understand some common errors, aligning with components of a software ( listed down there, you can download it ).

   For example, HTTP Status Codes: Common codes to communicate issues:

   • 400 Bad Request: The input provided by the user isn't valid.

   • 401 Unauthorized: The user needs to authenticate or re-login.

   • 404 Not Found: The requested resource is unavailable.

   • 500 Internal Server Error: Unexpected issue on the server.

   • 503 Service Unavailable: Temporary downtime or overload.

3. Make an agreement with product team and other teams principles to handle the error. OR it can be as simple as a guide Custom System-Specific Codes: Should include clear, descriptive messaging to aid users in troubleshooting without overwhelming them with technical jargon.

   

   Error Handling Guide

   11.7KB ∙ XLSX file

   Download

   Download

4. Keep updating the error.

Conclusion: Designing for Errors as Part of the Experience

Effective error handling is not just a technical requirement but a crucial component of thoughtful design. When users encounter errors, the quality of your error handling directly impacts their overall experience and perception of your product.

Key Design Principles for Error Handling

1. Contextual Error Messages

• Display errors in direct relation to the user's actions

• Help users understand both what went wrong and why it matters

• Maintain the user's context to reduce cognitive load

2. Visual Error Indicators

• Use consistent visual language (color, icons, positioning) to signal errors

• Ensure accessibility by not relying solely on color (following WCAG guidelines)

• Scale visual prominence based on error severity

3. Clear, Actionable Guidance

• Provide specific next steps rather than simply stating something went wrong

• Use appropriate error message hierarchy:

  • Critical system errors: Full-screen or top banner notifications that prevent further interaction

  • Action-specific errors: Contextual messages near the point of failure

  • Performance issues: Unobtrusive toast messages that don't interrupt workflow

4. Preparing for the Unknown

• Collaborate with QA, development, and business teams to identify potential error scenarios

• Implement robust error reporting mechanisms to capture unforeseen issues

• Create fallback error states that gracefully handle unexpected failures

Cross-Functional Collaboration

Error handling represents a critical intersection where design, development, and business concerns meet. Designers should:

• Partner closely with QA teams to understand common failure patterns

• Develop shared error handling protocols with development teams

• Establish clear ownership of error message content and presentation

• Create documentation for consistent error handling across the product

The Lasting Impact

Remember that while errors themselves may be temporary, their impact on user trust is lasting. Great error handling doesn't just minimize frustration—it demonstrates respect for your users and their goals. By transforming moments of potential frustration into opportunities for clarity and assistance, you transform errors from obstacles into stepping stones in the user journey.

Share

Biết người biết ta – Chọn lựa phương pháp phù hợp.

Chuyện là Chagee, một thương hiệu trà sữa xứ người, bỗng dưng nổi như cồn tại Việt Nam theo cái cách mà chẳng ai muốn. Chẳng hiểu sao họ lại lỡ dùng "đường lưỡi bò" đầy tai tiếng, rồi lại thêm vài món quà tặng với thông tin lịch sử... rất "ảo ma Canada". Người ta bảo họ là trà sữa sang chảnh, nhưng sang đến đâu mà lại lúng túng thế này? Địa bất lợi ( xứ mình thiều gì trà ), Nhân bất hoà ( Người Việt mình thật không dễ bắt nạt ) thì lại chọn thời điềm Thiên thời không thể khó hơn: Chúng ta vừa kỷ niễm sự kiện Gạc Ma, nơi đầu sóng ngọn gió của Tổ Quốc.

Ngoài ra, tôi cũng để ý:

• Chất lượng trà sữa nói chung ( tàu hay ta ) là điều khiến người tiêu dùng thắc mắc trong nhiều năm. Nhãn tiền thì rõ là uống trà sữa trong thời gian dài làm tăng khả năng mắc các bệnh tim mạch, phụ khoa, tiểu đường,… ( do hàm lượng đường lớn, các chất trong sữa hay phụ gia tạo mùi tạo hương tích tụ lâu ngày ). Theo đông y, trà + sữa cũng là món khó tiêu.

  

• Kiểu thiết kế bao bì của Chagee không ngại lợi dụng chất xám của bên khác, vơ vào mình với lập luận lấy cảm hứng truyền thống thì nghe thấy sai sai rồi. Nếu các bạn lên trang https://www.zcool.com.cn/ thì không khó tìm thấy những ý tưởng hay, thực hiện tốt. Nhưng việc nhãn vẫn lựa cách này dù không thiếu tiền thì… nó nằm trong tư tưởng của ông chủ rồi.

  

• Chagee có chiến lược bành chướng thương hiệu rất hiệu quả. Chả thế mà họ là 1 brand toàn cầu. Thị trường Việt Nam chỉ là 1 phần nhỏ. Nhưng việc họ đối với ta như thế nào sẽ quyết định vị trí brand trong mắt người Việt. Vị trí Thương hiệu không nằm trên miệng nhân viên Marketing hay chương trình truyền thông. Nó nằm trong cách người dùng nhìn, nghĩ gì và định vị thế nào về thương hiệu đó trong cuộc sống của họ.

Còn chúng ta, người Việt vốn dĩ chẳng xa lạ gì với trà hay chè.

Từ bát chè xanh bà pha mỗi sáng, đến ấm trà mạn ông uống khi chiều tà, trà hay chè đã ngấm sâu vào huyết quản người Việt, thấm đẫm tình nghĩa và văn hóa dân tộc. Chè có trong văn hoá của người Việt Mình từ bình dân đến tầng lớp tinh hoa.

Ngoài ra, trong tiếng Việt, Chè còn có nghĩa là các món chè ngọt, được nấu và chế biến bằng nguyên liệu tự nhiên có sẵn trong vùng. Còn gì lành hơn thế. Kết hợp với sự sáng tạo, chấp nhận linh hoạt nguyên liệu ngoại lai, người Việt có thể ăn chè theo hơn 100 cách. Một món toàn dân uplift tinh thần toàn dân.

Vậy khi có anh hàng xóm vừa to xác vừa to mồm, thích khơi mào thì ta nên làm gì? Hẳn trong suốt thời gian lịch sử, người Việt đã quá hiểu kiểu truyền thông phương “ấy”. Ta là nước nhỏ, lấy mưu thắng lực, lấy chính nghĩa thắng cường bạo, mềm mại nhưng cũng bền bỉ cứng rắn như cây Tre. Chúng ta có thể chọn cách "ra trận" bằng sáng tạo, bằng sự thông minh nhẹ nhàng mà thấm sâu, không để sa vào bẫy chính trị hóa, không tạo cớ cho ai buộc tội ta chèn ép chúng tại sân nhà cả. Từ ý tưởng này, tối xác định:

Mục đích của dự án:

Sử dụng hình ảnh để cổ vũ tinh thần đấu tranh

Có hình ảnh mới tụ lại được sức mạnh đủ lớn. Muốn làm cách mạng, phải có lá cờ. Muốn làm campaign, cần key Visual.

Sự tương phản làm nên thông điệp

Bạn có nhớ chuyện Bác Hồ từng dùng tranh biếm họa về người kéo xe để lên án thực dân không? Đúng vậy, chẳng cần nhiều lời, chỉ cần sự đối lập rõ nét, mọi chuyện lập tức trở nên sáng tỏ. Chúng ta làm Brand Chè Taa cũng vậy.

Do đó, chỉ cần nhìn vào logo và những gì Chagee có, chẳng khó để đi tìm một hình ảnh tương phản mang hướng dân tộc mình.

Họ có mũ kinh kịch mang tính giải trí xa hoa, còn chúng ta có mũ cối, biểu tượng quen thuộc của lao động, chiến đấu và giản dị đời thường. Hai hình ảnh đối lập đặt cạnh nhau khiến thông điệp nổi lên rõ ràng hơn bao giờ hết. Một cách nhẹ nhàng, Chè Taa vừa cà khịa vui vui, vừa nghiêm túc khẳng định: Chúng tôi là người Việt, chúng tôi tự hào, và chúng tôi không dễ bị qua mặt.

Cách thực hiện này rất đơn giản, nhưng sự thâm sâu nằm ở chỗ: Ai nhìn vào cũng hiểu ý ngay lập tức, mà chẳng cần tốn sức tranh luận dài dòng.

Sức mạnh của sự đoàn kết tử tế.

Chỉ sau hơn một ngày, hình ảnh Chè Taa lan truyền chóng mặt khắp mạng xã hội. Một làn sóng ủng hộ dâng cao, vừa hóm hỉnh vừa sâu sắc, vừa vui vẻ vừa kiên định.

Tuy logo chỉ là 1 phần của phong trào tẩy chay, nhưng với mục ban đầu đề ra thì nó đã đạt được

Sử dụng hình ảnh để cổ vũ tinh thần đấu tranh

Kết quả của sự đấu tranh đoàn kết trên các mặt trận là: Chagee đã phải điều chỉnh. Còn điều chỉnh tư tưởng hay chỉ điều chỉnh tí ti để lấy lại sự chấp nhận của thị trường trăm triệu dân này là thứ tất cả cũng phải theo dõi.

Chúng ta cũng hiểu rõ, con đường đấu tranh bảo vệ văn hóa, chủ quyền và lòng tự trọng dân tộc còn dài lắm.

Chè Taa có thể chỉ là một viên gạch nhỏ, nhưng chắc chắn viên gạch này đủ cứng cáp và tự hào để góp phần xây nên bức tường vững chắc mang tên "Việt Nam". Với suy nghĩ đó, tôi open chia sẻ logo cho mọi người sử dụng miễn phí. Các bạn có thể:

• Thay maù

• Thay tên - Slogan

• Tạo câu chuyện riêng cho thương hiệu của bạn

• Thậm chí nếu có thể, bạn có thể vẽ lại theo cách bạn thấy phù hợp với tư tưởng phẩm chất người dân Việt:

• Sự đồng hành, đồng hình, đồng tư tưởng mới làm nên một sự thay đổi lớn.

Cảm ơn các bạn đã ủng hộ dự án bằng chia sẻ, suy nghĩ cũng như ý tưởng thay đổi, hy vọng với hình ảnh trực quan, các bạn sẽ boost up nhãn hàng dịch vụ của mình thành công. Nếu thấy bài viết có ý nghĩa, mong các bạn cứ tuỳ tâm donate nhé. Vẫn tin là khi thiết kế có hiệu quả hay ý nghĩa nhìn thấy đựợc, chất xám được dùng đúng chỗ đúng cách, mọi người không ngại đầu tư cho thế hệ sáng tạo nghệ thuật mới. Tôi sẽ rất hạnh phúc khi những tin nhắn donate có cả sự suy tư về cuộc sống hay khích lệ.

Nếu bạn không download được, bạn có thể nhắn tin cho tôi qua email: growannamolly@hey.com hoặc Linked in. Bạn có thể tìm xem cách đọc Tarot tại đây

Free Download

Share