Giao diện người dùng là thứ mà chúng ta sử dụng hằng ngày để giao tiếp với máy tính cũng như trên các thiết bị di động. Đó có thể là phần mềm, các nút nhấn, thanh trượt, lẫy,… Để làm ra được “giao diện”, các lập trình viên phải tuân thủ theo một số quy tắc nhất định trước khi làm các phần mềm. Mới đây mình có nghiên cứu về vấn đề thiết kế giao diện người dùng và hôm nay mình xin chia sẻ với các bạn 2 bộ nguyên lý thường sử dụng trong lĩnh vực này, đó là bộ nguyên lý DOETvà nguyên lý Nielsen. Sau khi đọc xong, bạn có thể thử áp dụng các nguyên lý đó với những giao diện mà bạn gặp thường ngày và sẽ biết được liệu thứ mình đang dùng có thật sự được thiết kế một cách hiệu quả hay không.
I. Sự quan trọng của giao diện người dùng
Từ trước đến nay chúng ta thường nghĩ giao diện tức là những gì có mặt trên phần mềm của máy tính, điện thoại, máy tính bảng. Điều này không sai, nhưng nó chỉ là một phần nhỏ của khái niệm “giao diện người dùng” (user interface) mà thôi. Cách bố trí nút trên chiếc remote, cách bố trí đèn và cần gạt trên lò vi sóng,… đều là giao diện người dùng, miễn là chúng tạo ra được một phương thức nào đó mà con người có thể tương tác với máy móc. Còn giao diện của phần mềm mà chúng ta hay nói đến có tên gọi là “giao diện đồ họa người dùng” (graphical user interface – GUI).
Vậy vì sao giao diện người dùng lại quan trọng? Với một hệ thống có giao diện quá tệ, trong phần lớn các trường hợp thì người ta sẽ xem nó là một sự thất bại dù cho bạn có thiết kế những tính năng khác hay và tuyệt vời đến mức nào đi chăng nữa. Lý do là vì bạn không tạo được phương thức đủ tốt để người dùng tương tác, điều khiển với hệ thống của bạn, vậy thì làm sao họ có thể dùng nó một cách hiệu quả? Hoặc nếu giao diện bạn không thể tự đủ sự tin tưởng, liệu người dùng có giao dịch với bạn không? Do đó, giao diện là thứ được nhà thiết kế/lập trình viên rất quan tâm và họ luôn tìm cách giúp người dùng cảm thấy hài lòng nhất có thể.
Trong lúc nói về 2 nguyên lý bên dưới, mình chủ yếu lấy ví dụ về phần mềm để các bạn dễ hình dung vì nó quen thuộc với chúng ta, và cũng bởi lĩnh vực mà mình đang nghiên cứu để áp dụng DOET chủ yếu là về phần mềm.
II. Bộ nguyên lý DOET
Đây là bộ nguyên lý được tạo ra bởi nhà khoa học Donald A. Norman trong lúc ông nghiên cứu về vấn đề tương tác giữa con người với máy tính trong dự án gọi là “Design of Everyday Thigns” – DOET (tạm dịch: thiết kế cho những thứ được dùng hằng ngày). Nó được sử dụng để các nhà thiết kế tích hợp và đánh giá xem giao diện của mình có thực sự hữu ích và giúp cho việc tương tác giữa người với máy tính dễ dàng hơn hay không. Nó bao gồm những nhân tố như sau:
1. Hoàn tất những yêu cầu từ phía người dùng
Khi thiết kế một phần mềm nào đó, người ta sẽ tìm hiểu xem người dùng cần sử dụng gì. Ví dụ khi bạn chạy ứng dụng máy tính trong windows, các trường hợp sử dụng có thể diễn ra sẽ là: cộng 2 số, trừ 2 số, nhân 2 hoặc nhiều số, rút căn, tính lũy thừa. Để được xem là hiệu quả thì giao diện của app máy tính này phải đáp ứng được tất cả những tình huống nói trên. Đây cũng là nhân tố quan trọng hàng đầu trong nguyên lý DOET. Hãy thử tưởng tượng xem nếu một phần mềm không thể thực hiện những gì bạn muốn thì xem như bỏ đi rồi.
2. Sử dụng cả “Knowledge in the Head” và “Knowledge in the World”
Trước hết chúng ta hãy xem thử hai khái niệm là lạ này là gì nhé. “Knowledge in the Head” là những kiến thức mà người dùng đã biết, đã có sẵn khái niệm trong đầu của mình mà không cần người thiết kế phải nói ra hoặc đề cập đến trong giao diện phần mềm. Chẳng hạn, khi thấy một chiếc máy tính, bạn sẽ biết phải gõ bàn phím ra sao, phải xài chuột như thế nào.
Trong khi đó, “Knowledge in the World” thì ngược lại: nó là những kiến thức mà người dùng chưa biết đến, và sẽ cần phải được ghi chú rõ trên giao diện để người dùng học cách xài. Ví dụ, khi bạn lần đầu chạy game, người thiết kế/lập trình viên sẽ trình diễn cho bạn xem cách sử dụng app, cách điều khiển nhận vật, bắn thì nhấn nút nào, chạy thì điều khiển phím nào, xoay góc nhìn thì phải làm gì. Tương tự, Apple tích hợp hướng dẫn sử dụng touchpad đa điểm cho OS X bởi nó không giống với những gì người ta từng biết về cách xài chuột.
“Knowledge in the Head” không đòi hỏi người dùng phải học, trong khi “Knowledge in the World” thì có . Chính vì thế mà ở lần đầu tiếp xúc, những thứ thuộc về “Knowledge in the Head” sẽ tạo cảm giác thân quen hơn, nhưng bù lại có thể chúng ta sẽ mất thời để nhớ ra xem cách dùng thông thường là thế nào rồi mới có thể áp dụng.
Với “Knowledge in the World” thì sẽ mất thời gian học, nhưng việc học sẽ trở nên đơn giản khi chúng ta có hướng dẫn cụ thể. Và một khi đã quen tay thì những thứ thuộc về “Knowledge in the World” sẽ giúp mang lại hiệu quả sử dụng cao hơn. Cũng với ví dụ về touchpad đa điểm trên Apple, lúc mới đầu bạn sẽ mất thời gian học cách xài, nhưng khi đã quen rồi thì nó giúp mọi việc trở nên dễ dàng và nhanh chóng hơn rất nhiều, thậm chí trở thành một trong những thao tác chính mỗi ngày dùng đến cả trăm lần.Một giao diện ứng dụng tốt sẽ tìm được cách kết hợp tối ưu giữa hai loại kiến thức nói trên. để hoàn thành công việc một cách nhanh chóng và đơn giản, không đòi hỏi người dùng phải học quá nhiều nhưng vẫn đảm bảo được hiệu suất tương tác.
3. Đơn giản hóa tác vụ của người dùng
Ai ai cũng thích sự đơn giản, chẳng ai lại đi thích cái gì dài dòng cho mệt cả. Ngay cả khi xái máy tính, smartphone, tablet cũng thế, nếu nhìn vào một ứng dụng mà có hàng đống nút thì thôi, chúng ta có thể nghĩ ngay đến chuyện từ bỏ và đi kiếm app khác. Dù cho ứng dụng của bạn viết ra có hay, có “thần thánh” và có chạy nhanh tới cỡ nào đi nữa thì nếu các bước để thực thi một tác vụ nào đó quá phức tạp, người dùng sẽ chia tay ngay lập tức. Chính vì thế lập trình viên/nhà thiết kế cần phải đơn giản hóa chúng. Theo Norman thì có một số cách đơn giản hóa như sau:
1. Hỗ trợ về mặt tâm lý: giúp người dùng cảm thấy bớt “hoảng sợ” khi nhìn vào giao diện. Một ví dụ dễ thấy đó là combobox – tức một nút mà bạn nhấn vào nó sẽ xuất hiện một số tùy chọn trong đó cho bạn. Lập trình viên có thể xài combobox để cho bạn chọn mã vùng nếu cần nhập số điện thoại chẳng hạn, còn trên Tinh tế thì xài combobox để di chuyển bài viết giữa các subforum với nhau, hoặc để chọn tiền tố cho bài viết.
2. Giảm tải những gì mà người dùng phải nhớ. Ví dụ: trong môi trường DOS, để copy thì bạn phải nhớ lệnh cp, nhớ cú pháp của nó, còn ở Windows, chúng ta chỉ việc nhấn phím phải chuột, chọn Copy là xong. Ví dụ khác, khi bạn cần nhập liệu về thời gian, một ô nhỏ với ngày tháng năm, nói chung là cả bộ lịch, sẽ xuất hiện cho bạn chọn ngày. Bạn không cần phải nhớ cụ thể ngày đó là thứ mấy, tuần nào, tháng nào nữa.
3. Tự động hóa: đây là thứ mà chúng ta rất hay gặp. Chẳng hạn như khi bạn đăng kí tài khoản mới trên Yahoo hay Google, hai trang web này sẽ tự xác định vị trí, quốc gia của bạn dựa vào địa chỉ IP. Hoặc như các máy Android, lúc bạn mới mua máy mà có bỏ SIM hoặc kết nối Wi-Fi, thiết bị sẽ tự nhận diện múi giờ và chỉnh sẵn, bạn không cần phải làm nữa. Hoặc nếu bạn nhập mã vùng là 08, chữ “Thành phố Hồ Chí Minh” sẽ tự xuất hiện.
4. Thay đổi bản chất của tác vụ: trên các trình duyệt cũ, ô tìm kiếm sẽ nằm tách biệt với ô địa chỉ. Sau này, Chrome, Firefox, Safari, IE đều xài chung một ô cho cả hai tác vụ, dễ dàng hơn và bạn sẽ không cần phải suy nghĩ nên nhập liệu vào đâu.
4. Làm mọi thứ rõ ràng nhất có thể
Với những tính năng chính, hãy đem nó ra giao diện chính, nơi người dùng dễ thấy nhất. Đừng cố “tỏ ra nguy hiểm” và giấu nó vào những menu ẩn sâu trong ứng dụng, điều đó không giúp gì cho người dùng cả. Nó còn làm người dùng rối và cảm thấy bực mình nữa. Việc làm mọi thứ trở nên rõ ràng cũng là một cách nhắc cho người dùng biết những tính năng nào hệ thống của chúng ta có hỗ trợ, và cách dùng chúng như thế nào.
5. Thu hẹp khoảng cách thực thi và khoảng cách đánh giá
Lúc mới tiếp cận với một hệ thống, phần mềm nào đó, người dùng sẽ đối mặt với hai “khoảng cách” (Gulf) khiến họ chưa thể dùng hệ thống một cách thành công, đó là:
Khoảng cách thực thi (Gulf of Execution): Người dùng cần làm gì để một tính năng có thể chạy được?
Để giảm khoảng cách giữa sự thắc mắc của người dùng với giao diện, nhà thiết kế có thể dùng một thứ gọi là “Affordance”. Ví dụ, khi bạn thấy một cái nút, bạn sẽ biết là bạn cần phải nhấn vào đó. Hoặc với một thanh trượt (slider), bạn sẽ biết là bạn cần kéo con chạy để thay đổi giá trị, và kéo sang phải là tăng giá trị lên, còn kéo sang trái là giảm đi.
Khoảng cách đánh giá (Gulf of Evaluation): Làm sao người dùng biết rằng tính năng đó đã chạy theo đúng những gì nó được thiết kế?
Trong trường hợp, chúng ta có thể lấy sự phản hồi xúc giác trên các smartphone làm ví dụ. Khi bạn gõ bàn phím hoặc nhấn nút nào đó, smartphone sẽ rung nhẹ lên để báo hiệu rằng bạn đã thành công trong chạm vào nút đó. Âm thanh phát ra cũng là một sự phản hồi được xài rộng rãi.Nhiệm vụ của nhà thiết kế/lập trình viên sẽ là giúp người dùng trả lời hai câu hỏi nói trên một cách rõ ràng, dễ dàng nhất có thể.
6. Sắp xếp một cách đúng đắn
Trong đầu người dùng sẽ có sẵn một mô hình về cách hoạt động của một thứ gì đó. Ví dụ, khi bạn mua đồ trong siêu thị, các bước bạn sẽ làm đó là xem hàng > xem giá > chọn hàng > tính tiền. Áp dụng nó vào giao diện của một trang web bán hàng online, bạn không thể bắt người dùng xem giá rồi mới xem hàng được. Bạn phải theo đúng trình tự và mô hình mà người dùng suy nghĩ đến, khi đó thì việc sử dụng giao diện mới đạt hiệu quả cao.
7. Khai thác sức mạnh từ các biện pháp hạn chế
Biện pháp hạn chế (constrain), từ này nghe có vẻ ghê gớm nhưng thực chất nó không phải là thứ gì đó nghiêm trọng quá đây. “Hạn chế” ở đây là một sự tinh chỉnh nào đó vào giao diện để một thứ gì đó không còn sử dụng được nữa, tạm thời hoặc trong thời gian dài. Vì sau chúng ta lại muốn đưa hạn chế vào trong ứng dụng, sao không để người dùng muốn làm gì thì làm? Đó là vì chúng ta muốn người dùng chọn được một lựa chọn chính xác nhất, giảm lỗi về sau.
Có 3 loại biện pháp hạn chế thường xài ngày nay:
- Hạn chế vật lý: Ví dụ, nhiều phần mềm hiện xài các ô chọn radiobutton để lựa chọn một thứ gì đó, như giới tính chẳng hạn. Bạn chỉ có thể chọn một trong hai, hoặc “Nam” hoặc “Nữ” chứ bạn không thể gõ bàn phím để nhập được. Như vậy sẽ tránh tình huống gõ nhầm, gõ không đúng ý muốn của lập trình viên.
- Hạn chế về suy nghĩ: ở một giao diện cho phép nhập thông tin cá nhân, nếu ô đầu tiên có nhãn là “Họ”, ô thứ hai ghi chữ “Tên”, bạn sẽ biết cần gõ gì vào. Còn nếu hai ô đó không có nhãn thì bạn có thể nhập tên vào ô Họ, họ và ô Tên, sai quy tắc yêu cầu của phần mềm.
- Hạn chế về văn hóa: cái này hơi phức tạp, nhưng ví dụ đơn giản nhất là màu sắc. Nếu bạn thấy một nút tô màu đỏ, bạn sẽ nghĩ ngay đến chuyện nhấn vào nút đó có thể gây ra nguy hiểm gì đó. Còn nếu thấy nút màu xanh, bạn biết nút đó là để chấp thuận và tiếp tục. Cách chọn màu cũng phải tùy vào văn hóa, chẳng hạn như ở Nga, người ta xem màu đỏ là “tích cực”, khi đó bạn không nên tô nút “Xóa” với màu này.
8. Thiết kế phải tính đến lỗi
Cứ con người là phải mắc lỗi. Đó là chuyện quá hiển nhiên, và phần mềm phải được thiết kế để đảm đương lỗi từ phía người dùng, và cả lỗi phát sinh do bản thân ứng dụng nữa. Thực chất điều cốt lõi ở đây đó là phải loại bỏ lỗi từ gốc và không cho nó xảy ra. Nhưng không thứ gì là hoàn hảo, do đó, khi gặp lỗi thì lập trình viên sẽ phải cung cấp cho người dùng một thông báo hợp lý, ít nhất cũng phải chỉ dẫn cho người dùng nên làm gì để khắc phục lỗi, hoặc thông báo rằng lỗi đó là gì. Nếu được, nên kèm theo là một cách phục hồi hiệu quả để người dùng thoát khỏi lỗi đó.
Ví dụ 1: bạn vừa soạn xong bài báo cáo 50 trang trong Word, bỗng nhiên máy tính bị điên, Word bị đóng, thế là bạn mất hết bài viết dài vì chưa kịp lưu. May mắn là Microsoft có tích hợp tính năng AutoSave và khả năng tự khôi phục nên bạn có thể cứu được nội dung của mình.
Ví dụ 2: người dùng nhập liệu sai, ô số điện thoại thì chỉ được nhập số nhưng họ nhập vào cả chữ cái nữa. Lúc đó thông báo hiện ra nên là “Bạn chỉ được nhập số, hãy thực hiện lại nhé!”. Nếu chỉ có thông báo “Sai rồi!” thì người dùng chẳng thể biết họ sai cái gì và nên làm thế nào cho đúng.
Ví dụ 3: khi bạn đang download một tập tin 50GB, khi tải được 99% thì bạn lỡ nhấn nút đóng cửa sổ trình duyệt. Nếu đóng luôn, bạn sẽ mất hết dữ liệu đã tải. Nhưng may mắn là các hãng trình duyệt đều tích hợp một hộp thoại thông báo rằng “bạn đang download file, đóng trình duyệt là sẽ mất đi đó. Có đồng ý hay không”. Lúc này, nếu bạn chỉ nhấn nhầm vào nút đóng thì có nhấn nút Hủy để quay lại.
9. Chuẩn hóa khi cần thiết
Có những thứ mà người ta thường làm rất lộn xộn và không theo quy tác nào cả. Nếu cứ mỗi một phần mềm, một giao diện ứng dụng một kiểu thì người dùng sẽ rất rối. Đây là lúc chúng ta cần một chuẩn chung để tạo ra sự thống nhất cao đó. Chẳng hạn như với Windows, ở thanh menu của bất kì một ứng dụng nào đó thì nút đầu tiên sẽ là File, cuối cùng là Help. Trên máy Mac của Apple cũng y như thế. Hay như trên Android, Google đưa ra một chủ đề gọi là “Holo” với hai màu đen và xanh dương đặc trưng để lập trình viên áp dụng thiết kế này cho app của mình.
RGB.vn / Theo Duy Luân – TinhTe
Ảnh đầu bài: Timothy Long
Nhập hội Sáng tạo cùng RGB nha!