Design thinking is about to become infrastructure có gì mới?

• AI và công cụ lập trình đang làm cho việc tạo giao diện nhanh hơn rất nhiều.
• Vì thế, thiết kế không còn chỉ là vẽ màn hình, mà đang tiến gần vào cách sản phẩm thật sự vận hành.
• Designer sẽ cần hiểu thêm về dữ liệu, trạng thái, API và cách hệ thống thay đổi theo thời gian.
• Design system có thể không chỉ là thư viện giao diện, mà dần thành “luật vận hành” của sản phẩm.
• Dù vai trò thay đổi, design thinking không mất đi mà sẽ trở nên quan trọng hơn trong nền tảng sản phẩm.

Nhiều người làm thiết kế đang có cảm giác hơi lo. Khi AI có thể tạo giao diện rất nhanh, còn kỹ sư phần mềm cũng có thể dựng sản phẩm trực tiếp từ code, câu hỏi xuất hiện rất tự nhiên: designer còn đứng ở đâu trong quy trình làm sản phẩm? Bài viết này cho rằng nỗi lo đó là có thật, nhưng kết luận không phải là thiết kế sẽ bị thay thế. Ngược lại, thiết kế đang dịch chuyển xuống gần “phần ruột” của sản phẩm hơn, tức là gần hơn với cách hệ thống thật sự hoạt động. Trước đây, designer thường làm việc với bản mô phỏng. Nghĩa là ta vẽ ra giao diện, đặt nút bấm, sắp chữ, chia khung, rồi bàn giao cho đội kỹ thuật. Cách này rất hữu ích vì nhanh, ít tốn kém, và giúp thử ý tưởng trước khi code thật.

Bản thiết kế không phải sản phẩm thật. Nó chỉ là hình ảnh đại diện cho hệ thống. Nhiều thứ quan trọng như dữ liệu có thể thay đổi ra sao, trạng thái nào sẽ xuất hiện, lỗi nào có thể xảy ra, hay quy tắc nào giữ cho trải nghiệm nhất quán, thường nằm ở phía code chứ không nằm trong file thiết kế. Điều đang thay đổi là khoảng cách giữa “thiết kế trên màn hình” và “sản phẩm chạy thật” đang ngắn lại. Ngày càng nhiều công cụ AI và công cụ phát triển cho phép làm việc trực tiếp trên giao diện thật, hoặc dùng dữ liệu mô phỏng sát với thực tế hơn. Nói đơn giản, thay vì chỉ vẽ một chiếc áo đẹp trên giấy, designer bắt đầu nhìn thấy chiếc áo đó khi được mặc thật trong đời sống. Khi đó, các vấn đề như chỗ nào bị tràn chữ, nút nào không hợp trạng thái, hoặc màn hình nào thiếu dữ liệu sẽ lộ ra sớm hơn. Tác giả cho rằng đây là lúc design thinking trở nên quan trọng hơn, không phải ít quan trọng hơn.

Nhưng design thinking ở đây không còn chỉ là các buổi brainstorm, workshop hay bài tập dán sticky note. Nó trở thành cách nghĩ để xây dựng cả hệ thống sao cho có thể phát triển lâu dài.

Người dùng cần gì, hệ thống nên phản ứng thế nào, những trường hợp đặc biệt nào có thể xảy ra, và điều gì sẽ giúp sản phẩm nhất quán khi ngày càng lớn lên. Khi thiết kế tiến gần hơn tới phần lõi của sản phẩm, designer không chỉ quan tâm đến “màn hình trông thế nào”, mà còn phải nghĩ đến những thứ đứng phía sau màn hình đó. Ví dụ:

• Dữ liệu từ đâu đến?
• Khi thiếu dữ liệu thì giao diện sẽ ra sao?
• Khi người dùng chuyển từ bước này sang bước khác, trạng thái nào cần được giữ lại?
• Nếu có lỗi, hệ thống sẽ báo thế nào để người dùng không bị rối?

Đây là lý do bài viết nói rằng design đang “đi xuống stack”. “Stack” là cách nói về các lớp kỹ thuật tạo nên một sản phẩm số, từ giao diện người dùng, logic xử lý, đến dữ liệu và hệ thống phía sau. Nói dễ hiểu hơn, thiết kế đang đi gần hơn với nền móng của ngôi nhà thay vì chỉ chăm chút phần sơn bên ngoài.

Design system có thể sẽ không còn chỉ là bộ thư viện thành phần giao diện. “Design system” là tập hợp các quy chuẩn giúp sản phẩm giữ sự thống nhất, như màu sắc, nút bấm, kiểu chữ, khoảng cách, và cách trình bày. Trong tương lai, design system có thể trở thành một kiểu “mô hình vận hành”. Nghĩa là không chỉ quy định một nút bấm nên màu gì, mà còn quy định nút đó hoạt động trong trường hợp nào, khi nào được bấm, khi nào bị khóa, và cách các thành phần phản ứng với dữ liệu thật.

• **Token**: các giá trị nhỏ dùng lại nhiều lần trong hệ thống, như màu sắc, kích thước chữ, khoảng cách.

