Ngưỡng Doherty - Doherty Threshold

Năng suất tăng vọt khi máy tính và người dùng của nó tương tác với tốc độ (<400 ms) để đảm bảo rằng cả hai phía không phải đợi nhau.

- Phản hồi trong khoảng 400 ms để giữ sự chú ý và tăng năng suất của người dùng.

- Sử dụng hiệu suất cảm nhận (perceived performance) để cải thiện thời gian phản hồi và giảm cảm giác đang chờ đợi. 

- Animation có thể dùng để thu hút chú ý trực quan của người dùng trong khi đang tải hoặc xử lý tác vụ. 

- Thanh tiến trình giúp thời gian chờ dễ chịu hơn, bất kể độ chính xác của chúng.

- Việc có chủ ý thêm thời gian chờ đợi vào một quá trình cụ thể có thể làm tăng giá trị cảm nhận của người dùng và tạo niềm tin, dù thực tế quá trình đó diễn ra nhanh hơn nhiều.

Một trong những thuộc tính quan trọng góp phần tạo nên trải nghiệm người dùng tốt là hiệu suất. Người dùng có thể thất vọng và có ấn tượng tiêu cực khi các tác vụ bị xử lý chậm, thiếu phản hồi hoặc thời gian tải quá lâu. Tốc độ thường chỉ được xem xét khi tối ưu hóa sản phẩm nhưng thật ra chúng ta nên xem tốc độ như một tính năng thiết kế thiết yếu và cốt lõi của trải nghiệm người dùng tốt. Thời gian phản hồi của hệ thống rất quan trọng với trải nghiệm người dùng tổng thể cho dù đó là thời gian tải ban đầu, thời gian xử lý yêu cầu và phản hồi, hay là thời gian chuyển trang. 

Có nhiều yếu tố ảnh hưởng đến hiệu suất của các trang web và ứng dụng, nhưng yếu tố quan trọng nhất là dung lượng tổng thể các trang. Tuy vậy, dung lượng của các web đã tăng mạnh qua các năm. Theo dữ liệu từ HTTP Archive, dung lượng trung bình của trang desktop vào năm 2019 gần đạt 2 MB (1.940 KB), với trang mobile là 1.7 MB (1.745 KB). Dung lượng của các trang này tăng vọt vào năm 2010-2011: 609 KB trên desktop và 262 KB trên mobile.

Điều này dẫn đến thời gian chờ đợi lâu hơn và mọi người thường không thích chờ đợi khi đang thực hiện một tác vụ. Rất nhiều nghiên cứu đã chỉ ra rằng thời gian chờ đợi càng lâu chúng ta sẽ càng nản lòng và từ bỏ việc xử lý tác vụ đó. 

Ngoài ra, thời gian phản hồi chậm sẽ làm suy giảm năng suất người dùng. Phản hồi trong khoảng 100ms tạo cảm giác hệ thống phản hồi ngay lập tức, phản hồi từ 100 - 300 ms sẽ bắt đầu cảm nhận được bằng mắt người và người dùng cảm thấy mất kiểm soát hơn. Khi thời gian phản hồi vượt qua 1000 ms (1 giây), người ta sẽ nghĩ đến những việc khác, không còn chú ý đến nữa và quên dần các thông tin liên quan đến tác vụ dẫn đến sự giảm sút tất yếu trong hiệu suất. Sự tải nhận thức (cognitive load) cần thiết để tiếp tục tác vụ cũng tăng lên và trải nghiệm người dùng tổng thể sẽ bị ảnh hưởng. 

Vào những ngày đầu của việc sử dụng máy tính để bàn, thời gian phản hồi từ máy tính trong khoảng 2 giây được coi là chấp nhận được khi thực hiện một tác vụ. Tiêu chuẩn được chấp nhận rộng rãi này vì 2s là đủ cung cấp thời gian cho người dùng suy nghĩ về tác vụ tiếp theo. Sau đó, vào năm 1982, một bài báo được công bố bởi hai nhân viên của IBM đã thách thức tiêu chuẩn này với tuyên bố rằng "Năng suất tăng lên không chỉ theo tỷ lệ thuận trực tiếp với việc giảm thời gian phản hồi." khi thời gian phản hồi dưới 400 ms. Các tác giả của nghiên cứu cho rằng "khi máy tính và người dùng tương tác với tốc độ đảm bảo không có ai phải đợi, năng suất tăng vọt, chi phí công việc thực hiện trên máy tính giảm xuống, nhân viên cảm thấy hài lòng hơn với công việc của mình và chất lượng công việc có xu hướng cải thiện". Điều này đã thiết lập một tiêu chuẩn mới được biết đến với cái tên "ngưỡng Doherty", dựa trên quan sát của Doherty rằng thời gian phản hồi của máy tính tỉ lệ nghịch với năng suất.

