It sounds like you learnd it somewhere in an CS course or similar (which is a good thing IMO). I learnd it in some classes as well and I liked the approach that was taken by the teacher:
colleagues from other universitites, courses,... told me they were given big papers that explained normalization in a very theoretical (therefore rather boring) manner and they had no clue how to move this theretical knowledge into an ER-diagram.
We, on the other hand spend many hours learning how properly design ER-diagrams, the ideas that make up a good and maintainable database, how to solve arising problems in the diagram as well as in the database (with SQL) itself and much more. After these concepts were thought, we were told "what you did is called 'normalization'". You have done this and that when designing the ER, this is the 1st form of normalization.....
A sentence that got stuck in my head for such questions from my teacher is "with a well-though and properly designed ER-model, you ALREADY have a normalized database, so you do not need to think about all the forms of normalization".
Since your question is not about HOW/WHY use normalization but WHEN in the designing process, I think my long text above gives you a possible answer: when you understood the principles of good DB design, than your final ER-model IS normailzed (e.g. you created proper join tables, used foreign keys were applicable,...). I think it is a process that needs to go hand-in-hand with the setup of the tables, their relations and so on.
Of course, normalization is not always needed or wanted but in most cases, "drawing" the ER and thinking it through saves you from applying normalization by looking at the model and thinking: "OK, 1st form, are my values as atomic as possible"