Bóng ma: Là những chủ thể vô hình được cho là bị mắc kẹt giữa hai thế giới, hành hạ người sống và đồng thời cũng là sứ giả của thế giới bên kia. Chúng gợi lên một nỗi sợ vì con người không thể nhìn thấy, không thể chạm vào chúng, và hơn hết, chúng ta không có chút hiểu biết nào về sự tồn tại của chúng – giống như những quyết định bí ẩn trong lúc thiết kế đã và đang ảnh hưởng lên sản phẩm của bạn. (ở đây, người viết sử dụng cụm từ “bóng ma quá khứ” nhằm ám chỉ những quyết định đã đưa ra trước đó có ảnh hưởng ít nhiều tới hiện tại, tương tự câu “sai một li, đi một dặm” của người Việt – người dịch)

(Bài viết sử dụng thuật ngữ Constraints được giới thiệu bởi Don Norman, người khai sinh ra thuật ngữ UX – người dịch )

Các ràng buộc (Constraints) giúp phát triển và định hình bất cứ sản phẩm nào. Ràng buộc chính là nền tảng trong việc đưa ra các quyết định, cho phép nhiều người đồng thời làm việc cùng nhau với một sự hiểu biết chung. Ràng buộc giúp các nhóm có thể nhanh chóng khởi động lại một chu trình, thiết lập nhiều trường hợp khác nhau và tạo ra được các mẫu thiết có thể giải quyết được các vấn đề hiện có.

Và quan trọng hơn hết, ràng buộc chính là nơi khai sinh ra các mẫu thiết kế, các thành phần, các tương tác, và thậm chí là các từ ngữ – đây chính là những viên gạch đầu tiên cho hệ thống thiết kế của bạn.

Đôi khi các ràng buộc được mã hoá trong một số tài liệu trên mạng nội bộ của công ty (hoặc có thể là Google Docs). Đôi khi chúng được in ra và treo trên tường. Hoặc đơn giản hơn, chúng được truyền đi theo phương thức cổ điển nhất từ trước đến nay: truyền miệng. Và vì vậy, mặc dù bạn có thể thấy được rõ ràng các ràng buộc đó trong các thành phần hay trong hệ thống thiết kế,bạn vẫn chẳng thể hiểu nổi lý do tại sao lại có những ràng buộc như vậy. Và cuối cùng, thường thì lời giải thích mà bạn nhận được sẽ là “Ờ thì… trước giờ nó vậy rồi”.

Điều này nghe có vẻ cũng chẳng phải là một vấn đề gì lớn lao. Tuy nhiên, giả sử dự án được tiếp tục và có nhiều người tham gia hơn, sẽ nảy sinh ra các vấn đề đại loại như các quyết định được đưa ra tại thời điểm hiện tại lại bị áp đặt bởi một ràng buộc tại một thời điểm trong quá khứ, mà ràng buộc đó giờ đây không còn tồn tại hoặc đã bị thay đổi đến mức không thể nhận ra được – Và trong hoàn cảnh này, những ràng buộc đó nghe như là một bóng ma vậy.

May mắn thay, bạn có thể làm một vài điều sau để tránh việc sản phẩm của bạn bị “ám” bởi các “bóng ma” này.

Thứ nhất, là tổ chức các bài đánh giá thiết kế thường xuyên bao gồm việc làm mới lại các nguyên tắc và các ràng buộc trong thiết kế. Điều này sẽ giúp các thành viên trong nhóm tránh được bất kỳ sự nhầm lẫn hay hiểu lầm nào. Trong suốt quá trình đánh giá, câu hỏi hay nhất mà chúng ta nên đặt ra là “Tại sao?”

“Tại sao chúng ta nhãn tiêu đề như này?” “Tại sao lại làm hiệu ứng hover cho dòng thông tin này?” “Tại sao chúng ta lại đặt mạng lưới thông tin như thế này?” “Tại sao lại sử dụng cái màu đó?” “Tại sao cái quy trình này lại mất 6 bước?” Tại sao chúng ta không hiển thị thông tin về ______ ở chỗ này?”

Mốt số câu hỏi kể trên và hàng ngàn câu hỏi khác nữa, tất cả đều là những câu hỏi hoàn toàn quan trọng và cần thiết – kể cả khi bạn đã trả lời câu hỏi đó trước đây rồi. Việc đặt ra câu hỏi “Tại sao?” sẽ buộc chúng ta có cái nhìn khách quan hơn về giải pháp hiện tại và tiếp tục tìm kiếm giải pháp tối ưu nhất. Một nhà thiết kế có thể sử dụng các thành phần đã được phát triển trong quá trình thiết kế, nhưng nếu họ không thể hiểu rõ lý do tại sao họ đang sử dụng chúng và tại sao chúng lại tồn tại, khả năng cao là toàn bộ bản thiết kế sẽ đổ sụp chỉ trong một cái chớp mắt.

Cách thứ hai đó chính là áp dụng “Ghi chú giải pháp” trong quá trình thiết kế của bạn. “Ghi chú giải pháp” đơn giản là một vài dòng chú thích để nói rõ lý do tại sao bạn chọn giải pháp này và giải pháp này sẽ được thực hiện và sử dụng như thế nào. Nhiều nhóm khi làm việc với các quy trình như thiết kế mẫu/ phác thảo hệ thống, họ chú thích rất kỹ càng thông số kỹ thuật chính xác cho bố cục, bộ đệm, hành vi, v.v. Tuy vậy lại không có một lời giải thích rõ ràng về lý do tại sao lại làm vậy.

Phải thừa nhận rằng, làm mấy ghi chú kiểu như vậy trong Photoshop hoặc Fireworks thì nó khá là chán và tẻ nhạt. Đó là chưa đề cập đến việc sẽ gây khó khăn lúc mới bắt đầu với lại việc cập nhật cũng rất ư là mất thời gian.

Tuy vậy, tin tốt lành là ngày nay, có khá nhiều đội ngũ thiết kế UX bắt đầu sử dụng phương pháp “làm Bản mẫu trước” và xây dựng các phác thảo sản phẩm bằng HTML và CSS. Việc sử dụng các bình luận trong lúc lập trình sẽ giúp người khác nhanh chóng hiểu được cách mọi thứ hoạt động và liên quan đến nhau.

Đây có vẻ như là một công cụ hoàn hảo cho “Ghi chú giải pháp”. Ví dụ: bạn có thể chú thích HTML và CSS bằng vài dòng như sau:

/*  =Ghi chú giải pháp

    What: Khung điều hướng

    Who:  John McDecisonguy, Thom Leadhoncho

    When: 2 tháng Một, 2012

Why: chúng tôi muốn khung điều hướng sẽ xuất hiện trên tất cả các trang nội dung để người dung có thể dễ dàng tìm kiếm thông tin mà họ muốn.

*/

Bạn có thể đưa ra quyết định chú thích theo ý của bạn. Nếu bạn đang sử dụng Git hoặc SVN, bạn sẽ có một danh sách những thanh thay đổi đã được thiết lập. Nếu bạn đã am hiểu về Javascript, bạn có thể tạo ra một “Khung ghi chú Giải pháp” dính liền với các phần tử liên quan và có thể bật/ tắt tùy thích.

Mặc dù phương pháp này nghe qua có vẻ khá tốn công sức, nhưng bù lại, nó sẽ giúp các nhà thiết kế, các kỹ sư tránh khỏi việc nát óc suy nghĩ xem tại sao lại có cái này ở đây, và hơn hết là tiết kiệm được rất nhiều thời gian.

Để nhận được cái danh hiệu “Các dũng sĩ bắt ma” và giữ cho các sản phẩm của chúng ta khỏi bị “ma ám”, các nhóm phải luôn làm việc có trách nhiệm và nắm được lý do tại sao cho mỗi quyết định trong quá trình phát triển sản phẩm. Bằng cách này, chúng ta sẽ tránh được việc đổ lỗi và đùn đẩy trách nhiệm, tạo ra sự thấu hiểu sâu sắc hơn trong nhóm về những giải pháp hiện tại, tránh việc lãng phí thời gian cho các nhà thiết kế và kỹ sư.

Nguồn: 52weeksofux.com

Dịch bởi: Hà Đình Nhân

BBT iDesign