Thiết kế ma trận phê duyệt trước UI: ánh xạ quy tắc trước khi vẽ màn hình

Tại sao giao diện thất bại nếu không có ma trận rõ ràng

Một màn hình đẹp vẫn có thể che giấu một quy trình lộn xộn. Nếu logic phê duyệt không được xác định trước, người dùng có thể thấy các nút Phê duyệt và Từ chối nhưng vẫn không biết ai phải hành động, khi nào họ hành động, hay điều gì xảy ra tiếp theo.

Sự bối rối đó xuất hiện nhanh trong công việc thực tế. Ai đó gửi yêu cầu, nó tới ứng dụng, và câu hỏi đầu tiên là: "Nó đi đến quản lý, tài chính hay cả hai?" Giao diện có vẻ hoàn chỉnh, nhưng lộ trình quyết định thì thiếu.

Điều này xảy ra vì màn hình khiến các quy tắc trông đơn giản hơn thực tế. Một biểu mẫu có thể hiển thị trạng thái, bình luận và nút hành động, nhưng không thể đoán ma trận phê duyệt thực sự đứng sau quy trình. Nếu doanh nghiệp có giới hạn về số tiền, quy tắc theo phòng ban, hoặc người được ủy quyền tạm thời, UI sẽ bắt đầu lỗi khi các trường hợp đó xuất hiện.

Chỉ cần một ngoại lệ là đủ để công việc chạy ra ngoài ứng dụng. Có khi phê duyệt thường đến trưởng phòng, trừ khi yêu cầu khẩn, vượt quá một mức nào đó, hoặc người phê duyệt nghỉ phép. Nếu trường hợp đó chưa từng được ghi lại, người ta sẽ quay về email, chat hoặc bảng tính.

Rồi vấn đề lớn hơn xuất hiện: mỗi đội bắt đầu áp dụng phiên bản quy tắc riêng. Vận hành gửi một kiểu, tài chính gửi kiểu khác, và hỗ trợ xử lý ngoại lệ khác HR. Ứng dụng trở thành một màn hình chung cho các quyết định không nhất quán thay vì một quy trình chung.

Các dấu hiệu cảnh báo thường dễ thấy:

• người dùng hỏi ai chịu trách nhiệm bước tiếp theo
• những yêu cầu tương tự có kết quả khác nhau giữa các đội
• ngoại lệ được xử lý qua chat hoặc email
• thay đổi chính sách buộc phải sửa giao diện thay vì chỉ sửa quy tắc

Các cập nhật chính sách phơi bày điểm yếu này rất nhanh. Khi logic nằm trong màn hình thay vì trong các quy tắc luồng rõ ràng, mỗi thay đổi ngưỡng hay vai trò lại biến thành sửa giao diện. Điều đó làm chậm đội, tạo lỗi mới và khiến người dùng mất niềm tin.

Màn hình nên phản ánh lộ trình quyết định, chứ không định nghĩa nó. Khi ma trận được làm rõ trước, UI trở nên đơn giản hơn, ổn định hơn và dễ dùng hơn.

Cần ánh xạ những gì trước khi vẽ wireframe

Bắt đầu bằng logic quyết định, không phải màn hình. Một ma trận phê duyệt vững chắc ban đầu là một bảng đơn giản cho thấy ai có quyền phê duyệt gì, trong điều kiện nào, và chuyện gì xảy ra khi ai đó không có mặt. Nếu logic đó mơ hồ, ngay cả giao diện trau chuốt cũng sẽ làm người dùng bối rối.

Với mỗi loại yêu cầu, hãy ánh xạ các cấp phê duyệt theo thứ tự. Ghi rõ vai trò chịu trách nhiệm mỗi bước và bước đó cho phép làm gì: phê duyệt, từ chối, xem xét hay trả lại. Vai trò hữu ích hơn tên cá nhân vì con người thay đổi công việc, đội ngũ thay đổi, và quy trình vẫn cần hoạt động.

