Thiết kế đường ngoại lệ: lên kế hoạch từ chối trước khi phê duyệt

Tại sao luồng thuận không đủ

Hầu hết các nhóm bắt đầu với phiên bản gọn gàng của một quy trình. Một yêu cầu được gửi, ai đó xem xét, và nó được phê duyệt. Điều đó có vẻ hiệu quả, nhưng che giấu nơi công việc thực sự diễn ra.

Luồng thuận thường là con đường ngắn nhất. Biểu mẫu đầy đủ, tệp đính kèm có sẵn và người duyệt biết chính xác phải làm gì. Trong thực tế vận hành, đó hiếm khi là phần gây chậm trễ.

Sự chậm trễ bắt đầu khi có thứ gì đó thiếu, không rõ, trễ hạn hoặc chỉ chấp nhận một phần. Một quản lý có thể phê duyệt ngân sách nhưng từ chối một hạng mục. Bộ phận tài chính có thể cần một chứng từ thuế chưa được tải lên. Trưởng bộ phận hỗ trợ có thể trả yêu cầu lại vì trường lý do quá mơ hồ. Mỗi khoảnh khắc đó tạo ra bước bổ sung, tin nhắn bổ sung và thời gian chờ thêm.

Nếu những tình huống này không được lên kế hoạch sớm, mọi người đưa ra quyết định tùy tiện. Một người xét duyệt gửi email. Người khác để lại bình luận trong công cụ. Người thứ ba từ chối yêu cầu mà không giải thích. Người gửi yêu cầu bị để đoán: họ nên sửa, nộp lại hay hỏi ai giúp?

Sự bối rối đó có chi phí. Nó làm chậm người gửi yêu cầu, người xét duyệt và bất kỳ ai bị gọi vào để giải thích. Một quy trình nhìn trên bảng trắng có vẻ đơn giản biến thành các cuộc trò chuyện phụ, nộp trùng lặp và chuyển tay thủ công.

Một luồng phê duyệt cơ bản dễ phác thảo:

• submit request
• review request
• approve request

Phiên bản thực tế khó hơn. Nếu một tài liệu bị thiếu thì sao? Nếu chỉ một phần yêu cầu được phê duyệt thì sao? Nếu người xét duyệt từ chối nhưng người dùng có thể sửa được? Đây không phải là các trường hợp bất thường. Với nhiều nhóm, đó là những trường hợp bình thường.

Đó là lý do thiết kế đường ngoại lệ xứng đáng được chú ý trước khi vẽ màn hình và đặt tên trạng thái. Đường ngoại lệ định nghĩa điều gì xảy ra khi thực tế làm gián đoạn kế hoạch, và thực tế thường làm vậy.

Nếu bạn đang xây dựng ứng dụng phê duyệt nội bộ, kể cả trên nền tảng no-code như AppMaster, các trường hợp bị từ chối và không hoàn chỉnh cần được chăm chút nhiều như trường hợp được chấp thuận. Chúng định hình thông báo người dùng thấy, hành động họ có thể thực hiện tiếp theo và liệu quy trình giúp họ khôi phục hay để họ bị kẹt.

Luồng thuận cho thấy ý định. Đường ngoại lệ cho thấy quy trình có thể chịu được sử dụng thực tế hay không.

Đường ngoại lệ trông như thế nào

Đường ngoại lệ là điều xảy ra khi một yêu cầu không thể tiến theo cách bình thường. Nó không phải là một trường hợp hiếm. Đó là phần xử lý tình trạng rắc rối đời thường: yêu cầu bị từ chối, biểu mẫu không đầy đủ, một phần được phê duyệt nhưng phần khác thì không, hoặc công việc đơn giản là bị tắc.

Một đường ngoại lệ rõ ràng dùng ngôn ngữ đơn giản. Thay vì trạng thái mơ hồ như "Failed", hãy nói rõ chuyện gì đã xảy ra: "Bị từ chối vì ngân sách vượt giới hạn" hoặc "Đang chờ tài liệu ID". Mọi người nên biết lỗi là gì, ai cần hành động và chuyện gì sẽ xảy ra tiếp theo.

