Phần docs còn lại Py cần viết là “Screen Description”, ý như câu chữ: mô tả màn hình. Trong context của task “vỡ lòng”, phần này chứa nhiều kiến thức và kỹ năng cần phải học thêm trong giai đoạn đầu chuyển hướng sang con đường làm sản phẩm; thậm chí xa hơn, là “nền tảng” giúp Py lên backlog và roadmap cho các kỹ năng tiếp theo.
Dàn ý
Thường Py sẽ đề cập đến:
- Tên của “component” cần mô tả: thật ra không có chuẩn gì hết, gọi tên như thế nào để chỉ cần đọc qua là có thể dễ dàng nhận biết phần nội dung tiếp theo đang mô tả cho “section” nào trên màn hình là được
- Loại của “component”: phân loại nhanh loại “mảnh ghép” đang mô tả trên màn hình là gì — input field, button, checkbox, dropdown…
- Mô tả cách user sẽ tương tác trên màn hình: hành vi và logic hoạt động của component đó. Ví dụ: khi nào thì hint hiện, lúc nào validation được trigger, nhập sai thì hiện lỗi ra sao… Mục đích là để người đọc hiểu cách mà user sẽ tương tác thực tế với phần này trên UI, kể cả thao tác chủ động (như gõ, chọn) lẫn phản hồi từ hệ thống. Có thể hiểu đây là phần “giao tiếp” giữa user và component, nên càng cụ thể – càng khả thi.
Ví dụ by Anpy
“Format” có thể sẽ khác, nhưng nhìn chung các docs Py viết sẽ đều có phần điểm qua các nội dung trên. Nếu user flow và wireflow mà map tổng thể, thì phần 3 như việc “zoom-in” vào từng phần trên map.
Trở về task vỡ lòng, vì chỉ cần docs lại những logic đã được built, nên Py chỉ việc thao tác trên app + cross-check lại Dev và QC để đảm bảo tổng hợp đủ rules. Còn đối với tính năng mới việc viết lại mô tả trên từng màn hình là không gian chiêm nghiệm để PO xem lại tổng quan về UX1. Đây cũng là phần nội dung để QC lên test cases, team CS tham khảo để tư vấn cho khách hàng… nên nói chung, docs có thể tồn tại ở nhiều format, template (PRD, SRS…) nhưng luôn là phần bắt buộc phải có, thậm chí cần đảm bảo up-to-date.
Từ điển UX
Ngay từ bước vẽ wireframe, BA/PO đã bắt đầu làm quen với các loại component như button, input field, linked text… – những từ ngữ chỉ cần nghe đến là có thể hình dung ngay user sẽ thao tác gì: chọn, bấm, điền hay cuộn. Như đã đề cập trong Vỡ lòng (2), một số công cụ hiện nay hỗ trợ sẵn wireframe cùng tên gọi các component phổ biến. Nhưng dĩ nhiên, việc chủ động “google” để hiểu ý nghĩa và cách dùng từng loại component vẫn là nhiệm vụ không thể bỏ qua.
Nếu bạn quen dùng Figma để dựng wireframe, có thể tìm các file UI kit được chia sẻ miễn phí trên Figma Community (ví dụ: iOS/Android UI KIT). Tuy nhiên, cần lưu ý rằng những bộ kit này thường dành cho Designer, nên PO sẽ cần kinh nghiệm nhất định để chọn lọc component phù hợp – hiểu rõ loại nào nên dùng khi nào, và vì sao.
Trước đây, Py cũng dành thời gian đọc thêm các Design System như của Apple2, Google3, hay Ant Design4 – như một cách để cập nhật từ vựng, cách gọi tên, thao tác (gesture), và ngữ cảnh sử dụng của từng component. Những kiến thức này như vốn từ cơ bản, để từ đó bạn có thể mô tả hành vi người dùng một cách chính xác hơn. UX là một chủ đề rộng, thay đổi liên tục, nhưng cũng là phần “nền móng” tạo nên chất riêng của người làm sản phẩm. Nên “khẩu quyết” xuyên suốt hành trình vẫn vậy: đọc nhiều vào, quan sát nhiều vào.
Bước tiếp theo
Task vỡ lòng mang đến cho Py điểm bắt đầu để dần tiến sâu hơn vào con đường làm sản phẩm: hiểu đúng các khái niệm. Những năm tháng đó, nhiệm vụ quan trọng nhất vẫn là deliver tính năng, nên Py tập trung nhiều vào UX và việc các FE/BE tương tác với nhau như thế nào. Cụ thể hơn, sau task vỡ lòng, Py nhận được yêu cầu làm lại một tính năng đã vận hành nhưng khó sử dụng – KYB (KYC cho khách hàng là merchant). Thế là thay vì chỉ viết lại mô tả, Py cần define lại user flow, wireflow – cũng là lúc nhiều skills khác được unlock và đã được Py chia sẻ đâu đó trên chiếc blog bé nhỏ này.
Làm sao để đắp kinh nghiệm về UX? Có lẽ ChatGPT hay các LLM model khác sẽ có những câu trả lời mang tính “framework” hơn, còn đây là những gì Py đã, đang và sẽ là:
- Tự vấn bản thân về “lựa chọn UX” của các app hằng ngày đang sử dụng (chẳng hạn như vì sao có web bắt buộc dùng mail + pass để đăng nhập, nhưng cũng có web chỉ cần số điện thoại + OTP), tương tự phần Bài tập nhỏ của bài viết Moral Design.
- Trải nghiệm nhiều app/web, làm kỹ các câu hỏi research: các app/web khác đang xử lý như thế nào khi build tính năng
- Tham khảo khóa Google UX Design Professional Certificate5 – Theo Py cần tập trung các Module nền tảng (1 và 2) để tiết kiệm chi phí – hoặc cũng có thể request Financial Aid (như Py đã từng).
Túi mù: bolt.new
Chỉ với 1 câu prompt và wireframe là đã có thể dựng nên bản demo của màn hình đó. Có thể tận dụng tool này để phát hiện các “điểm mù” cần được define thêm. Và vẫn là lưu ý với các tool mới, sẽ cần thời gian để làm quen trước khi nó thật sự hữu dụng cho công việc hàng ngày.
Có thể trong thời gian tới, BA/PO sẽ không tiếp cận việc “build tính năng” giống như cách Py đã từng, vì hiện tại đã có nhiều công cụ hỗ trợ giúp tiết kiệm đáng kể resource (thời gian, sức lực), để từ đó tập trung nhiều hơn cho product discovery. Dù vậy, với Py, việc học “cách làm” trước khi đi sâu vào câu hỏi “vì sao phải làm” vẫn mang ý nghĩa nền tảng – đặc biệt trong thế giới công nghệ, nơi có không ít thứ được làm đơn giản vì… nó dễ làm.
- Interaction Design Foundation. (n.d.). UX Design. Retrieved May 12, 2025, from https://www.interaction-design.org/literature/topics/ux-design
- Apple Inc. (n.d.). Human Interface Guidelines. Retrieved May 12, 2025, from https://developer.apple.com/design/human-interface-guidelines
- Google. (n.d.). Material Design 3. Retrieved May 12, 2025, from https://m3.material.io/
- Ant Group. (n.d.). Design Specification | Ant Design. Retrieved May 12, 2025, from https://ant.design/docs/spec/introduce/
- Coursera. (n.d.). Google UX Design Professional Certificate. Retrieved May 12, 2025, from https://www.coursera.org/professional-certificates/google-ux-design
Bài viết trải dài nhiều phần và vẫn còn nhiều khía cạnh chưa được giải thích cặn kẽ để có dịp “kể” thêm ở các bài viết sau, mong là bạn vẫn ở đây, đến cuối bài viết như mọi khi.
Chúc bạn nhiều may mắn và bình an.
Anpy
Leave a Reply