it-swarm-vi.com

Có nên thông báo lỗi xin lỗi?

Chúng tôi đang thảo luận về nhóm của chúng tôi về thông báo lỗi có nội dung "Xin lỗi, bạn không có quyền truy cập tính năng này. Vui lòng liên hệ với quản trị viên của bạn để được hỗ trợ."

Có thích hợp để sử dụng ngôn ngữ "xin lỗi" trong trường hợp này không? Lý do chống lại nó là nó sẽ thích hợp hơn để "xin lỗi" cho một cái gì đó chỉ được coi là "lỗi" của ứng dụng như thời gian chết. ("Xin lỗi nhưng trang web của chúng tôi hiện không có sẵn ... vui lòng thử lại sau.")

521
JoelFan

Lý do tôi tin rằng điều quan trọng là phải có giọng nói xin lỗi là để đảm bảo bạn đang liên lạc với người dùng rằng, mặc dù đã xảy ra lỗi và anh ta đang tương tác với máy hoặc ứng dụng trong trường hợp này, bạn vẫn tôn trọng hành động của anh ta và đang nhân cách hóa Lỗi lầm.

Để trích dẫn điều này bài viết từ UXMatters :

Bạn có thể hiển thị thông báo lỗi của mình cho một người, vì vậy hãy viết nó bằng giọng nói bạn sẽ sử dụng nếu bạn đang thông báo lỗi cho người đó trực tiếp.

Tôi cũng khuyên bạn nên xem bài viết xuất sắc này, Bạn có nói rằng Không có khi bạn có thể nói về Có Có trong các hình thức web của bạn không? :

Thông báo lỗi có vẻ như là một phần không quan trọng và vô cùng nhàm chán trong việc tạo ra trải nghiệm người dùng. Nhưng tính chất của các thông báo lỗi có thể chuyển trải nghiệm xung quanh từ sự từ bỏ gần như chắc chắn sang chuyển đổi.

Bài báo nhấn mạnh rằng các thông báo lỗi sẽ mang một âm điệu tích cực và do đó, một phản hồi xin lỗi có thể giúp người dùng nhanh chóng phục hồi và không ngay lập tức trở nên phòng thủ về một lỗi mà họ có thể đã mắc phải.

Viết thông báo lỗi mang âm hưởng tích cực là khoa học tên lửa. Chỉ cần làm theo một vài quy tắc đơn giản:

  1. Đầu tiên, hãy loại bỏ các biệt ngữ công nghệ như không tương thích. Hầu hết người dùng đã giành chiến thắng, hiểu ý nghĩa của điều này. Nói chuyện với họ bằng ngôn ngữ của họ chứ không phải ngôn ngữ của các nhà phát triển của bạn. Ví dụ, ngôn ngữ không tương thích của người Viking dịch sang tiếng Đức không hoạt động cùng với tiếng Anh.

  2. Don mệnh dùng từ phủ định

  3. Xác định rõ ràng lỗi để người dùng biết phải sửa gì.

  4. Cung cấp cho người dùng một gợi ý về cách giải quyết vấn đề.

  5. Đổ lỗi cho chính mình, không phải cho người dùng.

Tôi cũng khuyên bạn nên xem Ảnh hưởng của thông báo lỗi xin lỗi và trạng thái tâm trạng đối với việc tự đánh giá hiệu suất của người dùng máy tính cho một nghiên cứu phân tích tác động của việc sử dụng thông báo lỗi xin lỗi đối với trạng thái tâm trạng của người dùng và cách con người- như tông màu xin lỗi có hiệu quả trong giao diện máy tính. Để trích dẫn một trích từ bài viết

