Blog thiết kế in ấn

Tìm hiểu về User Interface

Giao diện người sử dụng – User Interface (UI) là một khái niệm không mấy xa lạ với những nhà thiết kế chuyên nghiệp. Bạn có thể tham khảo về khái niệm UI của thiết kế trong bài này.

Tài liệu này là một nguyên tắc cơ bản về UI được rút ra từ những cuốn sách khác nhau về thiết kế UI, và cả kinh nghiệm của tôi. Hầu hết các nguyên tắc này đều có thể được áp dụng cho các thiết kế đồ họa hay lập trình phần mềm.

Tôi hoan nghênh các bạn bổ xung và thay đổi nếu bạn có ý kiến của riêng mình. Chúng như một tài liệu mở để cùng phát triển.

User Interface là một khái niệm để nói tới nơi mà con người và máy móc cùng làm việc với nhau. Với sự ra đời của máy tính, UI có thể coi là những gì chúng ta nhìn thấy trên màn hình và tương tác với máy tính thông qua những câu lệnh được mã hóa.

Đối với lĩnh vực thiết kế, UI có thể coi là những tác phẩm mà các nhà thiết kế thông qua đó truyền tải thông điệp tới người sử dụng. Mỗi người thiết kế như những nhà lập trình phải tìm mọi cách để bất cứ ai cũng có thể hiểu và sử dụng được sản phẩm của mình.

1. Nguyên tắc của người dùng

Biết người nào sẽ sử dụng sản phẩm của bạn

Trước khi chúng ta có thể trả lời câu hỏi “Làm thế nào để có thể có một UI tốt hơn”?, đầu tiên, chúng ta phải trả lời câu hỏi: Tốt hơn cho ai?

Một thiết kế tốt hơn cho một người dùng có kinh nghiệm sử dụng hay một người dùng chưa biết gì hoặc biết rất ít về việc sử dụng sản phẩm đó, hoặc độ tuổi người sử dụng.

Một cách giải quyết vấn đề này là tạo ra các mô hình người dùng khác nhau. Có một tài liệu xuất sắc dựa trên quá trình Brainstorming để tạo ra một “tư liệu” về người dùng. Kết quả của quá trình này là mô tả chi tiết của một hoặc hơn những người sử dụng “trung bình” với những chi tiết đặc biệt như:

  • Mục đích của người sử dụng là gì?
  • Kỹ năng, kinh nghiệm của người sử dụng?
  • Người dùng cần điều gì?

Dựa trên những thông tin này, chúng ta sau đó có thể tiến hành những câu hỏi: Làm thế nào chúng ta tận dụng thế mạnh của người dùng và tạo một giao diện giúp họ đạt được mục đích của mình?

Trong trường hợp một phần mềm cho nhiều người sử dụng, chẳng hạn như một hệ thống mở, sẽ có rất nhiều loại người sử dụng. Trong trường hợp này có thể hữu ích hơn nếu có một danh sách phân loại người dùng, chẳng hạn như “có tay nghề cao so với không có tay nghề”, “trẻ tuổi với không trẻ tuổi”,..v.v

Hoặc một số phương tiện đặc biệt khác nhằm sưu tầm đủ các trường hợp của người sử dụng.

Một cách khác để trả lời câu hỏi này là nói chuyện với một số người dùng thực sự. Liên hệ trực tiếp giữa người dùng cuối (end user) và các nhà thiết kế thường làm biến đổi quá trình phát triển sản phẩm.

2. Nguyên tắc của phép ẩn dụ.

Mượn từ các hành vi quen thuộc của người sử dụng.

Có nhiều yếu tố để xem xét khi sử dụng một phép ẩn dụ. Một khi ẩn dụ được chọn, nó phải lan truyền rộng rãi, thay vì sử dụng một lần tại một điểm cụ thể. Thậm chí tốt hơn là sử dụng cùng một phép ẩn dụ trong nhiều thiết kế.

Đừng mất thời gian suy nghĩ về một phép ẩn dụ mà chỉ dùng một lần. Một thiết kế có thể kết hợp các phép ẩn dụ khác nhau, miễn là chúng không xung đột lẫn nhau.

Một phép ẩn dụ thường có rủi ro nhất định. Trong đó, bất cứ khi nào các đối tượng được thể hiện trên màn hình, chúng ta đạt được cả những khía cạnh có lợi và khía cạnh bất lợi.