Hầu hết quy trình vỡ ở vài cách dự đoán được:

• yêu cầu bị từ chối với lý do rõ ràng
• một tài liệu hoặc trường bắt buộc bị thiếu
• chỉ một phần yêu cầu được phê duyệt
• yêu cầu không có chủ sở hữu hoặc không có bước tiếp theo được định nghĩa

Thiếu thông tin là một trong những vấn đề phổ biến nhất. Hãy tưởng tượng một biểu mẫu onboard nhà cung cấp cần chứng từ thuế và số tài khoản ngân hàng. Nếu thiếu một trong hai, hệ thống không nên chỉ dừng lại. Nó nên đánh dấu yêu cầu là không hoàn chỉnh, hiển thị chính xác phần thiếu và trả về cho người phù hợp.

Phê duyệt một phần cũng quan trọng. Nghĩ về một yêu cầu công tác gồm vé máy bay, khách sạn và ngân sách ăn uống. Quản lý phê duyệt vé và khách sạn nhưng cắt giảm ngân sách ăn uống. Quy trình cần có quy tắc. Nhân viên chấp nhận thay đổi, cập nhật yêu cầu hay hủy chuyến?

Tắc nghẽn cũng quan trọng. Một yêu cầu có thể nằm im vì người xét duyệt được phân công đã nghỉ việc, nhóm không đặt người dự phòng, hoặc quy trình đến bước không có người chủ tiếp theo. Về mặt kỹ thuật không có gì hỏng, nhưng yêu cầu vẫn không thể tiến.

Nếu bạn không thiết kế các đường này sớm, mọi người sẽ xử lý bằng email, chat hoặc ghi chú bảng tính. Chẳng lâu ai cũng không biết phiên bản nào là cuối cùng.

Ví dụ phê duyệt đơn giản

Lấy ví dụ một yêu cầu công tác cho người quản lý bán hàng muốn tham dự hội nghị hai ngày. Trên giấy, luồng trông dễ: nhân viên nhập ngày đi, ước tính chi phí và lý do. Quản lý phê duyệt, tài chính xác nhận ngân sách và chuyến đi được đặt.

Luồng đó sạch sẽ nhưng cũng không hoàn chỉnh.

Bây giờ phá vỡ cùng yêu cầu đó. Nhân viên tải lên ước tính vé và vé hội nghị nhưng quên báo giá khách sạn. Nếu hệ thống chỉ biết "submitted" và "approved", mọi người nhanh chóng bị kẹt. Tài chính có thể thấy yêu cầu không hoàn chỉnh, quản lý nghĩ là đã sẵn sàng, và nhân viên không biết thiếu gì.

Một luồng tốt hơn cho trạng thái riêng cho yêu cầu, ví dụ "Waiting for document" hoặc "Needs update." Nhân viên nên thấy thông báo rõ: "Thêm báo giá khách sạn trước khi yêu cầu này chuyển sang bộ phận tài chính." Quản lý không phải từ chối toàn bộ chuyến chỉ để yêu cầu một tệp.

Giờ thêm một vấn đề nữa. Quản lý đồng ý cho chuyến đi nhưng không đồng ý toàn bộ chi phí. Họ phê duyệt vé và một đêm khách sạn, nhưng từ chối phí hội thảo và đêm thứ hai.

Đây là lúc nhiều nhóm nhận ra họ không thực sự có quy trình phê duyệt một phần.

Nếu quy trình không thể phê duyệt chỉ một phần của yêu cầu, mọi người bắt đầu dùng giải pháp tạm. Họ có thể từ chối toàn bộ và yêu cầu nhân viên nộp lại. Hoặc tài chính có thể vô tình phê duyệt toàn bộ vì hệ thống chỉ lưu một quyết định đồng ý hoặc từ chối.