Trong HHI, lời xin lỗi thường được sử dụng để thể hiện sự hối tiếc (Leech, 1983; Schlenker vàDarby, 1981) hoặc để làm giảm bớt sự tức giận của cá nhân gây ra từ sự từ chối của họ đối với hành động của người khác. , Nielsen (1998) lập luận rằng các thông báo lỗi phản hồi hành động của người dùng máy tính nên bao gồm một tuyên bố xin lỗi đơn giản khi lý do lỗi là giới hạn của giao diện máy tính để thực hiện tác vụ dự định. Tzeng (2006) đã thực hiện một nghiên cứu điều tra người dùng Nhận thức về các hệ thống trực tuyến chứa ba thông báo lỗi khác nhau, mỗi thông báo bao gồm các chiến lược lịch sự khác nhau. Trong nghiên cứu, trước hết người dùng định hướng lịch sự của người dùng đã được gợi ra và sau đó những người tham gia được yêu cầu tương tác với các trang web bao gồm các vấn đề được xác định trước. Khi người dùng gặp sự cố, hệ thống đã cung cấp một số thông báo lỗi nhất định thể hiện một chiến lược lịch sự tích cực (nghĩa là trò đùa), một chiến lược lịch sự tiêu cực (nghĩa là một lời xin lỗi đơn giản) và một thông báo cơ học cho lỗi (ví dụ: trang tạm thời không khả dụng). Các kết quả của nghiên cứu cho thấy rằng những người dùng xử lý các sự kiện xã hội có biểu hiện lịch sự thích nhận thông điệp xin lỗi hơn đáng kể so với tin nhắn cơ học hoặc trò đùa và họ thích tin nhắn xin lỗi hơn đáng kể so với những tin nhắn ít hướng đến biểu hiện lịch sự.

bài báo cũng chỉ ra cách một giọng nói xin lỗi trái ngược với âm điệu tác động đến nhận thức mà người dùng về họ chọn và cách nhận thức xin lỗi tích cực có thể giúp tăng cường hiệu suất tích cực

De Laere, Lundgren và Howe (1998) đã so sánh các phong cách tương tác giữa người và máy giống như giao diện máy tính. Họ không quan sát thấy sự khác biệt đáng kể giữa các phong cách khác nhau về mặt đánh giá của người dùng. Những phát hiện của nghiên cứu cũng chứng minh rằng phản hồi tiêu cực ảnh hưởng đến nhận thức bản thân của những người tham gia khác với phản hồi tích cực.

Tzeng (2004) đã kiểm tra xem phản hồi xin lỗi có ảnh hưởng đến nhận thức về hiệu suất của người dùng trong môi trường máy tính hay không. Nghiên cứu này cho thấy rằng người dùng có thể không mong đợi máy tính là lịch sự, nhưng những lời xin lỗi đã khiến các đối tượng cảm thấy tốt hơn về sự tương tác của họ với chương trình.

Tài liệu nghiên cứu Lời xin lỗi máy tính: Ảnh hưởng của phản hồi xin lỗi đối với người dùng trong môi trường máy tính cũng nêu ra lý do tại sao phản hồi tiêu cực liên quan đến trải nghiệm người dùng từ khía cạnh xã hội

Việc sử dụng các câu lệnh xin lỗi với thông báo lỗi góp phần tương tác giữa người và máy tính. Nếu chúng tôi cho rằng mục đích chính của thiết kế lấy người dùng làm trung tâm là tạo môi trường cho người dùng mà họ cảm thấy thoải mái, thì việc sử dụng câu nói xin lỗi trong thiết kế giao diện người dùng trở thành một vấn đề rất quan trọng. Hơn nữa, trong tương tác giữa người với người, một trong những vấn đề quan trọng nhất, có thể là quan trọng nhất, là cư xử một cách tôn trọng. Trong hầu hết các xã hội khi một người không cư xử tôn trọng hoặc phạm lỗi với người khác, xin lỗi là cách truyền thống và hiệu quả nhất để khắc phục vấn đề. Tương tự, nghiên cứu này cho thấy hầu hết các đối tượng nghĩ rằng phản hồi xin lỗi không có vẻ khó xử với họ và 95% trong số họ nhận được phản hồi xin lỗi cảm thấy rằng phản hồi xin lỗi có vẻ nhạy cảm với họ. Ở đây, dường như các đối tượng cảm thấy thú vị khi đối mặt với hành vi tôn trọng như xin lỗi khi họ gặp phải lỗi do máy tính không có khả năng như thể họ gặp phải vấn đề trong tương tác của con người. Những phát hiện của nghiên cứu này chỉ ra rằng việc thể hiện trạng thái tình cảm của một người trong thiết kế giao diện là rất quan trọng trong tương tác giữa người và máy tính bởi vì mọi người cảm thông hơn khi thấy các khía cạnh cảm xúc trong giao diện như, sự nhạy cảm, tôn trọng và cảm giác của con người. Do đó, những kết quả này có thể được sử dụng làm bằng chứng cho tuyên bố rằng máy tính mà đưa ra tuyên bố xin lỗi cho người dùng có thể chứng minh ý tưởng về thiết kế tập trung vào người dùng thực.