Trong một số trường hợp thời gian xử lý yêu cầu vượt quá ngưỡng Doherty (> 400 ms) và rất khó rút ngắn thời gian này. Nhưng điều đó không có nghĩa là chúng ta không thể cung cấp phản hồi cho người dùng một cách kịp thời khi hệ thống đang xử lý yêu cầu. Kỹ thuật này giúp tạo ra cảm giác rằng một trang web hoặc ứng dụng đang chạy nhanh hơn thực tế.

Một ví dụ phổ biến được sử dụng bởi các nền tảng như Facebook là hiển thị một "skeleton screen" khi nội dung đang tải. Kỹ thuật này giúp trang web có vẻ tải nhanh hơn bằng cách ngay lập tức hiển thị các khối giữ chỗ trong các vùng mà nội dung sẽ xuất hiện sau này. Các khối này sẽ dần được thay thế bằng các văn bản và hình ảnh thực tế sau khi chúng được tải. Điều này giảm bớt cảm giác chờ đợi, tăng cường cảm nhận về tốc độ và khả năng phản hồi, ngay cả khi nội dung tải chậm. Ngoài ra, "skeleton screens" ngăn chặn trải nghiệm bối rối và mất phương hướng khi nội dung bị dịch chuyển khi các mục xung quanh tải xong, bằng cách dành chỗ không gian cho mỗi mục từ đầu.

Một cách khác để tối ưu hóa thời gian tải được gọi là kỹ thuật “làm mờ”. Cách tiếp cận này tập trung đặc biệt vào hình ảnh, thường là nguyên nhân chính gây ra thời gian tải quá lâu trong cả ứng dụng web và ứng dụng di động. Nó hoạt động bằng cách: đầu tiên chỉ tải một phiên bản nhỏ của bức hình và tải các chi tiết của hình lên sau ở vị trí định sẵn cho ảnh đó trên ứng dụng. Gaussian blur được sử dụng để loại bỏ các chi tiết không mong muốn và độ nhiễu của ảnh để thay đổi tỉ lệ ảnh có độ phân giải thấp. Khi phiên bản lớn hơn của hình ảnh đang được tải, nó sẽ được đặt phía sau phiên bản có độ phân giải thấp và được hiển thị ra bằng cách làm mờ dần hình ảnh phía trên. Kỹ thuật này không chỉ đảm bảo thời gian tải nhanh hơn bằng việc ưu tiên hiệu suất hơn nội dung, mà còn dành không gian cho hình ảnh có độ phân giải đầy đủ từ đầu để tránh nhảy trang khi phiên bản độ phân giải cao của hình ảnh được tải hoàn toàn.

Animation là một cách khác để thu hút sự chú ý của người dùng trong lúc đang tải hoặc xử lý tác vụ nền. Một ví dụ phổ biến là "percent-done progress indicators" (thanh tiến trình hiển thị phần trăm đã hoàn thành), còn được gọi là thanh tiến trình. Nghiên cứu đã chỉ ra rằng việc chỉ nhìn thấy một thanh tiến trình có thể làm cho thời gian chờ đợi dễ chịu hơn, bất kể tính chính xác của nó. Thanh tiến trình đơn giản này có hiệu quả vì một số lý do sau đây:

- Nó xác nhận cho người dùng biết rằng yêu cầu của họ đang được xử lý.

- Nó cung cấp yếu tố trực quan trong quá trình chờ đợi.

- Nó giảm thiểu cảm giác chờ đợi bằng cách dồn sự tập trung vào animation của thanh tiến trình thay vì quá trình chờ đợi thực tế.

Mặc dù chúng ta không thể hoàn toàn loại bỏ việc xử lý dữ liệu hay các thời gian chờ đợi, nhưng chúng ta có thể tối ưu hóa trải nghiệm người dùng bằng cách cung cấp phản hồi hình ảnh.

