Wireframe là gì?
Trước khi chúng ta đi sâu vào nội dung, hãy xác định lại một lần nữa thuật ngữ “wireframe”. Trong thiết kế web, wireframes được sử dụng để thể hiện trực quan cấu trúc và chức năng của một trang web, hoặc một ứng dụng. Wireframe thường được trừu tượng hóa theo thước xám (grayscale) và có ô trống thể hiện nội dung.
Nói một cách đơn giản, có hai loại wireframes: Loại thứ nhất là các bản phác thảo được tạo bằng bút và giấy hoặc bảng trắng và bút đánh dấu, đây là những wireframe có độ chính xác thấp (sketch, lo-fi wireframe). Thứ hai là các khái niệm được tạo ra với sự trợ giúp của các ứng dụng, đây là các wireframe kỹ thuật số có độ trung thực cao (hi-fi wireframe). Không giống như một bản phác thảo, thiết kế trở nên hữu hình hơn và mức độ chi tiết cao hơn.
Khi nói về wireframe trong bài viết này, chính là đang nói về wireframe có độ trung thực cao. Loại được tạo bằng phần mềm và được coi là bản thiết kế hoặc hướng dẫn cho giao diện người dùng. Mặt khác, wireframes có độ trung thực thấp trong bài này sẽ gọi là bản phác thảo (sketch). Do đó, để đơn giản, chúng ta đang nói về wireframe như một sản phẩm có thể chuyển giao được, là cái mà bạn sẽ gửi cho khách hàng.
Luận điểm 1: Wireframes cho phép quyết định các câu hỏi liên quan đến chiến lược và nội dung
Wireframes thường được sử dụng để đưa ra quyết định về cấu trúc của trang web. Tuy nhiên, ngay cả trước mỗi bản thảo thiết kế, chúng ta đã phải làm rõ một số câu hỏi cơ bản như: chúng ta muốn đạt được mục tiêu gì với trang web và làm cách nào để đạt được nó? Sau khi có câu trả lời, chúng ta thường xác định phương hướng chiến lược và đặt nền tảng cho các hoạt động thiết kế của mình. Chúng ta thường không xây dựng chiến lược đồng thời với thiết kế.
Và trước khi quyết định trang sẽ trông như thế nào, chúng ta phải thiết lập sự hiểu biết chung với tất cả các bên liên quan về mục tiêu mong muốn: chiến lược, thông báo, hình ảnh, chúng ta không thể kiểm soát hết tất cả cùng một lúc. Wireframes lúc này chỉ đơn giản là cố gắng làm quá nhiều khi bạn đang cố gắng làm chủ mọi thứ….
Luận điểm 2: Wireframes cho phép chúng tra kiểm tra sản phẩm ngay từ đầu
Wireframes thường được sử dụng để kiểm tra khả năng sử dụng ở giai đoạn phát triển ban đầu. Mục tiêu là xác định thông tin chi tiết về trải nghiệm sản phẩm và ưu nhược điểm của một giải pháp càng sớm càng tốt.
Ý tưởng này không phải là một ý tưởng tồi, nhưng thật không may, không phải lúc nào chúng ta cũng có thể lấy thông tin từ wireframe và tưởng tượng sản phẩm khi chuyển thành trải nghiệm kỹ thuật số sẽ như thế nào. Wireframe đơn giản là quá xa so với những gì người dùng mong đợi từ các ứng dụng kỹ thuật số vào những năm 2020. Trong thử nghiệm với wireframe, người dùng không trải nghiệm được khả năng đọc, màu sắc hoặc công thái học và do đó không đạt được gần như toàn bộ khả năng sử dụng của sản phẩm.
Điều cuối cùng chúng ta cố gắng đạt được trong một bài kiểm tra là sự tiếp nhận. Trong cuộc kiểm tra sản phẩm, chúng ta có thể âm thầm quan sát phản ứng, cử chỉ, tương tác và suy nghĩ của người dùng thử nghiệm. Wireframes độ trung thực cao khó có thể cung cấp điều đó khi mọi thứ đều là nội dung giả (dummy content). Yếu tố quyết định ở mỗi buổi kiểm tra là sản phẩm thử nghiệm chạy trên thiết bị phù hợp, được trang bị nội dung thực và trông giống với phần lớn các sản phẩm mà nhóm mục tiêu xử lý hàng ngày.
Chúng ta càng sớm tạo ra trải nghiệm gần giống với tương tác với sản phẩm thực, thì chúng ta càng sớm thu được kết quả đáng tin cậy. Lofi wireframes là quá đủ để chúng ta tạo ra sản phẩm gần giống nhất.
Luận điểm 3: Wireframes giúp tăng tốc quá trình
Wireframes thường được sử dụng để đưa ý tưởng sản phẩm từ giấy lên máy một cách nhanh chóng. Người ta cho rằng việc sắp xếp các yếu tố không có đặc điểm hình ảnh hoặc chức năng là một cách tiết kiệm thời gian trong thiết kế.
Lập luận rằng wireframes tiết kiệm thời gian là hoàn toàn dễ hiểu vào 20 năm trước. Vào đầu thiên niên kỷ, các nhà thiết kế trên khắp thế giới đã tạo ra thiết kế UI bằng Adobe Photoshop. Phải mất rất nhiều thời gian để phát triển một thiết kế. Mãi cho đến năm 2010, với sự thành công ngày càng cao của Sketch, các công cụ thuần thiết kế UI mới được phát. Ngày nay chúng ta làm việc với Sketch, Figma, Adobe XD, Invision Studio, v.v. Đồng thời, các thư viện như Marterial UI của Google được tích hợp trực tiếp vào ứng dụng. Với các công cụ như Bapt, thư viện biểu tượng (icon library) và nhiều bộ minh họa khác nhau, nội dung phù hợp có thể được tạo nhanh chóng.
Bây giờ, nếu chúng ta so sánh, wireframe vẫn có thể giành chiến thắng trong cuộc đua tốc độ. Nhưng phải tự hỏi rằng liệu kết quả này thực sự có giá trị và bền vững? Là nhà phát triển, công việc của chúng ta là thiết kế trải nghiệm tạo ra giá trị cho người dùng. Nếu có thể chứng minh điều này càng nhanh thì càng tốt. Đó là lý do tại sao chúng ta nên đầu tư thời gian vào việc tạo ra một nguyên mẫu thiết kế.
Thay vì lãng phí thời cho wireframe, chúng ta có thể phân phối được nguồn lực đó cho những bước phát triển khác. Phát triển sản phẩm là một cuộc chạy marathon, không phải chạy nước rút.
Luận điểm 4: Wireframes cho phép bạn tránh các cuộc thảo luận chủ quan
Khi trình bày một mẫu thiết kế thử nghiệm, người dùng hoặc khách hàng có thể bị phân tâm bởi thiết kế. Có thể thiết kế ban đầu có toàn bộ là màu vàng và khách hàng ghét màu vàng. Wireframes đủ trừu tượng để chúng ta có thể rút gọn khoảng cách đến sản phẩm cuối cùng và từ đó thảo luận về các ý tưởng cơ bản một cách thực tế nhất. Và wireframe đủ hữu hình để chúng có thể đưa ra các quyết định chung về kiến trúc thông tin, trải nghiệm người dùng và các yêu cầu kỹ thuật. Bạn đang cho là vậy đúng không?
Thật không may, khoảng cách từ wireframe đến bản thiết kế thực sự là vấn đề. Trong wireframe, thường hay quy ước một vài phần thành một biểu tượng chung để đại diện ví dụ như biểu mẫu, hình ảnh, thông báo. Nhưng chúng trông không gì khác gì đại diện cho chỉ một loại tương tác nhất định. Cho nên, các biểu tượng phải được ghi chú và giải thích để mọi người thấy sự khác biệt ở đó.
Tiếp theo là việc thiết lập những kỳ vọng vô thức về thiết kế. Nếu chúng ta càng rời xa ý tưởng wireframe trong quá trình thiết kế, thì sự thất vọng lại càng lớn. Hoặc nói một cách trực quan hơn, khi bản thiết kế thêm những chi tiết sáng tạo thì nó lại trông khác so với hifi wireframe và làm cho những nhà phát triển bối rối, gây chênh lệch trong kết quả kiểm thử người dùng. Hệ quả là trong nhiều trường hợp, nếu thiết kế chỉ lệch một chút so với wireframe ban đầu, chúng sẽ trở thành một bản thiết kế với ý tưởng mới (khả năng không phải là hoàn toàn nhưng khá cao).
Wireframes cuối cùng dồn chúng ta vào một góc không lối thoát, khi các designer phải quyết định là mình nên bám sát wireframe hay sáng tạo và chấp nhận sự sai lệch so với ban đầu.
Vậy cuối cùng chúng ta có nên từ bỏ wireframe?
Có lẽ có và có lẽ là không. Hoặc chính xác hơn ta có thể nói là:
Wireframes không lỗi thời, chỉ có cách tiếp cận của chúng ta đối với wireframes đã lỗi thời.
Khi nhiều designers ngoài kia có xu hướng tạo wireframe chỉ là một phiên bản màu xám của giao diện người dùng và xu hướng này cũng đang lan truyền rất nhanh trên internet. Bạn sẽ tìm thấy những wireframe màu xám, xanh lam, nâu hoặc đỏ tuyệt đẹp này, không chỉ rõ ràng mà còn hoàn hảo đến từng pixel. Một công việc bề ngoài trông rất là chuyên nghiệp, nó giúp cho khách hàng nhìn chúng ta với một con mắt ngưỡng mộ. Nhưng cho đến cuối cùng nó cũng chỉ màn trình diễn của các designer thiên về giao diện người dùng.
Và tại sao wireframe vẫn còn tồn tại? Nếu không có thiết kế tương tác cơ bản và các đặc điểm trực quan của wireframe, khó có thể có được những hiểu biết hợp lệ về các yêu cầu kỹ thuật, kiến trúc thông tin hoặc thậm chí là trải nghiệm người dùng và trải nghiệm người dùng không chỉ dựa vào nội dung.
Vì vậy hãy thử tiếp cận wireframe theo một hướng khác, tập trung hơn vào giai đoạn phát thảo, hoặc chúng ta có thể nói là hãy tập trung vào việc vẽ wireframe nhanh và “bẩn” hơn, không cần đẹp và chắc chắn không phải hoàn hảo theo từng pixel. Ngoài ra, chúng ta có thể tiếp cận wireframe theo những hướng sau, để tăng tốc độ khi phát thảo bản wireframe đầu tiên:
- Cấu trúc – Mỗi phần của luồng người dùng (user flow) khớp với nhau như thế nào và toàn bộ luồng sẽ khớp như thế nào trong tổng thể?
- Nội dung – Hiển thị gì trên mỗi bước của quy trình?
- Hệ thống phân cấp thông tin – Thông tin này được sắp xếp và hiển thị như thế nào?
- Chức năng – Giao diện này sẽ hoạt động như thế nào? Nó sẽ gọi là gì, nó sẽ đi đâu, mỗi phần tử sẽ làm gì?
- Hành vi – Nó tương tác với người dùng như thế nào? Và nó hoạt động như thế nào?
