Xử lý lỗi là một công việc được thực hiện theo quy trình. Vì vậy, việc xử lý một lỗi tốt hay còn tồn tại lỗ hổng không chỉ được quyết định bởi một hay một vài cá nhân, mà đó là kết quả của một đội nhóm.
Các thông báo lỗi xuất hiện như một phần trong cuộc sống trực tuyến hàng ngày của chúng ta. Mỗi khi máy chủ gặp sự cố, không có kết nối với Internet hoặc quên thêm một số thông tin vào form, chúng ta sẽ nhận được một thông báo lỗi. “Đã xảy ra lỗi” là một thông báo vô cùng quen thuộc. Nhưng đó là lỗi gì? Điều gì đã xảy ra? Và quan trọng nhất là làm thế nào để khắc phục lỗi?
Tham khảo thêm: Bug là gì? 5 Loại Bug Phổ Biến Nhất Hiện Nay
Chúng ta luôn gặp phải các thông báo lỗi, nhưng việc thường xuyên đối mặt với lỗi có giúp chúng ta xác định được lỗi xảy ra ở đâu và cách để khắc phục nó?
Khoảng một năm trước tại Wix, chúng tôi chợt nhận ra rằng mỗi khi xảy ra lỗi, chúng tôi đã cho người dùng biết lý do là tại sao. Khi nhận được lời cảnh tỉnh này, chúng tôi cảm thấy phải bắt tay vào hành động ngay, không để giải quyết chỉ một thông báo lỗi mà là nhiều hơn và hướng đến giải quyết được tất cả lỗi.
Chào mừng bạn đã đến với Errorgate 2021.
Ở lần đó, chúng tôi đã thay đổi hàng nghìn thông báo lỗi chỉ trong vòng một tháng.
Để hoàn thành tốt những nỗ lực này, trước hết chúng tôi phải tự xác định được điều gì giúp chúng ta nhận định được đâu là một thông báo lỗi tốt và đâu là một thông báo lỗi xấu?
Tham khảo thêm:
IT là gì? Học và làm IT: Yêu cầu và cơ hội việc làm [Cập nhật 2023]
Developer là gì? Chìa khóa để trở thành Developer chuyên nghiệp
Điều gì tạo ra một thông báo lỗi xấu
Đây là một ví dụ về thông báo lỗi xấu. Thông báo này sử dụng giọng điệu không phù hợp, đổ lỗi, sử dụng thuật ngữ chuyên môn gây khó hiểu và quá chung chung.
Rất tiếc! Đã xảy ra lỗi (Giọng điệu)
Bên thứ ba bạn đang truy cập vào không phản hồi (Đổ lỗi), vì vậy chúng tôi không thể Fetch data (Dùng thuật ngữ kỹ thuật). Thử lại sau nhé! (Giải pháp chung chung)
- Giọng điệu không phù hợp: Thử tưởng tượng một bác sĩ đang thực hiện một cuộc tiểu phẫu và nói “Rất tiếc! Có gì đó hơi sai…” Đây là điều mà không ai muốn nghe cả. Đó không phải là lúc để đùa giỡn. Chúng tôi muốn cho người dùng thấy rằng chúng tôi nhận thức được việc có lỗi xảy ra là rất nghiêm trọng và chúng tôi hiểu vấn đề đó quan trọng như thế nào đối với họ.
- Thuật ngữ kỹ thuật: Mặc cho thế giới ngày nay đề cao việc thiết kế lấy người dùng làm trung tâm, thuật ngữ kỹ thuật vẫn len lỏi xuất hiện trong các thông báo lỗi. Bạn không thể Fetch data của tôi? Thông tin xác minh của tôi bị từ chối? Những lỗi kỹ thuật không quan trọng đối với người dùng, họ đơn giản là chỉ muốn biết điều gì đã xảy ra và làm sao để khắc phục nó.
- Đổ lỗi: Hãy cố gắng tập trung vào giải quyết vấn đề thay vì đi tìm nguyên nhân vấn đề. Chúng tôi không muốn đổ lỗi cho người dùng, ngay cả khi lý do xuất hiện thông báo lỗi xuất phát từ hành động của chính họ.
Chúng tôi cũng sẽ không đổ lỗi cho các bên thứ ba vì điều đó khiến chúng tôi trở nên không chuyên nghiệp, kể cả khi nếu làm vậy có thể giúp Wix giảm bớt một phần áp lực. Người dùng đến với Wix vì nó là một nền tảng đáng tin cậy, họ không muốn và cũng không cần phải quan tâm đến các nền tảng khác. Chúng tôi có thể thông báo dạng “Chúng tôi đang gặp sự cố khi kết nối với …” nhưng chúng tôi sẽ không thông báo kiểu như “… hiện không phản hồi”.
- Thông báo chung chung mà không có lý do: Đôi khi chúng tôi sẽ không xác định được lỗi xảy ra ở đâu. Hoặc là, nếu chúng tôi biết nguyên nhân xảy ra lỗi mà không thông báo điều đó cho người dùng biết, có thể sẽ gây ra sự bất bình ở người dùng.
Tham khảo thêm:
UX Research là gì? UX Research làm gì, lợi ích, vai trò
QC Là Gì? Nghề QC Như Thế Nào? Các Phương Pháp QC?
7 Kỹ Năng Mềm Được Nhà Tuyển Dụng Đánh Giá Cao
QA là gì? Kỹ năng để trở thành nhân viên QA giỏi [Cập nhật 2023]
Điều gì làm nên một thông báo lỗi tốt
Đây là một ví dụ về một thông báo lỗi tốt. Nó giải thích những gì đã xảy ra và nguyên nhân tại sao, cung cấp sự yên tâm, thấu hiểu người dùng, giúp người dùng khắc phục sự cố và cho người dùng một giải pháp kịp thời.
Không thể kết nối với tài khoản của bạn (thông báo điều gì đã xảy ra)
Thay đổi của bạn đã được lưu (Trấn an người dùng), nhưng chúng tôi không thể kết nối tài khoản của bạn bởi vì vấn đề kỹ thuật ở cuối quy trình của chúng tôi (thông báo lý do xảy ra). Vui lòng thử lại sau.(Cách khắc phục sự cố) Nếu vẫn gặp sự cố, hãy liên hệ Trung tâm Chăm sóc khách hàng.(Cách giải quyết)
- Thông báo điều gì đã xảy ra và lý do: Thông báo rõ ràng điều gì đã xảy ra hoặc không xảy ra. Thông báo có thể được kết hợp bởi cả hình ảnh và văn bản. Giải thích tại sao người dùng lại gặp lỗi này, ngay cả khi lời giải thích duy nhất có thể có là có sự cố kỹ thuật. Tại Wix, chúng tôi quyết định nói rằng “chúng tôi gặp vấn đề” nếu chúng tôi có đủ không gian để giải thích lý do trong thông báo, để nhấn mạnh rằng đó không phải lỗi của người dùng.
- Trấn an người dùng: Nếu có thể, hãy cho họ biết những thứ sẽ không bị ảnh hưởng bởi lỗi. Ví dụ: Mặc dù email chưa được gửi đi nhưng các thay đổi của người dùng vẫn được lưu dưới dạng bản nháp
- Tìm sự cảm thông: Chúng tôi sẽ sử dụng “Vui lòng” trong một vài tình huống. Có thể là một tình huống thực sự nghiêm trọng hoặc là một vấn đề mà chúng tôi hoàn toàn không có giải pháp. Việc sử dụng từ “Vui lòng” sẽ nhận được thiện cảm hơn từ khách hàng.
- Giúp người dùng khắc phục sự cố: Hãy hướng dẫn người dùng nếu có cách để họ có thể tự khắc phục sự cố. Nếu thiếu không gian, hãy gửi đến họ một liên kết mô tả các hướng dẫn cách khắc phục như “Làm cách nào để khắc phục sự cố này?”
- Luôn đưa ra cách giải quyết: Nếu người dùng không thể tự khắc phục sự cố hoặc có thể sự cố vẫn sẽ tiếp tục xảy ra, hướng dẫn họ cách liên hệ với Bộ phận chăm sóc khách hàng.
Sau khi đã xác định được điều gì quyết định một thông báo lỗi là tốt hay xấu, chúng ta sẽ bắt đầu loại bỏ những lỗi xấu.
Cách loại bỏ các thông báo lỗi xấu
Chúng tôi đã tìm kiếm trong hệ thống quản lý nội dung và tìm thấy 7643 khóa có từ “lỗi” trong khóa hoặc giá trị. Như vậy, có ít nhất là 7643 phần nội dung cần được kiểm tra lại.
Đây chỉ là một trong những bảng của Monday.com mà chúng tôi đã sử dụng để phân loại từng phần nội dung liên quan đến lỗi. Bảng này giúp chúng tôi thiết lập mức độ ưu tiên, ngày đến hạn và giữ tất cả quy luật trong vòng lặp.
Dev đã gửi từng tin nhắn và map vị trí được kích hoạt trong mã code. Sau đó xem xét nguyên nhân dẫn đến hiển thị thông báo lỗi, tần suất xảy ra và họ có thể làm gì để giải quyết vấn đề.
Dựa trên ánh xạ lỗi đó, các PM, UX designer và writer đã thảo luận và đưa ra giải pháp. Chúng tôi bắt đầu bằng cách chuyển mọi thứ từ bảng tính sang bảng của Monday – để có thể dễ dàng theo dõi trạng thái của mọi thứ và xác định đúng những việc cần phải làm. Đó chỉ là một sự thay đổi nội dung đơn giản. Trong các trường hợp khác, có thể yêu cầu thông báo lỗi hoàn toàn mới. Và trong nhiều trường hợp khác nữa, có thể có nhiều công việc phát sinh cần được thực hiện trong quá trình khắc phục lỗi.
Sau cùng, chúng tôi sẽ ưu tiên những lỗi cần khắc phục trước. Mức độ ưu tiên được xác định dựa vào tần suất xảy ra lỗi và lỗi đó có cản trở người dùng hoàn thành quy trình không? Sau đó, chúng tôi đặt ra các mốc thời gian từ một đến bốn tuần để dễ kiểm soát.
Những gì chúng tôi đã học được
Thông báo chung chung và thông báo không rõ ràng là 2 khái niệm khác nhau. Trong khi có rất nhiều thông báo “Đã xảy ra lỗi” chung chung thì cũng có rất nhiều những thông báo không rõ ràng. Cả 2 thông báo này đều không được khuyến khích sử dụng.
Một ví dụ về một thông báo chung chung so với một thông báo không rõ ràng. Thông báo chung chung không nói cho người dùng biết bất cứ điều gì khác ngoài việc có sự cố xảy ra. Trong thông báo không rõ ràng, cố gắng giải thích điều gì đã xảy ra nhưng lại sử dụng ngôn ngữ gây khó hiểu.
Thông báo chung chung: Đã có lỗi xảy ra. Hành động này không thể hoàn thành
Thông báo không rõ ràng: Hãy chắc chắn rằng bạn được cấp quyền và thử lại.
It’s not a content issue most of the time. Nội dung không phaAvishai Abrahami, Giám đốc điều hành của chúng tôi đã gửi cho tất cả nhân viên 1 email. “Generic errors are the result of bad development and product. … We must all care about it together.” (Những lỗi chung chung là hệ quả của quá trình xây dựng và phát triển sản phẩm chưa tốt. Chúng ta phải quan tâm đến cả tổng thể)
Mọi người trong Wix đã phải tập hợp tất cả các quy tắc để sửa chữa những thông báo này. Dev đã phải điều tra và map. PM sắp xếp thứ tự ưu tiên cho các công việc. Designer thiết kế các flow mới. Và chúng tôi, những UX writer, phải viết đi viết lại hàng nghìn thông báo lỗi.
We should be asking more questions. Chúng ta nên đặt nhiều câu hỏi hơn. 1 Developer thường nói với chúng tôi rằng: “Này, chúng tôi cần một thông báo lỗi chung ở đây. Bạn có thể thêm một cái được không?”. Chúng tôi sẽ trả lời là có và nghĩ rằng đó sẽ là một thông báo dự phòng hoặc hiếm khi cần dùng đến thay vì dừng lại để hỏi những câu hỏi như “Tại sao người dùng lại nhìn thấy thông báo này?” và “Điều gì đang xảy ra?”
We missed a learning opportunity. Thật không may, chúng tôi đã không chủ động. Nếu việc lên kế hoạch được thực hiện có chiến lược, đó sẽ là một cơ hội học tập tuyệt vời cho mọi người. Thay vì làm vậy, chúng tôi lại cố gắng viết lại các thông điệp mà không có nhiều suy nghĩ chiến lược.
We were being a bad friend. Tại Wix, chúng tôi có câu thần chú, “Viết nó giống như bạn đang nói chuyện với một người bạn”. Chúng tôi thực sự tin tưởng vào việc đồng cảm với người dùng và là bạn với họ trong suốt quá trình của họ. Nhưng hóa ra chúng tôi giống như một người bạn thích buôn chuyện, nhưng không nhấc máy khi tôi gặp vấn đề. Chúng tôi không muốn trở thành những người bạn như thế, vì vậy phải thực sự tìm hiểu kỹ và thừa nhận rằng chúng tôi đã không làm tốt nhất có thể.
Khi chúng ta làm việc cùng nhau, chúng ta sẽ tạo ra một sản phẩm tốt hơn. Nghe hơi sến nhưng đó là sự thật.
Chúng tôi đã thay đổi những gì trong quy trình
Thành lập team liên chức năng để tập trung xử lý lỗi. Team này bao gồm Senior PM, FE, BE, UX designer và UI writer. Mục tiêu của nó là đảm bảo việc xử lý lỗi là một phần trong vòng đời sản phẩm, không phải sau đó.
Hãy xem điều đó như một trách nhiệm chung
Mỗi người đều có trách nhiệm đảm bảo rằng họ phải đang xử lý lỗi đúng cách. PM sẽ phải tập trung nhiều hơn vào các lỗi các các trường hợp phát sinh thay vì chỉ nghĩ đến Happy flows. Dev sẽ điều tra và ghi lại các lỗi theo các nguyên tắc nền tảng. Data Scientist sẽ phân tích lỗi tốt hơn để chúng tôi có thể theo dõi các sự kiện một cách chính xác.
Xem lại lỗi sau một tháng ra mắt
Đôi khi, đặc biệt nếu đó là một sản phẩm hoàn toàn mới, chúng tôi thậm chí không dự đoán trước được có thể xảy ra những lỗi gì. Vì vậy, chúng tôi có thể phải ra mắt sản phẩm với các lỗi chung chung, nhưng bây giờ đã có một quy trình mà ở đó chúng tôi có thể xem xét các lỗi đã xảy ra sau một tháng ra mắt. Nó giúp chúng tôi xác định được đâu là lỗi lớn nhất và viết nội dung cụ thể cho những lỗi đó.
Đang trong quá trình xem xét
Là một writer, chúng tôi biết mọi thứ luôn có thể tối ưu hóa. Vì vậy, chúng tôi liên tục xem xét các lỗi, ngay cả những lỗi vừa được cập nhật.
UX writers được giao nhiệm vụ với các lỗi chung chung
Trước đây PM hoặc Dev từng nói rằng “Hãy sử dụng thông báo lỗi chung chung này trong mọi trường hợp”, bây giờ chúng tôi có thể từ chối. CEO của công ty đã nói rằng lỗi chung chung là không chấp nhận được, vì vậy chúng tôi sẽ không viết nếu không có sự điều tra và hiểu biết rõ hơn về vấn đề.
Nhìn chung, chúng tôi đã thay đổi hàng nghìn thông báo lỗi bằng cách làm việc và phối hợp cùng các đồng nghiệp của mình. Đó là một công việc vô cùng khó khăn, nhưng là điều mà chúng tôi nên làm cho người dùng. Và đây cũng là cách duy nhất để chúng tôi làm việc và cống hiến đúng với giá trị mà chúng tôi cam kết: “Đặt người dùng lên trên hết”.
>> Tham khảo bài viết liên quan: UI UX là gì? Sự khác nhau giữa UI UX design