Cần biết rằng một số ẩn dụ có những rào cản về văn hóa. Có thể người Việt Nam quen với cách nói này còn người nước ngoài lại khác.

3. Các nguyên tắc tiếp xúc với tính năng

Hãy để cho người sử dụng thấy rõ ràng những thông điệp có sẵn.

Các nhà thiết kế thường dành cho người dùng một chút động não về các thiết kế của họ. Nhưng không phải ai cũng thích “động não”, thay vào đó họ muốn thấy các ý nghĩa ngay lập tức, thay vì phải suy nghĩ về chiều sâu của thiết kế.

Có hai loại cá tính “Trực quan” và “Cảm quan”, tất cả đều thông minh, nhưng lại tập trung vào những khía cạnh khác nhau của cuộc sống. Cần lưu ý rằng “Cảm quan” thường nhiều hơn “trực quan” với tỉ lệ 3-1.

“Trực quan” thích giao diện tập trung các mô hình trừu tượng, liên tưởng, ẩn dụ, v.v. Trong khi “Cảm quan” lại thích những giao diện được tận dụng khả năng năng nhận thức của họ – nói cách khác họ thích giao diện với các tính năng được đưa lên ngay vị trí dễ thấy nhất, thông điệp chỉ cần nhìn một lần là hiểu…

Điều này không có nghĩa bạn phải làm cho mọi thứ ngay lập tức dễ hiểu. Nhưng nó có nghĩa là cho thiết kế dễ dàng khám phá để có thể nhận biết nhanh chóng và tập trung vào điều thiết kế đó thật sự cần nói.

Tất nhiên có những trường hợp bạn không muốn để lộ một tính năng/chức năng ngay lập tức, bởi vì bạn không muốn “áp đảo” người sử dụng bởi quá nhiều chi tiết.

Trong trường hợp này, cách tốt nhất là cấu trúc các ứng dụng như các lớp của củ hành tây, có thể thấy lớp sau bằng cách tách lớp trước, lấy ví dụ như menu thả của website, mỗi lần rê chuột là một lớp liên kết mới.

Có nhiều cấp độ khác nhau của việc ẩn đi. Đây là một phần danh sách của thứ tự từ việc dễ thấy nhất, cho tới ít dễ thấy nhất.

  • Hoàn toàn thấy được.
  • Thấy được thông qua kinh nghiệm.
  • Thấy được khi liên tưởng một việc liên quan.
  • Thấy được bằng hành động.

Mặc dù vậy tất cả các thiết kế cần cố gắng đạt tới khái niệm đơn giản hóa và càng giúp người sử dụng tập trung vào tính năng chính của thiết kế càng tốt.

4. Các nguyên tắc của sự gắn kết

Các đối tượng nên được sử dụng nhất quán.

Có một số lập luận về việc các thiết kế/giao diện có cần phải cố gắng “trực quan” và khiến người xem phải tư duy. Tuy nhiên nó chắc chắn phải có sự thống nhất – gắn kết với nhau (chính xác với những thiết kế tạp trí hay trang web nên làm).

Nhất quán nội bộ có nghĩa là khiến người xem có thể “cảm giác” khi xem các phần khác nhau của một thiết kế. Ví dụ bạn dùng phông kích thước 25pt Time Roman cho tiêu đề, thì chỉ cần nhìn thoáng qua phông chữ kích thước vậy, người dùng có thể “cảm thấy” nó là tiêu đề.

Nhà thiết kế nên hướng tới nguyên tắc “ít bất ngờ nhất” trong một thiết kế, đặc biệt với các thiết kế có tính ứng dụng cao.

Nhất quán bên ngoài, nghĩa là thiết kế phù hợp với môi trường, con người sử dụng nó. Nó bao gồm việc sử dụng nền tảng nào, độ tuổi nào, thu nhập ra sao, làm gì, từ đâu tới .v.v.

5. Các nguyên tắc trực quan của từng môi trường

Thay đổi trong từng môi trường cần được phản ánh khi nó xuất hiện.

Mỗi thay đổi người sử dụng cần thay đổi tương ứng với giao diện. Có rất nhiều lời chỉ trích khi có những giao diện không thể phân biệt vùng miền sử dụng.