Mô hình rõ ràng theo dõi từng mục chi phí, hoặc ít nhất là tổng được phê duyệt. Yêu cầu có thể hiển thị:

• Flight: approved
• Hotel: approved for 1 night
• Workshop add-on: not approved
• Total requested: $1,450
• Total approved: $980

Ví dụ đơn này cho thấy vì sao lỗi trong quy trình phê duyệt thường đến từ thiếu quy tắc, không phải do con người cẩu thả. Nếu bạn định nghĩa các quy tắc đó trước khi thiết kế màn hình, phần còn lại của luồng trở nên dễ tin cậy hơn.

Thiết kế ngoại lệ trước khi vẽ giao diện

Cách tốt để cải thiện quy trình là giả định rằng yêu cầu sẽ không đi qua gọn gàng. Sự thay đổi tư duy đó nâng chất lượng thiết kế rất nhanh.

Bắt đầu với các trường hợp lộn xộn: biểu mẫu không đầy đủ, chính sách không rõ, người duyệt vắng mặt hoặc chỉ một phần yêu cầu nên chuyển tiếp. Hầu hết nhóm có thể gom những trường hợp này thành ba mẫu chính:

• rejection (từ chối)
• missing information (thiếu thông tin)
• partial approval (phê duyệt một phần)

Điều đó giữ công việc trong tầm kiểm soát. Thay vì nghĩ đáp án mới cho mọi trường hợp rìa, bạn định nghĩa một tập mẫu nhỏ và áp dụng cho từng loại yêu cầu.

Làm việc theo thứ tự này.

Đầu tiên, liệt kê mọi điểm nơi yêu cầu có thể dừng. Nghĩ về tài liệu thiếu, giá trị không hợp lệ, vi phạm chính sách, hạn chót hết, nộp trùng lặp và xem xét thủ công. Nếu yêu cầu có thể chờ, thất bại hoặc trả lại người gửi, hãy viết ra.

Tiếp theo, quyết định điều gì xảy ra trong mỗi trường hợp. Với mọi ngoại lệ, trả lời bốn câu hỏi đơn giản:

• ai được thông báo
• trạng thái của yêu cầu hiển thị là gì
• người dùng phải làm gì tiếp theo
• khi nào yêu cầu sẽ chuyển tiếp lại

Ví dụ, tưởng tượng một nhân viên gửi yêu cầu hoàn trả công tác $600. Hóa đơn khách sạn bị thiếu và một bữa ăn vượt chính sách. Nếu bạn chỉ thiết kế luồng thuận, yêu cầu hoặc bị kẹt hoặc bị từ chối hết. Nếu bạn thiết kế ngoại lệ trước, hệ thống có thể tạm dừng yêu cầu chờ hóa đơn, thông báo cho nhân viên bằng tin nhắn rõ ràng và vẫn đánh dấu các mục được cho phép là tạm thời được chấp thuận.

Đó là lúc quy tắc phê duyệt một phần quan trọng. Bạn cần quyết định liệu số tiền được phê duyệt có thể tiến ngay bây giờ không, phần còn lại có bị giữ lại hay không, và người yêu cầu có thể chỉ chỉnh sửa phần bị tranh chấp hay phải nộp lại toàn bộ yêu cầu.

Nếu bạn xây dựng quy trình trong AppMaster, đây là thời điểm vẽ các nhánh đó vào logic nghiệp vụ trước khi hoàn thiện giao diện. Dễ tin tưởng một quy trình hơn khi reject, return-for-edits và approve-with-conditions được đối xử như những đường đi riêng thay vì ẩn sau một trạng thái mơ hồ duy nhất.

Cuối cùng, kiểm thử một kịch bản thực tế từ đầu đến cuối. Dùng số liệu thật, một khoảng trống tài liệu thật và một ngoại lệ chính sách. Nếu người đọc không thể nói chuyện gì xảy ra tiếp theo trong chưa tới một phút, thiết kế vẫn còn quá mơ hồ.

