logo

HONTRAN.DEV

← Tất cả bài viết

[ Blog ]

10 tháng 7, 2026

7 phút đọc

Chuyên mục: Case Study

Lập Trình Viên Cho Designer: Dự Án Hoàng Moe

Một dev làm website cho designer mổ xẻ dự án Hoàng Moe — cách một trang cá nhân của designer có UX đọc, hệ theme và motion, được engineer ở độ trung thực tối đa.

Case StudyFront-End DevelopmentPortfolioDesignerGEEK UpVietnam
Lập Trình Viên Cho Designer: Dự Án Hoàng Moe

Khách hàng khó build nhất là một designer, vì họ nhìn thấy mọi thứ. Khoảng cách lệch hai pixel, một ease settle sai, một theme toggle bị nháy — một designer thấy hết ngay lập tức, trên chính site của mình, nơi tiêu chuẩn là tuyệt đối. Đó là áp lực tôi làm việc dưới nó khi làm website cho designer, và Hoàng Moe — trang cá nhân của designer kiêm writer Hoàng Nguyễn — là một ví dụ hay. Hoàng làm chủ thiết kế và nội dung viết; tôi build front-end. Bài này là bản mổ xẻ từ phía developer về chuyện build một trang cá nhân cho designer ở độ trung thực họ kỳ vọng.

Anh là ai — và vì sao tiêu chuẩn rất cao

Hoàng Nguyễn là một designer ở TP.HCM, Co-Founder và Design Coach tại GEEK Up, và một người viết năng suất với tác phẩm thu hút lượng quan tâm lớn trên Behance (hàng trăm nghìn lượt xem dự án) cùng một cộng đồng theo dõi trong vai trò người dạy thiết kế. Site của anh không phải một showreel phô trương — nó là một không gian đọc: các bài viết về thiết kế, công việc và cuộc sống, sắp xếp cho những người thực sự ngồi xuống và đọc. Điều đó làm brief tinh tế hơn và, thật lòng, khó hơn một portfolio thông thường.

Tôi sẽ nói chính xác về cách định khung, vì độ chính xác rất quan trọng: Hoàng là một designer và design coach được nể trọng với tầm ảnh hưởng cộng đồng thật — chứ không phải, để rõ ràng, một người thắng giải Awwwards hay FWA, và tôi sẽ không tô vẽ anh thành thế. Việc của tôi là lấy thiết kế của anh và biến nó thành hiện thực trong trình duyệt, một cách trung thực. Khi tôi build cho designer, phần credit giữ đúng sự thật: designer thiết kế; tôi engineer. Ranh giới đó cũng đúng ở portfolio Minh Pham, nơi một Design Lead tại Fantasy làm chủ tầm nhìn còn tôi làm chủ bản build.

Brief: một trải nghiệm đọc, không phải showreel

Site của một designer-writer có trọng tâm khác một portfolio thị giác. Nội dung là dạng dài; giá trị nằm ở sự đọc thoải mái, có cân nhắc. Ba ràng buộc định hình bản build:

  • Sự thoải mái khi đọc là sản phẩm. Theme (sáng/tối) và cỡ chữ điều chỉnh được không phải trang trí ở đây — chúng là UX cốt lõi. Người ta đọc bài của Hoàng trong thời gian dài, và các control phải cảm giác native và tức thì.
  • Độ trung thực là bất khả thương lượng. Thang chữ, độ dài dòng, nhịp, ease chính xác — mọi giá trị phải khớp thiết kế của Hoàng. Trên site riêng của một designer, "đủ gần" đọc ra như một sự tụt hạng.
  • Motion phục vụ việc đọc, không bao giờ cản. Transition và reveal nên làm không gian cảm giác được chăm chút mà không bao giờ xen giữa người đọc và con chữ.

Phần craft: hệ theme, chữ, và motion tiết chế

Một theme toggle không chớp nháy

Lỗi phổ biến nhất trên một site có theme là cú nháy sai theme ở lần paint đầu — một chớp trắng trước khi dark mode kịp vào. Trên site của một designer, cú nháy đó là không chấp nhận được. Cách sửa là giải quyết theme trước khi trình duyệt paint, từ một script inline nhỏ đọc lựa chọn đã lưu và set một attribute lên <html> một cách đồng bộ:

// Chạy trước paint — không nháy sai theme
const stored = localStorage.getItem('theme')
const system = window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light'
document.documentElement.dataset.theme = stored ?? system

Mọi thứ về mặt thị giác sau đó key theo [data-theme] trong CSS custom properties, nên đổi theme là một thay đổi attribute duy nhất mà cả trang phản ứng theo — không re-render, không nháy:

:root[data-theme='light'] { --bg: #faf9f6; --fg: #14110f; }
:root[data-theme='dark']  { --bg: #14110f; --fg: #f2efe9; }

body { background: var(--bg); color: var(--fg); transition: background 0.4s ease; }

Chữ để đọc giữ vững ở mọi cỡ

Vì người đọc có thể đổi cỡ chữ, hệ chữ không thể là một thang pixel cố định — nó phải scale theo quan hệ để độ dài dòng, nhịp và phân cấp sống sót ở mọi thiết lập. Các token fluid dẫn xuất từ một base mà người dùng điều khiển giữ cả cột đọc mạch lạc:

:root {
  --reading: 1.125rem;                 /* base người dùng chỉnh được */
  --step-1: calc(var(--reading) * 1.25);
  --step-2: calc(var(--reading) * 1.6);
  --measure: 66ch;                     /* độ dài dòng vẫn dễ đọc */
}

article { font-size: var(--reading); max-width: var(--measure); }

Khớp chính xác khoảng cách và nhịp của một designer là nửa không hào nhoáng của việc này — kỷ luật sâu hơn nằm trong hướng dẫn làm portfolio đạt giải của tôi.

Motion phục vụ con chữ

Motion ở đây cố tình tiết chế. Các section reveal dùng một ease chung và thời lượng ngắn để trang cảm giác sống mà không bao giờ bắt bạn chờ mới đọc được:

import gsap from 'gsap'
import { ScrollTrigger } from 'gsap/ScrollTrigger'

gsap.registerPlugin(ScrollTrigger)

gsap.utils.toArray<HTMLElement>('[data-reveal]').forEach((el) => {
  gsap.from(el, {
    y: 24,
    opacity: 0,
    ease: 'power3.out',
    duration: 0.7,
    scrollTrigger: { trigger: el, start: 'top 88%', once: true },
  })
})

Và nó lùi hẳn ra cho ai đã yêu cầu điều đó — prefers-reduced-motion tắt phần choreography để trải nghiệm đọc không bao giờ bị một animation bắt làm con tin.

Build cho một designer thực sự đòi hỏi điều gì

Bài học vượt xa một site: khi khách hàng là một designer, việc của developer là trung thực cộng tiết chế — render đúng tầm nhìn, chỉ thêm motion phục vụ nó, và tránh đường cho nội dung. Đó là một kỷ luật khác với một bản build WebGL cực đại, và cũng đòi hỏi không kém. Một designer tin bạn với chính site của họ là lời giới thiệu có tín hiệu cao nhất, vì họ thấy được từng đường may.

Nếu bạn là một designer cần một developer hiện thực hóa trang cá nhân hay portfolio ở độ trung thực đầy đủ, đó chính là việc tôi làm. Xem cách tôi định vị mối hợp tác đó giữa những designer và studio tôi build cho.

FAQ

Hoàng Nguyễn (Hoàng Moe) là ai?

Một designer kiêm writer ở TP.HCM, Co-Founder và Design Coach tại GEEK Up, với tầm ảnh hưởng mạnh trên Behance và cộng đồng theo dõi trong vai trò người dạy thiết kế. hoang.moe là trang thiết kế-và-viết cá nhân của anh.

Vai trò của Hon Tran ở hoang.moe là gì?

Front-end development. Hoàng làm chủ thiết kế và nội dung viết; tôi build site — hệ theme, chữ để đọc, và motion tiết chế — trung thành với thiết kế của anh.

Hoàng Moe có phải một site đạt giải không?

Không, và tôi sẽ không nói khác đi. Hoàng là một designer và design coach được nể trọng với tầm ảnh hưởng cộng đồng thật; site là một không gian đọc cá nhân, không phải một bài nộp giải.

Làm sao tránh cú nháy sai theme?

Giải quyết theme đã lưu/hệ thống trước lần paint đầu bằng một script inline đồng bộ nhỏ set attribute data-theme lên <html>, rồi điều khiển toàn bộ màu từ CSS custom properties key theo nó.

Cùng build site của bạn

Nếu bạn là một designer cần một developer build trang cá nhân hay portfolio ở độ trung thực mà tác phẩm của bạn xứng đáng — đó chính là việc tôi làm.

Viết bởi Hon Tran — creative developer, sáng lập hontran.dev, và thành viên ban giám khảo Awwwards. Hơn 11 năm xây trải nghiệm web đạt giải, ưu tiên hiệu năng (GSAP, WebGL, Next.js) cho khách hàng toàn cầu. Hai lần được Awwwards vinh danh "Independent of the Year" và là người Việt đầu tiên thắng một giải web quốc tế. hontran.dev · Behance.

Bài liên quan