So you want a mobile app for your company but you don’t know how to get it built? In this series of posts I’ll tell you all about how you go from idea to App Store. We’ll cover all of the steps: from firming up your initial idea to finding an app developer to getting your app out to your clients.
Today we’ll talk about the fifth, working with a mobile app developer while your app is built. The posts in the series will include:
- Firming up your app concept: Before talking to developers
- App design: What does your app do?
- How to find the right app developer for your project
- Engaging a developer: Contracts, milestones, and other considerations
- Working with an app developer: Communication and testing
- Putting your app out there: App Store submission and what happens after launch
Working with an App Developer: Communication and Testing
The best started project can fall apart once development starts. Without clear communication and solid testing, the app may end up being nothing like you expected or, even worse, never get finished. The effort to keep up with communication and testing isn’t much, maybe a few hours a week, but without it there’s a good chance the app won’t be half as good as it could be.
Documentation is key: if they should know it, spell it out. Make sure everything from the design is clear, from visual details to the flow users are expected to take to complete a task. The developer should have any descriptions, drawings, graphics, etc. that you can provide. If you expect the developer to take liberties with some of the design, let them know that and consider having them produce images or very early prototypes showing the design to avoid ending up with a design you don’t like.
To keep the amount of items you need to discuss manageable, set out milestones and work on one milestone at a time. Each milestone should be completely finished and polished before moving on to the next chunk of work. It’s easy to leave little bits of work undone with the intention of cleaning it up later, only to discover near the end of the project that there’s a lot of effort needed to bring the app to release quality.
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. — Tom Cargill, Bell Labs
Sometimes the final graphics might not be applied until a later milestone but any bugs or issues with the functionality should be taken care of while they’re still fresh in everyone’s mind.
You don’t need to wait until the end of a milestone to get a test version of the app to try out. Early and frequent test builds, along with your timely feedback, help keep expectations and current progress clear to everyone involved. Depending on the length of the project, test builds should be available every week or two, or at least halfway through each milestone.
Early builds are often far from perfect, so make sure it’s clear why you’re reviewing a build. There’s a big difference in the type of feedback that’s useful to me if my client is trying out the flow of actions for a task or assessing the layout of the app’s main screen. I usually request feedback within a few days. Depending on the length of the project, a weekly call to discuss the latest build might make sense but often waiting a week for feedback will slow the development process.
If your aim is to be less involved during development and you’ve provided clear and complete documentation of the design, still consider having a few test builds. In particular, if the developer expresses uncertainty about a feature, a quick implementation of what they think the specifications require can avoid a lot of rework later on.
Taking 5 minutes a week to check out the latest build will probably save hours of discussing the impact of changes later on.
My biggest risks in keeping any app project on schedule has always been getting timely feedback and avoiding changes to implemented features. If you’re not sure about something, take the time to hash it out so it doesn’t need changing later, but don’t take weeks to respond to questions about the requirements. If the project is a priority for you and your company, treat it as one.
Daily scheduled calls usually don’t speed up the process, unless you have a fairly large development team making significant changes on a daily basis and you have time to review them adequately. I’ve rarely found that more than 2 short meetings a week helped keep a project on schedule. Quick responses to short questions by email let the developer keep working but get the information they need.
Changes after development starts are best handled by spending more time designing before coding. This doesn’t mean everything needs to be decided upfront. It’s become common for developers to work in 1-2 week “sprints” where the work to be done is defined at the start of the sprint and completed during that timeframe. This is a great way to approach development since it’s often difficult to spell out everything before playing with the first test builds. But this agile development doesn’t mean that constant and frequent changes or lack of specificity will work out. The requirements for the sprint still need to be nailed down before the sprint begins. Sprints also allow for accurate tracking of progress against deadlines and estimates. With sprints, full feedback on each week’s work needs to be provided and the upcoming week’s work estimated and prioritized each week. That usually means at least 2 weekly meetings.
Testing keeps getting mentioned but it’s mostly been in reference to you testing pre-release versions of the app to make sure development stays on track. In all, there are several people who should be testing your app before it’s released:
- The developer(s) should be testing their code to avoid bugs and ensure it meets the requirements (as per their understading)
- You should be testing the test versions to ensure the app meets the requirements and to make sure those requirements make sense. Bring up any potential changes as quickly as possible.
- Potential users should be testing a solid “beta” version of your app when it’s nearly ready for release to weed out unexpected use cases, behaviour that’s different from how you use the app, and issues with the flow and usability of the app. They might even spot key features that were missed or point out current features that really aren’t necessary. While you probably don’t want future customers trying out early test builds, use paper or other prototypes early in the process to get their feedback on the design.
Your developer should be able to recommend tools to make each kind of testing easy for you and your testers. They should be able to explain how and why they test their code and how they will make sure it meets your requirements.
Your role is fairly clear: make sure you’re getting what you expect and make sure anything out of your expectations gets brought up as soon as possible.
For beta testers, Apple allows up to 100 beta testers per developer account per year. These testers can run the app before it’s available in the App Store to provide feedback and uncover issues with the app to be fixed before it’s public. If your app is complex, targeted at a niche market, or a game, you’ll definitely want to run a large beta test. Even if recruiting tens of people to try out the app isn’t in your plans, having just a few people try out the app while you quietly watch over their shoulder can be a very revealing experience.
That’s all about the app creation process. Next time we’ll dig in to the final step: App Store submission and what happens after launch. If you have any questions that you want to be sure that I cover, contact me.