Lập luận chống lại quy trình
Lập luận gần đây chống lại quy trình thiết kế thường diễn ra như sau:
Quy trình thiết kế truyền thống cảm thấy lỗi thời và tách rời khỏi cách mà công việc tốt thực sự diễn ra.
Việc lặp lại, trực giác, và bỏ qua các bước không phải là sai lầm mà là điểm mạnh. Hãy xây dựng trực giác mạnh mẽ, ám ảnh với chi tiết, và linh hoạt điều chỉnh quy trình cho phù hợp với từng hoàn cảnh.
Những sản phẩm xuất sắc thường bắt đầu từ giải pháp, không phải từ việc xác định vấn đề. Chỉ sau khi nhìn thấy một prototype đủ thuyết phục, người ta mới thực sự hiểu vấn đề mà nó đang giải quyết.
Lập luận này sai ở đâu
Những quan sát này không sai. Nhưng chúng không chứng minh rằng quy trình là không cần thiết. Chúng mô tả chính xác những gì các nhà thiết kế giàu kinh nghiệm vẫn làm: họ nội hóa quy trình và thích nghi nó với công việc, di chuyển linh hoạt giữa khám phá, lên ý tưởng và đánh giá thay vì coi chúng là các bước cứng nhắc.
Những gì trông giống như “bỏ qua quy trình” thực chất là nén nó lại — chạy nhanh hơn qua các giai đoạn và dùng kinh nghiệm làm kim chỉ nam.
Mô hình double diamond (và design thinking) chưa bao giờ được thiết kế như một checklist cứng nhắc. Mục đích của nó là quản lý rủi ro: giúp team hiểu vấn đề, khám phá giải pháp, và giảm khả năng xây dựng sai thứ.
Cách tiếp cận “solution-first” chỉ hoạt động khi không gian vấn đề đã trưởng thành, chứa nhiều tri thức tích lũy, và bạn đang xây dựng dựa trên các pattern đã được thiết lập thay vì tạo ra thứ hoàn toàn mới. Việc giả định rằng bạn luôn biết điều gì là tốt nhất cho người dùng ngoài những bối cảnh này là một cách nhìn đơn giản hóa quá mức.
Nén quy trình, không phải loại bỏ
Trong các lập luận chống lại quy trình, “design process” thường bị xem như một khối thống nhất. Nhưng thực tế, quy trình không phải là thứ bạn либо tuân theo hoàn toàn либо loại bỏ hoàn toàn.
Double diamond không phải là “quy trình”. Design thinking cũng không phải là “quy trình”.
Chúng chỉ là những biểu diễn đơn giản của các giai đoạn mà bất kỳ ai giải quyết vấn đề sáng tạo đều phải đi qua: hiểu điều gì sai, xác định cần xây gì, xây nó, rồi học từ kết quả. Đó là mô tả ở mức cao về những gì xảy ra khi bạn cố giải một vấn đề mà bạn chưa hiểu rõ hoàn toàn.
Lập luận “vứt bỏ quy trình” phần lớn dựa trên cách hiểu sai về cách thiết kế lấy con người làm trung tâm vận hành trong thực tế. Những người có kinh nghiệm triển khai nó một cách phi tuyến và theo ngữ cảnh. Các framework tồn tại để làm cho tư duy trở nên dễ tiếp cận và có thể truyền đạt.
Khi một designer dày dạn làm việc trên sản phẩm tiêu dùng cạnh tranh cao nói rằng “tôi chỉ bắt đầu build”, họ không hề bỏ quy trình. Họ đang nén nó lại — chạy một phiên bản đã được nội hóa, thường trong các paradigm quen thuộc và pattern đã được kiểm chứng.
Việc nén quy trình này được thúc đẩy bởi kiến thức tích lũy về người dùng và nhu cầu của họ, thông qua việc nghiên cứu hành vi người dùng, phân tích đối thủ, và làm việc với các team giàu kinh nghiệm. Thứ được gọi là “trực giác” thực chất là quy trình — đã được nén và nội hóa qua nhiều năm làm việc. Trực giác mà designer tin tưởng được xây dựng chính từ quy trình mà họ đang phủ nhận.
Các công cụ AI tiếp tục tăng tốc quá trình nén này — và dân chủ hóa nó. Vibecoding đã thu hẹp khoảng cách giữa ý tưởng và một thứ có thể kiểm thử; việc khám phá, xây dựng, học hỏi và cải tiến có thể diễn ra trong một buổi chiều. Nếu trước đây designer giàu kinh nghiệm luôn chạy vòng lặp thiết kế nhanh hơn so với framework chính thức, thì giờ đây AI giúp cả những người ít kinh nghiệm cũng làm được điều đó.
Trực giác không thay thế được quy trình
Lời khuyên “hãy tin vào trực giác” trong thiết kế nghe có vẻ giải phóng, nhưng nó đơn giản hóa quá mức một thực tế phức tạp.
Không phải ai cũng có thể vận hành bằng trực giác
Những designer giàu kinh nghiệm đã xây dựng trực giác qua nhiều năm làm việc trong môi trường có văn hóa thiết kế mạnh và team chất lượng cao. Họ có kỹ năng, quyền quyết định, track record và chất lượng team để dẫn dắt bằng trực giác.
Điều này gần như không khả thi với những người mới, chưa tích lũy đủ kiến thức để trực giác trở nên đáng tin. Việc cho phép một senior đưa ra quyết định nhanh dựa trên hiểu biết là hoàn toàn khác với việc bảo một người mới “hãy tin vào bản thân” khi họ chưa tiếp xúc đủ với tri thức tổ chức, hành vi người dùng hay ràng buộc kinh doanh.
Trực giác thiếu tính chịu trách nhiệm
Trong nhiều môi trường, quyết định cần được ghi nhận và giải trình. Các artifact của quy trình — như kết quả nghiên cứu, usability testing, hay dữ liệu analytics — là cần thiết để đạt được sự đồng thuận và phê duyệt từ stakeholder.
Trong hầu hết môi trường doanh nghiệp, câu “tôi làm theo trực giác” sẽ không đứng vững khi một VP hỏi: “Bằng chứng đâu?”
Trực giác không phù hợp với ngành có quy định chặt chẽ
Trong các ngành có rủi ro cao hoặc bị quản lý chặt — y tế, tài chính, chính phủ, hệ thống liên quan đến accessibility — quy trình không phải là thủ tục hành chính mà là cơ chế bảo vệ khỏi sai sót gây hại.
Bỏ qua nghiên cứu cho UI của thiết bị y tế không giống như bỏ qua nghiên cứu cho một tính năng whiteboard.
Trực giác mang theo thiên kiến
Ngay cả trực giác được rèn luyện kỹ lưỡng cũng có điểm mù. Designer giàu kinh nghiệm có thể vô thức bám vào các pattern quen thuộc hoặc bỏ qua các edge case không phù hợp với mô hình tư duy của họ.
Càng có nhiều trực giác, càng khó nhận ra thiên kiến. Quy trình buộc các giả định phải được đưa ra ánh sáng trước khi chúng trở thành sai lầm tốn kém.
Thiết kế “solution-first” chỉ hiệu quả trong phạm vi hẹp
Trong kỷ nguyên AI, nhiều chuyên gia ủng hộ cách tiếp cận “solution-first”: bắt đầu từ khả năng công nghệ mới rồi suy ngược lại xem nó giải quyết được vấn đề gì. Cách này đảo ngược mô hình truyền thống — nơi bạn xác định vấn đề trước rồi mới tìm giải pháp.
Nhưng các ví dụ thành công thường phản ánh survivorship bias. Những gì chúng ta không thấy là vô số thử nghiệm solution-first thất bại: prototype ấn tượng nhưng không chạm được người dùng, hoặc feature được ship nhưng không ai dùng vì không giải quyết nhu cầu thực.
Tốc độ triển khai nhanh là cần thiết khi thiết kế cho công nghệ mới, nhưng tốc độ không làm giảm tầm quan trọng của việc xác định đúng vấn đề. Bạn có thể không cần một problem statement formal hay discovery sprint, nhưng bạn vẫn cần biết mình đang cố sửa điều gì.
Solution-first không giảm rủi ro và chỉ phù hợp với một phần nhỏ của ngành. Nó hoạt động khi pattern sản phẩm đã rõ ràng, người dùng tinh vi, và bài toán chỉ là differentiation. Nó cũng giả định mức độ trưởng thành cao về tổ chức và UX.
Phần lớn team không hoạt động trong điều kiện đó. Trong môi trường ít trưởng thành, thiếu tri thức tổ chức, hoặc bối cảnh mới và rủi ro cao, bắt đầu từ giải pháp có thể làm tăng chi phí của những giả định sai. Trong những trường hợp này, dù chỉ một lượng nhỏ việc xác định vấn đề ban đầu vẫn là cần thiết.
Năng lực hiểu quy trình: chọn quy trình phù hợp với vấn đề
Kỹ năng thực sự trong thiết kế hiện đại không phải là bỏ quy trình — mà là hiểu quy trình: chọn đúng cách tiếp cận và công cụ cho từng bài toán. Biết quy trình nào phù hợp và hiểu rủi ro khi không áp dụng nó.
Tốt hơn hết, đừng nói rằng bạn không dùng quy trình nếu thực chất bạn chỉ đang áp dụng nó theo cách khác.
Điều này không có nghĩa mọi dự án đều cần 6 tuần discovery, hay mọi bài toán đều phải xử lý như thiết bị y tế. Nó có nghĩa là phải khớp quy trình với vấn đề: có bài toán cần nghiên cứu sâu, có bài toán phù hợp với thử nghiệm nhanh và lặp liên tục.
Điểm mấu chốt là lựa chọn có chủ đích, không phải vì ai đó tuyên bố rằng quy trình đã “chết”.
Các công cụ AI hiện nay cho phép prototype và iteration với tốc độ chưa từng có. Nhưng chúng không loại bỏ sự bất định và rủi ro mà quy trình thiết kế giúp giảm thiểu. Designer vẫn cần hiểu vấn đề và đánh giá ý tưởng.
Các framework như double diamond, design thinking hay jobs-to-be-done không phải là quy trình cứng nhắc — chúng là “giàn giáo” tư duy. Khi đã nội hóa, chúng trở thành cách mà những người có kinh nghiệm suy nghĩ và làm việc.
Câu hỏi chưa bao giờ là có nên dùng quy trình hay không. Mà là công việc bạn làm đang ánh xạ như thế nào với vấn đề bạn đang giải quyết.
Khi AI tiếp tục nén workflow và các hệ thống agentic bắt đầu hành động, ghi nhớ và ra quyết định thay con người, việc bỏ qua câu hỏi này sẽ ngày càng trở nên tốn kém hơn, không phải ít đi.