Hệ thống thiết kế: Quy chuẩn

Bài chia sẻ này được chuyển hóa từ dạng trình chiếu sang dạng chữ để phục vụ những bạn chưa nghe hoặc đã nghe phần thuyết trình của mình tại Vietnam Mobile Day 2019.

Câu chuyện thực tế

Mình gia nhập BraveBits vào mùa hè năm 2018 với nhiệm vụ là tham gia vào quá trình nghiên cứu,  xây dựng, tối ưu PageFly. PageFly là một trong hơn 3 nghìn ứng dụng nằm trên kho ứng dụng của Shopify, mục đích là giúp các chủ cửa hàng tự thiết kế, tối ưu tỉ lệ chuyển đổi cho trang web thương mại điện tử (TMĐT) mà họ tạo trên Shopify, tại thời điểm viết bài thì ứng dụng này đang nằm vị trí số 1 trong mục Thiết kế trang (Store design/Page builders) và vị trí số 19 trên tổng số ứng dụng.

Giao diện chính của PageFly.

Một trong những công việc mình đảm nhiệm ở PageFly là thiết kế lại giao diện cho sản phẩm này, mục đích là để cải thiện tính dễ sử dụng, đem lại sự thống nhất, tối ưu trải nghiệm người dùng để giúp họ thực hiện các hành động một cách mượt mà, dễ dàng hơn.

Khi đó, vấn đề mà PageFly gặp phải là chưa có một hệ thống thiết kế rõ ràng, chặt chẽ. Phần giao diện tương tác người dùng được xây dựng từ trước bởi đội ngũ phát triển, vốn không chuyên về việc thiết kế và nghiên cứu hành vi người dùng. Những yêu cầu về việc cải tiến sản phẩm, thêm bớt tính năng mới không có quy chuẩn rõ ràng khiến quá trình phát triển bị kéo dài, tốn kém chi phí.

Cùng với đó, PageFly còn sử dụng lại một hệ thống thiết kế khác là Polaris của Shopify để bổ sung cho những giao diện còn thiếu. Và Polaris thì được phát triển để hỗ trợ Shopify nên mọi sự thay đổi, nâng cấp tính năng đều phần nào bị ràng buộc bởi những giới hạn của Polaris và Shopify. Càng bị giới hạn thì càng phải can thiệp, tinh chỉnh lại và điều này càng khiến ứng dụng hoạt động nặng nề, chậm chạp hơn bởi vì sự chắp vá.

Hệ thống thiết kế Polaris do Shopify tự phát triển.

Nhìn chung, một sản phẩm mà không có hệ thống thiết kế chặt chẽ sẽ khiến cho phần giao diện người dùng không được thống nhất, thiếu hoàn thiện và rất khó bảo trì.

Và đó là lý do khiến bọn mình phải đầu tư thời gian, con người cho việc xây dựng một hệ thống thiết kế dành riêng cho PageFly.

Hệ thống thiết kế là gì?

Nếu bạn tự tin rằng mình đã hiểu thế nào là một hệ thống thiết kế thì có thể bỏ qua phần này, vì mục đích của mình là để giúp những người mới nắm rõ và làm quen với khái niệm này nên mình sẽ cố gắng chia sẻ thật chi tiết.

Thiết kế: Quá trình tạo ra, chỉ ra cách một thứ gì đó được trông thấy, hoạt động trước khi nó được hoàn thành.

Hệ thống: Bao gồm những nguyên lý để làm một thứ gì đó, được gắn kết một cách có thứ tự, phương pháp.

Về cơ bản, hệ thống thiết kế là một bộ sưu tập những thành phần có thể tái sử dụng (thiết kế) được liên kết với nhau bởi các quy chuẩn để có thể lắp ghép chúng lại với nhau và xây dựng thành một sản phẩm hoàn chỉnh (hệ thống). Hay nói cách khác, hệ thống thiết kế giúp đội ngũ phát triển sản phẩm đưa ra một thiết kế có hệ thống hơn.

Mục đích sử dụng hệ thống thiết kế là làm giao diện người dùng hiệu quả, dễ mở rộng hơn, giảm công sức và thời gian cho việc tập trung vào tính thẩm mỹ, tăng tốc độ phát triển sản phẩm để từ đó có nhiều thời gian tối ưu trải nghiệm người dùng, và cuối cùng là giúp đưa ra những bản mẫu phác thảo nhanh hơn phục vụ việc đánh giá hiệu quả của tính năng.