Mặt trái Microsoft khuyến nghị chỉ sử dụng âm điệu xin lỗi hoặc xin lỗi khi xảy ra lỗi nghiêm trọng:

Sử dụng Word, xin lỗi chỉ trong các thông báo lỗi dẫn đến sự cố nghiêm trọng cho người dùng (ví dụ: mất dữ liệu hoặc không thể sử dụng máy tính). Don Cầu xin lỗi nếu sự cố xảy ra trong quá trình hoạt động bình thường của chương trình (ví dụ: nếu người dùng cần chờ kết nối mạng được tìm thấy).

450
Mervin Johnsingh

Trong khi câu trả lời của Mervin là tuyệt vời, tôi sẽ nói xa hơn là "chấp nhận được" hoặc "ưa thích". Tôi muốn nói rằng bạn "phải" sử dụng giọng điệu xin lỗi vì một lý do rất chính đáng: nếu người dùng mắc lỗi, đó là do người dùng không hiểu các quy tắc hoặc logic của hệ thống. Đó không phải là lỗi của người dùng! Trách nhiệm của hệ thống là giải thích chính xác logic của hệ thống cho người dùng. Một lỗi người dùng sau đó là sự không phù hợp giữa những gì người dùng nghĩ nên được thực hiện và những gì hệ thống cho phép được thực hiện.

Mặc dù người ta sẽ không bao giờ nói dài dòng, nhưng nếu chúng tôi đánh vần hết, thông báo lỗi xin lỗi của bạn là: "Tôi xin lỗi vì giao diện người dùng của chương trình này, trải nghiệm trước đây của bạn với nó hoặc trải nghiệm với các chương trình tương tự khác , đã khiến bạn tin rằng bạn có thể thực hiện một hành động như vậy vào lúc này, nhưng bạn không thể vì .... "

Cụ thể đối với trường hợp được đề cập: người dùng nghĩ rằng quyền truy cập có thể khả dụng. Bạn đang xin lỗi vì sự hiểu lầm mà người dùng đã có, bởi vì hệ thống trước đây không thông báo rằng sự cho phép là không có sẵn.

Điều đó có nghĩa gì khi nói rằng một lỗi có thể là lỗi của người dùng? Người dùng không đi và làm những việc mà họ biết sẽ không hoạt động (điều đó sẽ chỉ lãng phí thời gian của chính họ). Lý do duy nhất khiến họ làm điều gì đó sai là vì họ không biết nó sẽ không hoạt động. Nếu người dùng không biết điều gì đó, thì đó có thực sự là lỗi của hệ thống vì đã không minh bạch điều này không? Bất kể lập trình viên có thể nghĩ nó rõ ràng như thế nào, phần lớn thời gian xảy ra lỗi là lỗi của hệ thống, vì vậy hãy viết thông báo lỗi của bạn theo cách phù hợp và bạn sẽ có người dùng hạnh phúc hơn.

106
AgilePro

Lùi lại một bước: Tại sao tính năng này được cung cấp (hiển thị) cho người dùng ngay từ đầu?

Nếu đó là một tính năng không có sẵn cho một người dùng cụ thể (hoặc lớp người dùng), hãy ẩn nó.

Nếu đó là một tính năng cao cấp mà bạn muốn tăng giá - hãy làm như vậy.

Xuất lịch sử là một cách tuyệt vời để sao lưu dữ liệu của bạn, nhưng chỉ có sẵn trên các tài khoản cao cấp. Hãy liên lạc với quản trị viên của bạn và yêu cầu họ nâng cấp tài khoản của bạn lên Premium.

Về thời gian chết hoặc lỗi (khi trách nhiệm chỉ thuộc về ứng dụng), tôi cảm thấy giai điệu là thứ yếu để biết rằng:

Vấn đề đã được ghi lại và một cơ thể ấm áp ở đâu đó biết bạn đang gặp vấn đề.

Có ai đó sẵn sàng cho tôi liên lạc.

Tôi có thể thử lại.

Một cái gì đó đã đi sai lầm khủng khiếp!
[.__.] Chúng tôi đã đăng nhập lỗi.
[.__.] Vui lòng thử lại hoặc liên hệ với [email protected] và chúng tôi sẽ liên hệ lại với bạn sớm nhất có thể.

62
Max

Tôi không thấy lời xin lỗi rất nhân bản hóa từ máy tính, bất kỳ hệ thống giữ tự động nào đối với mạng điện thoại khiến tôi cảm thấy cuộc gọi của mình rất quan trọng bằng cách nói: "Cuộc gọi của bạn rất quan trọng đối với chúng tôi! đại diện có sẵn tiếp theo. "

Tôi không nghĩ rằng lời xin lỗi là vấn đề chính ở đây. Điều quan trọng hơn nhiều là chúng đủ rõ ràng để giúp người dùng giải quyết vấn đề mà không áp đảo chúng.

Một thông báo lỗi tốt là hoàn toàn chi tiết về chính xác những gì gây ra vấn đề và cách khắc phục nó. Điều đó cũng hoàn toàn dễ hiểu và không gây căng thẳng cho người dùng bằng cách sử dụng biệt ngữ mà họ không hiểu.

Tất nhiên, hai mục tiêu này mâu thuẫn với nhau. Nói với người dùng rằng một ngoại lệ nghiêm trọng đã xảy ra trong khi làm rối loạn hạt nhân ở dòng 47 và có một kết xuất bộ nhớ được ghi lại là cực kỳ hữu ích cho nhà phát triển, nhưng nó hoàn toàn làm mất lòng người dùng và gây ra nhiều căng thẳng cho người dùng hơn là lỗi. Nhưng cũng không kém, nếu không đáng ghét hơn khi có một thông báo lỗi có nội dung: "Xin lỗi! Tôi đã làm hỏng. Xin lỗi về điều đó!" Là một người dùng, làm thế nào tôi có thể biết những gì đã sai? Làm thế nào tôi có thể bắt đầu giải quyết vấn đề của mình?

Điều này dẫn đến một sự thỏa hiệp có liên quan đến người dùng (Họ có phải là người sử dụng năng lượng không? Có phải đó là sự thật trong không khí? Tiếng Anh có phải là ngôn ngữ đầu tiên của họ không? V.v.).

Tôi thấy tốt hơn là tránh sự lộn xộn và lộn xộn của lời xin lỗi vì lỗi mà người dùng tự gây ra, và thay vào đó hãy viết các thông báo lỗi thực sự quan tâm đến người dùng bằng cách làm cho nó hoàn toàn rõ ràng về cách giải quyết.

36
Ben Mordecai

Có, thông báo lỗi sẽ xin lỗi khi có thể làm như vậy. Mọi người sẽ gán cảm xúc của con người cho máy tính , vì vậy máy tính nên lịch sự, đặc biệt đối với người dùng mong muốn mọi người lịch sự.