Rồi xác định các quy tắc làm thay đổi lộ trình. Số tiền là kích hoạt hiển nhiên, nhưng hiếm khi là yếu tố duy nhất. Quy tắc luồng phê duyệt thường phụ thuộc vùng, phòng ban, loại nhà cung cấp, loại yêu cầu hoặc mức độ rủi ro. Cùng một số tiền có thể là chuyện thường ở một đội nhưng nhạy cảm ở đội khác.

Vắng mặt cũng cần quy tắc. Nếu người phê duyệt chính nghỉ, ai tiếp quản ngay? Nếu người dự phòng chỉ tạm thời, khoảng thời gian nào áp dụng? Nếu không có điều đó, yêu cầu sẽ dừng lại vì không ai biết ai chịu trách nhiệm tuần này.

Giới hạn thời gian cũng quan trọng. Quyết định chuyện gì xảy ra khi yêu cầu không nhận được phản hồi. Bạn có thể gửi nhắc sau một ngày, leo thang sau hai ngày và thông báo cho vận hành sau ba ngày. Những lựa chọn đó ảnh hưởng đến nhãn trạng thái, thông báo và các danh sách chờ, nên cần thống nhất trước khi thiết kế màn hình.

Một ma trận thực tế thường trả lời năm câu hỏi cơ bản:

• Điều kiện nào kích hoạt quy tắc này?
• Vai trò nào phê duyệt ở giai đoạn này?
• Ai là người dự phòng?
• Người phê duyệt có bao lâu để hành động?
• Nếu quá hạn thì chuyện gì xảy ra?

Nếu bạn ánh xạ những câu trả lời đó sớm, phần còn lại của việc xây dựng sẽ dễ dàng hơn nhiều.

Cách xây ma trận từng bước

Dùng bảng, bảng trắng hoặc bảng tính. Giữ thật đơn giản để một quản lý, trưởng nhóm và chủ quy trình đều hiểu trong một lần xem.

Đầu tiên, liệt kê mọi loại yêu cầu cần phê duyệt. Đừng ép mọi thứ vào một luồng chung nếu doanh nghiệp đã xử lý các yêu cầu khác nhau theo cách khác nhau. Yêu cầu mua sắm, hoàn tiền, phê duyệt chiết khấu và yêu cầu truy cập thường cần người phê duyệt, giới hạn và thời hạn khác nhau.

Tiếp đến, ghi người phê duyệt đầu tiên và từng điểm quyết định sau đó. Với mỗi loại yêu cầu, ghi ai xem xét trước và chuyện gì xảy ra sau khi phê duyệt hoặc từ chối. Theo dõi đến khi đạt kết quả cuối cùng như được phê duyệt, bị từ chối, trả lại để chỉnh sửa hoặc bị hủy.

Sau đó, thêm các ngưỡng làm thay đổi lộ trình. Đây là điểm nhiều đội vướng sau này. Nếu yêu cầu dưới $500 đi tới trưởng nhóm nhưng trên $500 đi tới trưởng phòng, hãy viết rõ. Nếu yêu cầu khẩn rút ngắn một bước hoặc đi nhanh hơn, cũng ghi lại.

Rồi ghi các ngoại lệ, thời hạn và trạng thái cuối. Bao gồm các trường hợp như thiếu tài liệu, yêu cầu trùng lặp, vi phạm chính sách và phê duyệt quá hạn. Quy tắc chưa hoàn chỉnh nếu bạn chưa biết cách xử lý khi mọi thứ sai.

Cuối cùng, rà soát bản nháp với những người đang phê duyệt yêu cầu hôm nay. Hỏi họ nơi nào thường tắc, nơi nào người ta bỏ qua bước và chuyện gì xảy ra khi người phê duyệt thông thường vắng mặt. Thói quen thực tế thường tiết lộ các quy tắc chưa từng được tài liệu hóa.

