Trang chủ > Uncategorized > UX cho người không chuyên

UX cho người không chuyên

Tôi thấy UX là một vấn đề vừa bị xem nhẹ vừa bị thổi phồng. Xem nhẹ ở chỗ dường như ai cũng hiểu và lí luận về UX mà không cần tham khảo ý kiến xung quanh, ngay cả khi chưa từng biết hay tìm hiểu về những kiến thức liên quan. Thổi phồng là ở chỗ người ta quá coi trọng nó, chăm chút nó, tới nỗi tiêu tốn một phần không nhỏ thời gian cho những cuộc họp dài lê thê hay sửa đi sửa lại một chức năng nhỏ. Nếu dự án thiếu đi một người thực sự giỏi về UX để cầm trịch, thì những điều nói trên sẽ càng trầm trọng và đe dọa sự thành công của phần mềm.

Như vậy nên làm thế nào nhỉ? Tôi không biết, vì những gì tôi gặp phải chỉ là những kinh nghiệm rời rạc trong từng tình huống cụ thể, chưa đủ để tạo thành một tư tưởng gì đó thật đúng đắn. Bạn mà làm lập trình viên thì bạn cũng sẽ phải làm đi làm lại một chức năng cho UX nó tốt hơn thôi. Tuy nhiên, dưới con mắt lập trình viên, tôi nghĩ rằng với những nhóm nhỏ không chuyên về UX, thì điều quan trọng là làm cho phần mềm ổn định, logic, và linh động (hay nói cách khác là dẹp UX qua một bên).

Để có UX tốt thì trước hết phải chạy được đã, tức là phần mềm phải ổn định. Để phần mềm ổn định thì nhất định không được làm những thứ quá khó, đặc biệt là những thành phần trên giao diện web trong thời đại mà JavaScript là tất cả. Tôi biết là lập trình viên ham thử thách, và không có gì là không thể khi ta quyết tâm, v.v nhưng mà đôi khi phải nhìn nhận thực tế là chúng ta không đủ trình độ để làm mọi thứ, và nhìn ra thứ gì khó làm, không làm được, hoặc dễ gây lỗi cũng là một cách thể hiện trình độ. Với người viết yêu cầu cho phần mềm, cần nhìn ra bản chất của một yêu cầu để tìm ra cách thể hiện phù hợp và khả thi, nhất là tránh bị cuốn vào những hành vi tủn mủn trên giao diện mà quên mất chính flow bên dưới mới là thứ quyết định UX tốt hay không.

(Đấy là chưa kể thời gian cho việc phát triển một phần mềm luôn là có hạn, cho nên hệ quả là thời gian cho nhiều thứ quan trọng không kém như kiến trúc, unit test, build, deploy, v.v sẽ bị ăn bớt. Kiến trúc là thứ cần ổn định, mà một khi phần mềm đã cho dùng đại trà thì việc thay đổi nó sẽ khó khăn hơn. Còn yêu cầu về chức năng, UX, v.v thì luôn cần thử nghiệm và đổi mới, cho nên sẽ không hợp lí nếu tập trung công sức và thời gian vào nó trong giai đoạn đầu.)

(Nhưng ổn định không phải là không có gì. Bạn có nhận thấy vào buổi đầu của những ứng dụng web, người ta cố gắng nhái theo những phần mềm trên desktop, điển hình là các web mail. Kết quả là chúng ta có những ứng dụng đầy đủ chức năng, nhưng cồng kềnh, chậm chạp, nhiều lỗi. Về sau này, người ta lại có xu hướng tạo ra những ứng dụng cực kì đơn giản, rồi bổ sung dần tính năng song song với việc đảm bảo tính ổn định. Mọi chức năng đều cần được đưa vào đúng thời điểm.)