Ví dụ: các trang web được thiết kế cho người cao tuổi sẽ được hưởng lợi từ các thông điệp rất lịch sự cả

  1. để hiển thị rằng trang web và không phải người dùng có lỗi
  2. để phù hợp với mong đợi xã hội của những người dùng này. (Tôi đang đưa ra giả định rằng người cao tuổi có nhiều khả năng mong đợi sự lịch sự trong giao tiếp xã hội giữa người với người bình thường.)

Một chương " Mang lại ảnh hưởng đến tương tác máy tính của con người " có một phần về phản hồi xin lỗi (nhấn mạnh của tôi):

Nielsen (1998) lập luận rằng khi người dùng gặp sự cố và nhận được thông báo lỗi, thì nên bao gồm một tuyên bố xin lỗi đơn giản rằng lý do lỗi là giới hạn của giao diện để thực thi lệnh cho tác vụ dự định, không phải hành động của người dùng. [...]

Tzeng (2004) đã chỉ ra rằng các đối tượng trong các nhóm phản hồi xin lỗi không nhận thấy hiệu suất và khả năng của họ tốt hơn so với những người trong các nhóm không xin lỗi. Ông còn chứng minh rằng người dùng máy tính có thể không mong đợi máy tính là lịch sự; nhưng những lời xin lỗi làm cho các đối tượng cảm thấy tốt hơn về sự tương tác của họ với chương trình. Dựa trên ý tưởng rằng những người tham gia Định hướng lịch sự có thể có ảnh hưởng đến nhận thức của họ về thông báo lỗi máy tính xin lỗi, Tzeng (2006) đã thực hiện một nghiên cứu khác điều tra người dùng Nhận thức về các hệ thống trực tuyến chứa ba thông báo lỗi khác nhau, mỗi thông báo bao gồm các chiến lược lịch sự khác nhau. Ông gợi ra cho người dùng những định hướng lịch sự và yêu cầu họ tương tác với các trang web, mỗi trang đều chứa các vấn đề được xác định trước. Khi gặp sự cố, người dùng được cung cấp một số thông báo lỗi nhất định đại diện cho ba chiến lược lịch sự khác nhau, đó là chiến lược lịch sự tích cực (tức là trò đùa), chiến lược lịch sự tiêu cực (ví dụ như một lời xin lỗi đơn giản) và thông báo lỗi cơ bản (tức là trang tạm thời không có sẵn). Các phát hiện cho thấy rằng người dùng, những người sử dụng các biểu hiện lịch sự trong khi xử lý các sự kiện xã hội, thích tin nhắn xin lỗi hơn đáng kể so với cả tin nhắn cơ học hoặc trò đùa khác và những người dùng khác, những người ít định hướng để thể hiện lịch sự.

Cũng có một số bằng chứng cho thấy phản ứng của người dùng đối với tâm trạng của thông báo lỗi phụ thuộc vào tâm trạng của chính họ . Nếu bạn biết tâm trạng của người dùng có khả năng là gì, bạn có thể sử dụng điều đó để cấu trúc phản hồi lỗi thay thế.

29
Graham Herrli

Hãy tự nhiên, điều này có thể gây phiền nhiễu nếu bạn xin lỗi quá thường xuyên, viết tin nhắn của bạn bằng ngôn ngữ đơn giản như một người nói chuyện với một người khác . Nếu lỗi do bạn (ứng dụng của bạn, máy chủ của bạn, v.v.) thêm lời xin lỗi, nếu không, hãy để lại tuyên bố thực tế và cách giải quyết vấn đề.

Ví dụ:

  • "Xin lỗi, chúng tôi không thể gửi tin nhắn của bạn vì [một số] sự cố trên máy chủ của chúng tôi. Vui lòng thử lại."
  • "Chúng tôi không thể gửi tin nhắn của bạn; vui lòng điền vào trường email."

Một số khác:

  • "Xin lỗi, bạn không được phép truy cập tính năng này nữa; số dư của bạn thấp và chúng tôi đã hạ cấp kế hoạch của bạn."
  • "Bạn không có quyền truy cập vào tính năng này; nó chỉ khả dụng trong gói Mở rộng của chúng tôi."

