UX Note day 15: Object-Oriented design vs Task-Oriented design

Cách bạn tiếp cận vấn đề là cách bạn sắp xếp giải pháp đến file làm việc.

Trước đây khi làm design manager và cả sau này khi làm freelance, tôi có may mắn được chạm vào Figma file của nhiều designer khác. Từ đó, tôi cũng nhận ra cách tổ chức file của các thành viên khác nhau. Sẽ có lúc là 1 page, sẽ có lúc lại theo flow vắt qua nhiều page. Nói thật là cách nào cũng đúng. Có điều nó gây ra chuyện kiểm soát variation. Nhưng đó không phải chuyện chính trong bài này. Hôm nay tôi muốn viết về lý do tại sao có 2 cách sắp xếp file đó.

Tiếp nối câu chuyện bên trên, lý do rất đơn giản: Cách tiếp cận yêu cầu khác nhau ( từ business đến PM ). Lúc đầu sản phẩm khởi tạo, phần lớn chúng ta phải quy hoạch đất xây feature nên dùng Object-oriented approach. Về sau các feature nảy sinh theo sự nở rộ của tác vụ business, Task-oriented lại phổ biến hơn.

Nội dung sẽ bao gồm:

• Định nghĩa và nguyên lý cốt lõi của Object-Oriented UX design

• Sự khác biệt giữa OOD và Task-Oriented Design (cách tiếp cận truyền thống trong UX)

• Dùng cái gì và khi nào?

• Resource

Lưu ý. Gọi là Object-oriented do nó có xuất phát gốc từ việc lập trình theo mô hình này. Thiết kế trải nghiệm cho phần mềm nên sẽ cần tham khảo việc phần mềm được thiết kế ra sao.

Bạn có thể tham khảo thêm (Object-Oriented UX: Guide & Resources | Think Company)

---

1. Định nghĩa và nguyên lý cốt lõi của Object-Oriented Design

Object-Oriented Design (OOD) là cách tiếp cận UX tập trung vào các đối tượng (objects) trong miền nghiệp vụ của người dùng thay vì tập trung vào các quy trình hay chức năng của phần mềm. Nói cách khác, giao diện và điều hướng được định hướng quanh những “danh từ” quan trọng đối với người dùng (ví dụ: đơn hàng, khách hàng, sản phẩm), thay vì quanh các “động từ” hay tác vụ kỹ thuật (Object-focused vs Task-focused Design - UX Mastery) (The Opus Platform’s Metadata-Driven, No-Code Solutions | TraceLink). Mặc dù thuật ngữ “hướng đối tượng” xuất phát từ lĩnh vực lập trình, ở đây nó không liên quan đến code, mà ám chỉ việc thiết kế giao diện theo các đối tượng trong thế giới thực của người dùng (Object-focused vs Task-focused Design - UX Mastery).

Nguyên lý cốt lõi của thiết kế hướng đối tượng có thể tóm tắt như sau (Object-focused vs Task-focused Design - UX Mastery):

• Điều hướng xoay quanh đối tượng (danh từ) – Menu và cấu trúc thông tin ưu tiên hiển thị các đối tượng chính mà người dùng quan tâm, thay vì liệt kê các hành động.

• Đối tượng là thành phần chính trong UI – Mọi màn hình hay trang đều được xây dựng để đại diện cho một hoặc nhiều đối tượng (ví dụ: trang “Khách hàng” hiển thị thông tin một khách hàng cụ thể).

• Hành động (động từ) được thực hiện trên đối tượng – Các tác vụ của người dùng được thực hiện như những hành động áp dụng lên đối tượng. Ví dụ: từ trang đối tượng “Khách hàng”, người dùng có thể chỉnh sửa thông tin, thêm ghi chú, xóa khách hàng đó, v.v.

• Tác vụ chỉ là thứ yếu, phụ thuộc đối tượng – Các quy trình hay tác vụ được kích hoạt thông qua việc tương tác với đối tượng. Nói cách khác, đối tượng là điểm khởi đầu, còn hành động phục vụ cho đối tượng đó.

Nhờ cách tiếp cận này, giao diện mô phỏng cách tư duy tự nhiên của người dùng. Người dùng thường nghĩ về thực thể trước, hành động sau: ví dụ, họ nghĩ “chiếc xe bẩn quá... rửa xe thôi” (danh từ → động từ) thay vì “rửa đồ: rửa tóc, rửa em bé, rửa xe” (động từ → danh từ) (What Is Object-Oriented Experience Design? - Macquarium BlogMacquarium Blog). Vì thế, thiết kế OCD tận dụng mô hình tư duy “noun-verb” tự nhiên, giúp giao diện trực quan hơn.

---

2. Sự khác biệt giữa thiết kế OOD và thiết kế TOD

Task-Oriented Design (TOD)

Thiết kế hướng tác vụ (task-centric) – phương pháp truyền thống trong UX – tập trung vào những việc người dùng cần làm. Quy trình thiết kế thường bắt đầu bằng cách xác định các tác vụ hoặc luồng công việc (user tasks/flows) và xây dựng giao diện xoay quanh việc hoàn thành từng tác vụ đó. Ví dụ, một ứng dụng hướng tác vụ có thể cung cấp menu dạng hành động: “Tạo đơn hàng mới”, “Theo dõi đơn hàng”, “Báo cáo doanh thu” – tức là nhấn mạnh động từ và luồng từng bước thực hiện nhiệm vụ.

Focus:

• Tối ưu hóa luồng công việc, tập trung vào việc hướng dẫn người dùng hoàn thành các nhiệm vụ cụ thể, ví dụ: “Process Order” hay “Generate Report.”

Key Principles:

• User-Centric Workflows: Thiết kế dựa trên các quy trình làm việc của người dùng, theo vai trò và nhiệm vụ cụ thể.

• Efficiency: Giảm thiểu số bước cần thực hiện để hoàn thành nhiệm vụ, giúp tăng hiệu quả công việc.

• Role-Based Access: Tùy chỉnh giao diện và chức năng dựa trên vai trò của người dùng (ví dụ: nhân viên bán hàng so với kế toán).

Strengths in B2B:

• Usability: Giao diện đơn giản, dễ sử dụng giúp rút ngắn thời gian đào tạo.

• Automation: Tích hợp các quy tắc kinh doanh vào quy trình, ví dụ tự động phê duyệt đơn hàng dưới một mức giá nhất định.

• Error Reduction: Hướng dẫn người dùng qua từng bước đã được kiểm duyệt, giảm thiểu lỗi thao tác.

Ví dụ:
Một giao diện “Reorder Stock” có thể được thiết kế dưới dạng wizard, tự động gợi ý số lượng đặt hàng dựa trên dữ liệu lịch sử. Người dùng chỉ cần thực hiện theo các bước được chỉ dẫn rõ ràng để hoàn thành tác vụ.

Object-Oriented Design (OOD)

Ngược lại, Object-Oriented Design tập trung vào đối tượng trước. Giao diện OOD thường có cấu trúc danh mục theo đối tượng (object-based navigation): người dùng trước tiên chọn đối tượng mà họ quan tâm, sau đó mới thấy các hành động có thể làm với đối tượng đó. Ví dụ thực tế dễ thấy: các trang web du lịch như Orbitz, Kayak hay Expedia đều có menu chính là các danh mục đối tượng như Chuyến bay, Khách sạn, Thuê xe, Gói ưu đãi… chứ không liệt kê trực tiếp các hành động đặt dịch vụ (What Is Object-Oriented Experience Design? - Macquarium BlogMacquarium Blog). Người dùng sẽ chọn một đối tượng (ví dụ “Khách sạn”), rồi trong đó mới thực hiện các hành động cụ thể như tìm kiếm khách sạn, đặt phòng.

Focus:

• Mô hình hóa hệ thống xoay quanh các đối tượng – những “thực thể” mà người dùng thường tương tác, ví dụ: Customer, Order, Inventory.

Key Principles:

• Encapsulation: Gói gọn dữ liệu và các hành động liên quan vào cùng một đối tượng.

• Inheritance/Polymorphism: Cho phép tái sử dụng các thành phần và tạo sự linh hoạt trong tương tác giữa các đối tượng.

• Abstraction: Đơn giản hóa hệ thống phức tạp bằng cách ẩn đi những chi tiết không cần thiết.

Strengths in B2B:

• Modularity: Cấu trúc rõ ràng, dễ tích hợp với các hệ thống khác như ERP, CRM.

• Scalability: Dễ dàng mở rộng khi các quy tắc nghiệp vụ thay đổi.

• Maintainability: Cấu trúc minh bạch giúp việc bảo trì và cập nhật trở nên dễ dàng.

Ví dụ:
Trong một hệ thống quản lý kho, một đối tượng như PurchaseOrder có thể có các phương thức như generatePO hoặc validateSupplier. Điều này giúp nhân viên dễ dàng tạo và kiểm tra đơn hàng mà không cần quan tâm đến quá trình xử lý phía sau.

---

Vậy dùng cái gì nhỉ?

Nói ngắn gọn, OCD lấy “danh từ” làm trung tâm, còn thiết kế truyền thống lấy “động từ” làm trung tâm. Việc dùng tác vụ làm nền tảng giao diện có thể vô tình thêm một lớp phức tạp, bắt người dùng phải định hình trước “muốn làm gì” thay vì “đang xử lý đối tượng nào” (Object-focused vs Task-focused Design - UX Mastery). Với OOD, người dùng chỉ cần quan tâm đến đối tượng họ đang làm việc, hệ thống sẽ cung cấp các hành động liên quan một cách tự nhiên.

Dựa trên các tài liệu thu lượm và chủ ý cá nhân, việc lựa chọn giữa Object-Oriented Design (OOD) và Task-Oriented Design (TOD) phụ thuộc vào bối cảnh sử dụng, đặc điểm người dùng và tính chất của nhiệm vụ. Dưới đây là một số gợi ý:

Khi nào nên chọn OOD:

• Môi trường dữ liệu phức tạp: Nếu hệ thống chứa nhiều đối tượng (ví dụ: khách hàng, đơn hàng, sản phẩm) mà người dùng cần tương tác và tra cứu thường xuyên, OOD sẽ giúp họ “nhìn thấy” dữ liệu theo cách họ quen thuộc.

• Tính linh hoạt cao: Nếu người dùng chuyên nghiệp cần tự do thao tác, tùy chỉnh thông tin và có kiến thức về nghiệp vụ, OOD giúp họ dễ dàng truy cập vào các thông tin chi tiết của từng đối tượng.

• Mô hình dữ liệu rõ ràng: Khi nghiệp vụ đòi hỏi mối quan hệ chặt chẽ giữa các đối tượng, OOD tạo ra cấu trúc rõ ràng, dễ mở rộng và bảo trì.

Khi nào nên chọn TOD:

• Quy trình tác vụ đơn giản, tuyến tính: Nếu người dùng chỉ cần hoàn thành một số tác vụ nhất định theo trình tự (ví dụ: tạo đơn hàng, báo cáo doanh thu), TOD sẽ hướng dẫn họ từng bước một, giảm bớt sự nhầm lẫn.

• Đối tượng không chuyên kỹ thuật: Với người dùng mới hoặc ít kinh nghiệm, giao diện hướng nhiệm vụ giúp họ dễ dàng theo dõi và hoàn thành quy trình mà không cần hiểu sâu về cấu trúc dữ liệu. Ví dụ: Bạn ra chỗ đăng ký Căn Cước Công Dân, bạn sẽ thấy việc trải nhiều page gây khổ cho các cụ già như thế nào.

• Tối ưu hiệu suất làm việc: Khi các tác vụ có thể được tự động hóa (ví dụ: tự động phê duyệt đơn hàng dưới một mức nhất định), TOD giúp tăng tốc độ xử lý và giảm lỗi.

Kết hợp cả hai:

• Trong nhiều trường hợp, đặc biệt là với phần mềm B2B phức tạp, kết hợp OOD và TOD sẽ đem lại lợi ích tối ưu. Ví dụ, giao diện chính có thể được tổ chức theo OOD để phản ánh toàn bộ hệ thống dữ liệu, đồng thời cung cấp các lối tắt theo nhiệm vụ (TOD) cho những tác vụ quan trọng hoặc thường gặp.

• Cách kết hợp này giúp người dùng chuyên nghiệp có cái nhìn tổng thể về hệ thống, đồng thời đối với người dùng mới, họ sẽ có hướng dẫn cụ thể để hoàn thành tác vụ mà không bị choáng ngợp.

---

Dưới đây là một số tài liệu tham khảo:

Object-Oriented UX (OOUX)

• OOUX.org: Trang chủ chuyên sâu về OOUX với các bài viết, case study và hướng dẫn.

• Object Oriented UX: A New Paradigm for Designing User Experiences: Bài viết trên A List Apart giải thích các nguyên tắc cơ bản của OOUX.

• Object-Oriented UX and Object-Oriented UI https://outmn.medium.com/object-oriented-ux-and-object-oriented-ui-722b5abcb763 ( medium nên bật VPN nhá )

Task-Oriented Design

• Nielsen Norman Group – Task Flows: Các bài viết chuyên sâu về cách xây dựng luồng tác vụ hiệu quả cho người dùng.

• Task-Based Design: The Key to User-Centric Workflows: Bài viết trên Smashing Magazine chia sẻ kinh nghiệm thiết kế dựa trên nhiệm vụ.

• TASK-CENTERED USER INTERFACE DESIGN * * * * A Practical Introduction * * * * * * Clayton Lewis * * John Rieman

---

Cảm ơn các bạn đã đọc. Mình là một người không chuyên về lập trình nên phần nghiên cứu này nếu không bật 3 ông AI ( Chat GPT, Deepseek, Claude ) thì cũng ù ù cạc cạc. Thế mới thấy designer cần hiểu và theo dõi các công nghệ/tư duy trong lập trình, dù không biết code. Nhất là khi được giao cho 1 sản phẩm mới toanh và chưa launch.