Empirical discovery is the only really good way to obtain this information. To get a design started, you'll need to characterize the kinds of people who will use whatever you design (including the "softer" categories just mentioned), and the best way to do that is to go out and meet them.
Each user group is unique, of course. The target audience for, say, a new cell phone will differ dramatically from that for a piece of scientific software. Even if the same person uses both, his expectations for each are different—a researcher using scientific software might tolerate a less-polished interface in exchange for high functionality, whereas that same person may trade in his new phone if he finds its UI to be too hard to use after a few days.
Every user is unique, too. What one person finds difficult, the next one won't. The trick is to figure out what's generally true about your users, which means learning about enough individual users to separate the quirks from the common behavior patterns.
Specifically, you'll want to learn:
Their goals in using the software you design
The specific tasks they undertake in pursuit of those goals
The language and words they use to describe what they're doing
Their skill at using software similar to what you're designing
Their attitudes toward the kind of thing you're designing, and how different designs might affect those attitudes
I can't tell you what your particular target audience is like. You need to find out what they might do with the software you design, and how it fits into the broader context of their lives. Difficult though it may be, try to describe your potential audience in terms of how and why they might use your software. You might get several distinct answers, representing distinct user groups; that's okay. You might be tempted to throw up your hands and say, "I don't know who the users are," or, "Everyone is a potential user." That doesn't help you focus your design at all—without a concrete and honest description of those people, your design will proceed with no grounding in reality.
Unfortunately, this user-discovery phase will consume serious time early in the design cycle. It's expensive, but always worth it, because you stand a better chance at solving the right problem—you'll build the right thing in the first place.
Interviews and on-site user visits put you directly into the user's world. You can ask users about what their goals are and what tasks they typically do. Usually done "on location," where users would actually use the software (e.g., in a workplace or at home), interviews can be structured—with a predefined set of questions—or unstructured, in which you might probe whatever subject comes up. Interviews give you a lot of flexibility; you can do many or a few, long or short, formal or informal, on the phone or in person. These are great opportunities to learn what you don't know. Ask why. Ask it again.
Case studies give you deep, detailed views into a few representative users or groups of users. You can sometimes use them to explore "extreme" users that push the boundaries of what the software can do, especially when the goal is a redesign of existing software. You also can use them as longitudinal studies—exploring the context of use over weeks, months, or even years. Finally, if you design custom software for a single user or site, you'll want to learn as much as possible about the actual context of use.
Written surveys can collect information from many users. You can actually get statistically significant numbers of respondents with these. Since there's no direct human contact, you will miss a lot of extra information—whatever you don't ask about, you won't learn about—but you can get a very clear picture of certain aspects of your target audience. Careful survey design is essential. If you want reliable numbers instead of a qualitative "feel" for the target audience, you absolutely must write the questions correctly, pick the survey recipients correctly, and analyze the answers correctly—and that's a science.
Personas aren't a data-gathering method, but they do help you figure out what to do with that data once you've got it. This is a design technique that "models" the target audiences. For each major user group, you create a fictional person that captures the most important aspects of the users in that group: what tasks they're trying to accomplish, their ultimate goals, and their experience levels in the subject domain and with computers in general. They help you stay focused. As your design proceeds, you can ask yourself questions like, "Would this fictional person really do X? What would she do instead?"
And there's more. You might notice that some of these methods and topics, like interviews and surveys, sound suspiciously like marketing activities. That's exactly what they are. Focus groups can be useful too (though not so much as the others), and the concept of market segmentation resembles the definition of target audiences we've used here. In both cases, the whole point is to understand the audience as best you can.
The difference is that as a designer, you're trying to understand the people who use the software. A marketing professional tries to understand those who buy it.
It's not easy to understand the real issues that underlie users' interaction with a system. Users don't always have the language or introspective skill to explain what they really need to accomplish their goals, and it takes a lot of work on your part to ferret out useful design concepts from what they can tell you—self-reported observations usually are biased in subtle ways.
Some of these techniques are very formal, and some aren't. Formal and quantitative methods are valuable because they're good science. When applied correctly, they help you see the world as it actually is, not how you think it is. If you do user research haphazardly, without accounting for biases like the self-selection of users, you may end up with data that doesn't reflect your actual target audience—and that can only hurt your design in the long run.
But if you don't have time for formal methods, it's better to just meet a few users informally than to not do any discovery at all. Talking with users is good for the soul. If you're able to empathize with users and imagine those individuals actually using your design, you'll produce something much better.