Khi bạn xóa tất cả các "xin lỗi" này khỏi tin nhắn - bạn làm cho nó ngắn hơn, điều đó có nghĩa là người dùng có thể đọc và giải quyết vấn đề nhanh hơn . Nếu bạn đưa ra hướng dẫn rõ ràng và vấn đề có thể được khắc phục dễ dàng - không ai cần lời xin lỗi.

20
Dmitry Semenov

Tôi tin rằng hai quy tắc có thể được áp dụng trong hầu hết các trường hợp:

  1. Nếu người dùng mắc lỗi, đừng xin lỗi vì lỗi đó. Thay vì hướng dẫn cách tránh/sửa lỗi tiếp theo hoặc trong tương lai. Cung cấp tài nguyên trợ giúp nếu có thể/áp dụng.

  2. Nếu sự cố do chương trình gây ra, hãy đưa ra lời xin lỗi đơn giản vì sự bất tiện do lịch sự, nhưng điều quan trọng hơn là thông báo cho người dùng những gì thực sự xảy ra, những gì sẽ xảy ra tiếp theo, những gì có thể được thực hiện để khắc phục nó, cung cấp cơ hội để hỗ trợ sửa lỗi (ví dụ: đưa ra báo cáo lỗi), v.v.

13
epistemex

Phần mềm không có cảm xúc hay bản ngã, nhưng mọi người thì có. Ví dụ, nếu bạn mắc lỗi trong khi sử dụng tổng đài thương mại của AMEX, hệ thống sẽ nói "Xin lỗi, lỗi của tôi" bằng giọng nói dễ chịu của con người. Điều này có thể được coi là bảo trợ bởi một số người, nhưng nó cũng nhân hóa và theo tôi rất thông minh.

Tốt hơn hết là bạn nên xin lỗi, thay vì quá kiểm soát hoặc có ý nghĩa (ví dụ: "Nhập số, stooopid!", Hoặc tệ hơn: không có phản hồi nào cả). Con người thường có thứ bậc, và thật không may, lời xin lỗi thường được xem là hành động phục tùng. Mọi người muốn cảm thấy như họ tốt hơn máy tính họ sử dụng, vì vậy một lời xin lỗi sẽ hoạt động theo hướng này.

Nói tóm lại, xem đây là vấn đề của "ai có lỗi?" là một cách rất hợp lý để tiếp cận một vấn đề rất phi logic, đó là: làm thế nào để bạn giúp người dùng cảm thấy ổn về một trở ngại trong quy trình sử dụng phần mềm của bạn?

9
Brian Duncan

Giọng điệu xin lỗi giúp duy trì sự giao tiếp đúng đắn, giống con người. Một cái gì đó không nên đánh giá thấp!

Tương tác với một giao diện phải luôn được so sánh với cuộc trò chuyện trực tiếp của con người. Hãy tưởng tượng rằng bạn đang cố gắng mua vé tàu với mức giảm giá không áp dụng cho trường hợp của bạn. Bạn có muốn nghe "Truy cập bị cấm!" từ thủ quỹ, hơn một cái gì đó thông tin và lịch sự?

Ngoài ra, nếu người dùng có thể truy cập vào một địa điểm mà bạn không thể cho phép anh ta tương tác - đó là trong nhiều trường hợp lỗi nghiêm trọng của nhà thiết kế. Không có gì để đổ lỗi cho người dùng.

4
marcintreder

Có, hãy thăm dò ý kiến ​​người dùng, nhưng hãy nhớ rằng người dùng không đọc - đặc biệt là văn bản ở giữa. Vì vậy, hãy chắc chắn rằng thông tin thực tế là dễ dàng để phát hiện. Và nó có thể là một nỗi đau thực sự khi bạn có các biểu mẫu với một vài thông báo lỗi và mỗi một thông báo bắt đầu bằng "Xin lỗi ..." hoặc "Rất tiếc ..."