Tương tự như vậy, khi một thiết kế nếu thay đổi giao diện cần phải đáp ứng được các yêu cầu về UI của thiết kế cũ. Sẽ không có lý do rõ ràng nếu việc thay đổi diện mạo khiến người sử dụng cảm thấy xa lạ với thói quen sử dụng.

6. Nguyên tắc ngắn gọn

Nó cung cấp sự tập trung và ý nghĩa trừu tượng của thiết kế

Một khi người dùng đã quen với thiết kế, quen với việc sử dụng, thì việc còn lại là xây dựng một mô hình kinh nghiệm của thiết kế. Người dùng có thể phán đoán với độ chính xác cao trong bối cảnh cụ thể.

Ở thời điểm này các thiết kế có thể phá vỡ những chỉ dẫn phức tạp thành các bước đơn giản. Để làm điều này bạn cần chắc chắn người dùng đã nắm rõ thói quen sử dụng sản phẩm.

Ví dụ với một chiếc ghế có thể nâng lên hạ xuống, người dùng có thói quen cúi xuống dưới tìm chỗ điều chỉnh, trước đây nhà thiết kế phải để một cần gạt thò hẳn ra ngoài, thì nay họ có thể giấu nó gọn gàng dưới ghế bằng một nút bấm nhỏ chẳng hạn.

Tất cả phải đạt được khái niệm tốc độ nhưng phải “dễ hiểu”.

7. Nguyên tắc tập trung

Một số khía cạnh của UI thu hút người sử dụng hơn là những cái khác.

Mắt người là một thiết bị phi tuyến tính. Ví dụ nó có thể thấy Mach bans – là một ảo giác quang học, xuất hiện tại hai khu vực mà màu sắc tiếp xúc. Xem thêm tại đây). Nó cũng phát hiện được các vật chuyển động.

Chúng ta thường bị thu hút bởi các khu vực chuyển động hơn là các khu vực tĩnh. Những thay đổi tại khu vực động sẽ được phát hiện dễ dàng. Các con trỏ văn bản là một ví dụ của một đối tượng hấp dẫn mắt. Thay đổi hình ảnh của nó có thể là những báo hiệu thay đổi trạng thái khác nhau và hữu ích.

8. Nguyên tắc ngữ pháp

Một UI là một loại ngôn ngữ của người dùng.

Nhiều hoạt động trong một giao diện người dùng đòi hỏi cả một ‘chủ đề’ (đối tượng trên cùng) và một ‘động từ’ (hoạt động của đối tượng). Điều này cho thấy rằng các hành động tự nhiên trong giao diện người dùng tạo thành một loại ngữ pháp.

Các ẩn dụ ngữ pháp có thể được mở rộng nhiều hơn một chút, trong một số chương trình có thể dễ dàng nhận biết ‘trạng từ, tính từ …’.

Hai ngữ pháp phổ biến nhất được biết tới là “Action->Object” và “Object-Action“. Trong Action-Object các hoạt động (hoặc công cụ) là lựa chọn đầu tiên. Khi một đối tượng tiếp theo được chọn, công cụ này ngay lập tức hoạt động theo đối tượng.

Việc lựa chọn các công cụ này vẫn xảy ra từ một trong những hành động tiếp theo, dó đó nhiều đối tượng có thể được vận hành bởi từng lần chọn mà không cần chọn lại công cụ.

Action-Object còn được biết tới như “phương thức – modality” bởi việc lựa chọn là một “chế độ – mode” thay đổi hoạt động chương trình. Ví dụ cho kiểu này là phần mềm Illustrator, bạn có thể vẽ 1 nét, sau đó lựa chọn độ lớn nhỏ của nét mà không cần chọn lại.

Trong trường hợp Object-Action, đối tượng được chọn đầu tiên và còn tồn tại từ lần hoạt động tiếp theo. Hành động cá nhân được chọn sau đó hoạt động trên đối tượng đã chọn. Phương pháp này dễ thấy trong xử lý văn bản – đầu tiên kiểu chữ được chọn, sau đó người dùng chọn kiểu italic, bold,..

Object-Action còn được gọi là “không phương thức – non-modal” bởi vì những hành vi có thể được áp dụng cho các đối tượng có sẵn. Một kiểu đầy hiệu quả của Object-Action được gọi là “thao tác trực tiếp”, nơi mà bản thân mỗi đối tượng chính là một công cụ – ví dụ như kéo một đối tượng tới vị trí mới và thay đổi kích thước.

