Pitch your app as you would to your end user
Always start your conversation by pitching your app as you would to your end user. This creates context and your minds start ticking together in the same direction right from the word go.
Be consistent with your terminologies
This is extremely important. Define your terminologies earlier and stick with them. This is going to help you immensely to avoid confusion, frustration and most importantly save time not only with the development team but with all the people you would be dealing with. Your investors, your users, your partners, even yourself and your co-founders. It’s astonishing how much getting this right helps.
App screens as hand drawn sketches. Be ugly, exhaustive
Nothing beats putting your ideas down on paper. Don’t worry about looking professional and go for one of those tools only to waste your time, unless you really are comfortable using those tools. Draw your screens on paper, take a snap on your mobile and send it across.
Write your user stories
The best way to synch up with your development team and all parties involved is to write user stories. User stories are nothing but a bunch of things your end users could do with your app.
Examples
“As a guest user I can sign up using my email, password of my choice” “As a logged in user I can upload a profile picture”
A user story is one or two sentences of plain simple english. Writing down all the things your end user could do with your app is the best way to get the overall perspective and in a way it helps you experience your app as an end user. User stories have helped us and our clients pick the right features to keep the first version rolling. It’s a brilliant way to cherry pick and prioritize your features.
Convey your vision as you would to your co-founder
You might think this is irrelevant information to the development team but in the long run it is. People need to know that the code they are writing has a purpose in this world, that bigger things are at stake and it’s not just another Xcode project on their hard drive.
Technology last
It’s probably best not to put forth the technology you want to go with unless you are absolutely sure. If you do, you are going to get a lot ‘But that’s not possible with that technology’, ‘I will have to see if this could be done with HTML5’ and so on and so on and so on. Whenever you discuss a feature with the developer his mind will start wondering if it could be done with the limited choices of technology you put forth on the table and invariably leads the discussion to the technology rather than your feature. You could always brain storm the technology with the development team once you get things in order