Làm thế nào các lập trình viên có thể cải thiện kỹ năng UX của họ? [đóng cửa]

Là lập trình viên, chúng ta có thể giải quyết các vấn đề rất phức tạp, nhưng sau đó, khi chúng ta phải thiết kế giao diện người dùng, chúng ta có xu hướng thất bại trong việc làm cho chúng dễ sử dụng.

Trong các công ty nhỏ, họ không đủ khả năng để có các nhà thiết kế và chuyên gia UX, các lập trình viên phải làm hầu hết mọi thứ trong phần mềm. Nhưng các giao diện này hiếm khi trực quan ( ví dụ cổ điển ).

Vấn đề là gì? Làm thế nào các nhà phát triển có thể cải thiện kỹ năng của họ trong việc thiết kế trải nghiệm người dùng tốt?

Tôi đã gặp phải vấn đề này nhiều lần trong sự nghiệp - mẹo đầu tiên là phải nhận thức được rằng đó là một vấn đề và thừa nhận nó. Khi bạn đã thực hiện điều đó, việc dừng các giao diện quá phức tạp sẽ dễ dàng hơn.

Giao diện người dùng cũng là một phần của công nghệ phần mềm, nhưng có lẽ đối với nhiều kỹ sư phần mềm không thú vị lắm. Tuy nhiên, có nhiều thử thách thú vị liên quan đến điều này, và chúng có thể thú vị như nhiều thử thách kỹ thuật hơn, theo kinh nghiệm của tôi.

Tính khả dụng, thiết kế trải nghiệm người dùng (UX), tương tác giữa người với máy tính (HCI) - đó không phải là phép thuật và nó là một phần của quy trình phát triển phần mềm.

Mẹo của tôi là:

• thừa nhận hạn chế của bạn
• hỏi và lắng nghe những người tuyên bố biết về những điều này
• khi không chắc chắn, hãy google nó và tìm kiếm câu trả lời có thẩm quyền

Bằng cách tuân theo những nguyên tắc đơn giản này trong nhiều năm qua, tôi thực sự đã tích lũy được thông tin hữu ích về cách xây dựng giao diện người dùng, cách mọi người tương tác với phần mềm và cách họ nghĩ khi họ sử dụng nó. Tôi không có nghĩa là một chuyên gia, nhưng tôi có thể biết một ít hơn chút so với lập trình viên trung bình của bạn.

Tl; dr: HÔN

Đó là sinh học.

• UI và tất cả các nhiệm vụ liên quan đến thiết kế khác liên quan đến não phải .
• Nhiệm vụ lập trình liên quan đến não trái .

Họ có những mục đích khác nhau.

Rất hiếm khi tốt cả hai. Ít nhất là cùng một lúc.

CẬP NHẬT: Gần đây tôi biết rằng có những yếu tố khác như kinh nghiệm. Ngoài một số yếu tố di truyền, bạn phát triển năng lực tinh thần tùy thuộc vào cách bạn được kích hoạt trong thời thơ ấu. Ví dụ, trẻ em bị lạm dụng trung bình sáng tạo hơn nhóm kiểm soát vì chúng học cách ngắt kết nối với thực tế khủng khiếp của chúng trong giấc mơ.

Tôi cho rằng bạn có thể tranh luận về cách các lập trình viên và nhà thiết kế có tư duy khác nhau hoặc tính cách khác nhau, hoặc tranh luận về não trái so với não phải và sáng tạo so với logic, nhưng thực sự, có ba vấn đề cơ bản:

1. Công việc của lập trình viên là phần mềm của họ. Họ quan tâm đến nó; họ dành sự quan tâm của họ cho nó; họ có thể bị kích thích về nó. Công việc của người dùng là một cái gì đó khác ; phần mềm chỉ là một công cụ để tạo điều kiện làm cái gì khác, và họ muốn dành ít thời gian càng tốt chú ý đến nó để họ thay vì có thể tập trung về những gì họ làm chăm sóc về. Miễn là các lập trình viên hiểu sai về điều này, họ sẽ tạo ra sự đánh đổi sai trong thiết kế UI. (Để biết thêm về chủ đề này, hãy xem phần "Kiểm soát môi trường của bạn khiến bạn hạnh phúc" của Joel Spolsky hoặc "Luật cơ bản" của David S. Platt .)
2. Các lập trình viên biết phần mềm của họ một cách thân mật. Họ thoải mái với chi tiết và độ phức tạp của nó; họ hiểu tại sao nó hoạt động theo cách đó bởi vì họ có một mô hình tinh thần hoàn chỉnh về nó. Người dùng không có cơ hội (hoặc quan tâm; xem điểm số 1) để tìm hiểu mọi chi tiết và họ không thể có một mô hình tinh thần hoàn chỉnh vì họ không có quyền truy cập hoặc hiểu mã nguồn. (Để biết thêm về tầm quan trọng của các mô hình tinh thần, có lẽ bạn có thể đọc Thiết kế của mọi thứ hàng ngày của Donand Norman ; mặc dù nó không dành riêng cho máy tính, nhưng đây là một cuốn sách hay về thiết kế giao diện.)
3. Sự đánh đổi của các lập trình viên khác với người dùng. Một lập trình viên có thể dễ dàng quyết định để lại một tính năng quá phức tạp hoặc chỉ bán tự động hoặc ít hơn mức có thể sử dụng được vì đối với lập trình viên, việc giải quyết vấn đề thiếu khả năng sử dụng sẽ dễ dàng hơn so với việc viết mã đúng. Người dùng không quan tâm (bao nhiêu) người lập trình viên phải mất bao nhiêu công sức để viết mã đúng cách và thay vào đó hoàn toàn có thể sử dụng được.

Vấn đề thứ ba có thể được giải quyết bằng cách có đủ kỷ luật để không đi ra ngoài dễ dàng. Tôi không chắc chắn rằng hai vấn đề đầu tiên có thể giải quyết được; bạn càng ở gần công việc của bạn, thì càng khó nhìn nhận nó theo cách mà người ngoài làm. Đó là lý do tại sao kiểm tra khả năng sử dụng - ngay cả những thứ đơn giản, không chính thức như nắm lấy ai đó trong hội trường và ngồi trước ứng dụng của bạn - rất quan trọng.