5 App Development Mistakes To Avoid: Lessons From Our Cock Ups

Over the last nine years we have developed a lot of apps. Hundreds, and these have not been ‘cookie cutter’ products either, carbon copies of each other. No, each one has been unique, designed and built from the ground up.

We’ve seen a bunch of these apps be a huge success and we’ve see some of those not do so well. Along the way both us and our customers have made mistakes. Sometimes our customers misjudged the market, or didn’t invest enough in marketing. Those things are often out of our control, things about which we can do nothing and this blog isn’t about our customers mistakes, it’s about ours.

When we can look back on a the huge number of products we have developed we can identify some blunders we have made. So, read on and learn from our missteps as we have done. Because the great Richard Branson once said - ‘You don't learn to walk by following rules. You learn by doing, and by falling over.’ Hopefully if you read on you won’t have to fall over.

getting feedback for your mobile app

In our very first app on the app store we didn’t give the user an outlet, a way of communicating with us. This was our first major lesson because, on the face of it, it did not seem like a big issue - but it was. The app we had developed was well designed, had awesome content and worked really well - so it never occurred to use that the users might have an issue with it and want to contact us.

The app was a video driven tutorial app and carried a hefty price tag of £5.99 (this was a hefty price in the days when most apps cost nothing or 99p). The app took off in the UK and quickly became a commercial success. Another market we had our eye on was the USA and before the app could gain traction we got a single one star review. ‘The videos don’t play - what a waste of $6! Avoid, don’t buy!’

Sales stalled completely in the USA, because of a single, poor review which stated the app simply didn’t work. In testing we could not recreate the issue at all, the videos all played fine on all the devices we had and no other customers were reporting the same issue. We suspect this was an iOS issue, but we had no way of finding out because we could not contact the customer who had placed the review and in those days you could not respond to reviews either.

We quickly updated the app to include a simple mechanism on the app which allowed users to contact us if they had an issues or suggestions. Before long, we got the occasional question or issues and because we had opened a dialogue we were able to resolve specific issues. In a number of cases one star reviews were changed to five star reviews praising our responsiveness and helpfulness.

However the app in the states never really recovered from the initial poor review and sales remained low compared to the UK. It was not until we released the iPad version of the product when things really took off again.

Since that day, every single one of our app includes a contact mechanism and onboarding to help the users get the most of their purchases and give them an outlet that isn’t the app store if they want to have a moan.

simplify your mobile app 

We’re innovative and full of amazing ideas. We love to find ingenious solutions to problems that others struggle to solve. At times, however, we can be our own worst enemy. Super clever solutions often brings unnecessary complexity and we have, on occasion, got carried away. We have found ourselves too focused on providing the user with this amazing experience, one which relies on a load of clever code, and therefore adds technical risk and cost to the project.

There have been times where we’ve found ourselves at the end of a long and weary sprint with our clever feature, not much further on - and when we sit down to review someone will say… ‘Can’t we just add a button which makes this easier?’ This sentence seems to shake us from our technical trance and we look at one another as if to say, that’s not a bad idea and it’s only one tap, which is not going to be a big issue - and will probably work every time…

Smart solutions which mean the user does not have to think or do much to achieve their goal are great - if they are practical. However, if you find you are building a house of cards which keeps falling over, something’s wrong and you need to take a step back. Maybe adding in a button or human interaction is the best option, yes it adds a step, but it is preferable to an unreliable or buggy experience.

Nowadays we don’t shy away from the clever and complex solutions, but we do ask ourselves ‘are they worth it?’ Is it worth the risk and cost to do this awesome thing, or should we be pragmatic and just put in a button? Sometimes we do the clever thing because it is totally worth it and sets the solution apart from the competition. Sometimes we just stick a button in because discretion is the better part of valour.

From our experiences, we've learnt a lot about building brilliant business apps, but we've got one secret in particular that'll help create your mobile app. Want to find out?

updating your mobile app? let your users know!

We’ve seen some shocking apps out there (not ours) and from time to time the owner of said unlovely products will come to us and ask us to sort them out.

We have been caught out, though, by how people fall in love with an ugly duckling. A recent project saw us design and implement a really nice upgrade to a content app (an app which provides rich and interactive content to the user). The original app had tens of thousands of users, but was badly designed (it broke all kinds of UX rules), difficult to use and lacked functionality. The new app increased the functionality while making the app easier to use. We all sat around congratulating ourselves on a job well done.

Then the reviews came in… a small but vocal contingent did not like the upgrade. They were used to their ugly duckling, happy to live with its idiosyncrasies and did not like change, even if that change meant making things easier. The reason they did not like it was the act of change itself was disruptive and made things more difficult for them because they had to unlearn some bad habits.

While the number of users that complained were in the minority and the vast majority got on just fine, the only ones you hear from are those that are unhappy, therefore giving a distorted view of how people really felt about the upgrade.

On reflection we should have done more to manage the user’s expectations about the changes that were coming their way - especially if the app you are ‘upgrading’ has plenty of users and a decent rating. It is important we communicate what we are changing and why and if possible get the users bought into the process. This could be achieved by old fashioned communication channels or use of in-app messaging and onboarding in the old app, heralding the updates that are coming, why they are going to improve things, and reassuring users we are around to help with them during the transition.

trial new technologies in mobile app development

Apple, Google and Microsoft are introducing amazing new innovative technologies every day. Combine that with the wave of innovation with the internet of things (IoT) and other wireless technology, it really does seem like the sky is the limit in terms of what can be achieved in mobile computing.

However, just because a giant like Apple or Google wrote it, does not mean it will actually work as well they demonstrate at their developer conferences. When Apple announced iBeacon, we used it in a retail app to detect when a user moved around a store. It worked fine in our offices and in the ‘demo’ store - but in the real world it was not nearly as successful. Human bodies wreak havoc with the radio frequency signal and the app really got its knickers in a twist and couldn’t work out if the user was coming or going.

Thankfully, this project was developed as an R&D exercise to really push the limits of Bluetooth Beaconing technology to understand what it could and couldn’t do. In this respect, this was not a mistake - but is a good example how developers need to trial new technologies to ensure they work robustly in the field.

app development testing environment: getting it right

It’s late, you’re tired - you are on the messaging website of the new solution you are building, testing the messaging system one more time with a hilarious, toilet humour based phrase. You click send and check the phone - cursing quietly as your message that you’re oh so satisfied with ‘Massive Great Poo’ does not come through as expected. Then the cold realisation sets in… you double check the message composer in the browser hoping to see the page URL read http://dev.myapp.com - the system that will only send messages to your development device.

Your worst nightmares are realised – it’s actually http://staging.myapp.com. You’ve just sent ‘Massive Great Poo’ to ALL your testers and the customer! You quickly Slack the project manager who goes into client management overdrive and explains why they are seeing a Massive Great Poo in their inbox.

Unlike the BBC, we’ve never sent a message in error on a production app but we’ll admit, we have made a mistake like this on staging and had an awkward conversation with our customer, but it was years ago. Since then we enforce standard testing messages with innocuous content because you just never know - especially if you are pulling a late one to meet a deadline.

In fact, using standard test content for push, content delivery, error messages is really good practice as it really helps when defining test cases especially boundary tests. You can make sure your UI handles the content your app is designed to.

As they say, what doesn’t kill you makes you stronger, and our past errors have only made us even better app developers. In fact, we now know the secret to developing the best app for your business. Find out below.