“Phương thức – Action Object” bị chỉ trích khá nhiều trong UI vì chương trình được đề cao và có giao diện xấu xí. Còn “Không phương thức – Objec-Action) được sử dụng rộng rãi, cho dù một số tính huống trong cuộc sống lựa chọn rõ ràng là “Phương thức”.

Ví dụ trong nghề mộc, hiệu quả tốt hơn khi đóng cùng lúc nhiều chiếc đinh hơn là đặt búa xuống, rồi cầm thước, vẽ vị trí đinh kế tiếp, chay đi kiếm vít…

9. Các nguyên tắc Help – Trợ giúp

Hiểu được các Trợ giúp mà người dùng cần.

  • 1. Định hướng mục tiêu “Tôi có thể làm gì với chương trình này?”
  • 2. Mô tả “Cái này là gì? Thế nào? Làm sao?”
  • 3. Thủ tục “Làm thế nào để tôi làm điều này”
  • 4. Diễn giải “Tại sao điều này xảy ra”
  • 5. Định hướng “Tôi đang ở đâu?”

Đối với thiết kế đồ họa, mỗi sản phẩm cần ẩn chứa trong đó sự “trợ giúp” người dùng cần dễ dàng nhận biết họ đang có sản phẩm gì, để làm gì, sử dụng thế nào, và phù hợp với văn hóa của họ.

10. Nguyên tắc về an toàn

Hãy để cho người dùng tự tin bằng cách tạo dựng một hệ thống an toàn

Ted Nelson từng nói “Sử dụng DOS giống như tung hứng với dao cạo, còn sử dụng Mac giống tung hứng một Pin bowling – thanh gỗ phải ném đổ trong bowling)”.

Trong mỗi người có một số lượng các rủi ro, và có tối thiểu và tối đa rủi ro mà họ cảm thấy thoái mái. Nếu người dùng thấy quá nguy hiểm, họ sẽ tìm cách giảm nguy cơ đó. Ngược lại nếu quá an toàn – nói cách khác nguy cơ giảm xuống ngưỡng tối thiểu – họ lại tham gia các hành động để tăng nó lên.

Trong thiết kế có thể coi điều này là sự xác định nhận thức của khác hàng, nếu cung cấp một thiết kế vượt ra khỏi nhận định thẩm mỹ của họ, họ sẽ cảm thấy không tin tưởng, và họ cũng không tin tưởng nếu thấy một thiết kế theo họ quá tệ. Nó phải nằm trong mức độ nhận thức của họ.

Nhiều người cho rằng, những người dùng mới không chỉ kém về kỹ năng, mà còn cả trí tuệ. Nhưng đó là vấn đề chúng ta (những người chuyên môn) phải giải quyết để bất cứ người dùng nào cũng cảm thấy họ đang ở trong mức độ an toàn. Những hộp thoại “Are you sure – Bạn có chắc?” là một thao tác quan trọng cho người dùng.

Cuối cùng cần lưu ý rằng nhiều điều trong cuộc sống không thể đạt được dễ dàng. Thực hành là “no pain, no gain – không đau – không đạt”, nếu một cuộc thi chạy ai cũng về nhất thì không còn là cuộc thi.

Điều này đặc biệt thích hợp với thiết kế giao diện Game, các nguyên tắc giao diện cho Game có thể hơi khác với nhưng nguyên tác dành cho người sử dụng máy tính thông thường.

11. Các nguyên tắc ngữ cảnh

Hạn chế hoạt động của người dùng với một bối cảnh được  xác định, trừ khi có một lý do chính đáng để không làm điều đó.

Mỗi hành động người dùng diễn ra trong một bối cảnh cụ thể – những tài liệu hiện thời, lựa chọn hiện tại, hộp thoại hiện hành. Một tập hợp các hoạt động là hợp lệ trong một bối cảnh có thể không phù hợp trong bối cảnh khác.

Ngay cả trong một tài liệu đơn, có thể có nhiều cấp độ – ví dụ, trong một phần mềm vẽ, lựa chọn một đối tượng Text (Có thể di chuyển hay thay đổi kích thước) nó thường được coi là một trạng thái khác nhau từ việc chọn từng ký tự riêng lẻ trong đối tượng text đó.

