Nhà phát triển có nên thực hiện mockup UI nếu không có nhà thiết kế trong dự án?

Tôi đang làm việc với một nhóm nhỏ tạo ra một ứng dụng web độc quyền và UX không được ưu tiên nhiều vì người của chúng ta sẽ là những người vận hành nó, nhưng chúng tôi cố gắng làm cho công việc của họ dễ dàng hơn.

Tôi có nên tạo một mockup UI trước khi bắt đầu tạo màn hình mới không? Không có gì quá lạ mắt, chủ yếu là bố cục chung để nói chuyện với các đồng nghiệp và để có một mô hình tham khảo. Tôi đã so sánh nó với việc tạo ra một số sơ đồ UML trước khi đi sâu vào viết mã.

Một trong những đồng nghiệp của tôi nói rằng điều này là vô lý và không phải là công việc của tôi để làm điều đó.

Tôi rất thường xuyên làm việc trong các dự án như vậy, và câu trả lời là CÓ, và càng sớm càng tốt.

Mọi người thấy dễ dàng hơn nhiều để chỉ trích cải thiện một số dự thảo hơn là đưa ra một giải pháp từ đầu. Vì vậy, tôi bắt đầu soạn thảo sớm vì hai lý do:

• Cung cấp cho các chuyên gia vấn đề ấn tượng về cách thông tin có thể được trình bày.
• Cho thấy sự hiểu biết hiện tại của tôi về vấn đề và cấu trúc thông tin.

Trong những trường hợp hiếm hoi, thật tuyệt khi có một số bằng chứng cho thấy tôi đã thực sự giao những gì chúng tôi đã đồng ý ...

Mockup là tuyệt vời và không có lý do gì một nhà phát triển không nên làm chúng. (Nó thậm chí có thể thuận tiện cho một nhà phát triển thực hiện một bản phác thảo sơ bộ về bố cục UI ngay cả khi bạn có các nhà thiết kế UI trong dự án.)

Tôi đánh giá cao bạn không tạo ra các mockup trông giống như màn hình thực tế. Nếu bạn chia sẻ những điều này với người dùng cuối thường tập trung vào những thứ không quan trọng như màu sắc và chủ đề. Những gì tôi khuyên bạn nên làm là tạo ra bàn tay vẽ trên giấy hoặc bảng phác thảo. Hoặc nếu bạn muốn chúng trong máy tính, hãy sử dụng một cái gì đó như Pencil Project hoặc Visio ( đây là một số bút chì Visio từ Jonathan Abbett trông có vẻ như đã rút tiền.)

Chắc chắn rồi.

Đừng để người khác nói cho bạn cách làm công việc của bạn. Và bạn đã đúng, nó rất giống như làm UML cho mô hình dữ liệu của bạn. Giả sử bạn là một nhà phát triển, công việc của bạn là cung cấp phần mềm chất lượng. Nếu mockup giúp bạn làm điều đó, thì đó là một phần công việc của bạn.

Làm các mockup độ trung thực thấp - đừng làm cho chúng trông giống như màn hình thực sự. Bạn sẽ lãng phí quá nhiều thời gian để điều chỉnh phông chữ và pixel và viền và người dùng của bạn sẽ bị ám ảnh bởi những chi tiết như vậy thay vì tập trung vào chức năng. Một cái gì đó như balsamiq là tuyệt vời cho việc này, không có nghi ngờ gì về các công cụ tương tự khác. Với mockup trong tay, việc thảo luận các tính năng của dự án với người dùng của bạn và với các thành viên khác trong nhóm phát triển sẽ trở nên dễ dàng hơn nhiều.

Khi thiết kế "màn hình mới", trước tiên bạn muốn thảo luận về ý tưởng sơ bộ về giao diện người dùng với người dùng và / hoặc đồng nghiệp của bạn. Bạn không thể thảo luận điều này với người dùng "bằng mã" hoặc "trong UML", đơn giản là nó không hoạt động (thậm chí nó sẽ không hoạt động giữa các lập trình viên). Và bạn nên mong đợi rằng bạn cần phải vứt bỏ hai hoặc ba lần tải đầu tiên của mình hoặc ít nhất là sắp xếp lại các thành phần UI một cách nặng nề.

Vì vậy, nếu bạn có một công cụ thiết kế UI đồ họa cho phép bạn thực hiện việc này một cách nhanh chóng, thì thật hợp lý khi sử dụng nó. Tuy nhiên, nếu bạn cần mã hóa các thành phần UI theo cách thủ công và vứt bỏ hoặc sắp xếp lại các thành phần UI mất rất nhiều nỗ lực, thì rõ ràng sẽ không có ý nghĩa hơn khi không "mã hóa" UI trước. Sẽ hiệu quả hơn nhiều khi tạo ra các mockup riêng biệt, bằng cách sử dụng một công cụ vẽ đồ họa, hoặc đơn giản bằng cách sử dụng bút chì và giấy.

Không cần thiết. Có ít nhất hai lý do tại sao mockup có thể ít được sử dụng.

Đầu tiên, nếu có những thực tiễn công nghiệp được thiết lập tốt liên quan đến việc thực hiện những việc bạn sắp làm, bạn có thể tiếp tục và thực hiện chính xác điều đó. Bạn sẽ không thúc đẩy nghệ thuật thiết kế giao diện người dùng, nhưng điều đó cũng tốt.

Thứ hai, người dùng cuối của bạn thường không biết điều gì tốt cho họ và tại sao lại như vậy. Họ chỉ không thể nói cho đến khi họ bắt đầu sử dụng chương trình (với dữ liệu thực tế hoặc giả). Không có số lượng mockup tĩnh sẽ giúp với điều đó.

Với khung web linh hoạt khiêm tốn, đối với "chỉ một màn hình UI khác, như các màn hình N trước đó", bạn có thể bắt đầu với một nguyên mẫu hoạt động và sắp xếp lại khi bạn đi. Thực hiện một mockup và thảo luận với các đồng nghiệp bất cứ khi nào bạn sắp làm một cái gì đó lạ mắt.

LUÔN LUÔN!

Tôi làm việc cho một công ty nhỏ và tôi là người CNTT "Mềm" duy nhất. Tôi làm tất cả các yêu cầu, thiết kế, mã hóa, thử nghiệm (mặc dù ai đó luôn xác nhận thử nghiệm của tôi), thiết kế cơ sở dữ liệu, v.v.

KHÔNG BAO GIỜ CẮT CORNERS TRÊN CÁC BƯỚC THIẾT KẾ - người dùng cuối của bạn sẽ cảm ơn bạn. Bạn cũng sẽ cảm ơn chính mình, vì bạn S end sẽ làm việc lại để làm cho người dùng cuối hài lòng. Ngay cả khi mockup của bạn không có gì khác ngoài một mảnh giấy viết nguệch ngoạc, nó sẽ cho họ một ý tưởng về những gì mong đợi. Dành 10 phút để viết nguệch ngoạc một cái gì đó có thể tiết kiệm thời gian của một tuần (đã ở đó, thực hiện điều đó)

Nó cũng giúp bạn trong việc mã hóa của bạn. Nó cho bạn cơ hội suy nghĩ về những gì bạn cần làm, cách hiệu quả nhất để hoàn thành nó và bất kỳ trở ngại nào có thể cản trở.

Ví dụ: bạn có thể thấy rằng báo cáo "đơn giản" mà bạn cần tạo khó hơn bạn nghĩ trước đây vì bạn không ghi lại một ngày nào đó trên bảng xyz. Nó cũng mở rộng tầm nhìn của bạn và cho thấy nhóm của bạn, cấp trên hoặc thậm chí có thể được sử dụng cho các cơ hội nghề nghiệp tiềm năng trong tương lai mà bạn làm nhiều hơn mức tối thiểu và có thể vượt ra ngoài "đó không phải là công việc của tôi" (<--- nghiêm túc, ĐỪNG là anh chàng đó, tất cả chúng ta đều ghét anh ta) hoặc nó cho bạn cơ hội học hỏi thêm.

Hãy xem xét điều này một cách tổng quát hơn:

• Là tạo dự thảo là một ý tưởng tốt?
• Ai nên tạo bản nháp?

Là tạo dự thảo là một ý tưởng tốt?

Tạo dự thảo chủ yếu cung cấp 2 lợi ích. Đầu tiên, nó cung cấp trọng tâm, dẫn đến tăng tốc trong công việc thực tế đang được thực hiện. Thứ hai, nó làm cho việc thảo luận về hướng của công việc trước khi công việc hoàn thành đơn giản hơn rất nhiều.

Nhược điểm của việc tạo một bản nháp là nó sử dụng thời gian. Thật không có ý nghĩa gì khi dành 2 giờ để tạo ra một bản nháp công phu cho một cái gì đó mất 4 giờ để tạo ra.

Trong trường hợp của bạn, mức độ của mockup cần phải tính đến số lượng công việc ước tính đi vào dự án và lợi ích của dự thảo. Tùy thuộc vào những điều này, mockup của bạn có thể ở bất cứ đâu giữa 10 giây viết nguệch ngoạc trên một trang web sau đó và một trang web tương tác đầy đủ. Đối với các dự án rất lớn và đắt tiền, không có gì lạ khi toàn bộ các nhóm làm việc trên một bản nháp trong nhiều tuần và tạo bản nháp cho bản nháp của họ trong khi thực hiện điều đó.

Ai nên tạo bản nháp?

Không cần câu trả lời công phu ở đây: Nếu bạn được lợi từ việc tạo bản nháp, bạn tạo bản nháp. Nếu bạn được lợi từ người khác làm bản nháp cho bạn, hãy nhờ người khác làm bản nháp cho bạn.

Đồng nghiệp của bạn là hoàn toàn chính xác. Các ứng dụng nội bộ thường có giao diện được xác định trước. Ngoài ra, đối với các ứng dụng như vậy, người dùng không tìm kiếm giao diện người dùng tiên tiến. Tất cả những gì họ muốn là một cái gì đó hoạt động và rất dễ sử dụng. Trừ khi bạn có kế hoạch thay đổi hoàn toàn giao diện người dùng (mà tôi sẽ khuyên bạn nên chống lại .... đối với các ứng dụng nội bộ), chỉ cần làm theo giao diện hiện có. Mock-up là tuyệt vời, nhưng trong trường hợp của bạn, sẽ chỉ làm tăng nỗi đau của bạn.