Đặt quy tắc trước giao diện

Màn hình cho cảm giác cụ thể, nên các nhóm thường bắt đầu từ đó. Họ phác thảo nút, biểu mẫu và bảng kiểm tra trước khi đồng ý về quy tắc. Điều đó thường tạo ra vấn đề sau này, vì giao diện che khuất các quyết định mà thực ra chưa ai đưa ra.

Thứ tự tốt hơn là đơn giản: định nghĩa các trạng thái, chuyển giao, thời hạn và bằng chứng cần thiết để tiến tiếp. Rồi xây màn hình xung quanh đó.

Thiết kế đường ngoại lệ dễ hơn khi tập quy tắc nhỏ và rõ ràng. Nếu một yêu cầu có thể được phê duyệt, từ chối, trả lại để sửa hoặc phê duyệt một phần, những trạng thái đó cần tên rõ ràng chỉ một ý nghĩa. Tránh các nhãn gần giống như "returned", "reopened" và "needs changes" trừ khi chúng thực sự hành xử khác nhau.

Lấy ví dụ một yêu cầu mua sắm. Một quản lý mở và thấy báo giá thiếu. Nếu nhóm chưa quyết chuyện gì xảy ra tiếp theo, mọi người tùy ứng biến. Người thì từ chối. Người khác để pending. Người thứ ba gửi chat và không thay đổi gì trong hệ thống. Chẳng lâu ai cũng không tin trạng thái.

Viết quy tắc trước. Khi báo giá thiếu, yêu cầu chuyển sang "Needs documents." Người gửi chịu trách nhiệm bước tiếp theo. Yêu cầu ở đó năm ngày làm việc. Nếu không có gì đến, nó chuyển thành "Expired" và cần gửi lại.

Quy tắc đó định hình sản phẩm tốt hơn mockup. Giờ bạn biết người dùng nên thấy gì, nhắc nhở nào cần gửi và lịch sử gì phải lưu.

Một tập quy tắc thực tế nên trả lời bốn câu hỏi:

• Những tên trạng thái ít ỏi nào mọi người sẽ dùng hàng ngày?
• Ai hành động tiếp theo ở mỗi trạng thái?
• Món đó có thể ở đó bao lâu trước khi leo thang, hết hạn hoặc đóng?
• Trường, tệp hoặc kiểm tra nào cần có trước khi nó chuyển?

Phê duyệt một phần cần cùng mức chăm chút. Nếu công tác được duyệt nhưng chi phí khách sạn không, người yêu cầu chỉnh sửa cùng một bản ghi hay tạo bản mới? Tài chính chỉ xem xét phần thay đổi hay mọi thứ lại? Nếu không quyết sớm, giao diện có thể trông gọn trong khi quy trình phía sau vẫn lộn xộn.

Khi nhóm thống nhất quy tắc trước, giao diện trở nên đơn giản hơn. Quan trọng hơn, người dùng biết họ phải làm gì tiếp theo, ngay cả khi câu trả lời là "chưa được phê duyệt".

Viết thông điệp để người ta có thể hành động

Một thông điệp ngoại lệ tệ làm chậm mọi thứ. Mọi người không chỉ cần biết điều gì thất bại. Họ cần biết chuyện gì đã xảy ra, ảnh hưởng ra sao và phải làm gì tiếp theo.

Đây là lúc thiết kế trở nên thực tế với người dùng. Quy tắc nội bộ có thể rõ, nhưng nếu màn hình chỉ nói "Error" hoặc "Pending review", người ta sẽ đoán mò, gửi sai tệp hoặc hỏi hỗ trợ.

Lấy ví dụ duyệt nhà cung cấp. Người dùng gửi form có chứng từ thuế, thông tin ngân hàng và bằng chứng bảo hiểm. Thông tin ngân hàng ổn, chứng từ thuế hết hạn và bằng chứng bảo hiểm thiếu. Nếu hệ thống chỉ hiển thị "Request not approved", người dùng không có bước tiếp theo rõ ràng.

