In short, the devices that route traffic between your various subnets (assigned to various VLANs) need to enforce communication security policy. At minimum, this means using routers (or devices with router functionality) that support stateless access control lists. If you want to get fancier you might use devices with stateful filtering functionality (typical stateful firewalls, Linux iptables, etc).
I think you may have a simplistic conception of what it means to not allow "normal users access to production". The path you're heading down involves charting out the various protocols (TCP and UDP ports, typically) that the client applications will need to communicate with on the server computers (some of which, in the case of Microsoft RPC, are dynamic by default). Once you've figure out how that communication is supposed to work you build access control lists (or firewall rules) to allow the required communication while denying all other traffic.
This is a hard row to hoe. I've seen very few environments where this was actually completely thought through and implemented. It involves a lot of communication between the application administrators and the network administrators (or, if you're one in the same, a lot of studying software documentation). There will typically need to be a lot of testing, and in many cases you're going to learn that "boutique" software application developers haven't ever taken the time to figure out what protocols their applications use to communicate (and often just assume a flat, open network between the client and the server).
In the end you may find that you'll have better luck running host-based firewall rules and being fairly lenient with your intra-VLAN access control lists / firewall rules, not necessarily because that's the right thing to do but because it's the feasible thing to do. Good luck!
As an aside: Seeing your planned subnets increasing by powers of 10 in the third octet says the same thing as your statement "I have never designed a network from the ground up, by my self." If you want to allow room for growth in those subnets consider doing something more like:
- 10.10.0.0 / 19
- 10.10.32.0 / 19
- 10.10.64.0 / 19
- 10.10.96.0 / 19
Even if you start using those various subnets as /24's you'll have room in each to grow up to /19's (with 4 /19's available for future use, too). With the non-contiguous subnets you're proposing in your answer you're wasting IP space or creating networks that can't be summarized with a single CIDR route.