Do vậy, một hệ thống thiết kế nên được xây dựng bởi chính đội ngũ phát triển sản phẩm vì họ là những người hiểu rõ cách sản phẩm hoạt động nhất, những ràng buộc về mô hình kinh doanh, giới hạn công nghệ. Hệ thống thiết kế sẽ song hành cùng với sản phẩm trong suốt quá trình phát triển.

Xây dựng như thế nào?

Trong đội ngũ xây dựng hệ thống thiết kế, luôn luôn phải có sự góp mặt của ban thiết kế sản phẩm và ban phát triển, nếu có thể thì sẽ cần thêm một người đảm nhiệm vai trò viết lách. Tỉ lệ thiết kế/lập trình của bọn mình là 1/6 và đội ngũ thiết kế phải tự đảm nhiệm công việc viết lách.

Mỗi bên sẽ cần phải chuẩn bị những thứ khác nhau để cùng nhau phối hợp, xây dựng hệ thống nhưng mình sẽ chỉ chia sẻ về sự chuẩn bị của đội ngũ thiết kế.

Tập trung vào tính năng chính

Điều đầu tiên mà bạn nên làm là đánh giá lại sản phẩm của mình, nếu có thể tận dụng được tài liệu có sẵn thì càng tốt. Liệt kê ra những tính năng chính mà hệ thống thiết kế phải hỗ trợ bởi vì một ứng dụng là sự kết hợp của nhiều tính năng lớn nhỏ khác nhau. Đừng bao giờ cố gắng xây dựng lưới, phân vùng giao diện cho toàn bộ ứng dụng ngay từ đầu vì bạn sẽ bị giới hạn bởi những thứ đó và không thể nào có đầy đủ thông tin cần thiết để làm điều đó ngay đâu.

Đây cũng là lý do một hệ thống thiết kế thường không được phát triển ngay từ khi sản phẩm mới đang ở giai đoạn bắt đầu xây dựng.

Sau khi thống nhất được những tính năng gì cần phải hỗ trợ thì công việc tiếp theo sẽ là vẽ phác thảo chúng, trên giấy hay phần mềm tùy thuộc vào điều kiện cho phép. Đừng cố gắng vẽ chúng thật chi tiết mà chỉ nên giữ những phác thảo ở mức đơn giản nhất có thể vì để nhìn ra một tính năng hoạt động hoàn hảo như thế nào là không hề đơn giản. Tiến độ công việc sẽ được rút ngắn rất nhiều nhờ vào việc bỏ qua những chi tiết nhỏ nhặt như màu sắc, biểu tượng, phông chữ, các trường hợp ngoại lệ (áp dụng triết lý xây dựng sản phẩm đáp ứng tối thiểu - MVP).

Bước cuối cùng trong công đoạn này là đánh giá lại những phác thảo đã hoàn thành rồi cùng nhau chơi trò "tìm điểm khác biệt". Mục đích là để phân loại những thành phần cấu thành nên các tính năng, liệt kê ra được những thành phần được dùng đi dùng lại. Điều này sẽ giúp bạn rất nhiều trong quá trình thiết kế giao diện sau này.

Những thành phần này sẽ được liệt kê và mô tả trong một tệp tài liệu.

Dải màu

Dải màu cho một ứng dụng có 3 nhóm chính: màu sơ cấp, thứ cấp và nhóm màu trạng thái hệ thống.

Sơ cấp: Nhóm màu này thường có từ 1 đến 3 màu và thường là màu thương hiệu của sản phẩm.

Thứ cấp: Nhóm màu này là những màu sáng, tối để bổ trợ cho những màu sơ cấp và thường được sử dụng cho chữ, biểu tượng, nền, viền,...

Trạng thái hệ thống: Thường bao gồm 4 màu đỏ, xanh lam, xanh lục, vàng tượng trưng cho các trạng thái hệ thống của ứng dụng.

Khi quyết định được mình sẽ cần đến những màu chủ đạo như thế nào thì bạn có thể tham khảo những bộ kết hợp màu từ nhiều nguồn khác nhau, dựa trên định hướng nghệ thuật muốn đi theo để tìm ra bộ màu phù hợp.

Dải màu hiện tại của PageFly.

Sau khi có được những mã màu chính cho từng nhóm màu, công việc tiếp theo là tạo ra dải màu từ 8-10 màu theo độ sáng tăng dần hoặc giảm dần. Ở bước này, mình thường giảm độ trong suốt của màu gốc trên công cụ thiết kế dựa trên một quy luật nào đấy, chẳng hạn như 10%, 20%,... 90%, 100%. Nhưng vấn đề mình đã gặp phải khi áp dụng phương pháp này là các màu bị trộn vào nhau khi kết hợp những màu có độ trong suốt khác nhau. Đo đó, mình thường đặt các thành phần này trên một nền trắng và nhặt lại mã màu Hex của chúng.

