Đặc tả ứng dụng di động: mẫu một trang cho app iOS

Đặc tả ứng dụng di động: câu trả lời ngắn

Khi bạn tự làm app của mình, một bản đặc tả ứng dụng di động tốt chỉ cần một trang. Nó trả lời mười câu hỏi: cho ai, vấn đề gì, chức năng chính là gì, app kiếm tiền bằng cách nào, chuyện gì xảy ra khi không có tài khoản, dữ liệu nào phải được giữ lại, trên nền tảng nào, những gì nằm ngoài phiên bản đầu tiên, làm sao biết app hoạt động hiệu quả, và với những ràng buộc nào. Mẫu để sao chép nằm ở bên dưới. Bạn cũng có thể tải khung mẫu kèm bảng kiểm tra (.md), không cần đăng ký.

Các mẫu dài 40 trang bạn tìm thấy trên mạng được viết cho mục đích khác: một khách hàng đặt làm app với một bên cung cấp dịch vụ và cần một tài liệu mang tính hợp đồng. Còn bạn vừa là người quyết định vừa là người xây dựng, thường có AI hỗ trợ. Bản đặc tả của bạn phục vụ hai việc: chốt các quyết định trước khi code, và cho Claude, ChatGPT hay Cursor một bối cảnh rõ ràng để chúng xây đúng app.

Mình tự phát hành các app iOS của mình. Solys, một app báo thức kèm mini game, và TradaZen, một app mô phỏng giao dịch, đang có trên App Store. Nolera và Clic từng bị Apple từ chối, rồi đã được sửa. Đây là phương pháp mình áp dụng cho từng app, và cũng là phương pháp mình giới thiệu với bạn ở đây.

Vì sao một trang là đủ để định hướng app của bạn

Một tài liệu dài tạo cảm giác như đã tiến được một đoạn. Trên thực tế, nó được viết một lần, hiếm khi đọc lại, và dự án đi chệch khỏi nó ngay từ những tuần đầu. Ngược lại, một trang có thể đọc lại trong hai phút trước mỗi buổi làm việc.

Giới hạn về độ dài còn có một tác dụng hữu ích: nó buộc bạn phải quyết định. Nếu một câu trả lời dài quá hai câu, thường là quyết định chưa được đưa ra. Phát hiện điều đó trên giấy vẫn tốt hơn là trong code của bạn, ba tuần sau.

Cuối cùng, một trang là kích thước vừa vặn cho AI. Bạn có thể dán toàn bộ vào một cuộc trò chuyện, hoặc đặt nó vào file ngữ cảnh của dự án. Một tài liệu ngắn giúp việc đọc lại dễ hơn và giảm các chỉ dẫn mâu thuẫn. Nó không đảm bảo AI sẽ làm theo: hãy kiểm tra các đề xuất của AI dựa trên khung này.

Đặc tả ứng dụng di động cần có những gì?

Trả lời từng câu hỏi dưới đây trong một hoặc hai câu.

