Ở bài trước, tôi cho rằng trước khi tuyển designer, doanh nghiệp cần hiểu mình đang cạnh tranh bằng cách nào. Một Prospector sẽ cần Design tạo ra giá trị khác với một Defender. Từ đó, những năng lực và kiểu designer phù hợp cũng khác nhau.
Nhưng biết mình cần kiểu designer nào vẫn chưa đủ.
Bởi trên thực tế, doanh nghiệp không phải lúc nào cũng có đủ ngân sách để tuyển đúng người mình muốn. Một startup có thể biết mình cần một Product Creator, nhưng chưa đủ khả năng tuyển một người thật nhiều kinh nghiệm. Một công ty đang tăng trưởng có thể biết mình cần Specialist, nhưng quy mô sản phẩm chưa đủ lớn để tuyển riêng cho từng chuyên môn.
Vì vậy, xây dựng một Design Team không đơn giản là câu hỏi:
“Tôi cần designer nào?”
Mà là:
“Với chiến lược, nguồn lực và giai đoạn hiện tại, tôi nên kết hợp những năng lực nào để tạo ra một đội ngũ hiệu quả nhất?”
Tôi cũng muốn nói rõ một điều ngay từ đầu: Nếu Design không phải là năng lực tạo ra lợi thế cạnh tranh đáng kể cho doanh nghiệp, hoặc doanh nghiệp không muốn dành một mức đầu tư tương xứng cho Design, thì hoàn toàn không cần phải cố xây dựng một Design Team lớn. Điều đó không có gì sai.
Nhưng nếu đã xác định Design là một năng lực quan trọng, thì doanh nghiệp cần bắt đầu nghĩ đến đội ngũ, thay vì chỉ nghĩ đến từng designer riêng lẻ.
Từ chiến lược đến đội ngũ
Ở Phần 2, chúng ta đã nhìn doanh nghiệp và designer qua các khung tư duy:
- Chiến lược doanh nghiệp: Prospector (Khám phá), Analyzer (Cân bằng), Defender (Tối ưu & Ổn định), Reactor (Phản ứng).
- Designer Archetypes: Artist (Thẩm mỹ & Khám phá), Product Creator (Logic & Khám phá), Craft Designer (Thẩm mỹ & Chuẩn hóa), Systems Designer (Logic & Chuẩn hóa).
Khi ghép hai góc nhìn này lại, chúng ta định hình được loại năng lực trọng tâm:
- Prospector: Cần nhiều khả năng khám phá → Product Creator và Artist tạo ra nhiều giá trị.
- Analyzer: Cần vừa khám phá vừa tối ưu → Product Creator, Craft và Systems có thể cùng tồn tại.
- Defender: Cần sự ổn định, hiệu quả và khả năng scale → Craft và Systems giữ vai trò cốt lõi.
- Reactor: Rất khó xây dựng Design Team tối ưu vì chiến lược chưa rõ ràng, Design chủ yếu xử lý vụ việc ngắn hạn.
Mô hình này không phải công thức tuyển dụng cứng nhắc. Nó chỉ giúp trả lời câu hỏi đầu tiên: Đội ngũ đang thiếu loại năng lực nào?
Trước khi xây đội ngũ, hãy hiểu “nguyên liệu” mình đang có
Nếu chiến lược cho biết mình muốn “nấu món gì”, thì người đầu bếp cũng cần biết trong bếp đang có những nguyên liệu nào.
Sau nhiều năm làm tuyển dụng và tham gia chấm tốt nghiệp tại một số trường đào tạo thiết kế, tôi nhận thấy nguồn nhân lực Design có sự phân hóa khá rõ.
Phân hóa từ môi trường đào tạo
- Thiên về Visual Design: Sinh viên xuất thân từ Graphic Design, Visual Design, Illustration, Art... có thế mạnh vượt trội về hình ảnh, màu sắc, typography và ngôn ngữ thị giác. Đây là nguồn nhân lực phù hợp cho vai trò Artist hoặc Visual Designer.
- Thiên về Product Design: Sinh viên được đào tạo về UX, UI, Interaction, User Flow... quen thuộc với bài toán sản phẩm số, phù hợp cho vai trò Product Creator hoặc Digital Product Designer.
- Tư duy Khám phá vs. Kỹ năng Công cụ: Có trường khuyến khích khám phá, mạnh về tư duy nhưng yếu kỹ năng thực thi ban đầu; có nơi đào tạo sát công cụ, giúp sinh viên có thể làm việc ngay nhưng dễ bị giới hạn bởi cách tiếp cận quá phụ thuộc vào công cụ.
Background chỉ giúp chúng ta hiểu ứng viên từng tiếp xúc với điều gì. Năng lực thực tế mới là thứ cần tuyển.
Phân hóa từ môi trường làm việc
Môi trường làm việc cũng ảnh hưởng đáng kể đến cách một designer phát triển năng lực. Trong nhiều công ty outsourcing, designer thường được tiếp xúc với nhiều domain, nhiều khách hàng và nhiều loại bài toán khác nhau. Điều này tạo điều kiện để phát triển độ rộng (breadth) và tư duy Generalist. Ngược lại, ở nhiều product company, designer có cơ hội gắn bó lâu dài với một sản phẩm, đào sâu vào người dùng, dữ liệu và hệ thống, từ đó phát triển chiều sâu chuyên môn (depth).
Tuy nhiên, đây chỉ là xu hướng chứ không phải quy luật. Vẫn có những Generalist xuất sắc trong product company, đặc biệt ở các startup hoặc đội ngũ nhỏ. Ngược lại, nhiều công ty outsourcing cũng sở hữu những Specialist rất sâu trong các lĩnh vực như UX Research, Accessibility hay Design System.
Điều quan trọng không phải designer đến từ đâu, mà là môi trường đó đã giúp họ phát triển những capability nào.
Hiểu được bức tranh nhân sự giúp doanh nghiệp biết mình nên: kiếm ứng cử viên từ những trường nào, tuyển capability có sẵn, tìm Generalist đa năng, tuyển Specialist lấp khoảng trống, hay đầu tư đào tạo Junior lâu dài.
Generalist hay Specialist?
Đây không phải là câu hỏi về việc công ty lớn hay nhỏ. Nó là câu hỏi về độ phức tạp của sản phẩm và loại bài toán mà team đang giải quyết.
- Sản phẩm càng mới → càng cần breadth (độ rộng): Giai đoạn đầu có quá nhiều điểm chưa rõ về User, Product và Business Model. Một Generalist có thể đi qua nhiều loại bài toán, làm việc trực tiếp với Product & Engineering để thử nghiệm nhanh và giảm handoff.
- Sản phẩm càng phức tạp → càng cần depth (chiều sâu): Khi sản phẩm trưởng thành, các mảng như UX Research, UI, Motion, Content hay những chuyên môn khác có thể đòi hỏi sự đào sâu mà một Generalist khó đảm nhiệm cùng lúc. Lúc này, Specialist bắt đầu tạo ra nhiều giá trị hơn.
Junior hay Senior?
Nếu Generalist / Specialist đại diện cho Breadth vs. Depth, thì Junior / Senior đại diện cho Kinh nghiệm, Độ tự chủ và Độ phức tạp của bài toán có thể đảm nhận.
- Đừng dùng Junior để thay thế cho capability mà doanh nghiệp chưa có: Tuyển Junior khi chưa có ai định hướng Design rồi kỳ vọng họ giải quyết bài toán chiến lược là một khoản tiết kiệm sai chỗ.
- Senior tạo ra năng lực hiện tại: Họ đem lại khả năng định hình vấn đề, cân bằng User - Business - Tech, ra quyết định trong điều kiện thiếu thông tin và dẫn dắt team.
- Junior là năng lực tương lai: Họ không phải phiên bản rẻ hơn của Senior. Junior là một khoản đầu tư dài hạn, giúp xây dựng văn hóa và sự am hiểu sâu sắc về sản phẩm.
Khoản đầu tư vào Junior chỉ thực sự có ý nghĩa khi trong tổ chức đã có người đủ khả năng hướng dẫn và phát triển họ.
Một đội ngũ tốt không phải là tập hợp những người giỏi nhất
Một team gồm 3 designer rất mạnh về visual sẽ tạo ra sản phẩm đẹp, nhưng có thể thiếu người làm hệ thống hoặc nghiên cứu. Một team toàn Generalist thì tốt về độ phủ nhưng có thể thiếu chiều sâu chuyên môn. Một team toàn Specialist có thể rất mạnh ở từng capability nhưng lại khó giải quyết những bài toán chưa rõ ràng.
Doanh nghiệp không cần tuyển một tập hợp những designer giỏi nhất, mà cần xây dựng: Một tập hợp những người thiết kế có năng lực bổ sung cho nhau.
Sự phát triển đội ngũ qua từng giai đoạn
1. 1 Designer: Ưu tiên một Product Generalist có khả năng làm việc end-to-end.
2. 2–4 Designers: Tăng sự đa dạng về kỹ năng bằng việc bắt đầu bổ sung capability còn thiếu, ví dụ:
Product Generalist + Visual/Craft
hoặc:
UX-oriented + UI-oriented
3. Đội ngũ lớn hơn: Bắt đầu xuất hiện các Specialists chuyên biệt khi workload và độ phức tạp đủ lớn. Có thể là UXR, UI, Design system, Content strategist, Service Designer... và các cấp quản lý từ trung như Lead hoặc Manager hay Head. Tuy vậy điều này không có nghĩa team càng lớn thì càng phải có nhiều chức danh.
Một capability chỉ nên trở thành một role riêng khi nó đủ quan trọng, đủ phức tạp và có đủ workload để vừa đầu tư chiều sâu về kỹ năng. Hoặc cần sự phối hợp, tầm nhìn sản phẩm chiến lược, và tổ chức con người thì có thể tính tới các vị trí quản lý.
Xây dựng đội ngũ là bài toán về sự phù hợp
Xây dựng Design Team là một chuỗi quyết định mạch lạc: Hãy bắt đầu từ business Strategy: Doanh nghiệp đang cạnh tranh bằng chiến lược gì? Sau là chọn một Design Team phù hợp với chiến lược, sản phẩm, nguồn lực và giai đoạn phát triển của chính doanh nghiệp đó.
Kết luận
Xây dựng Design Team không nên bắt đầu bằng câu hỏi: “Chúng ta cần tuyển thêm bao nhiêu người?” Mà nên bắt đầu bằng: “Đội ngũ hiện tại đang thiếu năng lực gì để giúp doanh nghiệp đi đến bước tiếp theo?” Đó là lúc Design bắt đầu được nhìn như một hệ thống năng lực, thay vì một danh sách headcount.
Nhưng xây được team mới chỉ là bước đầu. Khi doanh nghiệp phát triển nhiều sản phẩm, nhiều nhóm làm việc song song, một câu hỏi khác xuất hiện:
Làm thế nào để năng lực của từng designer trở thành năng lực chung của cả tổ chức?
Khi nào nên chọn mô hình Centralized, Embedded hay Centralized Partnership? Khi nào Design cần được tổ chức như một function độc lập? Và khi nào những năng lực như Design System, Accessibility, Service Design hay Design Operations bắt đầu trở thành yếu tố giúp tổ chức scale hiệu quả hơn?
Đó sẽ là nội dung của Phần 4 – Khi nào Design cần bắt đầu scale?
