system
Given the following post, respond as if you're commenting on Reddit:
human
ELI5: what is the design process of building an application?
gpt
Ex-developer and now IT project manager here. It depends on the size and complexity of the application.

For little wee ones like an Excel macro that processes a sheet or a data-cleansing routine, you usually have an idea in mind of what you need to have happen, so you break it down into steps and work through developing each step. So your mental map of the data cleanser might be: Pick up a record, look at it for these features, correct these features if you find them, put back that record in a new area. Then you build those (sometimes in order, sometimes not), test and tweak it as you go along until it's done.

For slightly larger and more complex apps, such as a simple game, first someone thinks about where they want to go with it, then they write the basics down to describe it to whoever is paying for it to justify getting money (if not themselves). With that concept of the game there, they start breaking it down into what they need to do first - for example, a sidescrolling game needs the ability for the character to stand on something, or a data processing application needs to connect to a data source and read a record from it - and work through that, then meshing out each additional detail as they continue. Sometimes this approach needs a concept demo too, such as if you're going after kickstarter funding. The developer invests some of their time into building a tiny part of the game that will look and feel a little like the end product, then shows it to the people they want money from so that audience can see what they're going to get. Then the now-funded developer gets approval and funding to do all the remaining detail work.

Big projects need teams need a much larger approach. You start with the basics in a story - "it will be a first person science fiction single-player shooter with a machine possession mechanic and will support multiplayer", and then each of your sub-teams on it gets their piece to do once you've decided on fundamentals like what gaming engine you're going to use if you don't build your own, what platforms you're going to target, and who the target audience is (e.g. whether it has cartoony characters or gory exploding ones). The story/script team starts building how the visual world will work and how single-person gameplay will flow by working closely with the art design team, and the technical team weighs in on what's technically possible versus what's not. This is a very back-and-forth process. The multiplayer mechanics team starts working on getting all the send/receive processing going. Then as things work along, all the team leaders meet and check with the boss to ensure they're staying on direction, trading information and changes around, and hitting deadlines, and they adjust as they go along.

The "traditional way" of doing all that organizing, called "waterfall", was to write down and get a signed off list of details before you start coding. The "modern way" is called "agile" and saying "This is what we're pointing at doing this month", getting approval for that, then doing it and figuring out what the next month's work will be like when the time comes. Agile is more flexible than waterfall, but it's also less locked-in, so it's useful for some types of projects more than others.