Một thông báo tốt hơn sẽ nói: "Thông tin ngân hàng của bạn đã được chấp nhận. Chúng tôi vẫn cần chứng từ thuế cập nhật và bằng chứng bảo hiểm trước khi phê duyệt cuối cùng." Câu đó tiết kiệm thời gian vì tách phần đã xong ra phần cần làm.

Thông báo tốt thường trả lời bốn câu hỏi nhỏ:

• Phần nào bị từ chối, thiếu hoặc đang xem xét?
• Phần nào đã được chấp nhận?
• Người đó cần tải lên, thay đổi hay xác nhận gì?
• Chuyện gì xảy ra sau khi họ nộp lại?

Câu cuối cùng quan trọng. Người ta có khả năng hoàn thành nhiệm vụ hơn khi bước tiếp theo rõ ràng. "Tải lên tệp thiếu và nộp lại để xem xét" tốt hơn nhiều so với "Action required."

Những nhãn mơ hồ cũng tạo lo lắng. "Pending review" có thể nghĩa là chờ người, thiếu dữ liệu hoặc kiểm tra nội bộ. Nếu biết lý do, hãy nói thẳng. "Waiting for manager approval" và "Waiting for proof of address" không cùng tình huống và không nên trông giống nhau.

Nếu quy trình cho phép phê duyệt một phần, hãy hiển thị rõ trong trạng thái. Một bảng tóm tắt ngắn thường hiệu quả hơn một nhãn duy nhất:

• Approved: identity document
• Needs update: tax form
• Missing: insurance certificate

Giờ người dùng chỉ sửa những gì cần. Họ không phải bắt đầu lại.

Đây cũng là nơi tính năng nộp lại nên dễ tìm. Đặt hành động tiếp theo gần thông báo, không trên màn hình khác. Nếu bạn xây luồng trong AppMaster, nên đối chiếu văn bản trạng thái người dùng thấy với trạng thái nghiệp vụ thực tế để ứng dụng nói đúng những gì quy trình đang làm.

Thông báo tốt giảm ticket hỗ trợ, tăng tốc phê duyệt và khiến quy trình có cảm giác công bằng. Người ta có thể chấp nhận từ chối khi họ hiểu lý do.

Sai lầm tạo ra công việc lại

Hầu hết công việc lặp lại bắt nguồn từ một giả định sai: con đường bình thường là điều chính cần thiết kế. Các nhóm vẽ sơ đồ submit, approved, completed rồi dừng. Rồi thực tế tới: tệp thiếu, quản lý muốn thay đổi, hoặc chỉ một phần tiến được.

Khoảng trống đó nhanh tạo nên công việc thêm. Mọi người nghĩ ra sửa tay, gửi tin nhắn phụ và đổi tên trạng thái linh tinh. Vài tuần sau, chẳng ai tin quy trình vì mỗi ngoại lệ đều như trường hợp đặc biệt.

Một lỗi phổ biến là coi đường lý tưởng là sản phẩm và mọi thứ khác là dọn dẹp. Hãy tưởng tượng một yêu cầu chi tiêu cần hóa đơn, phê duyệt phòng ban và xét duyệt tài chính. Nếu hóa đơn thiếu, yêu cầu tạm dừng, trả về nhân viên hay bị từ chối? Nếu không rõ từ đầu, nhóm thường vá sau bằng email và bình luận.

Tên trạng thái lẫn lộn gây thêm công việc. Các nhãn như "In review 2" hay "Pending action" nghe vô hại, nhưng khiến người ta đoán bước tiếp. Tên rõ ràng giảm lỗi vì cho thấy vấn đề, chủ sở hữu, kết quả hoặc bước tiếp theo.

