Famous waterfall
For many years digital projects were designed and developed in the waterfall methodology. In this approach, each stage of the process takes place when the previous one is finished. The waterfall process starts with deep analysis, then it’s time to design, develop, and conduct QA tests, and after all, you go live, fix bugs after the release and... the job is done. This sounds logic and for some projects, this might be the most accurate way of project execution. But for others, it might not. Especially when it comes to working with a complex product.
The waterfall approach is associated with a step by step activities in the project, a more formal way of organizing the workflow and a lot of bureaucracy. A characteristic aspect of this approach is the fixed scope in the form of documentation that is approved by decision makers. This can work in a stable market, but there is always a risk that the longer a product is developed the more the surrounding environment is changed. The problem appears when you revise your project and decide to make some modifications. It requires taking a step back and making changes both to the project documentation and in the code, what is not a budget-friendly option. Moreover, the time of development is significantly prolonged. As a result, you end with a digital product that is coherent with documentation but is out of date and needs more adjustment work is already doomed to fail.
Fabulous Agile
The remarkable disadvantages of the waterfall approach were the main trigger to take a closer look at different methodologies to deliver digital products. There are more flexible ways to craft and launch new apps efficiently - there are called Agile methodologies. In this approach, teams are more cross-functional and self-organized. There is less “paperwork” and the decision-making process is much faster. When it comes to the development phase, it is done in an evolutionary way as the product is not built at once. The process of building the app is divided into smaller parts - iterations. After each iteration (called sprint), both the client and the team can see not only the progress of work but also the result of efforts. Such a check-up helps to plan the tasks for the next iteration. What’s important if any solution or feature needs to be changed, it will be also included in sprint planning. Moreover, a client can react to what is happening on the market and make necessary modifications with less severe consequences for his budget. This is how Agile methodologies “tame the change” and make it is less costly than in a waterfall fixed scope.
This change in software development had an impact on the product design process too. Designers and software engineers started to work more closely. Exchanging ideas and knowledge among team members has become more fluent and less formal. This way of cooperation in multidisciplinary teams is more effective and creative. When you gather people who represent different fields and who have diverse knowledge and background they will look at the problem from different perspectives. This new approach assumes that this group of people collaborate through the whole process - in contrary to the waterfall where designers after their work weren’t included in further steps. Their job was done. In reality, there are no strict phases of the product development and input of designers, developers, testers and other team members is crucial through the whole process.
Fascinating lean startup
Another popular way of organizing and managing workflow is a lean startup methodology. A key element of it is MVP (Minimal Viable Product). The main idea behind it is prioritizing functionalities that you want to put into your product. You should ask yourself whether all of them are necessary for satisfying users and reaching business goals. Of course, there are features you can’t remove because otherwise you won’t make money or your product simply won’t work properly. These core functionalities are called MVP. In other words, it’s your basic product that should be built at first.
Why is it not reasonable to devote a lot of time and money to develop a fully-fledged product at once? In the ever-changing environment, you need to react fast on what is happening on the market. By doing so you will validate if your idea for the product makes sense and get valuable insight on the next steps and future product improvements. MVP is important for at least two reasons: it saves time and money as you focus on building only the most beneficial part of your product, instead of crafting it all.
Fancy Design Sprint
Validation is another very vital keyword here. The product design process should be done in small iterations so that all ideas are checked regularly and changed if necessary. That approach leads to instant improvement of the product. It should start with the research to test if there is a real market need for your project and then be continued in the design and development phase.
Here with help comes the Design Sprint methodology. It’s a framework that uses design thinking methodology to help validate the ideas, solve product challenges, align team vision of a product while setting clear goals and objectives. It is one week sprint during which the design challenge (the goal, the problem to be solved) is worked through, solutions are generated, the prototype is constructed and checked with target users. Reached conclusions are the foundation of the final solution which will be tested again - in the real world. To hit this one-week deadline, you need to set a clear goal and have a deep knowledge of functionalities you want to implement in the MVP version of your product.
The Design Sprint is a framework, not a strict rule hence it could (and should) be adjusted to the particular project and its conditions. It can be done in more or fewer days, various product design workshops techniques can be used and the different participants can be engaged into it but the structure must always be the same: discover, sketch, decide, prototype, test. If there is no testing phase, it is not a Design Sprint.
Which design methodology should you choose?
The common truth in the digital world: what was true yesterday might be not true today. Hence the product needs to be crafted and launched in a very flexible and fast way. However, the methodology of development should be matched to the circumstances and specifics of the project.