UI Guidelines P1: Hiểu và áp dụng từ A-Z

9 min readSep 8, 2018

…..Mãi Medium chưa chịu hỗ trợ unicode toàn diện 😪

Thần chú: làm guideline là để tăng tính usability lên, sau tăng khả năng promotion của sản phẩm lên. Nếu đồng ý thuộc thần chú này thì hãy đọc tiếp.

Nên hiểu việc này là thế nào?

Trước khi bắt tay vào việc xây dựng một web app/app thì bạn phải xây dựng giao diện (UI) cho nó. Nhưng trước khi xây dựng UI cho app bạn phải phác thảo ra trước sơ đồ thiết kế cho nó. Sơ đồ thiết kế này gọi là UI Guidelines.

Cũng tương tự như việc bạn cầm trên tay sơ đồ thiết kế nhà, bạn nhìn vào sẽ thấy đâu là phòng khách, đâu là phòng ngủ, cửa chính cao bao nhiêu, rộng bao nhiêu, và bếp của bạn nằm ở hướng nào. Đó là cách nhìn của bạn.

Nhìn từ một sơ đồ thiết kế nhà…Nguồn: Google

Còn đối với cách nhìn của kiến trúc sư, họ sẽ thấy được hướng phát triển của căn nhà, đâu là hướng đón nắng tốt nhất, đâu là hướng gió đi vào dễ chịu nhất. Và nếu lần tới có buộc phải chỉnh sửa thiết kế, ít ra họ có thể dựa vào sơ đồ này để so sánh, cải tiến tùy vào điều kiện thực tế trong quá trình sử dụng căn nhà.

Cuối cùng là nhóm kỹ sư xây dựng, họ sẽ đọc sơ đồ này, hiểu chi tiết kỹ thuật của từng thành phần trong nhà , hiểu được mục tiêu thiết kế của đội ngũ làm việc, hiểu được mong muốn của chủ nhà.

Suy cho cùng, điều quan trọng nhất của cái sơ đồ này đó là: Làm sao tất cả mọi người đều có thể hiểu (theo từng chuyên môn/kinh nghiệm của bản thân) và hiện thực hóa nó được.

Đến môi trường product

Cũng tương tự như ví dụ trên, khi bạn có một nhóm làm sản phẩm gồm những người làm Product (PM, UX Designer, Developer, Tester) thì cái sơ đồ thiết kế này có tên là UI Guidelines.

Trong cái sơ đồ này có 3 thứ phải quán triệt sớm:

Việc định nghĩa và xây dựng sơ đồ này phải được thực hiện ở cấp độ quản lý.
UI Guideline là thứ dùng để trao đổi, thảo luận về mục tiêu của sản phẩm.
Luôn có sự nhất quán trong giao tiếp khi dựa vào UI Guidelines để đưa ra quyết định làm gì, không làm gì.

Như vậy nhìn rộng ra có thể thấy khi bắt đầu xây dựng cấu trúc thông tin cho sản phẩm, chúng ta sẽ phải sớm nhìn vào UI Guidelines để dọn sẵn lối đi theo cấu trúc thông tin ban đầu mà chúng ta muốn.

…cho đến một bản hướng dẫn thiết kế sản phẩm. Nguồn: Google

Ví dụ bạn xác định hướng người dùng đến việc Search trong sản phẩm của bạn. Bất kể là search dọc, ngang hay cài cắm vào các flow nào thì bạn phải dựng được UI Guidelines theo hướng này. Nó giống như là việc phải xác định hướng gió cho nhà bếp của bạn trước là vậy.

Nhưng việc này không dễ dàng, bởi vì khi làm UI rồi thì bạn sẽ nhận ra được có nhiều vấn đề phát sinh. Có hai thứ phải cân nhắc:

Sẽ luôn có những nhận định Cảm tính xuất hiện, nhất là khi đụng vào hình dạng của vật thể (tròn, vuông, chữ nhật, bo tròn bo vuông thế nào), và Màu sắc (chuyện muôn thưở). Nếu là team gồm tầm chục thầy designer thì tình hình có khi còn loạn hơn là 1 người làm, vì khi đó bạn sẽ phải đối diện với nhiều ý kiến Cảm tính hơn, mục tiêu dễ bị kéo ra xa hơn.
Chờ đến khi xong UI một thể mới mời Developer vào làm việc. Lúc đấy mới rõ mindset của Developer là gì thì quá muộn.

Làm UI Guidelines + Hiểu thêm tư duy của Developer