3
Steffen Kastner

Tuyên bố của bạn có vẻ tốt về tôi Nó không quá xin lỗi trong tự nhiên, vì nó không nên. Và, bạn rất khen lời xin lỗi với giải pháp có liên quan trong dòng tiếp theo. Lời xin lỗi trở nên cần thiết trong một số tình huống vì một số thông báo lỗi xuất hiện quá thẳng thắn và tiêu cực có thể khiến người dùng mất tinh thần.

Ngay cả khi đó là lỗi của người dùng, bạn không muốn tỏ ra thô lỗ và vô cảm vì phần mềm không bao giờ có thể biết người dùng cụ thể sẽ nhận thông báo lỗi cụ thể như thế nào khi nó cản trở năng suất của anh ta. Thêm một lời xin lỗi nhỏ và một giải pháp khả thi sẽ vô hiệu hóa toàn bộ thông báo lỗi và cho phép người dùng tập trung vào giải pháp thay vì vấn đề.

3
Mohit

Phụ thuộc vào ý định trang web hoặc ứng dụng. Bạn có muốn người dùng cảm thấy họ bị thua lỗ? Ví dụ; Bạn có muốn họ nâng cấp tài khoản của mình để tăng doanh thu không? Tôi nghĩ người dùng thường sẽ nâng cấp khi phải đối mặt với cảm giác mất mát hoặc "làm mà không có" một tính năng. Thông báo lỗi là một cơ hội quý giá khác để tạo ấn tượng với người dùng. Nếu lỗi không quan trọng đối với các mục tiêu của giao diện; Tôi sẽ không làm cho một "điều" lớn hơn từ lỗi. Nhanh chóng ghi nhận lỗi và giúp đưa người dùng trở lại nhiệm vụ dự định.

3
code-blind

Giống như tất cả các quyết định UX xem xét bối cảnh sử dụng. Tôi không nghĩ rằng xin lỗi vì bất cứ điều gì người dùng đã làm là phù hợp, nhưng nếu hệ thống hoặc ứng dụng không khả dụng với họ hoặc không thành công do sự cố không phải của người dùng (mất điện, lỗi cơ sở hạ tầng, v.v.), thì nó đáng để xem xét, miễn là nó đến với các thông tin hữu ích khác về vấn đề đang được biết đến, ETA khắc phục, phải làm gì tiếp theo, cách giải quyết - bất cứ điều gì để giữ cho người dùng tiếp tục hoặc đưa họ trở lại.

Trên một điểm liên quan, những gì khiến người dùng không hài lòng không phải là một lời xin lỗi hoặc thiếu, mà là các hướng dẫn để liên hệ với quản trị viên hệ thống. Rất nhiều người dùng không thể làm điều đó, hoặc thậm chí biết quản trị hệ thống là gì hoặc như thế nào! Tốt hơn trong các trường hợp thất bại trong ứng dụng như vậy để liên hệ với họ (nói với bàn trợ giúp hoặc nhóm hỗ trợ) và nói với họ rằng đã xong, dựa vào việc sử dụng quản lý sự cố và ghi nhật ký tự động. Sau đó, cho người dùng biết cách tiến hành, nếu công việc của họ an toàn, số sự cố là gì, cách chia sẻ, v.v.

Có lẽ điều này sẽ được sử dụng: https://bloss.Oracle.com/userassistance/entry/unazed_errors_are_they_ever_azed_anyway

3
uobroin

Có lẽ lý do không phải là cách tốt nhất để thông báo lỗi. Nếu chúng ta tuân theo logic phổ quát, vâng, chúng ta không nên xin lỗi vì điều gì đó không phải là lỗi của chúng ta.

Tuy nhiên, chúng ta nên luôn đặt giá trị của phương pháp lấy người dùng làm trung tâm với mục đích cuối cùng là làm cho người dùng cảm thấy thoải mái bất kể điều gì. Về vấn đề này, một phương pháp xin lỗi là giải pháp tốt nhất.

