Trong quá trình tìm hiểu để viết bài này, tôi đã hỏi các HTML engineers về áp lực mà họ đã phải đối mặt trước khi có Design System. Một người anh kể rằng đã từng nghĩ đến việc rời bỏ Got It, vì công việc của anh có những thời điểm rất nhàm chán, lặp đi lặp lại mà không có gì để cải thiện kĩ năng, lại còn phải làm đêm trong thời gian dài để đảm bảo luôn theo kịp deadline, không cân bằng được thời gian cho cuộc sống cá nhân. Nhưng rồi anh lại nghĩ, từ bỏ thì quá dễ, ở lại để giải quyết nó mới là điều đáng làm, dù rất khó khăn.

Còn về phần designers, khi mới vào Got It, nhiều người cũng cảm thấy hụt hẫng, chán nản và đã “khóc” rất nhiều khi không có một tài liệu nào hướng dẫn về branding, styleguide cho sản phẩm, cho nên mạnh ai người nấy thiết kế theo style riêng của cá nhân.

Trên đây chỉ là hai trong số những vấn đề mà team Design của Got It gặp phải trong quá trình phát triển sản phẩm. Nếu bạn tò mò những vấn đề của team Design ở một Got It còn non trẻ là gì, cũng như cách chúng mình giải quyết vấn đề đó ra sao, hãy lấy ngay giấy bút để take note và lắng nghe những kinh nghiệm xương máu của team Got It nhé.

Các thành viên của nhóm

Trước khi vào đề, hãy cùng Got It làm quen với các thành viên của team Design — những “nhân tố nòng cốt” tham gia xây dựng Design System — để dễ hình dung hơn về mạch truyện của bài viết. Khác với nhiều công ty, Got It có một team Design bao gồm 2 team nhỏ:

1. Designers: là những người chịu trách nhiệm về thiết kế giao diện ứng dụng, và hiện tại đang kiêm luôn cả công việc liên quan đến UX.
2. Engineers: là những người chịu trách nhiệm xây dựng layout bằng HTML/CSS, thuộc “biên chế” của team Design, sau đây tạm gọi là HTML engineers. Thực tế, Got It có 1 team Frontend khác rất xịn, riêng biệt, nhưng không tham gia làm HTML/CSS (do công ty không yêu cầu làm công việc này).

Ban đầu, team Design của Got It chỉ có vỏn vẹn 1 designer kiêm luôn HTML engineer. Sau này, team đã có thêm 1 designer, việc thiết kế UI và HTML được chia ra chuyên biệt.

Vài năm trở lại đây, cùng với sự phát triển nhanh chóng của công ty, nhân số team Design tăng lên đến 6 thành viên, trong đó 4 designers và 2 HTML engineers, với trưởng nhóm làm việc tại trụ sở chính tại California và các thành viên còn lại làm việc tại văn phòng Hà Nội.

Do công ty thường xuyên thử nghiệm và thay đổi các tính năng của sản phẩm, nên việc có một sub-team chuyên làm HTML layout thuộc quản lý của team Design ban đầu đã giúp công ty “chạy” rất nhanh trong quá trình làm sản phẩm.

Nhưng cuộc sống không phải lúc nào cũng màu hồng!

Vì sao Got It cần Design System?

Cách chia team Design thành 2 team nhỏ (designers và HTML engineers) bước đầu đã giúp Got It triển khai sản phẩm một cách thuận lợi và nhanh chóng. Tuy nhiên, khi ngày càng có nhiều sản phẩm, mà tiêu chuẩn thiết kế cũng tăng tỉ lệ thuận thì vấn đề bắt đầu nảy ra. Sau khi cùng nhau nhìn lại, team Design của Got It phát hiện ra 3 vấn đề mấu chốt mà mình gặp phải.

Lãng phí nhân lực

Do chưa có một quy trình thiết kế tối ưu nên quá trình thiết kế (design process) thường đòi hỏi rất nhiều nhân lực từ các team:

• PMs: Các PM luôn phải dành thời gian làm việc với các designer để đưa ra các ý tưởng thiết kế, kiểm định (review) và duyệt (approve) bản thiết kế được cho là hợp lý nhất.
• Designers: Tiếp đó, các designer phải làm việc với HTML engineers (trong cùng team Design) để nhận các tư vấn, góp ý về mặt kỹ thuật để đảm bảo mẫu UI đó “có thể triển khai được”. Ví dụ: Mẫu A dễ triển khai hơn mẫu B vì các thành phần đồ họa trong đó đã có sẵn trong code cũ, hoặc các thành phần đó là tiêu chuẩn chung của web nên dễ triển khai hơn so với các thành phần tùy chỉnh trên mẫu B.

• Engineers: HTML engineers làm việc với các Frontend engineers và giải thích về các thành phần trong HTML template mỗi khi có cập nhật (việc này diễn ra thường xuyên). Rồi Frontend engineers sẽ copy mã HTML đó, lồng ghép với code của mình để xử lý dữ liệu và logic.
• QAs: Team QA phải làm việc với engineers và designers để xác nhận tính chính xác của UI và các luồng dữ liệu (flow).

Nghe khá rối rắm phải không? Đó cũng là tâm trạng chung của chúng mình khi ấy. Thậm chí, nhiều lúc mọi người còn… cãi nhau như “mổ bò” vì có quá nhiều khác biệt giữa UI và HTML!

Thử thách về chất lượng — tiến độ

Ở bài viết trước, bạn có thể thấy từ 2016 Got It bắt đầu lên đà tăng trưởng, số lượng sản phẩm ngày càng nhiều, các tiêu chuẩn thiết kế cũng tăng theo, trong khi chỉ có 2 người làm HTML (cần biết rằng: Got It tuyển dụng rất khắt khe), thì xảy ra vấn đề: HTML engineers bắt đầu không thể kiểm soát được chất lượng cũng như đảm bảo bàn giao công việc đúng hạn, vốn thường rất gấp gáp. Nếu như công đoạn này bị tắc thì sẽ ảnh hưởng đến toàn bộ quá trình phát triển sản phẩm.

Sự thiếu nhất quán dẫn đến lãng phí thời gian, chi phí…

Các designers phải dành nhiều thời gian để lặp lại công đoạn tạo ra các mẫu đề xuất và thảo luận với các PM về nó. Có những thành phần đồ họa được phía PM gợi ý triển khai, nhưng các designers thì lắc đầu quầy quậy, lý do vì sao thì chắc các bạn designers tự hiểu rồi đấy!

Do chưa có các tiêu chuẩn về thiết kế (rules, reusable and situations definition), dẫn đến thường xuyên xảy ra việc thiếu nhất quán trong các bản thiết kế. Điều này khiến Engineers không thể kiểm soát quá trình xây dựng/cập nhật mẫu HTML:

• Tốn nhiều thời gian để tạo ra code mới, có khi chỉ được dùng 1 lần, rồi phải test đi test lại trên các trình duyệt và kích cỡ màn hình khác nhau.
• Do mẫu UI có “các biến thể” một cách “vô tình” từ phía designer, nên phải sao chép lại code cũ rồi sửa đi 1 chút, dẫn đến việc liên tục phải sửa HTML/CSS để đè lên style cũ, thành ra cũng lại phải test đi test lại trên các trình duyệt và kích cỡ màn hình khác nhau.

• Phải dành thời gian để bảo trì nhiều “biến thể” khác nhau ở nhiều nơi, dù cho chúng cùng thực hiện 1 tính năng. Việc cập nhật mỗi khi có thay đổi là rất tốn thời gian và khó khăn.
• Khi chuyển giao HTML/CSS tới team Frontend luôn phải giải thích cặn kẽ về việc: “What’s the HTML/CSS update for this version?”.

Chung quy lại, gốc rễ của vấn đề chính là sự thiếu nhất quán về thiết kế (Inconsistent design).

Để giải quyết những vấn đề trên, team Design đã tìm hiểu và thống nhất sẽ phát triển một hệ thống Design System riêng cho Got It, đảm bảo đáp ứng đúng các yêu cầu về đặc thù sản phẩm của công ty.

