The general idea behind software development processes of all kinds is to minimize the amount of work you do so you don’t waste your time, and money.
The idea is simple enough, but there’s plenty of ways to “waste time” on a task. From something basic like running into a lot of bugs because you’re inexperienced with programming, to more serious larger scale problems like the entire product you built has no target user base.
For a project you’re building to learn, these sorts of things aren’t really that big of a deal, its also possible wasting time might actually not be that big of an issue if it means you learned something.
Because of that focusing on learning goals might be more important than focusing on some process you learned. It’s fine to learn about processes as well, but just keep things in perspective as you could always cut corners for less important things.
So for example, creating mock-ups and designs might be faster than trying to build an initial UI, but if your more focused on learning how to build UIs it might not matter if you build your UI first and change it later.
So if you want to build to learn, understanding the goals of the project in regards to learning something are the most important. I usually recommend picking a few things you have some solid understanding of, and including them as a “base” of where you can start and add things you’d like to learn more about. This way you review what you already know, while being able to mix in a few other things to learn about.
You could in many cases do this if you’re focused on learning things about coding. Sure you might be going in with a super vague plan, but you could also spend all your time planning and not learning anything coding wise.
Having a vague general plan like “I’m going to build ___ using ___ within the next ___!” might be all you need to get things going.
If you were working professionally this approach wont cut it, and some sort of development process would become more important.
Good luck, keep building, keep learning 