Ý tưởng là tốt khi tránh pha trộn các cấp độ này. Ví dụ, hãy tưởng tượng một ứng dụng cho phép người dùng lựa chọn một loạt các ký tự văn bản trong một tài liệu, và cũng cho phép họ chọn một hoặc nhiều hơn toàn bộ tài liệu (cái sau là một khái niệm lựa chọn khác biệt với lựa chọn tất cả các ký tự trong một tài liệu).

Trong trường hợp như vậy, đây có thể là tốt nhất nếu chương trình không cho phép lựa chọn cả ký tự lẫn tài liệu trong cùng một lựa chọn. Một cách kín đáo để làm điều này là lựa chọn “mờ” khi mà trong bối cảnh này điều đó không được thực hiện.

Trong ví dụ trên, nếu người dùng có một loạt các văn bản được chọn, và sau đó lựa chọn một tài liệu, phạm vi các phần được chọn bị mờ đi, chỉ ra rằng lựa chọn không thích hợp. Các giải pháp lựa chọn chính xác nhất tất nhiên sẽ phụ thuộc và bản chất của các ứng dụng và mối quan hệ giữa các ngữ cảnh.

Một điều cần lưu ý là mối quan hệ giữa các ngữ cảnh. Ví dụ, có những trường hợp mà người dùng đang làm việc trong một không gian cụ thể, đột nhiên một hộp thoại bật lên hỏi về việc xác nhận một hành động.

Sự thay đổi đột ngột của bối cảnh có thể khiến người sử dụng tự hỏi bối cảnh mới liên quan gì tới bối cảnh cũ. Sự hỗn loạn này là trầm trọng do tính ngắn gọn của kiểu viết được phổ biến trong các phần mềm.

Tốt hơn hơn là “Bạn có chắc” là một cái gì đó như “Có hai tài liệu chưa được lưu. Bạn có muốn thoát tất cả?” sẽ giúp người dùng tập trung vào bối cảnh hiện tại của họ.

12 Quy tắc của thẩm mỹ

Tạo một chương trình đẹp mắt

Không nhất thiết mỗi chương trình là một tác phẩm nghệ thuật. Nhưng nó tốt hơn là một cái gì đó xấu xí. Có rất nhiều quy tắc của thiết kế đồ họa có thể học dễ dàng.

Một nguyên tắc được họa sĩ và nhà viết tiểu thuyết viễn tưởng William Rotsler khuyên: “Đừng làm cái gì mà mọi người nghĩ đó nó giống như một sai lầm”.

Một lĩnh vực có vẻ ít liên quan tới thẩm mỹ nhưng quan trọng đó là thời gian. Người dùng không thích các chương trình, các trang web chậm chạp. Hãy sử dụng các thủ thuật tốt nhất để làm tất cả chạy nhanh hơn.

13 Nguyên tắc thử nghiệm người dùng

Kêu gọi giúp đỡ từ những người khác để khắc phục những sai sót trong thiết kế của bạn.

Trong nhiều trường hợp, một nhà thiết kế tốt có thể phát hiện các khiếm khuyết cơ bản trong một giao diện UI. Tuy nhiên, có những loại khiếm khuyết khó phát hiện, và trong thực tế một nhà thiết kế hóa ra có thể bỏ qua những lỗi hơn mà nhiều người bình thường có thể phát hiện.

Trong những trường hợp khác lỗi chỉ xảy ra khi người sử dụng chương trình.

Thử nghiệm đối với người dùng chính là đề nghị chạy thử chương trình với người dùng cuối là một phương pháp hiệu quả để phát hiện lỗi thiết kế. Tuy nhiên cũng có vài kỹ thuật cụ thể để tối đa hóa thử nghiệm với end user.

  • Thiết lập quan sát. Tạo những nhiệm vụ thực tế cho người dùng, sau đó đề nghị những end user có cùng kinh nghiệm sử dụng, sử dụng sản phẩm (tránh những người đã quen thuộc với sản phẩm của mình).
  • Mô tả cho người dùng về công việc. Hãy họ biết rằng bạn đang kiểm tra các sản phẩm. Hãy nói với họ nếu có lỗi, đó không phải của họ, và bạn phải giải quyết nó.
  • Thảo luận về cách sử dụng
  • Đề nghị họ phát biểu bằng lời những gì họ nghĩ về sản phẩm, nhắc nhở nếu họ quên.
  • Giải thích với họ rằng bạn có mặt ở đó không phải để trả lời các câu hỏi của họ. Họ cần hỏi trước khi bắt đầu sử dụng sản phẩm.
  • Mô tả các tính năng và giới thiệu sản phẩm.
  • Kết luận các quan sát. Nói với họ những gì bạn phát hiện, sau đó trả lời các câu hỏi.
  • Sử dụng các kết quả.