Tình huống bị trộn 2 màu có độ trong suốt khác nhau và cách giải quyết.

Mục đích của việc tạo ra mã màu theo một quy luật như vậy là để quá trình giao tiếp giữa anh em thiết kế và anh em lập trình viên dễ dàng hơn, tiết kiệm công sức, thời gian cho đội ngũ nếu trong quá trình phát triển sản phẩm cần phải thay đổi màu thương hiệu. Nếu cứ phải chọn lại từng mã màu như thế, chẳng may sai sót ở đâu đó khiến mã màu không đúng như mong muốn thì thật là thảm họa.

Cuối cùng, mình đã phát hiện ra một phương pháp tối ưu công việc chọn màu này hơn. Thay vì sử dụng mã Hex, mình chuyển sang dùng HSB và HSL. Về cơ bản, HSB và HSL đều giống nhau ở phương pháp chọn tông màu (Hue) và sắc độ màu (Saturation) nhưng khác nhau ở việc một bên thì thay đổi độ sáng của màu (brightness) còn một bên thay đổi độ trong (lightness). Nhờ hai mã màu này và một số sự hỗ trợ của các thư viện Sass, mình có thể đặt ra quy chuẩn cho việc tạo ra những dải màu khác nhau chỉ dựa trên một mã màu gốc.

Sử dụng 2 hệ màu HSL và HSB giúp bọn mình tạo ra dải màu một cách tự động.

Xây dựng hệ thống lưới

Mình không nói về hệ thống lưới theo hàng hay cột được áp dụng trong quá trình thiết kế những trang web thông thường. Lưới ở trong hệ thống thiết kế là một trong những quy chuẩn cực kỳ quan trọng để có thể xây dựng được một sản phẩm mang tính chặt chẽ cao. Mọi khoảng cách, kích thước của các thành phần trên giao diện đều có mối liên kết chặt chẽ với nhau, dựa trên một hệ thống lưới duy nhất.

Hệ thống lưới phải hỗ trợ cả việc sắp xếp các đối tượng theo chiều ngang lẫn chiều dọc, do đó bọn mình sử dụng lưới dạng ca-rô với kích thước của từng ô là 4px. Tại sao lại là 4px mà không phải con số khác? Mình đã xem xét qua tất cả các trường hợp đó và thấy nó không phù hợp với sản phẩm mà bọn mình đang xây dựng — một ứng dụng nặng về kỹ thuật và gồm nhiều thành phần giao diện phức tạp. Tiêu chí của bọn mình là làm mọi thứ to hơn, dễ thao tác hơn nhưng vẫn đảm bảo là đủ diện tích để thể hiện thông tin. Cùng với đó, trong số tất cả các kích thước màn hình máy tính thì đều có ít nhất một cạnh chia hết cho 4px và nó giúp bọn mình chia tỉ lệ theo màn hình đơn giản hơn.

Ví dụ về sự phù hợp của lưới 8pt (tương đương 4pt) với các tiêu chuẩn hiển thị trên màn hình - https://spec.fm/specifics/8-pt-grid

Kích thước, khoảng cách

Khi đã thống nhất được một hệ thống lưới phù hợp, công việc tiếp theo là xây dựng một bộ quy chuẩn về kích thước và khoảng cách. Về cơ bản thì tất cả các thành phần giao diện của sản phẩm sẽ dựa trên bộ quy chuẩn về kích thước, khoảng cách này.

Ví dụ về việc xây dựng bộ quy chuẩn về kích thước, khoảng cách.

Lý thuyết thì là như vậy, nhưng đưa ra được một bộ quy chuẩn ngay từ đầu không những không mang lại nhiều hiệu quả mà còn khiến bạn chậm trễ trong quá trình xây dựng hệ thống thiết kế. Theo mình thì các bạn cứ tuân theo hệ thống lưới có sẵn và giữ trong đầu một tư duy là cần phải thiết kế những thành phần giống nhau một cách giống nhau, đừng tạo ra quá nhiều trường hợp. Bạn sẽ tối ưu, cập nhật lại những thứ này trong quá trình xây dựng các thành phần có thể tái sử dụng ở phần sau.

Mục đích của công việc này là giới hạn sự lựa chọn cho chính bạn và cho những người sử dụng lại hệ thống thiết kế. Từ đó sẽ dễ dàng đưa ra quyết định hơn với ít công sức, thời gian hơn.

