I've designed and obseved others design multiple systems in the past and I've seen the process unfold in many different ways, but what I find common is that the initial architecture should at least plan for the existance of most major features.
For example I've seen an HVAC control system that had no concept of buildings, floors, rooms etc being retrofitted with those and the result was as ugly as they come. Or a mobile music device built out from components better suited for your (non-smart) pocket watch. Needless to say the end products in either case weren't customers' favorites.
When you say "conception" that's only one step up from "idea" and a concept can be very fuzzy. Business usually cares about concepts. Customers usually care about UX - a concept brought to reality in a way that's easy and pleasant to use and brings some value through its use.
You have to do "concept" before any programming, I can't envision myself opening visual studio (or your IDE of choice) and randomly writing code, to see where it goes.
You may not do a complete design (and you shouldn't) before coding but you should have a rough sketch of what the user's workflow would be.
UX design and coding quite often feed off each-other, you'll likely be forced to use some Agile approach for anything but smallest of projects as a way to incorporate this fact into how you approach the work. So don't think you're the worst of programmers if you couldn't see it all at once - nobody can and the people who think they can are the ones who just ignore enough of the problem so they can claim they have a complete picture.
One example to put a size to something big.
Concept: "Create a visual cloud-based tool that allows businesses to integrate their software platforms". This sounds great and one can start writing up marketing material and sell it before it's even there. You have to have this before coding.
Pre-design: "Have shapes and arrows like in Visio to describe logic; have plug-in capabilities to allow connections to various platforms (SAP, SF, databases...); have a monitoring console where one can search data passing through the system; have a way of describing data visually and transform one format to another". Another great marketing blob. It also gives you some ideas on what's important, should have such a rough sketch before coding too.
Design/Code: "Have a browser hosted HTML designer with such and such features; code the backend in Java so it can run on any existing server; define data structures and UX for querying or modifying them as needed; plan for disaster recovery, error reporting, audit logging; plan version control; plan access control;...." - the finer the list the more unrealistic it is to foresee all of it.
... however one should be at least aware of what things might end up looking like roughly or your final product may end up with some really useless implementations that end up killing the otherwise great-sounding concept - say your visual designer requires a 40" screen to show any real-world workflow, or there's no way to search the logs other than an exact string match limited to one of the 20 fields in the log etc etc. There's no good way to prevent this from happening other than executing your implementation - some will succeed, others will fail.