- Define & Design
Define & Design
As a former software project manager, I see these as part of each other: Functional Requirements. What you want the app to do will affect the design and vice-versa. I am talking about the mechanics of the design - not the colours and typefaces (although that's part of it). What pieces of information are the most important? Where, on the screen, should they display? What's the logical progression of steps the user will walk through?
Be clear on what you want to accomplish. Why do you want the app? What will you get out of it? Next, be clear on how you want the app to reach that goal: what information must it get and what information must it return? In other words, what will its users expect of it?
Finally, what will it look like? Usually, you don't get a graphic designer and application builder in one person, but you can get a designer who has worked with mobile application builders and an application developer who has worked well with designers.
Try to start all of the thinking work way, way ahead of when you want the app. Having more time may result in a little of what we call 'scope creep' (you know, when stuff keeps getting added in), but that may be preferable to not having enough time to adequately design and test the product before it has to be deployed. As with any project, always build in time to deal with the inevitable mixups, mistakes, and miscommunications between you and your team.
Make sure you check in with each other on a regular basis - have milestones or deliverables to evaluate progress against. And, if possible, test each module.
Your contract with your application developer should include a section on who, how, and when the application should be tested. As far as I'm concerned, it's incumbent on the software developer to ensure his/her code works as expected, which means testing it. If their proposal or bid doesn't include this information, and you still want to work with them, you need to ask about it.
In addition, test it yourself. As both a project manager and a technical writer, I always tested the software. Quality Assurance had its test scripts and I had mine, which usually involved trying to break the application by doing things like entering alpha characters where numbers were expected or bizarre dates or clicking on the wrong button. These actions not only told me whether the software was working as expected, but what kind of error messages I got and how easy or hard it was to get back on track once I'd done something wrong. The developer may think it's idiot proof, but idiots like me will find a way to prove them wrong.
You'll likely have one app for iOS and one for Android; be sure to test them both.
If possible, close to the release date when everything looks like it's done, test that your deployment plan works. Try to download the app and install it, then use it. Have other people on other types of devices do it.
Have a backup plan.
What will you do if the app store is down? What if, despite all your work, the app doesn't work properly?
Have a contingency plan for dealing with these or other things that could possibly go wrong and share it with both your team and your nonprofit. Then you won't be caught having to think on your feet in a panic.
This may seem scarily involved and it can be - but it doesn't have to be. If you have a good set of Functional Requirements, have clear expectations and goals, stay on top of your communications with your designer and developer, and plan for contingencies, the road to your own mobile app may be a lot smoother than you think.