Một ví dụ nhỏ sẽ rõ ràng. Hãy tưởng tượng yêu cầu mua sắm: văn phòng phẩm dưới $200 đi tới trưởng nhóm, phần mềm từ $200 đến $2,000 đi tới trưởng phòng, và trên mức đó cần thêm tài chính. Nếu biểu mẫu không thu thập sớm số tiền và loại, UI không thể gửi yêu cầu theo đúng lộ trình.

Đặt ngưỡng để mọi người thực sự có thể tuân theo

Ngưỡng chỉ có hiệu quả khi mọi người đọc được nhanh và đưa ra cùng một quyết định mỗi lần. Nếu quy tắc nói "mua nhỏ" hay "nhà cung cấp rủi ro cao", mỗi người sẽ hiểu khác nhau. Dùng số cố định, ngày và điều kiện rõ tên thay vì thuật ngữ mơ hồ.

Một quy tắc rõ ràng sẽ như: "Từ $1.000 trở xuống đi tới trưởng nhóm. $1.001 đến $5.000 đi tới trưởng phòng. Trên $5.000 đi tới tài chính và giám đốc." Không ai phải đoán yêu cầu thuộc đâu.

Số tiền phổ biến nhưng không nên là yếu tố duy nhất nếu quy trình của bạn phụ thuộc vào các yếu tố khác. Một mua phần mềm giá thấp từ nhà cung cấp mới có thể cần xem xét kỹ hơn so với đơn hàng lớn từ nhà cung cấp đã được phê duyệt.

Hầu hết đội chỉ cần một tập quy tắc định tuyến nhỏ. Ví dụ phổ biến: dải số tiền, trạng thái nhà cung cấp, loại mua, phòng ban và tính khẩn. Quan trọng không phải số lượng quy tắc mà là mọi người áp dụng chúng cùng một cách.

Thứ tự áp dụng quy tắc cũng quan trọng. Nếu mọi người không biết điều kiện nào thắng, cùng một yêu cầu sẽ được định tuyến khác nhau. Chọn một thứ tự và giữ nhất quán. Bạn có thể kiểm tra trạng thái nhà cung cấp trước, rồi loại, rồi số tiền. Hoặc kiểm tra số tiền trước và xử lý ngoại lệ sau. Cách nào cũng được nếu mọi người tuân theo cùng một trình tự.

Nên xác định ai có thể vượt ngưỡng và khi nào. Nếu không, nhân viên hoặc chờ quá lâu hoặc bỏ qua quy trình qua email và chat. "Giám đốc tài chính có thể phê duyệt yêu cầu vượt hạn mức trong kỳ đóng sổ tháng" rõ ràng. "Lãnh đạo cấp cao có thể ngoại lệ" thì quá mơ hồ.

Một bài kiểm tra đơn giản hiệu quả: đưa cùng một ví dụ cho ba người và hỏi nó nên đi đâu. Nếu họ trả lời khác nhau, ngưỡng vẫn còn quá mơ hồ.

Lên kế hoạch người dự phòng, người thay thế và leo thang

Ma trận mạnh không dừng ở người phê duyệt chính. Công việc thực tế vẫn tiến khi ai đó nghỉ phép, ốm hoặc không phản hồi đúng hạn. Nếu bạn không lên kế hoạch sớm, màn hình có thể trông gọn nhưng quy trình im lìm.

Bắt đầu bằng việc đặt tên người phê duyệt dự phòng cho mỗi bước quan trọng. Đây nên là người hoặc vai trò có bối cảnh phù hợp, chứ không chỉ là "quản lý tiếp theo" mặc định. Nếu một trưởng nhóm tài chính phê duyệt chi phí trên mức nào đó, hãy quyết định ai tiếp quản khi người đó vắng mặt.

