标签：#beta

Google Play's 14-day closed test isn't just an ops requirement — it's 14 days when real people will use your app for the first time. If your design isn't ready for that scrutiny, you're getting expensive feedback on the wrong things. Here's what design should have shipped before day one of the closed test. Why 'good enough for testers' isn't The temptation: 'they're just testers, we'll polish for production launch.' What actually happens: Testers give feedback on rough UI, not the product. You lose the signal. Screenshots make it to social. First impression matters. The 14-day counter resets if engagement dips. Rough UX = lower engagement. Ship the closed test with launch-quality design or you're paying the 3-week price for lower-quality data. The five artefacts 1. Onboarding flow. Every tester's first 90 seconds. Empty states, permissions requests, initial value proof — all designed, not 'I'll clean it up later'. 2. All error states. Network fail, permission denied, invalid input. Real users hit these on day 1. Placeholder 'something went wrong' text loses trust fast. 3. Play Store listing assets. Screenshots, feature graphic, description. Play requires them before you can even publish to closed testing. Don't leave this for day 13. 4. Empty states for every screen. 'You have no [thing] yet' + 'here's how to get started'. Most closed-test users are seeing your app the first time with zero data — every empty state matters. 5. A visible feedback mechanism. In-app 'Send feedback' button or shake-to-report. Testers WILL find bugs; make it easy to report while they're in the moment. Designing the in-app feedback loop Testers who have to remember to email you get around to it maybe half the time. Testers who can tap 'Send feedback' from inside the app respond 5-10x more often. Design this before day 1: Persistent 'feedback' entry point (settings screen, help menu, floating button in beta builds). Feedback form is 3 fields max: (1) What were you trying to do? (2) What hap