Quá trình phát triển Design System

Quá trình phát triển Design System của Got It được chia làm 2 giai đoạn lớn: Giai đoạn 1 (8–10/2019) và Giai đoạn 2 (1–3/2020). Hệ thống này được xây dựng với mục tiêu trở thành:

Để xây dựng được hệ thống như thế, team Design đã trải qua rất nhiều khó khăn, từ quy trình làm việc cho đến tìm kiếm và áp dụng công nghệ. Ở phần này, Got It sẽ chia sẻ về các thành phần của Design System, cũng như những khó khăn đã gặp phải, cách khắc phục và các bài học rút ra. Hy vọng đây sẽ là một tài liệu tham khảo hữu ích để giúp các huynh đệ “cùng cảnh ngộ” giải quyết bài toán của mình nhé. Nào, giờ thì cùng lấy giấy bút ra thôi!

Quy trình — Khi team Design lần đầu áp dụng G Process của chính Got It

Ở Got It, có một nguyên tắc là Data-driven. Nếu muốn đề xuất một thay đổi gì đó, bạn cần đưa ra số liệu thống kê, dẫn chứng đầy đủ để thuyết phục mọi người. Và rất có thể, bạn sẽ phải thuyết trình trước tập thể công ty để chứng minh điều mình nhận định là đúng.

Đối với team Design, ban đầu, việc này được coi là “quá sức”, bởi Design vốn là một cái nghề nhiều cảm hứng và dị ứng với những thủ tục, con số. Nhưng ở Got It lại chỉ có khoa học, không có đặc cách để nuông chiều cho những gì đã cũ. Founder Hung Tran biết rõ tính cần thiết của Design System tại Got It, nhưng vẫn phải nói rắn: “Các chú phải tuân theo đúng G Process thì mới được, nếu không thì anh cũng chịu!”.

Team Design đã liên hệ với các PM để học hỏi và áp dụng G Process. Hóa ra việc này rất có ích, vì ngoài việc biết áp dụng theo G Process, cả team còn “học lỏm” được Product Design Process từ các PM nữa. Song cũng phải nói rằng, cả team đã phải làm đi làm lại rất nhiều lần tài liệu G mới được chấp nhận, thậm chí có những phần phải dành cả tháng trời mới xong.

Phương pháp — Không biết phải bắt đầu từ đâu, choáng ngợp trước nhiều thông tin tìm hiểu trên internet

Có rất nhiều thông tin về Design System, về thiết kế module hóa,… thậm chí ngay cả khái niệm Design System cũng mỗi nguồn một khác. Cả team đã phải đơn giản hóa khái niệm về Design System sao cho dễ hiểu nhất, lược bỏ một số tiêu chí tạm coi là chưa cần thiết trong giai đoạn đầu (ví dụ như bỏ qua “Voice and Tone”, đơn giản vì team tự thấy chưa làm được phần này).

Ngoài ra, team Design cũng phải “đánh cái hẹn” với bạn bè ở các công ty khác để trao đổi và góp nhặt những gợi ý thực tế về cách tổ chức Design System, cũng như học hỏi kinh nghiệm của họ.

May mắn là đã từng biết đến phương pháp Atomic Design, nên sau khi bàn bạc kĩ lưỡng, team Design đã chọn tổ chức và xây dựng UI Components theo cách này.

Thống kê, kiểm định lại toàn bộ các thành phần đã thiết kế (cực khổ lắm các bạn ạ). Phải gán mác chúng vào một component nào đó, nói cách khác là phải đặt tên cho chúng. Ví dụ: Buttons, Ask form (form đặt câu hỏi đặc trưng của ExcelChat), Carousel, Modals, Tabs,… Sau đó so sánh và đồng nhất chúng về một giao diện, cân nhắc tạo thêm các biến thể giao diện của nó nếu cần.

Thời gian — Không biết cách phân bổ thời gian, kế hoạch hợp lý