Tất cả mọi người đều muốn được quyền lựa chọn, đó là điểu hiển nhiên rồi. Đôi khi những sự lựa chọn này khiến họ bối rối và không biết phải chọn cái nào vì lựa chọn nào cũng thấy hợp lý.
Đọc thêm "Thiết kế trải nghiệm người dùng ứng dụng tâm lý học".

Mặt chữ và biểu tượng

PageFly là một ứng dụng trên nền tảng web nên bọn mình không bị ràng buộc bởi việc phải chọn mặt chữ một cách quá khắt khe. Thay vào đó, bọn mình sử dụng những mặt chữ do hệ thống cung cấp tùy thuộc và hệ điều hành và trình duyệt mà người dùng sử dụng.

Dưới đây là bí kíp võ công của tụi mình, một áp dụng cho việc hiển thị chữ và thứ còn lại áp dụng cho việc hiển thị số liệu.

font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', 'Roboto', 'Oxygen', 'Ubuntu', 'Fira Sans', 'Droid Sans', 'Helvetica Neue', sans-serif;

font-family: "SF Mono", "Segoe UI Mono", "Roboto Mono", "Ubuntu Mono", Menlo, Courier, monospace;

Đối với biểu tượng, có hai thể loại biểu tượng mà bạn cần phải cân nhắc đến khi làm việc với chúng: đơn sắc và đa sắc.

Đơn sắc

Danh sách biểu tượng đơn sắc của PageFly (trích xuất từ bộ Nucleo).

Biểu tượng đơn sắc là những thành phần cơ bản nhưng quan trọng không khác gì mặt chữ, tác dụng của nó là để giúp người dùng quét thông tin nhanh, dễ dàng hơn. Tuy nhiên, không phải biểu tượng nào cũng đủ phổ biến để mọi người hiểu được thông điệp mà bạn muốn truyền tải, do vậy sử dụng biểu tượng cũng phải luôn luôn kèm theo chú thích để giải thích mục đích của bạn: sử dụng chú thích hoặc kèm theo nhãn.

Kết hợp chú thích khi sử dụng biểu tượng.

Đa sắc

Biểu tượng đa sắc thường được thiết kế riêng để phục vụ một số trường hợp nhất định. Và để thiết kế được chúng thì bạn cần phải nắm được một số kỹ thuật để có thể đưa ra được những biểu tượng tối ưu nhất.

Giao diện cài đặt trang của PageFly chứa một số biểu tượng đa sắc.

Bạn sẽ phải làm nhiều thứ hơn là chỉ vẽ chúng ra, xuất bản tệp .svg rồi cho đội ngũ phát triển vì mình không dám chắc rằng nếu làm thế thì bạn có thể được thư giãn hay ngồi nhâm nhi cà phê tiếp và tục công việc của mình đâu.

Về cơ bản, nội dung của một tệp .svg nên là một thẻ <svg> chứa những thẻ <path>, số lượng <path> tương đương với những mảng màu mà bạn thiết kế. Nếu biểu tượng của bạn chỉ có 2 màu mà có tới 5 thẻ <path> kèm theo một đống <line>, <rect> thì chuẩn bị nghe anh em lập trình viên xả đạn đi là vừa.

Với PageFly, bọn mình sử dụng rất nhiều biểu tượng đa sắc và chúng xuất hiện thay những nút bấm có đầy đủ cả trạng thái :hover, :active, :selected. Ở phía thiết kế, mỗi biểu tượng sẽ có 4 trạng thái nhưng mà bạn chỉ cần xuất bản một tệp <svg> cho mỗi biểu tượng rồi để đội ngũ lập trình thay đổi màu của <path> cho từng trạng thái khác nhau. Nhét cả 4 cái tệp <svg> sẽ khiến ứng dụng trở nên nặng nề, hoạt động thiếu mượt mà hơn.

Hãy tưởng tượng nếu bạn thiết kế từng tệp ảnh <svg> cho những biểu tượng này và ném chúng vào ứng dụng?

Cả biểu tượng đơn sắc lẫn đa sắc đều phải tuân thủ quy chuẩn về kích thước, khoảng cách, màu sắc. Luôn luôn ghi nhớ việc giới hạn số lượng lựa chọn.

Trên đây là những quy chuẩn mà tụi mình đã xây dựng để cố gắng bám theo trong quá trình phát triển sản phẩm. Cảm ơn mọi người đã dành thời gian đọc hết bài viết này, hi vọng sẽ còn nhiều dịp để chia sẻ những gì mình học hỏi được trong chuyên môn cũng như cuộc sống!