We wanted users to have a good initial experience with the Budget App so we added a demo. Yes, there was an issue or two along the way but in general, the demo turned out to be useful. When your App crosses the trivial boundary, you need to be able to show users what they can do; there is little worse than signing up to a new App and not being able to do anything because you don’t have any data.
Good initial data
However, the existence of a demo is not enough – it needs to be useful, it needs to include mock data but more importantly, hint at all or many of the features that exist in your App. As developers it is all too easy to create data that is ‘pretty’, we need to create mock real data that will more closely match a user’s real-life experience.
With a blogging App, it might make sense for the initial data to show all the available states a post can have, ‘published’, ‘draft’, ‘scheduled’ etc. – that way rather than seeing a list of completed posts, the user gets to see that posts exist and immediately discovers there is a scheduling system.
Our demo issues?
The demo for Budget creates two projection accounts and ten expense items of several types, that way when a user loads the demo, they get to see how their budget is likely to display and they can play.
So far so good.
Nope, we aren’t exposing all the features; budget items can be marked as paid, disabled and their balances can be adjusted on an ad-hoc basis. These are small features but are part of the general workflow, by being missing from the demo data, we are hoping users find the relevant action buttons rather than letting them know they exist from the start.
Before the official release I am going to review the demo data for Budget and correct the issues I’ve talked about in this post. I’m also going to make a point of reviewing the demo data every few months to ensure we are covering any newly added features.