Quyền sở hữu là nơi khác quy trình vỡ. Yêu cầu không bao giờ nên nằm ở trạng thái không thuộc về ai. Nếu một vụ đang chờ, phải có người chịu trách nhiệm thúc tiến, yêu cầu thêm thông tin hoặc đóng. Nếu không, những trì hoãn im lặng tích tụ và người dùng nghĩ hệ thống mất yêu cầu của họ.

Phê duyệt một phần thường bị xử lý tệ. Nhóm biến nó thành từ chối toàn phần vì đơn giản hơn. Nhưng hai kết quả đó khác nhau. Nếu một yêu cầu công tác gồm vé, khách sạn và ăn uống, tài chính có thể phê duyệt vé và khách sạn nhưng từ chối ăn uống. Trường hợp đó cần đường đi riêng, tin nhắn riêng và thường hành động theo dõi riêng.

Khi phê duyệt một phần bị gộp với từ chối, người ta nộp lại toàn bộ, tải tài liệu trùng lặp và bắt đầu lại các xét duyệt đã xong. Đó là công việc lại thuần túy.

Một bài kiểm tra đơn giản giúp: đọc từng trạng thái không phải luồng thuận và hỏi, "Ai sở hữu, người dùng thấy gì và chuyện gì xảy ra tiếp theo?" Nếu câu trả lời mơ hồ, quy trình có lẽ sẽ vỡ ở cùng chỗ đó sau này.

Kiểm tra nhanh trước khi xây dựng

Trước khi xây giao diện hoặc tự động hóa, duyệt một lần nữa các trường hợp lộn xộn. Thiết kế đường ngoại lệ tốt thường chỉ là vài quyết định rõ ràng được đưa sớm, trước khi sự bối rối biến thành công việc lại.

Nếu yêu cầu bị từ chối, tạm dừng hoặc chỉ phê duyệt một phần, ai đó luôn phải biết chuyện gì xảy ra tiếp theo, ai làm việc đó và thông tin nào còn thiếu.

Dùng kiểm tra nhanh này cho mỗi ngoại lệ trong quy trình của bạn:

• Mỗi ngoại lệ có chủ sở hữu.
• Mỗi trạng thái dẫn đến một bước tiếp theo rõ ràng.
• Các mục thiếu được đặt tên bằng ngôn ngữ đơn giản.
• Phê duyệt một phần có quy tắc, không đoán mò.
• Thời gian được xác định rõ.

Rồi làm một bài kiểm tra đơn giản. Giao quy trình cho người không tham gia thiết kế. Đưa họ một yêu cầu bị từ chối và một yêu cầu thiếu một tài liệu. Nếu họ không thể nói phải làm gì trong chưa tới một phút, quy trình vẫn còn mơ hồ.

Một ví dụ nhỏ nêu rõ. Giả sử quản lý phê duyệt yêu cầu phần mềm nhưng từ chối phần phần cứng. Nếu trạng thái chỉ nói "Partially approved", nhân viên có thể tưởng mọi thứ vẫn tiến được. Trạng thái tốt hơn nói chính xác phần được phê duyệt, phần bị từ chối và liệu nhân viên có thể nộp lại phần thiếu hay không.

Nếu bạn muốn biến những quy tắc đó thành ứng dụng nội bộ hoạt động, hãy lập bản đồ trạng thái ngoại lệ trước và xây luồng thuận sau. Trong AppMaster, điều đó có thể nghĩa là định nghĩa trạng thái, quy tắc nghiệp vụ và trường bắt buộc trước khi bận tâm đến màn hình trau chuốt. Đây là cách thực dụng để xây ứng dụng no-code xử lý công việc thực tế, không chỉ phiên bản lý tưởng của nó.

Bước tiếp theo đơn giản: liệt kê năm ngoại lệ hàng đầu của bạn, gán chủ sở hữu cho mỗi ngoại lệ và viết thông báo người dùng nên thấy. Nếu ba phần đó rõ, việc xây thường trở nên dễ hơn nhiều.