Giving Good Mobile App Feedback
Giving Good Mobile App Feedback
Join the DZone community and get the full member experience.Join For Free
- Marketplace description: That’s a very long first paragraph. Try and break it into two or more or shorten it. A large block of text can be off-putting and make people unlikely to read it.
- Marketplace description: That's a long list of bullet points. Are the most important/compelling ones at the top of the list?
- Phrase each point the same point. Don't jump back and forth between what the app does and what "You" can do.
- Don't claim improved usability. Let the users decide if something is usable. If you have to tell them then something is wrong.
- As an alternative set of bullet points I would suggest something like this.
New in this version:
- simpler indicating of XXXXX completion
- easier to change XXXXXX order
- improved performance
- improved personalisation
- simplified editing
- If the old version of the app won't update, what are you doing to help users migrate data or provide other support. - You want users talking about how you helped them, not that they lost data or had problems.
- When the upgrade nag screen is displayed the screen may looked more balanced if the buttons were of equal size (each half the screen width). I'd also recommend making this message larger and in the centre of the screen.
- You probably also want to avoid displaying the application bar when the upgrade nag screen is displayed. It can be selected at this time.
- The application is very empty on first use. Add something that makes it clear what the user should do.
- You could also consider automatically opening the "New XXXXXXX" screen if that's all the user can do with the application when started for the first time.
- If I select a XXXXXX then the application bar contains a "cancel" option. This appears to do exactly the same thing as the back button. If they do the same thing remove the cancel option as there's no reason to have 2 buttons which do the same thing.
- On the edit screen, there is no need to have colons after labels.
- On the edit screen, the label "XXXXX YYYYY" could just be "XXXXX". Having "YYYYY", in the past tense, implies this is something that has been done which isn't necessarily the case with new items. The shorter label removes the possibility of ambiguity.
- Internationalisation issues aside, I would make the "XXXXXX" box smaller and the "YYYYY" one bigger so they are the same size as the date and time boxes. This should make the screen seem more evenly balanced.
- On the edit screen, the label to indicate if the XXXX is active or complete could be closer to the toggle switch to better indicate that they are connected.
- This label is also quite difficult to see in the light theme.
- I would consider adding a label to the time field as it isn't necessarily clear what the field is for. Alternatively you could provide a default value of "00:00". This wouldn't affect anything in terms of order unless a different time and/or a date is selected.
- As selecting a time defaults to the current time, I would expect the date to be set to the current date if I select a time before setting a date.
- If I enter a description with characters containing descenders, these are not fully displayed on the main page. This particularly affects the "g"s.
- When I entered a phone number in a description it detected the number but didn’t include the last digit in the selected/highlighted number.
- On the preferences screen, the "XXXXX" essentially has 2 labels. You could probably drop the sentence starting "Change the ..." without compromising understandability of the preference.
- The "XXXXXXX" input box doesn't appear to adjust for theme settings and always looks like it as light theme colours applied and this stands out as odd/different when the dark theme is selected.
- The button to add a "New" XXXXXXXX would look more in keeping with the buttons used by the OS and default apps if it was the full width of the page.
- The "Create a new XXXXXX" input box doesn't behave as I would expect with regard to respecting the back button. If it is displayed and I press the back button I would expect the prompt to close, not the XXXXXX selector.
- In the email created from the about screen, you may want to include the version number of the application. This will likely be helpful to you when investigating any reported error or problem.
- When tombstoned from the XXXXXXX screen the selected pivot item isn't remembered. Just a minor point but surprising, and not in a good way.
- On the about screen (in trial mode) the "buy" button is cased differently to the other buttons and so stands out. (And not in a positive way.)
What the developer of the app thought of this feeedback:
I was impressed with both the breadth and depth of your comments. It was extremely valuable that in addition to your direct feeback you provided concrete examples of ways to improve upon it. This made it very easy to actually fix the problems you identified rather than having to wonder how I would go about resolving the issues. The attention to detail in your comments made it clear that you had combed over the entire application which made me much more confident that there weren’t any missed items. Based on your feedback, I will be able to provide a much more polished and meaningful experience for my users which is invaluable.
What do you think of the above? Is me posting these useful to you as well?
Published at DZone with permission of Matt Lacey , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.