By 
Today, we will talk about three options for custom web application development. All of these methods have their pros and cons, so one may suit someone, and another may suit someone else.
Design process
Just the case when the design is drawn even before full immersion in the technical part of the work. Sometimes prototypes are allocated, and the design is made based on them, but be that as it may, the key difference in this option is that there is no discussion of technical issues until the final design of all application layouts appears.
The design is drawn without regard to how it works – only after receiving the design, the TOR is drawn up and the development itself begins.
Why is this approach reasonable?
By creating a design at the first stage, you can quickly see what the final application will look like. No need to wait until the technical specifications are written, until all the details are thought through – you can immediately see the finished layouts that will be implemented at the final stage of development.
What is bad?
There are very few designers who consider the technical features of the development and understand the design. Quite often, clients come to us with their own design, but eventually, it turns out that on one screen there is one number of fields and forms, on the second – another, and how it all should be combined should be thought out by the programmer.
Where all this will be stored, no one thought at all, there are links to a screen that is not drawn theoretically. In short, the designer does not think about how all this will work. He was paid, he painted – everything is ready, this is his job.
It rarely happens that a designer leads a project – usually, he simply performs his task and no longer bears any responsibility that falls entirely on the founder of the project. Be prepared for the fact that when you come to the programmer, he will report that the design does not have one, the other, the third and the tenth, that the screens do not agree with each other, and therefore will ask you to redo everything and only then return to it.
However, to show the investor, that this option, theoretically, may be enough – the most important thing is not to forget about the architecture. I recommend this approach only for making a beautiful presentation to get money for development.
Classic approach
The second, most common approach: first, the TOR is written, and the details are thought out, then prototypes and designs are made, and based on what the designer drew and what is written in the TOR, a mobile application is assembled.
What are the advantages of such an approach?
Firstly, it is understood by the vast majority of developers and designers, who will know what part of the path they are on, there is no need to tell, detail, and explain anything.
Secondly, everything is logical here: first, they described what should happen in text format, then they did it visually, and then they put everything into practice. And if there are no deviations along the way, you are almost guaranteed to get exactly what you originally ordered.
And what are the disadvantages?
After the TK, at the stage of frameworks and design, changes are often made. And just as often, these changes are forgotten to be added to the original documentation. You need to follow this very closely and avoid inconsistencies because when you come to a programmer, and in the designer’s layouts and in the TK there are absolutely different things, and the programmer will definitely make a mistake somewhere. All data must be updated in a timely manner so that everything is the same everywhere, accessible and understandable.
Technical Approach
Like the second, it assumes the presence of TK at the initial stage; then wireframes are drawn, sometimes called linked prototypes.
At this stage, customers often find that they can add or improve, and not in the visual, but in the logical part – and immediately, in hot pursuit, make the appropriate changes. Wireframes can be made in one week, so if we wrote TOR for two weeks, made wireframes for a week, then only three weeks after the start of work we can already see what and how to improve and spend only one week on introducing changes to the TOR and wireframes.
And it is then that the magic begins, which allows you to significantly reduce the implementation time: both the technical and visual parts are done in parallel. Programmers work on the server side, make an application based on wireframes, and designers draw the final interface, layout designers make it up.
As a result, when the application, design, and layout are ready, it will take very little time to transfer the design to the application assembled on wireframes. It can be done within a week. The frames themselves are designed in such a way that it is possible to change their structure minimally.
Why is it good?
It turns out a simple process during which the mobile application is quickly launched – without delays and without problems.
Comments