1. Ai dùng app, và trong tình huống nào? Không phải "người 18-35 tuổi". Mà là một người cụ thể, vào một thời điểm cụ thể trong ngày.
2. App giải quyết vấn đề gì, trong một câu? Nếu bạn cần đến chữ "và còn", bạn đang mô tả hai app.
3. Đâu là chức năng chính DUY NHẤT của phiên bản đầu tiên? Chỉ một. Những thứ khác chờ số liệu. Trang MVP ứng dụng iOS giải thích cách chọn.
4. App kiếm tiền bằng cách nào? Gói thuê bao, mua một lần hoặc miễn phí. Câu trả lời này thay đổi app ngay từ màn hình đầu tiên. Nếu bạn còn phân vân, hãy đọc thuê bao hay mua một lần cho app iOS.
5. Không tạo tài khoản thì làm được gì? Quyết định sớm những gì dùng được mà không cần đăng ký giúp bạn khỏi phải làm lại toàn bộ luồng chào mừng người dùng mới.
6. Dữ liệu nào phải được giữ lại khi đổi điện thoại? Đây là câu hỏi quyết định bạn có cần backend như Supabase hay không, hay mọi thứ có thể nằm trên thiết bị.
7. Chỉ iOS, hay cả iOS và Android? Lời khuyên của mình khi bạn mới bắt đầu: iOS trước. Mình giải thích lý do trong làm app iOS và Android cùng lúc.
8. Những gì RÕ RÀNG nằm NGOÀI phiên bản đầu tiên? Phần hữu ích nhất của tài liệu. Nó cắt đứt các cuộc tranh luận trước khi chúng nảy sinh, với chính bạn cũng như với AI.
9. Làm sao bạn biết app hoạt động hiệu quả? Một tín hiệu duy nhất, đo được trong những tuần sau khi ra mắt: số lượt dùng thử miễn phí bắt đầu, số người đăng ký, số người dùng quay lại.
10. Những ràng buộc thực tế của bạn là gì? Thời gian bạn dành ra được mỗi tuần, thiết bị của bạn, và tài khoản Apple Developer của bạn, có giá 99 $ mỗi năm. Không có Mac? Không sao cả, như mình giải thích trong phát hành app iOS không cần Mac.

Mẫu đặc tả để sao chép

Sao chép mẫu này vào một ghi chú hoặc một file văn bản ở thư mục gốc của dự án, rồi điền vào từng dòng.

• Tên tạm thời của app: …
• Cho ai: một người … vào lúc …
• Vấn đề được giải quyết, trong một câu: …
• Chức năng chính của phiên bản 1: …
• Những gì người dùng thấy khi mở app lần đầu: …
• Mô hình kinh doanh: thuê bao / mua một lần / miễn phí, và phần nào phải trả tiền: …
• Không cần tài khoản, người dùng có thể: …
• Dữ liệu cần giữ giữa hai điện thoại: không có / …
• Nền tảng: iOS trước (Android sau nếu số liệu khả quan)
• Ngoài phiên bản 1: …, …, …
• Tín hiệu thành công: …
• Stack: React Native, Expo, Supabase nếu cần tài khoản, RevenueCat cho gói thuê bao
• Ràng buộc: … giờ mỗi tuần, đã mở tài khoản Apple Developer hay chưa, có Mac hay không
• Những app có trải nghiệm mình thích, và vì sao: …

Thêm ba đến năm ảnh chụp màn hình của những app bạn thích, kèm một dòng về điều bạn thích ở đó. Như vậy dễ hình dung hơn một bộ nhận diện thương hiệu, với cả bạn lẫn AI.

Bản đặc tả không phải là danh sách mong muốn. Nó là danh sách những quyết định đã đưa ra.

Ví dụ: trang đã điền cho một app giả định

Để thấy mức độ chi tiết cần có, đây là mẫu đã điền cho một app được bịa ra làm ví dụ: một app hẹn giờ ôn bài.

• Cho ai: một sinh viên tự ôn bài vào buổi tối và mất tập trung sau mười phút.
• Vấn đề: bạn ấy không thể duy trì một buổi học mà không chạm vào điện thoại.
• Chức năng chính: bắt đầu một buổi học có bấm giờ và xem chuỗi ngày đã duy trì.
• Màn hình đầu tiên: một nút duy nhất để bắt đầu buổi học.
• Mô hình kinh doanh: thuê bao cho thống kê chi tiết, buổi học cơ bản miễn phí.
• Không cần tài khoản: mọi thứ, trừ việc sao lưu giữa hai điện thoại.
• Ngoài phiên bản 1: chế độ nhóm, bảng xếp hạng với bạn bè, widget, phiên bản Android.
• Tín hiệu thành công: người dùng quay lại nhiều ngày liên tiếp.

Hãy để ý những gì cố tình bị bỏ qua: không có danh sách hai mươi màn hình, không áp đặt màu sắc, không có kiến trúc. Những lựa chọn đó sẽ đến trong lúc xây dựng, và trang này giúp bạn kiểm tra rằng chúng vẫn phục vụ chức năng chính.