Người thay thế tạm thời cần giới hạn rõ. Người thay thế nên có quyền phê duyệt chỉ trong khoảng thời gian xác định, như ngày nghỉ hoặc kỳ nghỉ có kế hoạch. Điều đó giữ trách nhiệm rõ ràng và tránh việc ai đó giữ quyền quá lâu.

Một thiết lập đơn giản nên trả lời bốn điều: ai là người phê duyệt chính, ai là dự phòng, người thay thế có thể hành động trong bao lâu, và khi nào yêu cầu được đẩy lên cấp trên.

Các bước leo thang nên dựa trên kích hoạt rõ ràng, không phỏng đoán. Kích hoạt thường là thời gian, số tiền, rủi ro hoặc thiếu thông tin. Ví dụ, nếu một yêu cầu mua trên $10.000 nằm im 24 giờ, nó có thể leo thang lên trưởng phòng.

Giữ đường leo thang ngắn. Nếu người ta cần một sơ đồ phức tạp chỉ để hiểu ai nhận yêu cầu tiếp theo, quy tắc đó có lẽ quá phức tạp. Một hoặc hai bước nhảy rõ ràng thường là đủ.

Ghi lại mỗi quyết định nữa. Lưu lại ai phê duyệt, ai thay thế, khi nào chuyển giao và lý do yêu cầu bị leo thang. Lịch sử đó quan trọng khi ai đó hỏi sau này vì sao yêu cầu bị chậm hoặc được phê duyệt bởi người dự phòng.

Một quy tắc nữa quan trọng hơn vẻ bề ngoài: tránh vòng lặp. Yêu cầu không bao giờ nên bật về người đã phê duyệt trước đó, hoặc về một người thay thế đang hành động thay cho cùng người đó. Kiểm tra ma trận để phát hiện đường vòng trước khi xây bất kỳ logic ứng dụng nào.

Một ví dụ đơn giản: phê duyệt yêu cầu mua sắm

Hình dung một công ty nhỏ mua vật dụng hàng ngày. Nhân viên gửi một yêu cầu mua với mục, số tiền, lý do và ngày cần. Định tuyến được điều khiển bởi quy tắc, không phải bởi ai đang online.

Nếu yêu cầu $420, nó đi thẳng tới trưởng nhóm. Điều này giúp mua nhỏ nhanh. Yêu cầu $3.200 bỏ qua trưởng nhóm và đi tới trưởng phòng vì ảnh hưởng ngân sách lớn hơn.

Bây giờ lấy ví dụ $7.800 cho thiết bị mới. Trưởng phòng vẫn xem xét, nhưng vậy chưa đủ. Vì số tiền trên $5.000, tài chính cũng phải xem xét. Đó là lúc ma trận rõ ràng có ích: số tiền lớn hơn thêm kiểm soát mà không thêm đoán mò.

Vắng mặt cũng quan trọng. Nếu trưởng phòng nghỉ, yêu cầu không nên nằm im. Một người thay thế được đặt tên sẽ nhận tự động và có thể hành động trong khoảng thời gian đã định.

Thời hạn cũng cần rõ. Nếu không ai hành động trong hai ngày, yêu cầu leo thang tới vận hành. Vận hành có thể theo dõi, phân bổ lại hoặc đảm bảo nó không chặn công việc.

Trong ví dụ này, ma trận trả lời vài câu hỏi quan trọng: số tiền yêu cầu, vai trò phê duyệt theo từng mức, khi nào thêm tài chính, ai bù khi vắng mặt và chuyện gì xảy ra khi quá hạn.

Khi những câu trả lời đó được định nghĩa, thiết kế màn hình trở nên đơn giản. Biểu mẫu chỉ cần dữ liệu đúng, và trang yêu cầu chỉ cần hiển thị người phê duyệt hiện tại, bất kỳ người thay thế nào và đồng hồ leo thang có đang chạy hay không.

Sai lầm phổ biến gây ra làm lại

