What comes first: code or design?
Where does work on a project begin: in the realm of code or design? Each approach has got its pros and cons, as you might have guessed. Let’s try to explore the question and choose the appropriate strategy.
Code first
The title states it quite explicitly: the team dives into coding, ignoring the other parts of the product. Developers make sure that the product performs its key functions, for example, it can collect data, process it, and provide analytics. The main target is to create a working version, which is able to deal with the given tasks.
The beauty of this approach lies in the fact that the team does not spend time on the front end. Instead, they test the product’s reliability and efficiency in the first place. If the solution does what everyone expects it to do, then the time to craft its exterior has come.
The weak point is that at this stage the product will hardly be user-friendly. Sure, it can be tested quite well, but the absence of the graphical interface stands for the fact that the actual use of the solution will be rather unobvious for many perspective customers. If the software product is intended for the mass market, the command prompt manipulations are not the top choice.
Chances are that complexities might occur at the stage of uniting the front end and back end, resulting in code change. All the previously saved time would be spent on redesigning.
Design first
When this approach is chosen, it is not the developer team, but the team of designers and system analysts that do most of the work at the first stages. They study the requirements and begin to build a prototype that should have defined functionalities and that will be easy to use.
The prototype goes through usability testing, so the team makes sure that they actually designed a user-friendly solution that fits client’s needs. After that the developers start writing the code, uniting the front end and back end.
The advantage of the design first approach is that the created product turns out to be user-friendly. It might not be perfect, yet it is way easier to use it in comparison with the initial versions of the software developed in accordance with the code first approach.
The weak point of this approach is a much slower speed. While designers are building, testing and improving the prototype, developers have no chance to start full-scale work.
Moreover, if designers give rein to imagination and add functionalities that are difficult to implement, the story with complexities at the intersection of the front end and back end might repeat itself. The only difference is that instead of rewriting code, developers will have to puzzle their heads about implementing cunning features.
How to choose?
If your task is to release a working version within short timeframes, while beauty and interfaces are not important, the code first approach seems to be a perfect fit. First releases are going to be a bit rough, but they do not require too much time on the development and allow you to evaluate the overall efficiency of the system.
If you can afford to spend some time on creating a prototype, the design first method should help. Giving your designers an opportunity to build and test a prototype, you have higher chances of getting a more user friendly interface of the product in early development stages.
Both approaches can shine under certain specific conditions. Figure out the priorities, resources, and the time that you have. Remember that any methodology requires collaboration, so developers and designers should always keep in touch. Changes and improvements are inevitable in any case — these are integral parts of a work process, after all.
Minimize the risks of conflicts at the intersection of the front end and back end by working with system analysts. They will help to shape proper product requirements, set tasks, and make sure nothing important is missing.