Mặc dù đã vượt qua 1 số trở ngại, bước vào giai đoạn xây dựng kế hoạch phát triển Design System thì cả team lại gặp phải vấn đề là:

• Không biết phải làm những gì trước (quá nhiều thứ cần phải design lại)
• Thời gian làm trong bao lâu (3 ngày, 1 tuần, 1 tháng, 6 tháng, hay 2 năm thì xong?)
• Làm như thế thì đầu ra (output) sẽ là những gì?

Hàng tuần, cứ hết lần báo cáo này đến lần báo cáo khác, team không đưa ra được một “output” nào cả. Rõ ràng cả team đã không có kiến thức tốt để giải quyết vấn đề này.

Và rồi Founder Hung Tran tham gia hỗ trợ, góp ý rằng không nên ăn một miếng bánh quá to, vì nó khiến mình nghẹn mà không thể ăn được gì tiếp. Anh đã đưa ra cho team nhiều gợi ý, từ hướng dẫn lựa chọn Sprint 2 tuần cho đến việc liên tục giữ cảm hứng bằng cách bằng mọi giá phải đưa ra được “một cái gì đó” sau mỗi Sprint. Quan trọng nhất là thái độ “Get shit done” — đã đưa ra kế hoạch thì phải bám sát để hoàn thành kế hoạch, bất kể thức đêm thức hôm, phải thật sự quyết tâm. Anh cũng khuyên các HTML Engineers nên tự học thêm ReactJS để về lâu dài có thể tự phát triển Design System,…

Nhân sự — Team Design hiện không thể xây dựng được một Design System hoàn thiện bao gồm cả giao diện UI và Code

Nhân sự trong team chỉ có Designers và HTML engineers thực hiện các đoạn mã tĩnh, vậy làm sao để triển khai được code ở dạng React Component?

Team đã đề xuất sự tham gia của team Frontend, từ đó có thể xây dựng được cả UI và Code tương ứng. Qua đó HTML engineers cũng đã học được nhiều kỹ năng từ Frontend engineers.

Cách tiếp cận mới về triển khai CSS

Bootstrap CSS framework đang rất thông dụng. Bản thân các sản phẩm của Got It cũng đang sử dụng Bootstrap, thậm chí từ thời Bootstrap 2.x. Qua nhiều năm làm việc với thư viện CSS này, team Design dường như đã quá rõ về nó. Và các HTML engineer nhận ra một điều: Nếu cứ dùng thư viện kiểu này thì khi có càng nhiều component sẽ phải viết càng nhiều CSS, dẫn đến việc sản phẩm sẽ luôn “bị phụ thuộc” vào HTML engineers. Giả sử những cá nhân này nghỉ phép, hoặc thậm chí nghỉ hẳn công việc ở Got It, thì ai sẽ đảm nhiệm được phần HTML/CSS đây? Nếu cùng 1 thời điểm, có 4 đến 5 sản phẩm cần cập nhật và đều gấp rút như nhau thì liệu 2 người có làm kịp hay không? (Bạn nào đang áp dụng nó thì sẽ rất rõ vấn đề này)

Chúng mình nghĩ đến việc xây nhà, ngôi nhà nào cũng có nhiều phòng, phòng nào cũng đều được xây dựng bởi những viên gạch. Lúc này một ý tưởng lóe lên: “Thế thì liệu có thể xây dựng một thư viện CSS chỉ có những thành phần cơ bản nhất thôi hay không? Rồi mình sẽ dùng nó như những viên gạch để xây dựng các components!”. Thực tế là team Design của Got It không hề sáng tạo ra cách tiếp cận này, mà đơn giản là chợt nghĩ đến và tìm kiếm xem liệu có ai đó trên đời đã thử áp dụng/kiểm định hiệu quả của cách đó hay chưa thôi.

Sau khi google, chúng mình đã nhận thấy chỉ có một số ít nguồn đề cập đến chủ đề này lúc bấy giờ (nổi bật hơn cả là Tailwind CSS). Và thế là cả team bắt đầu tìm hiểu kỹ hơn về nó để về sau có thể tự tin áp dụng ý tưởng này vào Got It Design System.

