Feasibility là gì? Ý nghĩa và vai trò trong dự án sản phẩm
Bài viết này là một phần trong chuỗi 3 bài về ba trụ cột đánh giá sản phẩm trong thiết kế: Desirability (người dùng có muốn không), Feasibility (kỹ thuật có thể làm được không), và Viability (doanh nghiệp có lợi không). Đây là bài về Feasibility – chiều liên quan đến ràng buộc kỹ thuật và những điều designer cần hiểu để cộng tác hiệu quả với engineering. Nếu bạn quan tâm đến hai khái niệm còn lại, có thể đọc thêm tại: Desirability là gì? và Viability là gì?
Định nghĩa của Feasibility
Feasibility – hay khả thi – là mức độ một giải pháp thiết kế có thể được xây dựng và triển khai trong thực tế, với các ràng buộc hiện có về kỹ thuật, thời gian, và nguồn lực.
Trong bối cảnh phát triển sản phẩm số, feasibility thường được đánh giá theo ba chiều:
Technical Feasibility (Khả thi kỹ thuật): Giải pháp có thể được xây dựng bằng công nghệ hiện có không? Hệ thống backend có hỗ trợ tính năng này không? API và data cần thiết có sẵn không? Hiệu năng có đảm bảo ở quy mô người dùng thực tế không?
Time Feasibility (Khả thi về thời gian): Giải pháp có thể hoàn thành trong sprint hoặc timeline của dự án không? Chi phí phát triển có nằm trong ngân sách không?
Operational Feasibility (Khả thi vận hành): Sau khi ra mắt, sản phẩm có thể được vận hành và bảo trì không? Team có đủ năng lực để support và phát triển tiếp không?
Feasibility không phải câu hỏi “có thể làm được không” theo nghĩa tuyệt đối – gần như bất kỳ thứ gì đều có thể làm được nếu có đủ thời gian và nguồn lực. Câu hỏi thực tế là: có thể làm được trong điều kiện hiện tại của dự án không?
Có công cụ nào để đo lường Feasibility không?
Feasibility không có một thang điểm chuẩn duy nhất – nó được đánh giá thông qua một số phương pháp và framework thực tế:
Feasibility Study (Nghiên cứu khả thi): Tài liệu đánh giá toàn diện các chiều feasibility trước khi quyết định đầu tư vào một tính năng hoặc sản phẩm mới. Bao gồm phân tích kỹ thuật, ước tính chi phí và thời gian, và đánh giá rủi ro.
T-shirt Sizing: Phương pháp ước tính nhanh của engineering team – phân loại độ phức tạp và effort theo XS, S, M, L, XL. Không cho kết quả chính xác nhưng nhanh và đủ để so sánh tương đối giữa các option.
Story Points và Sprint Planning: Trong môi trường Agile, engineering team ước tính effort bằng story point và lên kế hoạch sprint. Qua đó xác định tính năng nào khả thi trong sprint hiện tại và tính năng nào cần xếp vào backlog.
Impact vs. Effort Matrix: Framework phổ biến để ưu tiên: đánh giá từng tính năng theo hai chiều – tác động với người dùng (impact) và effort cần thiết để xây dựng (effort). Tính năng có impact cao, effort thấp được ưu tiên; tính năng impact thấp, effort cao thường bị loại.
Proof of Concept (PoC): Thay vì chỉ thảo luận, build một phiên bản prototype kỹ thuật tối thiểu để kiểm chứng xem giải pháp có khả thi về mặt kỹ thuật không. PoC không phải sản phẩm – nó trả lời câu hỏi kỹ thuật cụ thể trước khi đầu tư toàn bộ effort.
Ý nghĩa của Feasibility trong một dự án sản phẩm
Feasibility là một trong ba đỉnh của tam giác cân bằng sản phẩm – bên cạnh Desirability (người dùng có muốn không) và Viability (doanh nghiệp có lợi không). Một giải pháp chỉ đáng được xây dựng khi cả ba điều kiện đều được đáp ứng.
Nhiều dự án thất bại không phải vì thiếu ý tưởng tốt, mà vì thiếu đánh giá feasibility sớm:
- Designer thiết kế tính năng phức tạp mà engineering team ước tính mất 3 tháng để xây – trong khi deadline là 6 tuần
- Một flow yêu cầu real-time data từ hệ thống legacy không có API
- Animation và transition được thiết kế chi tiết nhưng không khả thi trên thiết bị tầm trung – đối tượng người dùng chính
Khi feasibility không được kiểm tra sớm, hệ quả thường là: thiết kế bị cắt giảm tính năng đột ngột ở giai đoạn cuối, hoặc engineering team phải tìm giải pháp thay thế mà không có designer tham gia – dẫn đến sản phẩm ra mắt khác xa với bản thiết kế.
Ai sẽ là người chịu trách nhiệm kiểm soát Feasibility?
Feasibility không phải trách nhiệm của một vai trò duy nhất – nó là kết quả của sự phối hợp giữa nhiều bên:
Engineering Lead / Tech Lead là người đánh giá technical feasibility chính xác nhất. Họ biết kiến trúc hệ thống hiện tại, giới hạn của các công nghệ đang dùng, và độ phức tạp thực sự của từng tính năng.
Product Manager chịu trách nhiệm tổng thể về feasibility của roadmap – đảm bảo những gì được cam kết trong kế hoạch là thực sự khả thi với team và timeline hiện có. PM là người cân bằng giữa kỳ vọng của stakeholder và thực tế kỹ thuật.
UX Designer có trách nhiệm chủ động kiểm tra feasibility của thiết kế trước khi bàn giao cho engineering. Designer không cần biết cách code, nhưng cần đủ hiểu biết để đặt câu hỏi đúng và nhận ra khi nào cần điều chỉnh thiết kế.
Stakeholder / Business Owner đưa ra ràng buộc về ngân sách và timeline – hai yếu tố ảnh hưởng trực tiếp đến scope khả thi của sản phẩm.
Trong thực tế, feasibility được kiểm soát tốt nhất khi designer và engineering làm việc song song từ sớm – không phải khi designer bàn giao bản thiết kế hoàn chỉnh rồi engineering mới bắt đầu đánh giá.
Designer cần chú trọng điều gì?
Cần trao đổi thế nào với các bộ phận liên quan?
Với Engineering:
Trao đổi về feasibility cần xảy ra sớm – lý tưởng là trong giai đoạn Develop của Double Diamond, khi design còn đang ở dạng wireframe hoặc prototype thô. Ở giai đoạn này, chi phí thay đổi vẫn thấp.
Các câu hỏi designer nên chủ động hỏi engineering:
- “Flow này có phần nào phức tạp hơn các phần còn lại không?”
- “Animation này – có phần nào khó implement trên mobile không?”
- “Data cần hiển thị ở màn hình này – có sẵn từ hệ thống không hay cần build thêm?”
- “Nếu tính năng A và B đều cần build, cái nào mất nhiều thời gian hơn?”
Thay vì hỏi “cái này có làm được không” – câu trả lời thường là “có thể, nhưng tốn thời gian” – nên hỏi “cái này mất bao lâu so với option kia” để có thông tin ra quyết định thực tế hơn.
Với Product Manager:
Designer cần hiểu các ràng buộc của sprint và roadmap để thiết kế trong phạm vi thực tế. Khi có nhiều hướng thiết kế, nên trình bày cùng với ước tính effort tương đối để PM có đủ thông tin chọn hướng phù hợp với timeline.
Với Stakeholder:
Khi stakeholder yêu cầu tính năng phức tạp trong thời gian ngắn, designer cần phối hợp với PM và engineering để trình bày rõ trade-off: có thể làm đủ tính năng nhưng cần thêm thời gian, hoặc ra mắt đúng hạn với phiên bản tối giản hơn.
Cần tự bổ sung kiến thức gì?
Designer không cần trở thành developer, nhưng cần đủ hiểu biết để làm việc hiệu quả với engineering. Cụ thể:
Hiểu cơ bản về cách web và app hoạt động: Sự khác biệt giữa frontend và backend, client-side và server-side rendering ảnh hưởng đến tốc độ và khả năng của giao diện. Hiểu điều này giúp designer không thiết kế những thứ đòi hỏi real-time data từ server ở mọi interaction.
Hiểu giới hạn của platform: iOS và Android có design pattern và giới hạn kỹ thuật khác nhau. Animation phức tạp có chi phí hiệu năng. Custom component tốn thời gian hơn native component. Những giới hạn này ảnh hưởng trực tiếp đến quyết định thiết kế.
Hiểu về API và data: Thiết kế cần biết data đến từ đâu và có dạng gì. Nếu một màn hình cần hiển thị 10 loại thông tin khác nhau từ 5 nguồn data khác nhau, đó là tín hiệu cần kiểm tra feasibility với engineering trước khi finalize.
Hiểu về design token và component system: Thiết kế dùng component và token đã có trong design system dễ implement hơn nhiều so với thiết kế hoàn toàn mới. Biết những gì đã tồn tại trong codebase giúp designer đưa ra quyết định nhanh hơn và giảm effort engineering.
Cần có tư duy gì?
Tư duy về constraint, không phải limitation: Ràng buộc kỹ thuật không phải chướng ngại vật – nó là thông tin giúp thiết kế tốt hơn. Designer giỏi thiết kế trong điều kiện thực tế, không phải trong điều kiện lý tưởng không tồn tại.
Tư duy về trade-off: Mọi quyết định thiết kế đều có đánh đổi. Tính năng A có thể làm được, nhưng nếu làm A thì không còn effort cho B – và B có thể quan trọng hơn với người dùng. Hiểu trade-off giúp designer tham gia vào quyết định prioritize, không chỉ nhận yêu cầu và thiết kế.
Tư duy về iteration: Không phải mọi thứ cần phải hoàn hảo ngay lần đầu. Thiết kế phiên bản đầu khả thi về kỹ thuật, ra mắt, đo lường kết quả, rồi cải thiện – thường hiệu quả hơn là giữ lại tính năng chờ đến khi có thể implement đúng 100% ý tưởng ban đầu.
Tư duy về partnership với engineering: Mối quan hệ giữa designer và developer không phải client-vendor – designer đưa yêu cầu, developer thực hiện. Khi hai bên làm việc như đối tác, engineering có thể đề xuất giải pháp kỹ thuật mà designer không biết là có thể làm, và designer có thể điều chỉnh thiết kế theo cách giảm effort mà không ảnh hưởng đến trải nghiệm người dùng.
Học Code for Designer để hiểu thêm về vai trò của lập trình trong dự án
“Code for Designer” không có nghĩa là designer phải trở thành developer. Mục tiêu là hiểu đủ để cộng tác hiệu quả – không phải để tự build.
Những gì designer cần hiểu ở mức độ đọc hiểu:
HTML và CSS cơ bản: Hiểu cách layout được xây dựng, box model hoạt động ra sao, và tại sao một số hiệu ứng CSS đơn giản trong khi những hiệu ứng khác tốn kém về hiệu năng. Figma Auto Layout được thiết kế để phản chiếu cách CSS Flexbox hoạt động – hiểu một cái giúp dùng cái kia tốt hơn.
Hiểu component và props: Cách component trong code hoạt động – với các props (thuộc tính) có thể thay đổi – tương đồng với cách component trong Figma hoạt động với variants và properties. Hiểu điều này giúp designer xây dựng design system phản chiếu cấu trúc code thực tế thay vì tạo ra mô hình không khớp.
Hiểu về state và interaction: Ứng dụng có trạng thái – loading, empty, error, success, disabled. Mỗi trạng thái cần được thiết kế. Designer hiểu khái niệm state trong lập trình sẽ chủ động thiết kế đủ các trạng thái thay vì bỏ sót và để engineering xử lý tùy ý.
Có nhiều tài nguyên và khóa học ngắn dành riêng cho designer muốn hiểu code ở mức độ này – không yêu cầu nền tảng lập trình, chỉ cần đủ để đặt câu hỏi đúng và đọc hiểu những gì engineering đang giải thích.
Kết luận
Feasibility là một trong những yếu tố quan trọng nhất mà designer dễ bỏ qua – không phải vì không biết nó quan trọng, mà vì đánh giá feasibility đòi hỏi kiến thức vượt ra ngoài thiết kế thuần túy.
Designer hiểu về feasibility không thiết kế kém hơn – họ thiết kế thực tế hơn. Biết ràng buộc kỹ thuật không giới hạn sáng tạo; nó định hướng sáng tạo vào những nơi có thể tạo ra tác động thực sự.
Tại TELOS Academy, feasibility và sự phối hợp giữa designer và engineering là một phần trong nội dung của khóa Product Design & Manage – để người học hiểu thiết kế không chỉ ở góc độ giao diện, mà ở toàn bộ vòng đời của một sản phẩm từ ý tưởng đến triển khai. Bên cạnh đó, người học cũng sẽ phần nào trải nghiệm các task đơn giản của coder để hiểu sản phẩm của mình sẽ được hiện thực hóa như thế nào ở lớp Code for Designer. Bạn có thể sẽ quan tâm và muốn tìm hiểu cả lộ trình toàn năng tại TELOS luôn, hãy điền vào form dưới đây.