Sẽ có những thứ mà Developer sẽ chỉ quan tâm đến UI Guidelines của bạn. Một số thứ mình viết bên dưới theo quan sát và kinh nghiệm làm việc trước đây, có thể sẽ khác nhau ở nhiều nơi, có thể nó còn thiếu (tất nhiên). Có thể có một số quan sát không còn đúng nữa, hoặc đã lỗi thời.

Việc của Designer là thêm thắt phần sáng tạo, nhưng cũng phải thực tế. Nguồn: Google

Kích thước canvas, global margin, padding phải được tính toán từ sớm.
Mỗi kích thước của window sẽ có các dạng padding khác nhau.
Độ rộng giữa các cột trên grid (gutter).
Cách thiết kế từ màn hình lớn xuống màn hình nhỏ và ngược lại, tùy vào nhóm đối tượng phục vụ.
Dùng grid system một nào đó, cái nào cũng được miễn có sự thống nhất giữa 2 bên từ sớm: Developer sẽ dễ dàng xác định được cột nào có thể tùy chỉnh kích cỡ hoặc muốn làm gì đó tùy thích. Đa số các developer mà làm full-stack thì thường “thủ” sẵn cho mình món Bootstrap, dùng grid 960 với 12 cột.
Khi các element được canh trái, phải, hoặc giữa trong các kích cỡ màn hình khác nhau: code của developer thì được viết theo nhiều dòng, nhiều dòng tạo nên một Khối. Các khối này về cơ bản vốn dĩ là các dạng chữ, nằm cạnh nhau từ trái sang phải, hoặc xếp theo thứ tự chồng lên nhau. Chỉ trừ khi nó được áp CSS vào thì sẽ khác. Vì vậy cần phải tính đến sự nhất quán của các vị trí này khi ở trên các màn hình khác nhau.
Đừng cố gắng tạo các mẫu UI gồm nhiều đường lượn sóng (curves). Trên Sketch tạo 1 đường này chỉ mất 30s, nhưng để code ra được 1 đường như vậy là cả một vấn đề, vì bản chất của HTML và CSS vốn dĩ được sử dụng để tạo các đường cong đều ở các góc như viền của nút. Bất kỳ các dạng đường cong không đều nào khác đều được xếp vào dạng curves này, và đều phải được thực hiện bằng cách xếp rất, rất nhiều hình nhỏ li ti cạnh nhau để tạo ra “cảm giác” cong thật như vẽ tay. Để hiểu được điều này, bạn mở 1 tấm hình chụp bằng máy DSLR trong Photoshop, rồi zoom in đến hết mức có thể để thấy được các pixel màu ô vuông. Lúc này cong hay thẳng thì đều là các mảnh pixel ghép lại mà thành. Nếu ai nói code mấy cái đường này dễ thì mời vào Wiki đọc [Curve — Wikipedia](https://en.wikipedia.org/wiki/Curve#Topology), đừng nhầm lần giữa người lập trình ngôn ngữ và lập trình với thuật toán.
Nếu cần phải làm responsive, thì content luôn đi đầu tiên, rồi mới đến layout. Cách đây 3–4 năm mình có nghe thuật ngữ “Content is KING”. Có vẻ thời thượng. Nhưng giờ thì không ai nhắc đến nó nữa, vì vốn dĩ đây là việc phải làm trước khi tính đến bài toán responsive.

Chọn hướng xây dựng UI Guidelines

Cách nguyên thủy nhất đó là…làm mọi thứ từ đầu. Việc này tất nhiên tốn nhiều thời gian lẫn công sức bỏ ra. Tuy nhiên nếu đã làm được thì sẽ rất tuyệt vời. Việc này nên nhìn nhận dưới 2 góc độ.

Ở góc độ phát triển một sản phẩm mới toanh, việc đầu tư làm guidelines mà không cần tham khảo các guidelines khác là việc khá…stupid, nếu không nói là thiển cận.

Ở góc độ đã có một sản phẩm rồi nhưng chúng ta chưa có bộ guidelines nào chuẩn, nên đầu tư vào nó bằng cách nhìn từ sản phẩm hiện tại có thể góp nhặt lại được guidelines gì, từ đó đánh giá ưu nhược điểm để có thể bổ sung thêm các phần còn thiếu, bỏ bớt các phần không phù hợp. Phần này mình sẽ viết chi tiết ở P2.

OK, thế còn câu chuyện của những ông lớn? Ví dụ Microsoft, Google?

Fluent Design

Chẳng có lý do gì chúng ta không tham khảo 2 thương hiệu hàng đầu thế giới này, nhất là khi Microsoft đã phổ biến tài liệu online tại [Windows Desktop Development — Windows app development] (dành cho các app trên nền Desktop, môi trường Windows) và [Design Universal Windows Platform (UWP) apps — UWP app developer](dành cho phong cách Fluent Design, được cải tiến từ kiểu giao diện Metro từ Windows 8).

Nôm na Google có Material Design thì anh Bill cũng có vũ khí đáp trả chính là thứ Fluent Design này. Tại sao có Fluent Design? Đơn giản vì trước kia mấy chú Metro gì đó quá xấu, phải có cái gì đó đẹp hơn để tạo sự cân bằng với đối thủ, thế thôi. Bên đấy có thì mình cũng phải có, kiểu nó phải thế. Người dùng cuối cùng cũng phải thốt lên: “Cuối cùng rồi Windows cũng đẹp!”

— Tham khảo thêm tại [Kĩ hơn về Fluent Design: cuối cùng Microsoft cũng đã làm cho Windows đẹp lên | Tinhte.vn]

Nhưng đừng nhầm lẫn khái niệm, dùng cái nào thì phải dùng từ đầu, đúng kiểu của nó. Đừng dùng nửa Google nửa Microsoft. Kiểu này rất nguy hiểm vì đây là 2 ông dạng phổ biến toàn thế giới, dùng không tới thì sẽ gây ra tác dụng ngược lên người dùng.

Material Design

Cái này thì quá phổ biến rồi [Design — Material Design](https://material.io/design/)

macOS Design Theme và iOS Design Theme

Mém chút quên mất Apple.

Có thể thấy cục diện bây giờ ở thế chân vạc, 3 ông nổi tiếng nắm giữ trong tay 3 phong cách. Cũng phải thôi khi trong thị trường này cần phải có kẻ dẫn đầu để tạo cú hích và dẫn dắt các xu hướng mới. Nếu không phải 3 ông này thì ai sẽ làm bây giờ?

Phân biệt rõ một số loại UI Guidelines

Có bao nhiêu loại thì mình không biết, cũng chẳng có chỗ nào thống kê chính xác hoặc sách vở chỉ ra. Hiện tại có một số loại cơ bản như bên dưới.

Style guidelines (dùng kèm với một trong các mục 2–9)
Layout
Mockup/wireframe (vâng, nghe quen không?)
UI Controllers
Typography
Interactions
Responsives hoặc Cross platform
Các loại pattern phổ biến
Các resources được phép sử dụng (bao gồm free, trả phí)

OK, cái mình thấy nhiều người hay nhầm lẫn nhất chính là Style Guidelines. Đa số hay nói đây chính là UI Guidelines, thực chất chỉ đưa ra được Style mà không hề biết là mình làm chưa đủ. Một bộ Style Guidelines cơ bản gồm các tiêu chuẩn để phục vụ việc xây dựng:

Logo
Màu sắc
Icon
Typography
Có thể có một số định nghĩa về nút.

Vì vậy nếu đem Style Guidelines ra nói là UI Guidelines là không chính xác. UI Guidelines là sự kết hợp giữa mục 1 và các mục còn lại, hoặc bản thân nó là một trong số các mục 2–9, tùy vào mục đích của team và sản phẩm cuối cùng.

Một số câu hỏi

Câu hỏi 1: Có cần phải dựng UI Guidelines không?

Cần, tất nhiên là phải cần. Nhưng, nếu.. (đọc câu hỏi 3).

Câu hỏi 2: Làm đại trước một Style guidelines rồi dựng UI Guidelines được không?

Được, tất nhiên là được. Tùy thời điểm cụ thể chúng ta sẽ áp dụng các cách khác nhau. Có thể cầm đèn chạy trước ô tô, nhưng chung quy vẫn là thương hiệu ra ngoài. Nếu nghĩ đến nó thì đầu tư tiếp.

Việc này mình nghĩ cách nhìn rất đơn giản, vì việc làm UI Guidelines bản thân nó cũng nói lên Personality của bạn và team bạn rồi. Không gì tuyệt vời hơn khi thể hiện Personality của sản phẩm cho người dùng biết có phải không?

Câu hỏi 3: Tôi chính là UI Guidelines có được không?

Hoàn toàn được, khi đấy bạn quyết định mọi thứ. Đây cũng chỉ là một cách để thực hiện hóa nó.

Câu hỏi 4: Copy Guideline của một hãng khác được không?

Thế giới vẫn đang làm như vậy. Chỉ có những người không phân biệt được Copy, Creation và Curation. Dù là phương pháp nào cũng phải thể hiện rõ nét một phương pháp đó. Như Xiaomi chẳng phải thừa nhận hãng đang dùng phương pháp Copy đó hay sao? Hãy copy nghệ thuật như Xiaomi.

— —

Phần 2 sẽ nói rõ chi tiết của UI Guidelines và các thành phần bên trong nó.