UXCamp Vietnam

Viettel Post yêu cầu ứng viên Product Designer có những kỹ năng gì?

UXCamp Vietnam vừa hoàn thành bộ khung, tiêu chí và câu hỏi đánh giá năng lực cho ứng viên apply vào Viettel Post theo request của Design Manager Hương Trần.

Việc trở thành một đơn vị khảo thí độc lập cho các đơn vị / tập đoàn giúp chúng tôi nhìn ra nhiều cái hay:

Ứng viên không chỉ cần có kỹ năng Product Delivery - bao gồm cả Product Design, Product Validation trên diện vừa và nhỏ mà còn yêu cầu có tư duy về số liệu sản phẩm, từ product metrics đến hypothesis testing.

Việc Viettel Post là ứng dụng dành cho end-user cần tối ưu và cải tiến liên tục dựa trên sự thay đổi từ thị trường và hành vi của người dùng cũng yêu cầu một ứng viên nắm chắc kỹ năng thực hiện nghiên cứu (Conducting Primary Research):
Từ việc xây dựng bộ câu hỏi nghiên cứu dựa trên mục tiêu nghiên cứu, đến lựa chọn đối tượng cần nghiên cứu rõ ràng, từ đó giúp việc hiểu ý nghĩa đằng sau những con số hệ thống -> giải thích và cải tiến được trong những lần release tiếp theo thay vì ngồi bàn giấy và đưa ra giả định tại sao số lại thế nọ thế kia!. =))

Chúc Hương và team phát triển lớn mạnh hơn nữa trong tương lai. Mái iuuu.

Các đơn vị có nhu cầu xây dựng bộ khung đánh giá ứng viên / nhân sự inbox cho bảnh luônggg. Ok vào việccc!

Sao cái page này trông lỏ vậy? - Thì lỏ thật, chúng tôi bận wa bảnh ôiiii!

Đợt rồi chúng tôi được chị Hồng Đàm - Head of Design tại ABBANK - Ngân hàng An Bình giao nhiệm vụ xây dựng bài đánh giá năng lực cho ứng viên thuộc khối Khách Hàng Doanh Nghiệp.

Sau khi nhận được các tiêu chí của ABB, nhiệm vụ của chúng tôi là xây dựng được ra các câu hỏi, làm sao cho việc sàng lọc, so sánh các ứng viên nhanh chóng, đúng đắn và khách quan nhất.

Sau mấy hôm cày đêm, cuối cùng bài đánh giá cũng đã hoàn thành và gửi cho ABB đưa vào quy trình tuyển dụng.

Trong hình là các tiêu chí ABB lựa chọn ứng viên phù hợp. Các khía cạnh khác ngoài những tiêu chí trên sẽ được ABB đánh giá thông qua quá trình phỏng vấn và scan CV...

Nói thật, đây là một trải nghiệm thú vị nhưng nhiều thách thức. UXCamp Vietnam cảm ơn chị Hồng, ABB đã tin tưởng giao phó nhiệm vụ. Mái iuuuu ❤

Các đơn vị đang có nhu cầu tuyển dụng và đánh giá nhân sự, inbox cho sốp để kết hợp xây dựng bài đánh giá năng lực nhé!
Ok, vào việc. 🤜🤛

Ngụy thống kê, nguyên nhân và ví dụ.

Có lần phỏng vấn 1 Product Designer: profile đẹp keng, làm toàn chaebol , brand nổi tiếng các thứ. Bạn sharing có lần cải tiến 1 feature giúp NPS tăng từ âm điểm lên 3 mấy, 4 chục điểm. CHỈ SAU 1 LẦN RELEASE!

"Vãj đáj", trong đầu tôi lúc đấy có 2 kịch bản: Hàng real hoặc con vợ này luyên thuyên.

Hỏi 1 hồi thì .... feature v1 release cho all users, còn v2 thì chọn lọc: Chỉ release cho những người dùng v1 tích cực nhất.

Thế mà con vợ lại so sánh NPS của all users v1 với NPS của hàng tuyển v2. Phét lác thật! Con vợ này bị loại.

Tình huống trên dính vào sampling bias - một trong những bias phổ biến của ngụy thống kê (statistical fallacy).

Sampling bias: "Drawing a conclusion about a population based on a sample that is biased, or chosen in order to make it appear the population on average is different than it actually is."

Statistical fallacy: "A statistical fallacy is an error in statistical reasoning where statistical data is misused, misinterpreted, or presented in a biased way to support a misleading or incorrect conclusion"

Nguyên nhân của ngụy thống kê thì nhiều.

Trong survey thì:
Chọn loại câu hỏi sai, đặt câu hỏi mơ hồ không rõ ràng, đến thiên vị nhóm đối tượng, hoặc phân tích trong khi cấu trúc sample không đầy đủ...

Trong product analytic:
Đặt trigger sai, chọn số sai, chọn timeframe phân tích sai, sử dụng điều kiện sai hay diễn giải sai, trình bày sai thì cũng đều đứt...

Kể cho các con vợ 1 ví dụ khác trong product analytic cho dễ hiểu:
Có một cốp của cốp bank yêu cầu ưu tiên luồng chuyển khoản đến người thụ hưởng vì số liệu chỉ ra số lượng giao dịch chuyển khoản đến người đã lưu cao gấp 10 lần chuyển khoản đến người mới.

Quái lạ, nghe rất chi là phản trực giác. Tại quen biết, tôi xin mở quả dashboard nội bộ lên để select theo 1 chiều khác thì số nó lại ra khác. bảo cốp check lại xem chứ nhìn theo 2 aspects khác nhau mà số khác nhau tức là mâu thuẫn rồi. Cốp mất nửa tiếng ngồi soi. Hóa ra cái để ghi nhận là chuyển đến người thụ hưởng được trigger khi người dùng view màn chứ không phải khi họ chọn người thụ hưởng.

Cái này thì phân tích chẳng có vấn đề gì, lỗi tại ông đánh máy.

Để các bảnh khi phỏng vấn ứng viên hay đơn giản là phản biện nhau trong công việc thì nhớ hỏi kỹ:

- Số được lấy bằng phương pháp gì?
- Lấy từ tập người nào? Tiêu chí lấy là gì? Cấu trúc?
- Thu thập trong bao lâu? Phương pháp thu thập?
- Số liệu là gì? Phản ánh điều gì?
- Sâu hơn thì hỏi các bước từ lấy số đến phân tích.

Chỉ cần 1 bước trong này hẹo thôi là đã có cơ sở reject kết luận cuối cùng dòiii.

Chúc các con vợ có số có má, chứ đừng "Số? Má!!!" nhé.

Bài viết được chúng tôi phịa ra vào năm 2025 sau công nguyên. UXCamp Vietnam - uxcamp.vn