Yes, of course, that’s a normal process. I do that all the time. Most of my designs start as pen-and-paper ideas. This applies to software, electronics and mechanical. I still do state machine and such things on paper before coding. It is often hard to create in the context of a rigid CAD system of any kind, I see it more as a means for documentation once you have a reasonable idea of what it is you are after.
What I will sometimes do on EDA is grab components from the most convenient library and thread together a design. That means I give preference to our vetted components, sometimes without regard for values or details and, if they are not there, I might go for a stock library of some kind just to get moving. The closer I get to the golden component library the less work I create for myself later.
At some point all components have to be from the qualified libraries. If some are missing, this is the moment to do the work require to add them.
Once you do that and make all appropriate replacements it’s one turn of the crank to get a BOM you can review and order and off to layout it is.
I would guess everyone has a process along these lines to one degree or another. You have to get your thoughts down first before you can engage in detail work.
Ah, good point. I am using language from object-oriented programming without realizing a lot of people might have no clue what I am talking about. Thanks for pointing this out.
In case you happen to be interested in that context, Wikipedia does a decent job:
https://en.wikipedia.org/wiki/Function_overloading
In this context I use it to mean the use of a field for more than one thing and that these things are not necessarily the same.
Let me use a completely unrelated example:
You go to the doctor. They make you fill out one of those horrid forms nobody likes to fill out. One of the items has a label that reads “height”. You write in your height and move on.
A few minutes later the assistant comes over and says, “You didn’t enter your weight. We need that.”.
You look at the form. There is no field tagged “weight”.
You ask. They say "Oh, just put it in the “height” field.
What do I do with my height?
Oh, just cross it out.
Do you need it?
Yeah, but there’s no place to put it. Just write it somewhere on the side of the page.
So…you want me to put my weight where it says “height” and my height on the side of the page?
Yes.
OK.
The reuse of the “height” field to record the weight is, in programming terms, akin to function overloading. It isn’t a perfect parallel but most programmers would understand what I meant when I used the term. Sorry for not realizing I was speaking gibberish to everyone else.
Anyone can understand the obvious problems with such a medical form. Imagine if every office used the “height” field differently. Imagine if every office had a different idea on where to record the weight and what to call it. It would be a mess and your medical records could not be moved shared from doctor to doctor without a ton of work.
That’s the issue I am presenting here. The term “semantics”, as I apply it here, is about having fields that capture the appropriate meaning. The “value” field should never have a part number or be linked to the symbol name. Anyone can understand that the “footprint” field should not have the URL to the datasheet and that the “datasheet” field should not have a link to the 3D model. Everyone gets this and would likely agree with this. Well, it isn’t any different with the “value” field.
From this it follows that we need two standard fields: “part number” and “manufacturer”, along with a “value” field that has no connection to the symbol name.
This isn’t about forcing people into workflows as much as it is about creating a sensible starting point from which a greater ecosystem can evolve. Nobody in the electronics industry orders part by hand-waving. As a famous race car builder and mechanic used to say “When all the smoke and bullshit clears out, you have to drive the car and win the race”. Well, when all the huffing and puffing clears out, you have to have a real orderable part number and the manufacturer’s name to be able to get anywhere with anything other than hobby electronics or just hacking around. They are, without a doubt, absolutely necessary. And KiCad does not provide official support for any form of this in a standardize manner that would enable the user and software author community to expand capabilities beyond what anyone could possibly imagine.