Sử dụng người dùng thử nghiệm có thể xảy ra bất cứ thời điểm nào của dự án, tuy nhiên, nó thường hiệu quả để xây dựng một mô hình mẫu và thử nghiệm trước khi xây dựng mô hình thực tết. Dễ dàng hơn để đối phó với một lỗi thiết kế khi phát hiện nó trước đó.

Tognazzini khuyên bạn có không quá ba người cho mỗi thiết kế – nhiều hơn khiến bạn chỉ đơn giản liệt kê các vấn đề đã phát hiện ra.

14. Nguyên tắc của sự khiêm nhường.

Lắng nge những gì người bình thường nói.

Một trong những kiến thức giá trị nhất có thể đạt được là xem những người khác cố gắng sử dụng chương trình của bạn. Những điều khác có thể tới từ việc lắng nghe ý kiến của họ về sản phẩm. Tất nhiên bạn không cần làm chính xác tất cả mọi thứ họ nói.

Điều quan trọng là nhận ra rằng mỗi người, người dùng, người thiết kế đều có phần hình ảnh của riêng mình. Lý tưởng nhất là cần nhiều ý kiến người sử dụng, cộng với hiểu biết của nhà thiết kế, phát triển và làm chúng thanh lịch và thuận lợi. Nó có thể không đáp ứng tất cả, nhưng đáp ứng đúng nhu cầu lớn nhất của số đông.

Mỗi sản phẩm được xây dựng hoàn toàn từ phản hồi của khách hàng là một sản phẩm tầm thường, bởi vì người dùng hầu hết mong muốn những tính năng mà họ không thể đoán trước.

Nhưng chỉ một nhà thiết kế để đánh giá tốt và xấu lại không đủ. Nó chỉ đại diện cho một nhóm nhỏ và không đại diện cho số đông.

Một số điều nhà thiết kế nên giữ trong đầu về người dùng của họ.

  • Hầu hết mọi người có một ý tưởng như là “ai cũng nghĩ thế”, do các mối quan hệ đều tự ta lựa chọn, và chúng ta có xu hướng lựa chọn những người đồng quan điểm.
  • Hầu hết mội người đều có một “sở trường” nào đó, do đó có thể làm tốt trong “sở trường” của họ.
  • Kỹ năng sử dụng máy tính hóa ra khó hơn chúng ta nghĩ.
  • Không sử dụng máy tính không có nghĩa là họ thiếu thông minh. Đơn giản là họ có nhiều thú vui hơn là việc ngồi trước một màn hình và khám phá những hệ thống phức tạp. Phần lớn những người sử dụng thông thạo bắt nguồn từ việc “Chơi” trên máy tính.

Kết luận

Đây là một tài liệu được dịch từ sylvantech.com có từ năm …1998. Các nguyên tắc đều rất cơ bản, nhưng chủ yếu dùng cho thiết kế phần mềm. Khi đọc iDesign nhận thấy có sự tương đồng giữ UI trong thiết kế giao diện phần mềm và UI trong các thiết kế đồ họa.

Ví dụ:  Nguyên tắc Khiêm nhường – có tương đồng với với Nguyên tắc dễ hiểu của Dieter Rams. Rồi Nguyên tắc bối cảnh, nguyên tắc tập trung, nguyên tắc ngắn gọn…

Bạn có thể rút ra những điều bổ ích cho mỗi thiết kế của mình thông qua bài viết về UI này. Vì thiết kế cũng giống như các nhà lập trình, cần đưa tới cho người sử dụng những thiết kế dễ hiểu, truyền tải thông điệp, ấn tượng, thẩm mỹ …

 

2
  Bài viết liên quan
  • No related posts found.