Hầu hết việc sửa đi sửa lại bắt đầu trước khi vẽ một màn hình nào. Các đội đoán đường phê duyệt, rồi cố nhồi UI vào các quy tắc chưa thực sự thống nhất.

Một sai lầm thường thấy là sao chép sơ đồ tổ chức và gọi đó là workflow. Điều đó có thể trông gọn, nhưng yêu cầu thực tế thường di chuyển theo số tiền, rủi ro, địa điểm hoặc loại yêu cầu. Nếu ma trận bỏ qua điều đó, màn hình sau này sẽ cần thêm trường, trạng thái và các ngoại lệ lạ.

Vấn đề khác là quên các trường hợp đặc biệt. Yêu cầu khẩn, mua chịu quy định, hoặc yêu cầu liên phòng ban thường cần lộ trình khác. Nếu ngoại lệ không được ánh xạ sớm, người ta sẽ yêu cầu giải pháp thủ công, và giao diện sẽ đầy các tuỳ chọn một lần khiến mọi người rối.

Các đội cũng tự gây rắc rối khi cho hai người cùng một quyền mà không có quy tắc phân thắng thua. Nếu cả hai đều có thể phê duyệt, ai làm trước? Nếu họ khác nhau, quyết định của ai có hiệu lực? Không có câu trả lời, yêu cầu sẽ bị chuyền vòng và người dùng mất niềm tin.

Quy tắc người thay thế là điểm yếu khác. Người thay thế nên che cho sự vắng mặt, không biến thành chủ sở hữu thứ hai mãi mãi. Khi bao phủ tạm thời và sở hữu lâu dài bị trộn lẫn, báo cáo rối và trách nhiệm biến mất.

Thiết kế biểu mẫu trước khi định tuyến xong sẽ tạo vòng sửa nữa. Biểu mẫu có vẻ hoàn chỉnh, nhưng khi quy tắc phê duyệt được cố định, bạn thường phát hiện thiếu trường như dải số tiền, phòng ban, tính khẩn hoặc cờ chính sách. Rồi bố cục, kiểm tra hợp lệ và thông báo đều phải thay đổi.

Một kiểm tra thực tế nhanh có thể phát hiện sớm:

• Có hai người cùng nhận cùng một yêu cầu cùng lúc không?
• Có sự khác biệt rõ ràng giữa dự phòng tạm thời và quyền sở hữu lâu dài không?
• Các trường hợp khẩn hoặc được quy định có lộ trình riêng không?
• Mỗi quyết định định tuyến có dựa trên trường đã tồn tại không?
• Quy trình có vẫn hợp lý nếu một người phê duyệt rời công ty không?

Nếu bất kỳ câu trả lời nào mơ hồ, dừng lại. Sửa ma trận trước khi mài giũa giao diện.

Kiểm tra nhanh trước khi thiết kế màn hình

Trước khi phác thảo biểu mẫu hay nhãn trạng thái, thử logic bằng ngôn ngữ đơn giản. Một ma trận tốt nên dễ giải thích mà không cần mở sơ đồ. Nếu một quản lý, trưởng tài chính hoặc đồng nghiệp vận hành không thể mô tả lộ trình trong khoảng một phút, quy trình vẫn còn quá mơ hồ để làm UI.

Chạy rà soát nhanh bằng ví dụ thực. Hỏi một người mô tả toàn bộ lộ trình từ gửi đến quyết định cuối cùng. Kiểm tra mọi kết quả có người phê duyệt tiếp theo được đặt tên, không chỉ kịch bản thành công. Viết lại các ngưỡng mơ hồ thành quy tắc chính xác như "$1,000 trở xuống" hoặc "hơn 10% chiết khấu." Xác nhận rằng quy tắc dự phòng và leo thang dùng giới hạn thời gian rõ như "sau 24 giờ" hoặc "sau 2 ngày làm việc."

