Căn bản thiết kế Concept trong xây dựng sản phẩm phần mềm

Dạo gần đây, mình nhận được khá nhiều câu hỏi: “Không technical thì viết spec như thế nào để Dev hiểu?”, hoặc “Tại sao spec đã viết mà Design vẫn thiếu screen, QA vẫn thiếu case, còn Tech thì bảo chưa đủ technical?”

Theo mình, vấn đề không hẳn nằm ở việc PM không biết code. Nhiều khi do PM chỉ mới mô tả được màn hình có gì, user bấm vào đâu, nhưng chưa mô tả được hệ thống vận hành như thế nào.

Mình thấy vấn đề này có 3 triệu chứng sau:

• (1) Bắt đầu bằng màn hình thay vì đối tượng nghiệp vụ: có flow và UI, nhưng chưa rõ dữ liệu, trạng thái và logic phía sau.
• (2) Mô tả ở tầng trừu tượng quá thấp (Quá technical) khiến team không hiểu feature sẽ generalize như thế nào, hoặc ở tầng trừu tượng quá cao (Quá high-level), không biết feature sẽ hành xử cụ thể ra sao.
• (3) Không mô tả edge case của tính năng mà chỉ mô tả được happy path.

Bài này không cam kết giải quyết toàn bộ bài toán viết spec cho PM không technical, nhưng với nhu cầu nâng cấp suất ăn cho độc giả The Poly Manager, mình hi vọng phần nào sẽ giải đáp được vấn đề trong bài hôm nay.

Để dễ hình dung, thử bắt đầu bằng một ví dụ quen thuộc: nếu phải build lại VNExpress, mình sẽ spec nó như thế nào?

Nếu phải build lại VnExpress?

Nếu một ngày bạn lead 1 team Product và được giao nhiệm vụ "clone" lại VNExpress, tức là build ra lại trang báo đình đám nhất Việt Nam, bạn sẽ mô tả sản phẩm này như thế nào để team hiểu và build đúng?

Nghe dễ đúng hông? Nhưng tin mình đi, nó phức tạp hơn bạn tưởng.

Phản xạ thường gặp nhất, kể cả với mình hồi mới làm Product, là mô tả theo những gì nhìn thấy trên màn hình: "Trang chủ có 1 banner thời tiết, dưới đó là list bài viết, mỗi bài có title, mô tả ngắn, category, nút bookmark. Bấm vào bài thì mở ra trang đọc, dưới bài có khung comment."

Nghe thì đầy đủ, vẽ ra cũng dễ hình dung. Nhưng nếu bạn đưa bản mô tả này cho dev, sớm muộn họ cũng sẽ hỏi lại:

• "Vậy nếu user sửa bài viết sau khi đã publish thì sao?"
• "Comment có thể sửa/xoá không?"
• "Một bài viết có thể gắn bao nhiêu tag?"
• "Tag có thể tồn tại mà không gắn với bài viết nào không?"
• "Ai là người tạo tag?"

Mô tả theo UI/flow chỉ trả lời được câu hỏi "nhìn thấy gì, bấm vào đâu", chứ không trả lời được câu hỏi "hệ thống này vận hành ra sao". Và phần "vận hành ra sao" đó mới chính là phần khó, phần dễ gây hiểu lầm giữa PM, dev, design, và QA.

Đây cũng tình cờ một trong những vấn đề rất căn bản dẫn tới sự misalignment trong product design and delivery, vậy thì mình có thể giải quyết vấn đề này thế nào??

Bóc tách VNExpress thành Product Concept

Nếu không mô tả theo UI, vậy thì mô tả theo cái gì?

Một trong practice của quản lý sản phẩm là mình mô tả theo Concept, những đơn vị logic độc lập, tồn tại bất kể bạn render nó lên web, app, … hay trên smart watch.

Nhìn lại VNExpress, concept đầu tiên và quan trọng nhất chắc chắn là Bài viết. Mọi thứ khác trên trang này, comment, tag, lượt xem, bookmark, đều xoay quanh khái niệm Bài viết.

Ở hình thái đơn giản nhất, 1 newsfeed sẽ có nhiều bài viết, một bài viết sẽ có tiêu đề, và content.

Để ý là khi mình mô tả concept mình sẽ không nhắc gì đến việc title hiển thị font chữ gì, hay nút bookmark nằm bên trái hay phải.

Đó là vì Bài viết là 1 concept tồn tại độc lập với cách nó được vẽ render màn hình ntn.

Sau đó mình mới phát sinh nhu cầu: “Vậy ủa, nếu những bài post chưa sẵn sàng, chỉ đang soạn thảo mà không public thì như thế nào?”.

Với nhu cầu này, mình mới sinh ra tiếp concept Trạng thái:

Khi này với concept “Trạng thái của bài viết” mình sẽ enable được việc hiển thị theo quy tắc rằng: Nếu trạng thái là Published thì sẽ hiển thị, còn draft hay archived (đã bị ẩn) thì không. Problem solved.

Nhưng mà có gì đó lấn cấn, thật ra mình chỉ muốn ẩn bài viết này với khách đọc báo thôi, còn biên tập viên thì có thể thấy và xem được.

Thế là mình phải phát sinh thêm concept users, và sau đó là phân quyền, ra sao,..

Nếu cứ tiếp tục như vậy, từ concept Bài viết, mình có thể tiếp tục bóc ra các concept khác xoay quanh nó như Comment hay Tag, và có thể dần dần tiến tới cái MVP Concept đầu tiên của VNExpress.

Ngôn ngữ Concept và Ngôn ngữ UI / Flow

Ủa rồi mô tả dậy chi???

Trong khi ngôn ngữ của UI / Flow cho bạn biết trải nghiệm tổng thể của một cái Product hay Feature sẽ như thế nào, còn ngôn ngữ Concept sẽ cho biết Feature sẽ có những đặc tính, trạng thái hoặc action nào.