Cách dùng bản đặc tả để dẫn dắt AI

Đây là chỗ trang giấy của bạn mang lại nhiều giá trị nhất. Một AI code mà không có ngữ cảnh sẽ phải đoán, và nó thường đoán ra một app khác với app của bạn.

Đặt trang này vào ngữ cảnh thường trực của dự án. Claude Code đọc file CLAUDE.md ở thư mục gốc, Cursor có các file rules riêng. Dán bản đặc tả vào đó, kèm stack của bạn. Khi đó mọi yêu cầu đều xuất phát từ cùng một nền tảng.

Trích phần "ngoài phiên bản 1" khi AI làm quá tay. Các trợ lý AI rất hay đề xuất thêm chức năng: chế độ tối, chia sẻ, thông báo. Danh sách loại trừ cho bạn sẵn câu trả lời: chưa phải lúc này.

Yêu cầu một kế hoạch tôn trọng trang đặc tả. Trước một hạng mục lớn, hãy viết: "đây là bản đặc tả của mình, hãy đề xuất kế hoạch cho chức năng chính, đừng code vội". Bạn sẽ nhận ra ngay nếu kế hoạch đi lệch khỏi những gì bạn đã quyết định.

Nhờ AI đọc lại trang đặc tả, không chỉ code. Hãy hỏi: "những câu hỏi nào trong bản đặc tả này còn mơ hồ hoặc mâu thuẫn?". Đây là cách dùng AI bị đánh giá thấp, và nó giúp bạn tránh nhiều tuần làm việc sai hướng.

Để tìm hiểu sâu hơn, mình đã trình bày chi tiết các cạm bẫy và bước kiểm tra trong tạo app iOS bằng AI.

Biến các quyết định thành tiêu chí kiểm tra

Một chức năng chính phải có kết quả quan sát được. Với app hẹn giờ giả định trong ví dụ này, "bộ hẹn giờ hoạt động" là quá mơ hồ. Hãy viết: "Mình bắt đầu một buổi học, thời gian còn lại hiển thị, mình có thể dừng lại và thấy lại buổi học vừa hoàn thành gần nhất sau khi mở lại app." Hãy quyết định riêng liệu bộ hẹn giờ có phải tiếp tục chạy khi khóa màn hình hay không: lựa chọn này có thể thay đổi phần việc kỹ thuật.

Với mỗi chức năng, thêm ba dòng: hành động, kết quả mong đợi, bằng chứng. Bằng chứng có thể là một bài test tự động cho một phép tính, hoặc một lần kiểm tra trên thiết bị cho một luồng thao tác. Ghi lại cả những gì chưa được kiểm tra. Bảng nhỏ này giúp bạn không nhầm lẫn giữa một màn hình đã làm xong và một chức năng đã sẵn sàng để dùng.

Đây là bảng đã điền cho app hẹn giờ giả định. Đây là các tiêu chí cần kiểm tra, không phải các bài test đã đạt:

Quyết định trong bản đặc tả	Cần kiểm tra	Kết quả mong đợi
Buổi học cơ bản dùng được không cần tài khoản	Cài app và bắt đầu một buổi học mà không đăng ký	Không có form đăng ký nào chặn việc bắt đầu
Buổi học bỏ dở không được tính vào chuỗi	Dừng một buổi học trước khi kết thúc, rồi mở lịch sử	Không có buổi học hoàn thành nào được thêm vào
Lịch sử được lưu trên thiết bị	Hoàn thành một buổi học, đóng rồi mở lại app	Buổi học xuất hiện đúng một lần với thời lượng chính xác
Bộ hẹn giờ cơ bản hoạt động không cần mạng	Bật chế độ máy bay và hoàn thành một buổi học	Bộ hẹn giờ và việc lưu cục bộ vẫn dùng được
Thống kê chi tiết phải trả phí	Mở thống kê khi chưa đăng ký thuê bao	Màn hình ưu đãi hiển thị; buổi học cơ bản vẫn dùng được

