Mỗi phòng ban một công cụ riêng, nên công việc kẹt ở mỗi lần bàn giao.

Các tổ chức chúng tôi làm việc cùng không bắt đầu từ con số không. Hầu hết phòng ban đã có một công cụ phục vụ đúng nhu cầu của mình.

Một yêu cầu nội bộ đơn giản có thể đi qua nhiều người: nhân viên gửi, quản lý duyệt, một nhóm khác xử lý, rồi nhân viên chờ trạng thái. Thông tin nằm ở nhiều nơi. Trạng thái phải hỏi thủ công. Trách nhiệm ngày càng khó truy vết.

Quản lý phải dựa vào Dự án, Bán hàng, Kế toán, Nhân sự và Vận hành để biết cần can thiệp ở đâu. Nhân viên phải nhớ từng việc, yêu cầu hay quy trình nằm ở đâu.

Đây là một nguyên nhân gốc có thể hành động. Nó đổi công việc từ "thiết kế lại màn hình gây rối" thành ba hành động ở cấp hệ thống.

Chúng tôi lập bản đồ sản phẩm từ việc cần làm xuống đến giao diện: Việc cần làm, rồi Quy trình, Đối tượng nghiệp vụ, Quy tắc, Năng lực, và cuối cùng là Module.

Các việc này dùng chung một tập đối tượng: Công việc, Yêu cầu, Nhân viên, Khách hàng, Dự án, Đơn hàng, KPI, Phê duyệt, Trạng thái và Đơn vị tổ chức. Chẳng hạn, một Yêu cầu có thể nối một nhân viên, một quản lý, một phòng ban, một quy tắc phê duyệt và một trạng thái.

Một persona cố định Quản lý hoặc Nhân viên là điểm khởi đầu hữu ích nhưng quá đơn giản với một doanh nghiệp vừa và nhỏ. Một người có thể làm việc ở hai chế độ, tài khoản vẫn là một nhưng trách nhiệm đổi theo tác vụ.

Sau khi các module cốt lõi đầu tiên chạy thật, câu hỏi đổi từ "cần có gì?" thành "điều gì đáng được chú ý tiếp theo?". Riêng tần suất là một câu trả lời yếu: chấm công tạo ra lượt dùng hằng ngày, còn một lỗi phân quyền hay một phê duyệt có tác động lớn xảy ra ít hơn nhưng rủi ro cao hơn. Vì vậy các tín hiệu được cân theo năm chiều, và mỗi tín hiệu nhận một trong bốn cách phản hồi.

Nhờ vậy roadmap không biến mọi yêu cầu thành một tính năng. Một tín hiệu trước hết phải cho thấy loại và mức độ của vấn đề.

Phân quyền không thể chỉ là quy tắc ở cấp màn hình khi ISS365 phải hỗ trợ nhiều cấu trúc tổ chức khác nhau. Ba nhu cầu phải được giữ cân bằng: người dùng chỉ thấy những gì họ được phép truy cập, phân quyền không chặn công việc họ chịu trách nhiệm, và mô hình phục vụ được cả tổ chức đơn giản lẫn phức tạp.

Các vai trò rộng như Chủ doanh nghiệp, Quản lý và Nhân viên là điểm xuất phát. Quyền kiểm soát sâu hơn mở ra qua ba bước: tổ chức và phòng ban, rồi dự án và phạm vi dữ liệu, rồi trách nhiệm và ngoại lệ. Kết quả gần với mô hình lai giữa RBAC và ABAC hơn là mô hình chỉ có vai trò cố định.

Phân quyền cũng thay đổi những gì giao diện hiển thị. Ẩn khi bản thân tài nguyên không nên bị phát hiện. Hiện ở dạng hạn chế khi người dùng có thể biết nó tồn tại nhưng không mở được nội dung. Hiện ở dạng vô hiệu hóa kèm giải thích khi việc giữ một hành động không khả dụng giúp giải thích quy trình.

Quyết định thứ hai xuất phát từ một giả định của sản phẩm tất-cả-trong-một: mọi công cụ hiện có rồi sẽ chuyển vào bên trong nền tảng. CRM cho thấy giả định đó có thể sai. Các cuộc trò chuyện với khách hàng vốn đã diễn ra trên Zalo, Facebook, fanpage và các điểm chạm khác, còn đơn hàng, lịch sử mua, người phụ trách và hoạt động bán hàng thì nằm ở nơi khác.

Giá trị đến từ việc giảm sự rời rạc quanh quan hệ khách hàng, không phải từ việc ép mọi cuộc trò chuyện vào ISS365. Lựa chọn này mang theo rủi ro phụ thuộc dài hạn về API, xác thực, chính sách nền tảng và bảo trì. Chúng tôi chấp nhận vì thay thế các kênh quen thuộc sẽ tạo rủi ro đổi hành vi lớn hơn mà giá trị cho người dùng lại yếu hơn.

Hành trình Yêu cầu cho thấy một tín hiệu đi từ phát hiện đến thiết kế như thế nào. Analytics trên môi trường thật cho thấy một điểm rơi đáng kể quanh bước chi tiết phê duyệt. Người dùng đã vào được và bắt đầu luồng, nên khả năng tìm thấy ít có khả năng là vấn đề chính. Mỗi loại bằng chứng trả lời một câu hỏi khác nhau.

Bằng chứng cho thấy sự do dự lặp lại, quay lui, thao tác lặp lại và phản hồi của hệ thống yếu. Người dùng khó hiểu thông tin nào là bắt buộc, hành động của mình đã được ghi nhận chưa, mình đang ở đâu trong quy trình và điều gì sẽ xảy ra sau khi gửi. Chẩn đoán làm việc có hai phần: gánh nặng quyết định, khi quá nhiều thông tin và lựa chọn hiện ra ngay từ đầu, và phản hồi hệ thống yếu.

Khi các module được làm song song, những tương tác giống nhau bắt đầu có nhiều bản triển khai cục bộ khác nhau. Người dùng phải học lại hành vi, còn designer, developer và QA lặp lại công việc. Nguyên tắc là: lặp lại trước, trừu tượng hóa sau. Một giải pháp ở lại mức cục bộ khi yêu cầu còn cụ thể, hành vi còn đang đổi, hoặc miền nghiệp vụ thật sự cần một mẫu khác. Khi hành vi đã ổn định và lặp lại ở nhiều bối cảnh, nó chuyển vào hệ thống chung: giải pháp cục bộ, hành vi lặp lại, xem xét, quy tắc chung, rồi Figma và Storybook.

Hành vi dùng lại được cũng cần hướng dẫn sử dụng: khi nào dùng, vì sao nó tồn tại, nó hoạt động ra sao và nó bao gồm những trường hợp biên nào.

Chuẩn hóa có giới hạn. Một quan điểm cho rằng ít trường hơn và mật độ thấp hơn luôn dễ dùng hơn. Các quy trình kế toán đã thách thức điều đó: kế toán viên có kinh nghiệm dựa vào mã, cột, thuật ngữ và cấu trúc tài chính quen thuộc, và ẩn quá nhiều sẽ làm việc đối chiếu chậm đi. Với các quy trình chuyên gia có mật độ cao, chúng tôi giữ lại thông tin hữu ích và cải thiện thứ bậc, cách nhóm, căn lề, khả năng quét mắt và phòng ngừa lỗi.

Vì vậy các buổi review thiết kế của tôi đặt những câu hỏi vượt ra ngoài một màn hình.