Phân tích các thành phần của Design System

Hướng tới đối tượng người dùng là chính các Designers, PMs, Engineers và QAs trong nội bộ nhóm làm sản phẩm, team Design của Got It đã xác định các thành phần chính cần phải xây dựng bao gồm: Style guide, UI Library, Code components và Design process (quy trình thiết kế) áp dụng Design System.

Style Guide

Style Guide là một bộ quy tắc tập hợp các tiêu chuẩn áp dụng cho việc quản lý branding; cách sử dụng màu sắc, text styles, illustrations,… trong thiết kế sản phẩm.

Ví dụ ở đây, các màu sắc được phân rõ chính, phụ, kèm mã màu và hướng dẫn sử dụng vô cùng cụ thể. Không chỉ team Design mà bất cứ team nào cần đưa ra hình ảnh, thông điệp, hoặc bất cứ sản phẩm nào mang màu sắc thương hiệu Got It đều có thể dễ dàng tham khảo và làm theo.

UI Library

UI Library là một file Sketch quản lý các components được tạo ra dưới dạng các Smart Symbols, Text Styles và Layer Styles mà các designers có thể dễ dàng thêm vào thư viện trong Sketch để sử dụng trong khi thiết kế. Khi cập nhật các thành phần trong thư viện này, các files sử dụng chúng sẽ nhận được thông báo cập nhật.

Code components

Mỗi component được tạo ra trong UI Library đều được team Design triển khai một phiên bản code ở dạng React Component. Cùng với UI Library, thư viện Code Components cũng cập nhật liên tục các mẫu, trạng thái, ví dụ thực tế kèm theo các đoạn Code Example, nhằm hỗ trợ công việc của các Frontend engineers, và chủ động bám sát những thay đổi của sản phẩm.

Design Process

Quy trình thiết kế cũng được thay đổi sau khi đưa Design System vào sử dụng. Việc sử dụng lại các components đã có sẵn giúp tiết kiệm thời gian thiết kế, đẩy nhanh việc triển khai các phương án thiết kế khác nhau cho một vấn đề, các Designers có thêm thời gian để tập trung hơn vào thiết kế nâng cao trải nghiệm người dùng.

Dù nhìn quy trình phức tạp hơn, nhưng thực tế khi áp dụng thì Design Process đã được thu gọn đáng kể so với trước đây. Ví dụ, trước đây mỗi lần nhận task và chuẩn bị mock design cho askbox, designer đều phải “đẻ ra” một phiên bản mới, dẫn đến vừa tốn thời gian, vừa dễ bị khác với những gì đã làm trước đó. Mà giả dụ có thể dùng lại những thiết kế của askbox cũ, thì việc tìm lại cũng khá… hên xui vì không có hệ thống lưu trữ thống nhất cho cả team. Chưa kể, cách làm này rất khó để đi lâu dài, công việc dễ trở nên rối rắm khi ngày càng có nhiều sản phẩm.

Còn với Design Process mới, khi đã có một thư viện (library) các components có sẵn, designer có thể chỉ đơn giản lấy component mình cần ra dùng, hoặc lắp ghép các components với nhau để tạo ra cái mình muốn. Nếu chưa có component nào thì tạo ra thêm, rồi lại đưa vào thư viện để sau này có thể tái sử dụng, không cần mất thời gian lục lọi trong vô vọng, hay lo lắng về thiết kế không thống nhất.

Với những yêu cầu đòi hỏi phải tạo mới các components, các bên liên quan bao gồm PMs, Designers và Engineers sẽ cùng ngồi lại với nhau để thảo luận, bàn bạc để tạo nên các components mới không chỉ giải quyết các vấn đề hiện tại, mà còn tính toán để có thể sử dụng lại trong tương lai.

Bài học rút ra

Từ quá trình đầy “bão táp” để tạo nên Design System, team Design nhà Got It đã rút ra được kha khá những bài học, cũng là lời khuyên và gợi ý muốn chia sẻ đến các bạn đang gặp bài toán tương tự:

• Phải nói lên vấn đề mình gặp phải để các cấp quản lý cũng như đồng nghiệp tìm cách hỗ trợ xử lý kịp thời.
• Các team phải biết kết nối với nhau, đồng lòng cùng xử lý vấn đề chung.
• Biết tiếp thu học hỏi từ người khác, không nên bảo thủ. Nên học hỏi thêm nhiều kỹ năng khác tuy rằng công việc chính của mình chỉ là design hoặc code, nó sẽ là công cụ hữu ích cho mình trong quá trình phát triển sự nghiệp.
• Biết mạo hiểm chọn giải pháp mới, phù hợp với đặc thù sản phẩm của công ty.

Thành quả — Design System đã thay đổi công việc của các Got It-ians ra sao?

Nhìn chung: Sau một thời gian được đưa vào sử dụng, Design System đã chứng minh hiệu quả trong việc.

Cụ thể:

• PMs: Việc nắm được bao quát các thành phần hiện tại có trong sản phẩm giúp PMs dễ dàng hơn trong việc triển khai các yêu cầu, ý tưởng, lo-fi mocks. PMs trao đổi dễ dàng hơn với bộ phận kỹ thuật thông qua một ngôn ngữ chia sẻ chung nhờ cách đặt tên các components, prop và CSS utilities trong Design System.
• Designers: Thiết kế của sản phẩm được thống nhất, chất lượng các bản thiết kế từ các Designers trong team tương đối đồng đều theo tiêu chuẩn đã đề ra. Thay vì dành hết thời gian để chỉnh sửa mẫu thiết kế, Designers có thêm thời gian để tập trung vào thiết kế trải nghiệm người dùng.
• Engineers (bao gồm HTML engineers và Frontend engineers): Được kiểm chứng qua quá trình phát triển 2 sản phẩm gần đây của công ty, tốc độ triển khai HTML template nhanh hơn đáng kể: 40% đến 50%. Các Frontend engineers vốn chưa từng tự tạo HTML layout thì nay dựa vào DS dần dần đã biết cách áp dụng, chủ động hơn về mặt công việc, giảm phụ thuộc vào HTML engineers.
• QAs: Do nhất quán từ UI đến Code, nên không phải test đi test lại các thành phần UI nữa, dành nhiều thời gian tập trung vào việc test logic kỹ càng hơn.

Kế hoạch tiếp theo của team

• Phân tích, đánh giá khả năng áp dụng Design System vào các sản phẩm khác trong platform vốn dĩ đang sử dụng phương pháp cũ.
• Một số thành viên trong team tiếp tục học thêm về ReactJS để có thể chủ động tự bảo trì, cải tiến, thêm mới các thành phần cho Design System. Tương lai có thể tham gia vào team Frontend để tiến thêm một bước trong quá trình phát triển sự nghiệp.
• Chuyển giao công đoạn tạo HTML layout sang team Frontend vì giờ đây họ đã có thể tham khảo code mẫu của Design System trực tuyến (vẫn có sự hỗ trợ từ phía HTML Engineers), tiến tới cắt giảm nhân lực làm HTML/CSS trung gian (HTML engineers), giúp Design Process được tối ưu hơn nữa.
• Nghiên cứu xây dựng thêm các công cụ nội bộ hỗ trợ việc tạo layout bằng kéo thả. Trước mắt thử nghiệm với việc tạo những trang web tĩnh dạng landing page. Tiêu chí là dễ dùng nhất có thể cho các PM, Designer và bộ phận làm Branding/Marketing.

Việc xây dựng Got It Design System đã có sự đóng góp ý kiến, chia sẻ kinh nghiệm của bạn bè đồng nghiệp khắp nơi, giúp mọi thứ rõ ràng hơn. Đối với các kế hoạch tiếp theo, chắc chắn team Design sẽ có lúc nhờ cậy thêm từ mọi người, rất mong sẽ lại nhận được sự giúp đỡ của bạn bè gần xa!

Bạn có thể tham khảo Design System của Got It tại: https://designsystem.got-it.ai/