Những chủ đề còn mơ hồ trở thành các quyết định cần đưa ra. Ví dụ: làm gì nếu người dùng khóa màn hình hoặc đổi giờ điện thoại trong lúc đang học? Đừng để agent âm thầm tự chọn. Hãy viết ra hành vi mong muốn, rồi thêm trường hợp đó vào bảng. Để tổ chức việc kiểm thử này trên một bản cài đặt thật, hãy dùng hướng dẫn kiểm thử app iPhone với TestFlight.

Quyết định bỏ gì khi phiên bản đầu tiên bị phình ra

Xem lại từng chức năng và đặt một câu hỏi: "Không có nó, người dùng có còn đạt được kết quả đã hứa không?" Với app hẹn giờ của chúng ta, bảng xếp hạng với bạn bè có thể chờ. Việc xem lại buổi học đã hoàn thành là cần thiết nếu bạn hứa hẹn chuỗi ngày. Màn hình thuê bao chỉ trở nên cần thiết nếu bạn thực sự bán phần thống kê ngay từ phiên bản này.

Ghi lại quyết định và lý do trong nhật ký của mẫu tải về. Bạn có thể xem lại lựa chọn này sau khi kiểm thử mà không quên lý do của phạm vi ban đầu. Hướng dẫn tạo ứng dụng với Claude Code sau đó chỉ cách biến bản định hướng này thành các yêu cầu có giới hạn và kiểm chứng được.

Về kinh nghiệm thực tế, TradaZen đã thay đổi phạm vi sau khi phát hành. Bản định hướng giúp tung ra một phiên bản đầu tiên đo lường được, rồi quyết định phiên bản tiếp theo dựa trên phản hồi thật.

Cái bẫy danh mục tính năng

Phản xạ tự nhiên là liệt kê mọi thứ app "sẽ phải làm": bản đồ, chat, thông báo, giới thiệu bạn bè, chế độ offline. Danh mục này là dấu hiệu đáng tin cậy nhất của một dự án không đi đến đích, vì một lý do đơn giản: mỗi chức năng thêm vào trước khi ra mắt đều làm chậm thời điểm người dùng thật cho bạn biết điều gì quan trọng.

Một phiên bản đầu tiên tốt làm một việc, và làm tốt việc đó. Nhưng cũng cẩn thận với thái cực ngược lại: Apple yêu cầu app phải hơn một website được đóng gói lại, theo quy định 4.2 của App Review Guidelines. Một chức năng chính, được; một cái vỏ rỗng, không: đó là lý do của guideline 4.2.

Những gì đặc tả app di động không nên có

• Một bộ nhận diện thương hiệu đầy đủ. Lúc đầu, vài ảnh chụp màn hình tham khảo là đủ.
• Một lịch trình theo từng ngày. Bạn chưa có đủ thông tin để bám theo nó. Một mục tiêu theo tuần là đủ.
• Một kiến trúc kỹ thuật chi tiết. Chọn một stack đã được kiểm chứng, rồi để các chi tiết được quyết định trong lúc xây dựng.
• Các chức năng "để sau" lẫn vào phần còn lại. Tất cả chúng đều thuộc phần ngoài phiên bản 1.

Khi nào nên cập nhật bản đặc tả?

Đọc lại nó vào đầu mỗi tuần làm việc. Chỉ cập nhật khi một quyết định thay đổi vì một lý do thật sự: một lần test trên iPhone cho thấy một màn hình không ổn, phản hồi từ người thử nghiệm, một ràng buộc của Apple phát hiện ra giữa chừng. Nếu bạn sửa nó mỗi ngày, nghĩa là nó không còn định hướng được gì nữa.

Khi phiên bản đầu tiên đã phát hành, trang này trở thành nền tảng cho phiên bản tiếp theo: những gì nằm ngoài phiên bản 1 được đưa lên, sắp xếp theo những gì số liệu cho bạn biết. Toàn cảnh hành trình, từ ý tưởng đến phát hành, có ở trang tạo ứng dụng iPhone.

Từ trang giấy đến app được phát hành