Rồi thử khả năng truy xuất. Sau này, ai đó sẽ hỏi vì sao yêu cầu chậm, ai đã phê duyệt ngoại lệ hay khi nào người thay thế can thiệp. Quy trình của bạn nên trả lời những câu đó. Dấu thời gian, lịch sử quyết định và thay đổi trạng thái rõ ràng không phải là phần thêm. Chúng là một phần của tập quy tắc.

Một tình huống đơn giản thường lộ điểm yếu. Hãy tưởng tượng một yêu cầu $4,800 đến vào chiều thứ Sáu khi người phê duyệt thường xuyên vắng mặt. Ai nhận nó tiếp? Hệ thống chờ bao lâu trước khi di chuyển? Nếu người dự phòng cũng không làm gì thì sao? Nếu những câu trả lời đó chưa được ghi, UI sẽ che giấu sự bối rối thay vì giải quyết nó.

Khi các kiểm tra này vượt qua, thiết kế màn hình sẽ dễ hơn nhiều. Bạn không còn đoán giao diện nên hiển thị gì nữa. Bạn đang hình dung một bộ quy tắc rõ ràng.

Bước tiếp theo: biến ma trận thành ứng dụng hoạt động

Khi quy tắc rõ ràng, xây quy trình trước khi mài giũa giao diện. Bắt đầu với logic, các trường dữ liệu và trạng thái phê duyệt. Nếu định tuyến hoạt động, giao diện sẽ dễ thiết kế hơn nhiều. Nếu định tuyến vẫn thay đổi, giao diện đẹp chỉ che giấu vấn đề.

Phiên bản đầu thực tế thường bao gồm cơ bản: loại yêu cầu, số tiền, phòng ban, người phê duyệt hiện tại và lịch sử quyết định rõ ràng. Rồi thêm quy tắc di chuyển yêu cầu, gửi tới người dự phòng hoặc kích hoạt leo thang khi ai đó không phản hồi đúng hạn.

Giữ màn hình đầu đơn giản. Người gửi nên có thể nộp, kiểm tra trạng thái và trả lời câu hỏi theo dõi. Người phê duyệt nên xem xét, phê duyệt, từ chối hoặc phân công lại. Đó đủ để kiểm tra xem workflow có phù hợp trong thực tế hàng ngày hay không.

Thứ tự xây dựng hợp lý:

• xác định các trường dữ liệu cốt lõi và giá trị trạng thái
• thêm quy tắc định tuyến cho ngưỡng, người dự phòng, người thay thế và leo thang
• tạo các màn hình cơ bản cho người gửi và người phê duyệt
• đảm bảo mọi kênh dùng cùng một nguồn chân lý
• thử một yêu cầu thực từ đầu đến cuối trước khi triển khai rộng

Nguồn chân lý chung quan trọng hơn nhiều đội nghĩ. Nếu mobile hiển thị một trạng thái, bảng web hiển thị trạng thái khác, và backend theo ngưỡng khác, niềm tin nhanh chóng mất đi.

Nếu bạn xây điều này trong AppMaster, một ma trận rõ ràng giúp việc thiết lập dễ dàng hơn rất nhiều. Bạn có thể mô hình hóa dữ liệu, logic kinh doanh và luồng phê duyệt trước, rồi mang cùng quy trình đó qua backend, web và mobile mà không phải viết lại quy tắc trên nhiều công cụ.

Dùng một trường hợp thực cho bài thử đầu tiên. Chạy một yêu cầu mua với ngưỡng, người phê duyệt thay thế và leo thang quá hạn. Quan sát chỗ mọi người lưỡng lự, dữ liệu họ thiếu và nhãn trạng thái nào làm họ bối rối.

Sửa ngôn từ và bố cục sau đó. Khi quy trình hoạt động với một yêu cầu thực, thiết kế màn hình dễ hơn và ít có khả năng phải làm lại trong tuần tiếp theo.