I usually go the same way I did when I was playing Legos... I think, do, rethink and redo and so on until I get it right making up new things as I go along.
That seems like a good approach. I like to "develop" or "grow" the project...
The "right way" is to develop your requirements/specifications first. With a hobby project, you don't need all of the details nailed-down first, in fact you might get some good/better ideas as you progress. But, you should have an idea where you are going...
Then try to figure-out if it's feasable and economical, and try to get some ideas of how you are going to approach it. What's it going to take in terms of time, materials, knowledge, and skill? (If you wanted to build a motorcycle, you wouldn't use Legos, etc. 
)
For me it seems like I usually start with the hardware. I try to figure-out what kinds of parts I'm going to need (is the Arduino going to work, or do I need something different?) and I sketch-up a schematic, even if I don't know details like exact resistor/capacitor values, or what transistor I'm going to use, etc. Then I order some parts, and probably a few extra parts. It's not unusual for me to make a 2nd parts order as the project moves-along, but hopefully I'll only have to order parts once or twice.
Then I start development... What I mean by "development", is that I break it down into parts/modules that can be built & tested separately. I do this with both the hardware and software, and where I start depends on the project... Typically, there is input and output. I may be able to test the output-hardware (i.e. relays, or an LED matrix, etc.) by itself by hooking-up voltages, or I may be able to use a little test-program. Same with the input-side hardware (i.e. switches, op-amps, etc.). I may be able to test it by itself, or with a multimeter, or I might need to hook-up the Arduino and run another little test-program. Or, maybe I need the Arduino and the output-stuff working before I can fully-test the input side... That's stuff you have to figure-out.
For "prototyping", my standard practice is to build the final circuit on a plug-in "breadboard" whenever possible, so my final-prototype is my final-design.
The same "development" is true with the software (even more true with software). You generally need to write the output-stuff first, so you can "see" what your program is doing. If you try to write the whole program (sketch) at once, you will have lots of errors, it won't work, and you won't know why. And, you usually cannot just start at the top, and work down... You need to start with things that you can try/test and when they work, add more.
When you write a function, you can start-out with a simple function that does part of what you need (and maybe it blinks an LED, or sends a message to the serial monitor) and then add to it, testing as you go-along. Whenever you add a function, or a bit of code, make sure you can test it before moving-on. If you can't test your code/function because the program isn't finished, you are porbably working on the "wrong" part of your program. Or, sometimes you have to write some extra "test code" just to check-out your "real code". You can remove or comment-out the test code when you're done.
And if you are dong it the "right way", the final step would be to test and confirm you've met all of your requirements/specifications. With a hobby project this isn't usually necessary... You know if you are happy with the result.