Nếu bạn đã trả lời mười câu hỏi, bạn đã làm phần việc mà nhiều dự án bỏ qua. Tiếp theo là xây chức năng chính, test trên iPhone, tích hợp thuê bao và chuẩn bị hồ sơ cho Apple.

Đó chính là lộ trình của iOS Kit, gồm bốn bước để theo theo nhịp của bạn: bước đầu tiên giúp chọn app có thể sinh lời, đối tượng và giá của nó, và bản đặc tả của bạn là điểm xuất phát.

Bạn không chắc ý tưởng của mình đã sẵn sàng gói gọn trong một trang? Bài chẩn đoán miễn phí cho bạn biết điều gì đang chặn dự án của bạn hôm nay và nên bắt tay vào bước nào trước. Trang chủ sau đó chỉ cách tạo app di động từ bản định hướng này, với Claude Code.

Mình không hứa hẹn thu nhập hay việc được phát hành: Apple là bên duyệt, và thị trường quyết định phần còn lại. Không có kit, mẫu này vẫn đủ để bạn bắt đầu.

Câu hỏi thường gặp

Làm thế nào để viết đặc tả cho một ứng dụng di động?

Giữ bản đặc tả trong một trang: mười câu hỏi, mỗi câu trả lời một hoặc hai câu. Chúng xoay quanh đối tượng, vấn đề, chức năng chính, mô hình kinh doanh, chuyện gì xảy ra khi không có tài khoản, dữ liệu cần giữ lại, nền tảng, những gì nằm ngoài phiên bản đầu tiên, tín hiệu thành công và các ràng buộc. Nếu một câu trả lời dài quá hai câu, thường là quyết định chưa được đưa ra.

Nên dùng phần mềm gì để viết đặc tả ứng dụng?

Một ghi chú đơn giản hoặc một file văn bản ở thư mục gốc của dự án: bạn sao chép mẫu vào đó, rồi điền vào từng dòng. Bạn cũng có thể tải khung mẫu kèm bảng kiểm tra (.md), không cần đăng ký. Để dẫn dắt AI, sau đó hãy đặt nó vào file ngữ cảnh của dự án.

Có cần một bản đặc tả 40 trang cho ứng dụng không?

Không, khi bạn tự làm app của mình: một trang là đủ. Các mẫu 40 trang trên mạng được viết cho khách hàng đặt làm app với một bên cung cấp dịch vụ và cần tài liệu mang tính hợp đồng. Bạn thì tự quyết định và tự xây dựng: trang của bạn dùng để chốt quyết định trước khi code và cung cấp ngữ cảnh cho AI.

Làm thế nào để đưa bản đặc tả cho AI code?

Đặt trang này vào ngữ cảnh thường trực của dự án: Claude Code đọc file CLAUDE.md ở thư mục gốc, Cursor có các file rules riêng. Trích phần "ngoài phiên bản 1" khi AI làm quá tay. Trước một hạng mục lớn, yêu cầu một kế hoạch tôn trọng trang đặc tả, chưa code ngay.

Làm sao kiểm tra một chức năng có đúng bản đặc tả không?

Với mỗi chức năng, thêm ba dòng: hành động, kết quả mong đợi và bằng chứng. Bằng chứng có thể là một bài test tự động cho một phép tính, hoặc một lần kiểm tra trên thiết bị cho một luồng thao tác. Ghi lại cả những gì chưa được kiểm tra, để không nhầm giữa một màn hình đã xong và một chức năng sẵn sàng để dùng.

Không nên đưa gì vào bản đặc tả ứng dụng?

Bốn thứ cần tránh: một bộ nhận diện thương hiệu đầy đủ, một lịch trình theo từng ngày, một kiến trúc kỹ thuật chi tiết, và các chức năng "để sau" lẫn vào phần còn lại. Lúc đầu, vài ảnh chụp màn hình tham khảo là đủ, và một mục tiêu theo tuần là đủ cho lịch trình. Các chức năng để sau đều thuộc phần ngoài phiên bản 1.