“Đây là quan điểm cá nhân của em khi em làm Product, em cũng newbie nên mong chị Đáp, chị Vân, anh Thành, anh Nam, và mọi người xem thử và góp ý cho em nếu có chỗ nào hong phù hợp hénnn. Về việc define ra được hết các use case để không bỏ sót màn hình hay logic nào, thì em sẽ đi theo 1 system thinking trả lời cho câu hỏi “system thay đổi thế nào và thay đổi đó phản ánh lên những đâu khi người dùng thực hiện 1 điều gì đó”. Nó sẽ bao gồm object oriented requirements, CRUDL+, system context diagram, state transition matrix, và 1 checklist nhỏ cho những điểm UI cần lưu ý.
Object oriented requirements
Thay vì tập trung vào user flow, thì em sẽ tập trung nhìn vào entity lifecycle.
- Entity là cái quái gì? Là 1 cái object (đối tượng) mà tính năng này động vào. eg: 1 order, 1 bài post, 1 user account, 1 voucher, etc.
Khi định nghĩa 1 action → em sẽ đặt câu hỏi “dữ liệu này còn xuất hiện ở đâu nữa”. Ví dụ:
- Screen List view: có cần filter trạng thái mới không?
- Screen Detail view: thông tin mới hiển thị ở đâu?
- Screen Admin: operation có cần thấy để hỗ trợ không?
- Screen Log/History: Có cần ghi lại thay đồi không?
Khi tự đặt cảu hỏi như vậy thì kiểu gì mình cũng vẽ ra được tất cả các use case (or at least most of it)
CRUDL+ (bảng nâng cấp của CRUD - hình như học ở Half sau của BPM)
Em hay dùng cái này để check logic cho any tính năng:
- C = Create: Tạo mới ở đâu? Ai tạo được?
- R = Read: Xem ở đâu? User thấy gì? Admin thấy gì?
- U = Update: Khi nào thông tin bị thay đổi? Ai sửa được? Sửa xong thì các màn hình hiển thị thông tin cũ có update real time không? Thông tin cũ sẽ đi về đâu?
- D = Delete: Xóa đi khi nào? Ai xóa được? Có xóa permanent không hay chỉ tạm ẩn? Các liên kết cũ sẽ ảnh hưởng như thế nào khi xóa?
- L = List: Hiển thị trong danh sách nào? Sorting ra sao?
System Context Diagram
Có thể là do em làm technical nhiều nhưng em hay vẽ ra 1 cái sơ đồ mô tả relationship và interaction giữa các thành phần với nhau để tránh khả năng miss logic do không nắm được dependencies đang ở đâu.
- Muốn show UI phải link tới BE, BE phải check với DB → Ví dụ như vậy xong mình vẽ ra connect chúng lại với nhau
- Mỗi mũi tên interaction/relationship hãy đặt câu hỏi “cái gì sẽ xảy ra khi chỗ này bị lỗi/ timeout” =)) Em hứa chắc chắn là kiểu gì cũng đẻ ra 101 tình huống mà có thể mình không bao giờ nghĩ tới khi chỉ vẽ happy case
State Transition Matrix
Có thể lập 1 cái bảng với 4 cột: Trạng thái hiện tại | Action | Trạng thái tiếp theo | Thay đổi ở đâu (Có thể để UI thay đổi ở đâu)
- Vậy để vẽ ra được cái bảng này thì mình phải xác định được các trạng thái mà 1 tính năng mình có sẽ là gì. e.g. Thanh toán order thì sẽ có các trạng thái: chờ xác nhận giao dịch, xác nhận giao dịch, xử lý giao dịch, thanh toán giao dịch thành công/ thất bại → Map xuống thành từng các database value như pending, fail, success
Góc khuất của UI
Nếu là em thì em sẽ check qua 4 trạng thái hiển thị của 1 cái màn hình với 4 cái checkpoints này:
- Empty State: Khi chưa có dữ liệu thì màn hình hiện gì?
- Loading State: Khi mạng chậm/ hệ thống đang xử lý thì hiện gì?
- Error State: Khi API lỗi, mất mạng, hoặc không có quyền truy cập thì hiện gì?
- Partial State: Khi có 1 phần dữ liệu thì hiện gì?
— Disclaimer: Đây là dưới góc nhìn của em (1 người có technical background) và đang làm Technical Product nên sẽ có những thứ khá theo hướng của mấy anh Dev → Nếu mình hong clear thì có thể hỏi lại elm để em giải thích lại rõ hơn nhaaa. Và em mới là newbie thôi nên em xin mở rộng lòng mình đón nhận các góp ý và các ý kiến khác cho việc nì.”
(tin nhắn của Minh Anh (Bo), được repost từ Discord community của Khoá học BPM 7 tuần)
ạ. Em hay dùng draw.io, miro, nhưng cảm giác vẫn chưa tối ưu lắm :
:
Nếu mà tool có freemium thì:
:
Còn xài free hoàn toàn thì dùng Mermaid open source như Bo suggest