Có một quan niệm chung giữa nhiều người dùng và khách hàng doanh nghiệp rằng khi nó trông hoàn chỉnh, nó gần như hoàn tất. Như bạn có thể biết, điều này là xa sự thật. Người ta có thể có nó trông đẹp, nhưng không có phụ trợ và một số người dùng nghĩ rằng làm cho nó trông đẹp là 80% công việc chứ không phải 20% ( hoặc 80% còn lại ).
Vô số nhà phát triển có thể kể những câu chuyện rùng rợn về điều này - nhận được một loạt các trang được thực hiện trong Microsoft Word bằng cách sử dụng ảnh chụp màn hình của một số công cụ khác và khách hàng nói rằng "vậy, bạn gần như đã hoàn thành chưa?"
Bạn cần phải tăng tốc để tất cả các phần được thực hiện khi nó được thực hiện. Cố gắng thực hiện tất cả các phụ trợ trước và sau đó tất cả các giao diện người dùng sẽ dẫn đến người dùng cuối nghĩ rằng bạn không làm gì cả và hỏi tại sao bạn được trả tiền khi không có gì để hiển thị cho nó. Mặt khác, giao diện người dùng trước và bạn sẽ thấy người dùng cuối thực hiện các thay đổi gây cười và tiêu tốn toàn bộ thời gian của chúng tôi.
Trường hợp xấu nhất với 'cái đầu tiên và cái kia' là khi bạn đến phần khác, bạn thấy rằng nó hoàn toàn không phù hợp với thiết kế.
Do đó, xây dựng cả hai. Hiển thị tiến trình ở mặt trước, làm cho mặt sau hoạt động với những gì bạn đang xây dựng. Trong nhiều trường hợp, một ý tưởng tốt là cung cấp các bản dựng gia tăng và đảm bảo bạn đang thực hiện những gì khách hàng muốn (điều này được đưa vào Agile). Đi quá lâu với 'những tiến bộ có thể nhìn thấy' có thể làm tổn thương mối quan hệ khách hàng (điều này là cho cả hai trường hợp 'mọi thứ đều được thực hiện sớm' và 'không có gì được thực hiện cho đến khi kết thúc' - thật khó để khách hàng thấy khung được viết hoặc các bài kiểm tra đơn vị hoặc vệ sinh dữ liệu theo tiến độ).
Joel đã viết về điều này trong The Iceberg Secret, tiết lộ :
Hệ quả quan trọng Hai. Nếu bạn hiển thị một người không lập trình màn hình có giao diện người dùng đẹp 100%, họ sẽ nghĩ rằng chương trình gần như đã hoàn tất.
Những người không lập trình viên chỉ nhìn vào màn hình và thấy một số pixel. Và nếu các pixel trông giống như chúng tạo ra một chương trình làm một cái gì đó, chúng nghĩ rằng "ồ, trời ơi, nó có thể khó hơn bao nhiêu để làm cho nó thực sự hoạt động?"
Rủi ro lớn ở đây là nếu bạn giả lập UI trước, có lẽ để bạn có thể có một số cuộc trò chuyện với khách hàng, thì mọi người sẽ nghĩ bạn sắp hoàn thành. Và sau đó khi bạn dành năm tới để làm việc "dưới vỏ bọc", có thể nói, không ai sẽ thực sự thấy những gì bạn đang làm và họ sẽ không nghĩ gì cả.
Điều này một lần nữa được nhắc lại trong bài đăng trên blog Đừng làm cho bản Demo trông Xong có biểu đồ hữu ích này:
Lưu ý ở đây, hai tùy chọn thường phản ánh 'hoàn thành ui' (và sau đó kỳ vọng là bạn sẽ hoàn thành sớm) và 'hoàn thành phần phụ trợ' (và sau đó khách hàng lo lắng về việc bạn bỏ lỡ thời hạn).
Làm thế nào 'hoàn thành' một cái gì đó trông phù hợp với cách 'hoàn thành' một cái gì đó là.
Mỗi nhà phát triển phần mềm đã trải nghiệm điều này nhiều lần trong sự nghiệp của họ. Nhưng các công cụ xuất bản trên máy tính để bàn dẫn đến sự đau đầu tương tự đối với các nhà văn công nghệ - nếu bạn đưa cho ai đó một bản nháp thô được phông chữ và định dạng hoàn hảo, họ sẽ thấy nó được thực hiện nhiều hơn bạn muốn. Chúng ta cần một trận đấu giữa nơi chúng ta đang ở và nơi người khác cảm nhận chúng ta.
Bài viết này cũng đưa ra một điểm quan trọng về loại phản hồi bạn nhận được với các mức độ khác nhau của giao diện người dùng. Nếu bạn có một cái gì đó có vẻ hoàn chỉnh, bạn có nhiều khả năng nhận được phản hồi về "bạn có thể thay đổi phông chữ" hơn "bố cục này không hoạt động - có quá nhiều tab."
Đối với những người đang chiến đấu với điều này trong thế giới Java Swing, có một giao diện được gọi là Napkin khiến cho giao diện người dùng trông không hoàn chỉnh (ngay cả khi nó là).
Chìa khóa ở đây là làm cho nó trông không hoàn thành. Giao diện người dùng hoàn chỉnh là một tín hiệu cho nhiều người dùng doanh nghiệp rằng ứng dụng đã hoàn tất (ngay cả khi chỉ là một vài trang tĩnh mà không có logic nào đằng sau nó hoặc một cái gì đó được xây dựng trong trình xây dựng giao diện).
Đọc thêm (và các liên kết từ bài viết):