Một ví dụ về việc sử dụng animation để giảm thiểu sự không chắc chắn và áp lực khi chờ đợi có thể được tìm thấy trong ứng dụng email nổi tiếng của Google - Gmail. Màn hình tải hiển thị một phiên bản animation của biểu tượng của Gmail kết hợp với một thanh tiến trình đơn giản. Hiệu ứng animation đơn giản nhưng đặc biệt này tạo ra cảm giác thời gian chờ đợi ngắn hơn và cải thiện trải nghiệm người dùng tổng thể bằng cách trấn an người dùng rằng ứng dụng đang được tải.

Mười giây được công nhận là giới hạn để giữ sự tập trung của người dùng vào công việc hiện tại - bất cứ thời gian chờ đợi nào vượt quá giới hạn này, họ sẽ muốn thực hiện các công việc khác trong khi đợi. Khi thời gian chờ đợi phải kéo dài hơn giới hạn tối đa 10 giây, thanh tiến trình vẫn hữu ích nhưng nên được bổ sung bằng ước tính thời gian còn lại để hoàn thành và mô tả công việc đang được thực hiện. Thông tin bổ sung này giúp người dùng biết cần bao nhiêu thời gian để công việc hoàn tất và họ sẽ rảnh tay làm các việc khác trong thời gian đó. Ví dụ, màn hình cài đặt của Apple được hiển thị khi đang tiến hành cập nhật.

Một kỹ thuật thông minh khác để cải thiện hiệu suất cảm nhận là "giao diện người dùng lạc quan" (optimistic UI). Kỹ thuật này hoạt động bằng cách cung cấp phản hồi lạc quan rằng một hành động đã thành công trong khi nó đang được xử lý, thay vì chỉ cung cấp phản hồi sau khi hành động đã hoàn tất. Ví dụ, Instagram hiển thị các bình luận trên các bức ảnh trước khi thực sự được đăng. Điều này làm cho thời gian phản hồi của ứng dụng trở nên nhanh hơn thực tế: nó ngay lập tức cung cấp phản hồi hình ảnh cho rằng bình luận sẽ được đăng thành công, và chỉ hiển thị thông báo lỗi sau đó nếu hành động không thành công. Quá trình xử lý cần thiết vẫn diễn ra, nhưng cảm nhận của người dùng về hiệu suất ứng dụng được cải thiện.

Khi thời gian phản hồi quá nhanh

Hầu hết các vấn đề liên quan đến thời gian phản hồi thường do ứng dụng quá chậm. Tuy nhiên, có lúc cần xem xét lại nếu thời gian phản hồi quá nhanh. Mặc dù có vẻ hơi ngược đời, nhưng việc thời gian phản hồi quá nhanh có thể gây ra một số vấn đề. Trước tiên, thay đổi diễn ra quá nhanh có thể bị bỏ sót hoàn toàn - điều này đặc biệt đúng khi thay đổi không phải là kết quả của hành động của người dùng mà là điều gì đó xảy ra tự động. Một vấn đề khác có thể xảy ra khi thời gian phản hồi quá nhanh là người dùng có thể khó hiểu được điều gì đã xảy ra, vì tốc độ thay đổi quá nhanh với tư duy xử lý của người dùng. Cuối cùng, thời gian phản hồi quá nhanh có thể dẫn đến sự không tin tưởng nếu nó không phù hợp với kỳ vọng của người dùng về tác vụ đang được thực hiện. Việc tạo thêm độ trễ cho một quy trình thực tế có thể tăng giá trị cảm nhận của nó và khơi dậy niềm tin, ngay cả khi quy trình thực tế diễn ra nhanh hơn rất nhiều.

Ví dụ, quy trình kiểm tra bảo mật của Facebook, quét tài khoản của bạn để tìm các lỗ hổng bảo mật tiềm tàng. Facebook sử dụng nó để cho người dùng biết việc gì đang được quét và thêm thời gian trễ cho quy trình để khơi dậy lòng tin rằng thiết bị của họ đang được quét toàn diện.

Hiệu suất không chỉ là yếu tố kỹ thuật của các nhà phát triển mà còn là tính năng thiết kế quan trọng. Là một nhà thiết kế, trách nhiệm của chúng ta là đảm bảo người dùng sản phẩm và dịch vụ hoàn thành tác vụ của họ nhanh chóng và hiệu quả nhất có thể. Để làm được điều này, chúng ta nên đảm bảo việc cung cấp phản hồi phù hợp, nâng cao hiệu suất cảm nhận và sử dụng thanh tiến trình để giảm cảm giác chờ đợi. 

Bài viết này mình dịch từ Chap 10 của Laws of UX, mọi người có thể kiếm sách ở đây: