Design
Design is a critical part of development, usually starts as the second step in a development project, and overlaps later steps.
The first step, before design, is to look at the project who, what, and why.
Why are you starting the project? A project could be an experiment or for self education. Anything else needs a reason why you would lock up time, money, and resources for the project.
What is the project? Creation of a new application is different to adding an extra feature and is different to those projects where you are copying an existing application. Yes, you might want to create something "new and disruptive" but there are always parts in existence that you can build on.
Who do you need for the project? The available people may change your design or change the way you design. Think about a project to set up an line bakery where people can design their own cakes. The baker is available now and the cake decorator is off somewhere having a baby. Your design could start today with the part of the Web site for ordering the cake base. Things like icing colour selection would be left until the icing expert is back from leave.
Your design might include a software framework and the framework selection might vary depending on the experience of the available developers. As an example, a few years ago you might look at a framework based on the incredibly fast Phalcon instead of PHP 5, to the extent of hiring a Phalcon expert to help get your project started. PHP 7 is so fast that Phalcon is now only a slight speed improvement and not worth the effort of hiring a specialist.
Your choice of software, database, hosting, and other technologies will have an expansion plan for the time when there are millions of users, if that is your long term aim. For a large project, your design will split development into smaller chunks that can be individually developed and tested.
Think about the online bakery. Will they sell conventional products like bread? Your basic shop can be developed by people with online shop development experience. The decoration section could be separate. A home delivery service could have the home delivery scheduling developed by another team.
For one online shop, I increased traffic to the shop many times with each increment a development phase that could have been a separate project if the project owner had hired more people. My little team made most changes so fast that the owner had a problem building the organisation to handle the massive increase in sales. We often had to switch features off to reduce customer purchases down to a level the warehouse could handle.
You will hear lots of arguments for specific design and development fashions. Someone will tell you to use NoSQL for data storage then, when you are stuck deep in the development problems created by NoSQL, they will suggest an add-on product that is actually just an SQL layer you glue on top of NoSQL. Your design has to be independent of fashion.
Effectively you have two levels of design, the logical and the physical. The logical level might have a requirement for a postcode lookup. Your design says the application can find suburbs from a postcode and postcodes from a suburb. At a later stage in the design, you might decide the lookup has to be a fast in memory lookup because it is used frequently or you might decide it will not be used very often.
How can something like a postcode lookup jump from high frequency to low frequency usage? In your logical design, your customer might select the postcode just once when they register for membership. This reduces postcode lookups to only occasional use. Your design might then change to let people shop without registering, which means they enter their address for every purchase. Now you need every component of the address entry to be instant. The developers may use a different physical design.
At the logical design level, you have some physical considerations. The customer enters an address. You then decide they can have a delivery address separate to their regular address. The extra address is a logical change that forces a physical change. In your logical design, you then add an option for multiple delivery addresses to allow for people ordering goods for relatives or branch offices.
This is the one, two, many problem. If there is only ever one of something, code and databases can be built for maximum efficiency and simplicity. When you decide there can be two, the design has to change. If there will only be two, the design change can remain simple and efficient. If there can be more than two, there is almost always a variable limit.
Suddenly you have to introduce code to to handle a variable list. Your logical design of user interaction has to handle "add another entry" and "delete and existing entry". When the list grows, you need scrolling on the list. You might introduce categories for entries, groups like work and family.
Good design includes designing the testing of user interactions to ensure the software will match what people do in real life. They may have shortcuts for some frequently performed activities. You may be able to reduce the user workload by remembering what they did last time. Shortcuts like that might, in some situations, make the action slower or lead to errors where people forget to check selections that are set on by default.
Experience helps. Using the example of the online bakery, you can benefit from experience building online shops plus experience shopping at the bakery plus experience behind the counter at the bakery. You then know the user interactions and options from both sides of the shopping.