Hiện nay nó có thể mang nhiều ý nghĩa hơn là chỉ “đẹp hay không đẹp”. - **Component**: một mảnh giao diện dùng lại được, như nút bấm, ô nhập, thẻ thông tin. - **API**: cách các phần mềm nói chuyện với nhau. Có thể hiểu như “cầu nối” để giao diện lấy dữ liệu hoặc gửi yêu cầu. - **State**: trạng thái hiện tại của hệ thống, ví dụ đang tải dữ liệu, đã có dữ liệu, bị lỗi, hay đang chờ người dùng nhập. Điểm đáng chú ý là designer tương lai sẽ cần quen hơn với những thứ trước đây thường thuộc về kỹ sư. Không phải để tự viết hết code, mà để hiểu cách hệ thống tạo ra trải nghiệm. **Những việc designer cần hiểu rõ hơn** - Dữ liệu ảnh hưởng giao diện như thế nào.

• Một màn hình có thể có bao nhiêu trạng thái khác nhau.
• Khi nào trải nghiệm nên ổn định, khi nào nên linh hoạt.
• Các quy tắc kỹ thuật nào có thể làm thay đổi quyết định thiết kế.
• Làm sao để sản phẩm vẫn nhất quán khi nhiều người cùng phát triển.

Tuy vậy, bài viết cũng không tô hồng xu hướng này. Khi thiết kế đến gần sản phẩm thật hơn, designer sẽ nhìn thấy giới hạn sớm hơn. Điều đó có lợi, vì giảm sửa đi sửa lại sau này. Nhưng nó cũng làm quá trình làm việc khó hơn, vì không còn nhiều “khoảng trống mơ mộng” như lúc chỉ vẽ trên file. Nói cách khác, việc thử ý tưởng sẽ ít “rẻ” hơn một chút, vì các quyết định đã chạm gần đến thực tế hơn. Nếu chọn sai từ đầu, cái giá sửa sau có thể cao hơn. Designer cũng có thể phải gánh nhiều thông tin hơn và phối hợp chặt hơn với kỹ sư. **Bài viết chỉ ra vài trade-off rõ ràng** - Ưu điểm: khoảng cách giữa thiết kế và sản phẩm thật nhỏ lại.

• Ưu điểm: phát hiện lỗi sớm hơn, giảm làm lại.
• Ưu điểm: bớt tình trạng thiết kế một kiểu, triển khai một kiểu.
• Nhược điểm: ít không gian hơn cho thử nghiệm tự do.
• Nhược điểm: designer phải hiểu rộng hơn, nên áp lực nhận thức tăng lên.
• Nhược điểm: ranh giới giữa thiết kế và kỹ thuật mờ hơn, cần phối hợp tốt hơn.

Dù vậy, tác giả không xem đây là lý do để lo sợ. Trái lại, đây là cơ hội để thiết kế trở nên thật sự có ảnh hưởng. Khi hệ thống được xây bằng những quy tắc rõ ràng, trải nghiệm cũng sẽ nhất quán và dễ kiểm soát hơn.

Trước đây designer chủ yếu trang trí mặt tiền. Còn bây giờ, designer có thể góp phần viết ra “luật chơi” của cả ngôi nhà. Nếu luật rõ, mọi căn phòng sau này cũng sẽ vận hành trơn tru hơn. Điều đó cũng làm thay đổi cách tổ chức công việc trong đội sản phẩm. Thiết kế không còn là bước cuối cùng để làm cho đẹp, mà dần trở thành một phần của nền tảng sản phẩm ngay từ đầu. Vai trò của designer lúc này không mất đi, mà được đặt vào vị trí sâu hơn và quan trọng hơn. Tác giả kết luận rằng AI không xóa bỏ design thinking. AI chỉ làm nổi bật điều gì đang được đưa vào hệ thống. Nếu hệ thống có tư duy thiết kế tốt, AI sẽ khuếch đại điều tốt đó. Nếu hệ thống thiếu tư duy thiết kế, AI cũng có thể khuếch đại sự lộn xộn.

Thiết kế đang chuyển từ việc tạo ra bề mặt sang việc tạo ra cấu trúc. Designer tương lai cần hiểu sản phẩm ở mức hệ thống, không chỉ ở mức giao diện. Nói ngắn gọn, design thinking không biến mất. Nó đang được cài vào bên trong cách sản phẩm được xây dựng.

Insight giúp bạn nắm ý chính của một bài dài chỉ trong vài phút, thay vì phải đọc hết toàn bộ nội dung gốc. Với những chủ đề như AI, sản phẩm, thiết kế hay công nghệ, điều này rất hữu ích vì bài gốc thường có nhiều khái niệm chuyên môn, nhiều ví dụ và nhiều đoạn giải thích dài. Điểm mạnh của Insight là lọc ra phần quan trọng nhất, diễn giải lại bằng tiếng Việt tự nhiên và dễ hiểu, để ngay cả người không làm kỹ thuật vẫn theo dõi được. Bạn không cần mất thời gian dò từng thuật ngữ, cũng không phải tự đoán tác giả đang muốn nói gì.

Xu hướng nào đang xảy ra, nó ảnh hưởng gì đến công việc, và nên chú ý điều gì trước. Nếu bạn là người bận rộn, đây là cách tiết kiệm thời gian mà vẫn không bỏ lỡ các ý tưởng đáng chú ý. Nếu bạn không chuyên công nghệ, đây là cách đọc nhanh nhưng vẫn hiểu đúng, không bị ngợp bởi thuật ngữ hay câu chữ phức tạp.