Nếu chúng ta không đủ trình độ hay dữ kiện để hiểu được người dùng mong đợi gì, thì hãy cố gắng làm do mọi chức năng logic nhất có thể. Việc không làm người dùng bất ngờ thì sách báo hay nói rồi, tôi cũng không dám ý kiến gì nhiều. Nhưng ít nhất yêu cầu chức năng không được làm lập trình viên bất ngờ. Tính logic sẽ giúp lập trình viên giữ code "ngăn nắp" và ít lỗi. Không nên để lập trình viên phải xoay sở với những sơ đồ trạng thái lòng vòng đầy những kịch bản tủn mủn và khó xảy ra. Chẳng hạn, những thứ mà lập trình viên có thể đoán đúng mà chưa cần đọc yêu cầu, hay người kiểm tra có thể nhớ được dễ dàng thì thường có logic tốt.

(Tôi định viết một vài ví dụ trong dự án tôi làm, nhưng có vẻ dài dòng không cần thiết. Có vẻ các dự án mới thường hay có xu hướng phức tạp hóa mọi flow vì sợ người dùng không hiểu, người dùng "ngu si", v.v. Cho nên người ta hay bỏ thời gian vào việc suy đoán và lựa chọn giùm đường đi cho người dùng, chặn cái này cái kia, thậm chí tìm cách bỏ bớt các thông báo cần thiết. Khi đã cho dùng thử và bắt đầu cảm thấy tự tin thì họ lại bắt đầu đơn giản hóa nhiều thứ. Tuy không có thẩm quyền can thiệp vào chuyện này,  lập trình viên nên sẵn sàng cho những thay đổi tới lui như vậy.)

Có một cách giúp phần mềm ổn định và logic là xây dựng một hệ thống tổng quát cho mọi tình huống, linh động, để người dùng muốn làm gì thì làm. Thay vì bắt người dùng hạnh phúc theo một cách nào đó, thì tốt nhất để họ tự "mưu cầu hạnh phúc". Chẳng hạn, chúng ta có custom fields hay custom flows trong các phần mềm như Jira, tùy chọn màu trong những phần mềm của Microsoft, add on trong các trình duyệt. Bên cạnh đó, undo (như trong Remember the milk) là một công cụ tuyệt vời để người dùng có thể yên tâm khám phá. Tất nhiên, nhìn ra những điều như vậy trong những ngày đầu xây dựng một phần mềm thực sự không dễ. Thường thì những ý tưởng khái quát sẽ nằm sau những giới hạn bí ẩn, không rõ lí do kiểu như người dùng chỉ được tạo một cái gì đó, liên kết một đối tượng kiểu này với đối tượng kiểu khác, không được nhập quá bao nhiêu đó thông tin. Cả người viết yêu cầu và lập trình viên phải nhìn ra các giới hạn ẩn trong yêu cầu của phần mềm để tìm kiếm những bản chất và khái niệm khái quát hơn đằng sau những yêu cầu đó.

(Tôi có nhớ đã đọc ở ít nhất một cuốn sách toán là khi không thể tìm lời giải cho một bài toán, hãy tìm lời giải cho bài toán tổng quát của nó. Nếu bạn vẫn nhớ những bài toán phổ thông thì sẽ thấy sự khái quát trước hết đến từ việc loại bỏ đi những giới hạn cụ thể, chẳng hạn từ (x+1)2 >= 4x ta có (x+y)2 >= 4xy, rồi (x+y)n >= (tôi quên rồi), hay (x1+…+xn)2 >= (tôi cũng quên rồi). Dĩ nhiên là đi xa hơn để nhìn ra giới hạn từ số n (lũy thừa n), hay phép cộng (+) thì phức tạp hơn từ 2 (bình phương), và cần những bộ óc siêu việt hơn.)

Cuối cùng, phải nhắc lại là UX là một thứ rất khó, và quyết định nhầm là chuyện hoàn toàn có thể xảy ra. Nhiệm vụ của lập trình viên là lập trình và lập trình thật tốt, vì vậy trong bất cứ tình huống nào, cũng cần đảm bảo phần mềm ở trong trạng thái vận hành được, và việc thay đổi yêu cầu chức năng, dù nhỏ hay lớn, đều có thể thực hiên trong một khoảng thời gian xác định được, và sẽ không làm mất đi khả năng vận hành của phần mềm.

  1. Chưa có phản hồi.
  1. No trackbacks yet.

Gửi phản hồi

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s

%d bloggers like this: