Đô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
