What Indie App Testers Actually Say About UI and Design
By Luis Krin, Founder, IndieAppCircle
If you read a pile of tester feedback in a row, one thing becomes obvious fast: most of it is about how the app looks and where things are. Not the architecture, not the pricing, not the idea. Where the button is, what the icon means, why this screen feels busy and that one feels empty. UI is what a tester is looking at for every second they spend in your app, so it is what they write about.
A keyword pass over the approved, written feedback testers leave on IndieAppCircle (thousands of reports, hundreds of thousands of words) puts UI and design comfortably at the top of the most frequently mentioned areas, ahead of onboarding and ahead of bugs. That is a crude count, not a scientific study, and it does not tell you what any one tester wrote. It does tell you where to expect the most feedback on your own app, and it is rarely about colours.
This is not a collection of quotes. Individual tester write-ups on IndieAppCircle are private to the app owner by design, and we do not publish them without the tester's consent. What follows is the pattern behind that count: the handful of shapes UI feedback keeps taking, how to tell a real usability problem from a matter of taste, and how to ask for feedback you can act on.
Why UI is the most flagged thing
Three things push UI feedback to the top. First, every tester sees every screen. A bug three levels deep only gets found by the testers who get that far, but a cluttered home screen is seen by all of them, in the first ten seconds. Second, nobody needs to be technical to notice it. A tester who could not tell you what an API is can tell you exactly which button they could not find. Third, you cannot see your own UI clearly. You know what every icon means because you chose it, so the screen reads as obvious to you and as a puzzle to everyone else.
That is also why UI feedback is mostly about usability, not beauty. Testers rarely say "this should be a different blue." They say "I did not know that was tappable" and "I was not sure what to do next." Those are the sentences worth listening for.
The five shapes UI feedback keeps taking
Read enough reports across enough apps and the same handful of complaints keep reappearing under different wording. None of these are exotic, and almost all of them are invisible from the designer's chair.
1. Nothing tells me where to look
Every element has the same size, the same weight and the same colour, so the eye has nowhere to land. The main action looks like a secondary one, a heading looks like a label, a card looks like the page behind it. Founders usually build screens by adding the next needed thing, and the result is a flat page where a stranger cannot tell what the screen is for. The tell in a report is a tester describing what they did first as "I just clicked around."
2. Controls that do not explain themselves
An icon with no label. A button that says "Submit" on a screen with three things to submit. A tab that looks like a heading. Something that is clickable but does not look clickable, or the reverse. You know what the three-dot menu holds; a tester has to open it to find out, and some will not. This is the most fixable shape on the list, because the fix is usually a word: a label next to the icon, a verb on the button instead of a generic one.
3. The screen that shows everything at once
A dashboard with fourteen numbers, a settings page that is one long scroll, a form with every optional field open by default. It all made sense when you added it, one piece at a time. Together it reads as "a lot", and a tester who feels overwhelmed does not work out which three things matter, they leave. The fix is rarely removing features. It is deciding what a first-time visitor needs on this screen, and moving the rest one tap away.
4. Parts that look like different apps
Buttons that change shape between screens, three different spacings, an old page nobody restyled, the same action called "Save" in one place and "Done" in another. Indie apps get built in bursts over months, so the UI is a sediment of whatever you liked that week. A tester does not analyse it, they just report a feeling: it seems unfinished, or like it was put together from templates. That feeling matters because it is what people use to decide whether to trust the app with their data or their card.
5. Text and buttons that are hard to read or hit
Light grey text on white, a font size that is fine on a 27-inch monitor and tiny on a phone, tap targets packed so close that the wrong one gets hit, a dark mode where one screen was forgotten. You build on one good screen in good light and never feel it. Testers use the app on a bus, on an older phone, with the brightness down. If a report says "hard to read" or "kept tapping the wrong thing," believe it on the first mention.
A usability problem or a matter of taste?
Not every UI comment deserves action, and acting on all of them is how an app ends up redesigned every week. A rough way to sort them:
- Act on anything where the tester was stuck, lost or slowed down. "I could not find it" and "I did not know what that did" describe behaviour, not opinion.
- Act on anything more than one tester says. One person disliking your colour scheme is taste. Three people missing the same button is a layout problem.
- Treat pure preference as a note, not a task. "I would prefer it rounder" is fine to read and fine to ignore, unless it comes in a crowd.
- Fix the cheap fixes first. Labels, button text, spacing and contrast take an afternoon, and they remove most of the friction before you touch a layout.
How to ask for UI feedback you can act on
"What do you think of the design?" gets you a polite adjective. The following get you something you can change:
- Give a task, not a tour. "Create a project and share it" shows you every place the UI gets in the way. "Look around" shows you what the tester found interesting.
- Ask what they would press first on each main screen. If their answer is not the thing you wanted pressed, the hierarchy is the problem.
- Ask where they hesitated. The pauses are the UI problems. People rarely volunteer them unless you ask.
- Ask for the device and screen size. Half of the "hard to read" and "hard to tap" reports only make sense once you know what the tester was holding.
- Use testers who have never seen the app. Anyone who has watched it being built, friends and co-founders included, has learned the UI and can no longer report its problems. The same goes for a landing page, which you can check for free with the Landing Page Roast.
Getting this feedback on IndieAppCircle
This is the loop IndieAppCircle, the site you are reading, runs on. Other developers spend their time using each other's apps and write down what they found, so the UI feedback comes from people who have never seen yours and who spend all day looking at interfaces. Sign-up is free, and new accounts start with 5 credits. Test 2 apps and yours goes live in the feed. When you list it, you write the task you want testers to try, so you can point them at the screen you are least sure about. Reports come back as written feedback, you approve them, and an approval is what pays the tester. A report you do not get to is approved automatically after 48 hours, so nothing is left hanging.
The first tester on a new app also gets a bonus of 5 credits, which is there to make the first report worth taking. If you would rather not wait for your own credits to build up, credit packs start at 50 credits for 5€, and the credits do not expire.
Frequently asked questions
Should I fix UI feedback before or after launch? Fix the stuck-and-lost kind before launch, because those cost you users who will not come back for a second look. Leave redesigns and preference notes until you have real usage to weigh them against.
Do I need a designer to act on this? Not for most of it. Labels, button text, contrast, spacing and what sits above the fold are decisions a developer can make in a day once someone has pointed at the problem. A designer earns their fee on the larger redesigns.
How many testers do I need for UI feedback? Fewer than you think for the obvious problems. Three to five people who have never seen the app will agree on most of what is confusing, and the beta-testers guide below has the fuller breakdown for a first round.
What if testers disagree about the design? That is information. If one person loves a screen and another cannot use it, look at what each of them was trying to do, and trust the one who got stuck.
UI feedback is one of three things testers flag most. The other two are covered in what they say about onboarding and bugs, and the guide to getting beta testers covers how many people to recruit. If you want to see how this works on your own app, you can put it up for testing on IndieAppCircle and get written reports from people who have never opened it.