The "easy answer" is to educate THEM that it is their
responsibility to communicate software design/architecture ideas to you.
In a nutshell, software development has three primary layers - back end, middle-tier, and front end.
Unless you take major courses and bootcamps, you will not be able to "talk" back-end. It is filled with issues like unit testing, data distribution, object modeling, and so forth. This is where the "surgeons" live. As a "Master Surgeon" myself, I can assure you that the BEST back-end developers have mastered the ability to talk to "civilians" without attempting to sneer (a sign of an immature developer), or act confused (a sign of an incompetent developer), or respond with silence (a sign of a useless developer).
The BEST back-end developers reflect your business requirements back to you, in terms you can understand, and then present their own questions using diagrams and analogies so that YOU can make educated decisions.
Continuing with my (pretty loose) layer speech - the middle-tier developers are a little more "human" than the back-end developers. They speak in terms that you can sometimes understand. Connecting servers together, reaching remote offices, backing up data ... that's not something you have mastered, but you can wrap your head around the broad strokes.
The thing about middle-tier developers is that they think they are in charge of everything. Since they work on coupling the complexities of the back-end with the tools of the front-end -- they generally are more demanding and akin to project managers. If you can handle project managers, you can handle middle-tier designers/developers.
When you speak to them - talk to them in terms of business - not tech. Cost, delivery time, future-proofing ... these are things that matter to you. Design model, framework, API, and test set ... these are things that don't matter to you - as long as the middle-tier people are CLEAR with you on what choices they are making and (with a little google-fu) you confirm that their choices aren't ancient, or rare (people using email to distribute databases = bad, e.g.). Once again - these people should be able to communicate to YOU what is going on, even more so than the back-end people.
Finally - there's the front-end people. Sadly, this is where most of the noise you fear originates - because it's easiest to "fake" being good at front-end ... and even worse, it's easier to build a good front-end that does nothing and pass it off as a real application than it is to build a back-end that does nothing and pass it off as anything at all.
There are brilliant front-end designers and developers ... but for every one of those - there are 10 wannabes who started by drawing digital pictures and now believe they are programmers. They are not. If you can't code on paper with a pen (in theory) then you are not a coder. Using a "web building" tool is not coding.
I hate to say it, but more often than not, THESE are the incompetents who play emotional games to make you feel stupid, uninformed, or behind the times. They are doing so because they are hiding their own inadequacies (sometimes even from themselves).
Do I hate front-end developers - absolutely NOT! The good ones build the critical tools that empower users to interface well with the application. Nothing kills an app faster than a lousy User Interface (front-end). But I do hate two things: people who pretend they know things they don't, and people who try to make others feel bad for not knowing what they do. It's hard to fake it in the back-end and middle-tier ... but the front end can be faked ... so, you get my point.
But how you talk to the front-end people is simpler ... because it involves YOUR normal USER-based sense of things.
Go to the iPhone app store or Android marketplace and download a 1-star app (no, don't :) ) ... will I need to stand with you for you to understand why it got 1 star? No. That's instinctual - you KNOW what makes a good interface because you know how a good interface feels. So when you talk to the front-end people, you can talk about "I don't think that this font color pops out enough" or "I'm lost, where's the button to order the coffee?" (I'm looking at YOU Starbucks :D ).
If the answers are "oh, you're right -- I can see that the font is hard to read, let me check that out" -- you're all set. If the answer is "no - that's what everyone is doing now, it works" - you don't need ME to tell you that's pointless.
If you want jargon, talk about UX (user experience). The GOOD front-end designers will be able to tell you what visual standards they are using to make their choices (the cancel button is always next to the submit button because of standard "confirmation controller" design rules, e.g.).
So to conclude this long post:
My advice to you is stop trying to be knowledgable about architecture in order to find the right office space for your needs. Find the architects that translate building code into terms you can understand and appreciate.
When you approach developers, identify the roles and people with whom you are speaking. Are they back, middle, or front-end people? Ask them - point blank. If they don't answer, yuck. If they're confused, fear. If they sneer - meh.
The farther back they are - the more you can tell them, point-blank "I do not understand what you just told me" and have the right to demand that they explain it again. The farther forward they are, the more you can talk to them in terms of what YOU understand ("the phone's pop-up keyboard is blocking this icon").
As you talk to developers, realize that it is THEIR responsibility to make things clear to you - if they don't, find another vendor - if you can't - then go back into "human space" and work with them to develop better tools of communication.
Fear of Looking Like a Fool
I am an expert. Period. Lightning crackles from my fingertips and I save castles from dragons every day.
When I am in a room with a bunch of techs, and someone mentions a tech I don't know - I say "what is that, I don't think I know that term."
Here's a secret. The man or woman who says "I don't know what that is" in the "tech battle" is the one who is not afraid. She or he may not know every detail, but you can be sure that person is confident, transparent, and trustworthy.
If it references something obvious - I laugh - in large part because everyone in the room knows I'm the expert. If it references something I don't know - and it's near something critical to the business (e.g. the difference between "our flarn is going to make the mouse work better" vs "this blarp is connecting to your bank account") -- I make a project point of having that explained to me (or more likely, just say "don't move until I research that" and then go read up on it).
But here's an even bigger secret: when the client says "I don't understand that" - the smartest techs start explaining, because the person who explains to the client gets "the king's ear."
Be the king or queen. Offer your ear to the best explainer. You are the power - you don't need to be empowered.
ANY time you find yourself in a room with someone who is playing "black magic" games, it's a measure of their failings, not yours.
You have a right to be an expert in your own field and not feel "stupid" because you don't understand what they are doing. Tech is 100% artificial - it's "man made" ... that means that there is nothing in it that can't be explained to a human.
If you (as a human) are confused -- someone with more knowledge than you is failing. If you like that person, help them and tell them. If you sense that they aren't trustworthy and/or are hiding their own incompetence -- deal with it like any other vendor/employee/specialist.
The best of the best should be able to translate for you (e.g. "do you want a large multi-core system or a cluster?" becomes "do you think this solution needs a single elephant, or a herd of horses? Let's discuss that with a whiteboard.") ... you are good at what you do, you are intelligent, and you know it better than this developer. Their job in life is to build a software application that helps you in your field, if they can't explain that - then find someone else.