Hãy nghĩ về những gì người dùng cảm thấy trong thời điểm đó:

"Chết tiệt, tôi không được phép sử dụng tính năng này!"

Một lỗi là một thời điểm quan trọng khi bạn có thể dễ dàng mất một khách truy cập, đó là lý do tại sao bạn phải xử lý tình huống rất cẩn thận, suy nghĩ về tất cả các ý nghĩa nhận thức và tâm lý. Đây là những gì thực sự quan trọng, không phải logic cuộc sống hàng ngày.

Dù đó có phải là lỗi của anh ấy hay không, khi gặp lỗi, người dùng sẽ cảm thấy thất vọng. Khi bạn cảm thấy thất vọng, bạn muốn lời xin lỗi của ai đó. Vâng, bạn đổ lỗi cho tất cả mọi người và mọi thứ xung quanh bạn, nhưng chính bạn.

Thật trẻ con, nhưng tôi thừa nhận nó cũng xảy ra với tôi. Khi một ứng dụng làm tôi thất bại (vì lỗi của tôi) và xin lỗi, nó thực sự đặt một nụ cười trên khuôn mặt của tôi và khiến tôi suy nghĩ:

"Tốt thôi, tôi tha thứ cho bạn. Dù sao thì tôi cũng biết bạn không làm gì sai cả."

Nếu bạn nhắm đến tất cả các chi phí cho một xác chết chính trị nhất định và bạn không muốn xin lỗi vì điều gì đó không phải là lỗi của bạn, hãy xem xét một giai điệu trung lập hơn, như:

" Thật không may , bạn không có quyền truy cập tính năng này."

Tôi thấy Lời "không may" rất quan trọng. Nếu không, nó có vẻ như là một sự buộc tội, sẽ xua đuổi người dùng bực bội trong một giây:

"Bạn không có quyền truy cập tính năng này." (thêm dấu chấm than và bạn sẽ không gặp lại người dùng đó)

Tôi thấy toàn bộ thông điệp quá trang trọng bằng cách nào đó (đó là sự thật, nó phụ thuộc vào ngữ cảnh của ứng dụng của bạn). Tôi sẽ tìm kiếm một cái gì đó ngắn gọn và hài hước để truyền tải thông điệp theo kiểu không robot. Nghe có vẻ đơn giản, nhưng rất khó để đưa ra những văn bản như vậy, unles bạn được đào tạo theo cách đó, để tránh tình trạng khó xử hơn nữa như thế này:

Bạn cũng nên cung cấp một lời giải thích có thể cho lỗi và một số cách để phục hồi từ nó. Điều này sẽ làm giảm sự thất vọng của người dùng rất nhiều!

4 tin nhắn viết lỗi

2
Mircea

Làm việc cho công ty SAS, tôi sẽ nói rằng việc xin lỗi là cần thiết, giả sử rằng bạn không nhận lỗi.

Với các công ty như Starbucks, Apple và Zappos ngoài kia, mọi người không quan tâm đó là lỗi của ai, miễn là đó không phải là của họ. Người tiêu dùng, người dùng cuối và người mua là vua hoặc nữ hoàng.

Vì vậy, đừng xin lỗi nếu ứng dụng/trang web của bạn xóa tất cả dữ liệu của họ ... Đó là việc chào đón một vụ kiện với vòng tay rộng mở, nhưng mọi người thích cảm thấy thế giới là con hàu của họ. Và nếu bạn có một tin nhắn xin lỗi VỚI một phương tiện để nhanh chóng tìm ra giải pháp - hãy tìm nó.

2
Peter

bạn nên xin lỗi vì đã không cung cấp cho họ liên kết hoặc số điện thoại hoặc bất kỳ cách nào khác để "liên hệ với quản trị viên của họ để được hỗ trợ"

Người dùng đang tự hỏi "quản trị viên của cái gì?", "Quản trị viên văn phòng của tôi hay người ở công ty bạn?"

1
Steve Whetstone