Mohid Khurram
App designing is not an easy task to accomplish and it takes most of the time of the senior management and the developers and if it is not carefully planned, then all the work goes in vain, only to find that either this solution was not possible at all or there are many loop holes in it. So, we will be looking at the most carefully derived and structured framework for working on any bubble project starting with talking to the clients and gathering requirements for the project. First of all, we need to go down or rise up to the level of the client to understand the need of the app and the target market of that app. So your first and most basic question to the client should be
“Why did you think of designing this app? What is the use case and which target market will it go into?”
If there is any similar app(s) already deployed in the world in the same target market then you should add this to the list of your basic questions,
“Why did you feel the need to redesign this app? What are the rabbit holes in already deployed apps? ”
Or in some cases, our question changes to,
“What were you doing when the idea of making this app popped in your mind?”
These questions will help you narrow down and understand the KPIs (Key Performance Indicators) of the app/project that you are going to work on.
One thing to note here is, that not all that glitters is gold. You should not include everything in your KPI(s). You need to understand the client’s basic needs (why he thought of building this app) and collaborate with one or two peers to define the KPI(s). What we really need to look into at this point is what the end user is expecting from this app, and what the basic functionality this MVP should contain. What seems right to us may not be suitable for the end users or others so we really need to reduce it too needs if we want to develop our MVP fast.
The default response to any idea other than the basic structure of the app should be “Interesting. Let’s see, maybe”. It is like telling a soft “no” instead of “yes”. We don’t keep it in the backlog, instead, we give it space to think about and work on it if it is really doable or not. Even if we are excited about the new cool feature and it seems fancy for the app we don’t commit it right away only to find out later that this idea was not easy to implement or it can’t be implemented. This leaves a bad impression on the client and the company’s profile.
Now that we have our app’s scope and all the things are sorted out with the client we need to work on shaping the app
Setting a life cycle means defining a fixed time frame in which you roughly consider that the app will be completed. Break that time frame in half and take the first half and break it into further checkpoints/milestones. These milestones should be as follows:
Shaping the app should be done by the senior people and/or team leads in collaboration. It is early primary design work, from a user’s perspective. It defines what a feature does. Kind of private early rough work. It should include:
It should not be too opaque and not too firm that it can’t be changed.
Setting the boundaries means defining a time frame in which all the initial work will be done and it will become clear whether the app is deliverable or not. What are the limitations and what are the best practices? You can also set the task priorities in this phase, high and low priority tasks.
Use the technique of breadboarding for roughing out the elements. Don’t wireframe them yet instead draw the rough design and sketches on paper or on a whiteboard. Use the “KISS (Keep it simple, stupid!)” approach. Keep in mind the fixed time, and variable scope approach in mind too. We have to alter the approaches of doing something in a fixed time so we can alter the scope of the app instead of extending the initial time frame that we have set. Remember that “Good” is relative. There should be like three components in breadboarding
Look for and figure out all the rabbit holes and possible risks that might come up in the future. Watch out for grab-bags in this stage too. A tell-tale sign of the grab bag is the “2.0” label. Alter or cut down the scope of the app and /or reshape the app altogether without wasting any more time. At this point, you can also defer the idea. If after working out you think that this is not possible at all.
After you are done shaping the app, wireframe your ideas and designs. You can now collaborate with the designers and developers.
After wireframing the design, the most important building block of the app is the database design and architecture of the app. Make the best minds sit together and based on the breadboard design and wireframes, figure out the database structure of the app.
After the database design part is complete, move on to developing the app and bringing it to life. Focus on completing the high-priority tasks first and make the basic functionality of the app available asap. Don’t waste your time on useless and not-so-important things.
After development, the most important part before handing over the project to the client for evaluation is testing. Once you have completed a chunk of the project, test it and see if that thing is giving you the desired results or not.
After you are done with the successful testing, send the project over for review and take the feedback from the client and repeat the process from 4.
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}