When you are developing an app, this is where things get hard. Really, really hard. This part is the part where managing your own expectations is just as important as managing your timelines.
Actually, what happens here is more planning of your timelines to suit your budget and goals. They need to be done in conjunction with your developer to make sure you are both on the same page. Keeping in mind, right now, you don’t even have designs, you actually don’t even know what your app looks like, how the User Interface (UI) will look, and how the User Experience (UX) will be. Let alone, how long it’s going to take to develop these things.
But, you need to plan for it. The first thing you need to do is work out how long it is going to take to design your app. Normally, developers will want to go through a wireframing process where they make your app on a piece of paper (or on a screen) with boxes and squares to give you a kind of general idea of the layout of how things are.
After that, you’re going to need to design the app. What I like to call (and what designers hate me calling it) the colouring in. Putting the colours of buttons, making it all look awesome, font sizes, logo placements and so on.
Now see, you won’t really start getting into timelines until after this process has completed.
I may have actually jumped the gun here talking about this stuff, and in my next blog I will actually talk about the design process, but I want to make sure you understand what it is to build an app.
Firstly, and most importantly, just like the construction of a house. Nothing will be finished on time. Because no matter what, and no matter how well you think of everything, you have never thought of everything.
Your developer will ask a lot of probing questions about this stuff, and it’s important for you to remember, they aren’t being negative, they aren’t trying to stop you from developing, they are really trying to find out what they should do in certain cases. They’ll sound like they are coming up with every negative scenario and only caring about that. But really, it’s important to do this. More than you can know.
You see, when you theorise an app or a function, you will only think of the perfect way it will be used. And if you only think of that, you’ll release it like that. And then users will break your app by using it outside of how you planned. So, managing the timelines is directly linked to managing the expectations.
For every function that you can think of, and every item you want to add, you haven’t thought of every eventuality. And your developer will also not be able to think of every eventuality. And so, each time a new thing comes up, you’ll have to rework your idea, and develop new restrictions or functions to manage it.
This will actually happen all the way through your development and for the lifetime of your app. And it’s really important to manage this up front. Even when wireframing (so I guess this is why I am talking about this now). You’ll tell the developer how you want it to be. You might even draw it for them.
They’ll ask you “But what if this happens?” and then you’ll have to re-draw it. So, you spent 5 hours drawing all your screens and all your wireframes, and then suddenly you have to go back and redraw them.
And so this is managing your expectations. Something to remember is, nothing is ever finished, and nothing is ever perfect. Remember this and you will avoid some disappointments.
Next time I’ll get in to how to wireframe and then designing. But for now, remember, at all points, when you are dealing with your developer, allow yourself some extra time for the surprises.
And make sure your developer is always up front about this. At every stage your agreement may include a limit on the number of feedback rounds you have. So you may want to talk to your developer about this up front.
