8 Asking Good Questions

CONTENT

  • Why Questions Matter
  • Things to Avoid
  • Other Things to Consider
  • Activity: What’s Wrong With These Questions?
  • A Final Thought

One of the most important skills in software design is learning how to ask good questions.

At first, this might sound simple. After all: How hard can asking questions be?

As it turns out, harder than many people expect.

In CIS3750, your team will work with a community partner to better understand a real challenge and design a thoughtful software solution. That means you will regularly need to:

  • gather information,
  • clarify uncertainty,
  • explore ideas,
  • understand needs,
  • challenge assumptions,
  • and identify potential problems.

Good questions help make this possible.

Poor questions can lead to confusion, misunderstandings, missing information, or software that solves the wrong problem.

Put simply: Good software design begins with good questions.

Why Questions Matter

Imagine someone tells you: “We need an app for volunteers.”

At first, that might sound straightforward. But immediately, several questions should come to mind:

  • What problem are volunteers experiencing?
  • Who are the volunteers?
  • What does the current process look like?
  • What frustrations exist?
  • What information needs to be tracked?
  • Who will use the system?
  • What happens if nothing changes?

Without asking questions, it is very easy to start designing the wrong solution.

This is one of the biggest mistakes new software designers make: Jumping to solutions before fully understanding the problem. For example, imagine designing a mobile app when users actually need:

  • a simpler website,
  • a scheduling system,
  • clearer communication,
  • or a process change that does not require software at all.

Sometimes the best solution is not the first idea. And sometimes the problem people describe is not the real problem.

Learning how to ask thoughtful questions helps teams:

  • better understand challenges,
  • identify user needs,
  • clarify assumptions,
  • gather requirements,
  • uncover hidden issues,
  • and design more useful solutions.

In many ways, software design is part investigation.

Open Questions

An open question encourages someone to explain, describe, or elaborate.

These questions often begin with words like:

  • what
  • why
  • how
  • tell me about
  • describe

Open questions are especially helpful when:

  • learning about a problem,
  • gathering information,
  • understanding experiences,
  • exploring ideas,
  • or identifying unexpected issues.

For example, instead of asking: “Do volunteers have trouble signing up?”

you could ask: “Can you walk me through how volunteers currently sign up?”

Why is the second question better?

Because it encourages explanation.

The person may describe:

  • frustrations,
  • missing information,
  • workarounds,
  • communication problems,
  • or unexpected barriers.

You often learn much more than you expected.

Here are some examples of strong open questions in software design:

Understanding Problems

  • What challenges are you currently experiencing?
  • Can you describe your current process?
  • What tends to go wrong most often?

Understanding Users

  • Who typically uses this system?
  • What are users trying to accomplish?
  • What frustrations do users experience?

Exploring Possibilities

  • What would an ideal solution look like?
  • If you could improve one thing, what would it be?
  • What would success look like?

Open questions are often the best place to start.

They help you learn before making assumptions.

Closed Questions

A closed question usually has a short or specific answer.

Often: yes, no, a number, or a brief fact

For example:

  • How many volunteers participate each week?
  • Does the system currently store usernames?
  • Do users need accounts?

Closed questions are useful when:

  • confirming details,
  • clarifying information,
  • checking assumptions,
  • or gathering specific facts.

For example:

Instead of asking: “Tell me about your organization.” you might ask: “Approximately how many people use this service each month?”

That question provides a specific detail that may influence system requirements.

The challenge with closed questions is this: They can accidentally shut down conversation.

For example: “Do users like the system?” The answer might simply be: “No.”

That does not tell you very much.

A better follow-up question might be: “What frustrations do users experience with the current system?”

Good software designers often combine: open questions + closed questions

Open questions help explore. Closed questions help confirm.

Things To Avoid

Not all questions are equally helpful.

Sometimes the way a question is asked can accidentally influence the answer or create confusion.

Here are a few things to avoid.

Leading Questions

A leading question pushes someone toward a particular answer.

For example: “Don’t you think a mobile app would solve this problem?”

Why is this problematic?

Because the question assumes: a mobile app is the right solution.

A better approach might be: “What kinds of tools or changes do you think might help?”

This leaves room for new ideas.

Remember: Your job is to understand the problem before proposing solutions.

Asking Multiple Questions at Once

Sometimes students accidentally ask three or four questions at the same time.

For example: “How do volunteers sign up, what problems happen, and do you think a mobile app would help?”

That is a lot to answer at once.

People may:

  • answer only one part,
  • forget pieces,
  • or become confused.

Instead: ask one clear question at a time.

Questions That Are Too Vague

Questions that are too broad can make it difficult for people to know how to respond.

For example: “Tell me everything about your organization.” That is overwhelming.

Instead, narrow the focus: “Can you walk me through how volunteers currently register?”

Specific questions often lead to clearer answers.

Jumping to Solutions Too Early

This is one of the most common mistakes in software design.

Students often begin asking questions like:

“Would you want a chatbot?”
“Should we make an app?”
“Would notifications help?”

Too early.

Before asking solution-focused questions, make sure you understand:

  • the problem,
  • the users,
  • the context,
  • and the existing process.

Otherwise, you risk solving the wrong problem.

Other Things To Consider

Asking good questions is not only about the wording.

It is also about how you listen.

Listen Carefully

Sometimes people answer a question and accidentally reveal something important.

For example: “Well, we usually track everything in Excel because the old system stopped working…”

That might lead to useful follow-up questions:

  • Why did the system stop working?
  • What problems existed?
  • What works well about Excel?
  • What does not?

Good software designers pay attention to unexpected details.

Ask Follow-Up Questions

Often, the most useful information comes after the first answer.

For example: “You mentioned volunteers get confused during sign-up. Can you tell me more about that?”

Follow-up questions help move beyond surface-level answers.

Do Background Research

Before meeting with a community partner: Do your homework.

Take time to:

  • read their website,
  • understand their mission,
  • review existing materials,
  • and learn basic information.

This helps you ask stronger questions and use meeting time more effectively.

Be Comfortable With Silence

Sometimes people need time to think. That is okay.

You do not need to immediately fill every quiet moment.

Pausing often leads to more thoughtful responses.

Write Things Down

You will forget details. Everyone does.

Take notes during meetings and discussions.

Important ideas often become:

  • requirements,
  • assumptions,
  • design decisions,
  • or follow-up questions later.

Activity: What’s Wrong With These Questions?

Consider the following questions.

What problems do you notice?

  1. “Don’t you think students would prefer an app?”
  2. “Can you explain how registration works, what problems exist, and whether volunteers like the current system?”
  3. “Tell me everything about your organization.”
  4. “Should we add AI to the system?”

For each question, consider:

  • What makes the question problematic?
  • How could it be improved?
  • Would an open or closed question work better?

Discuss your answers with a partner or small group.

A Final Thought

Many students enter CIS3750 thinking software design is mostly about building systems.

In reality: software design often begins with listening.

The better you understand the people, challenges, and context surrounding a problem, the more likely you are to design something useful.

Before jumping to solutions:

Slow down. Stay curious. Ask better questions.

License

Software Design: Planning Purposeful Solutions Together - A Community-Engaged Approach Copyright © 2026 by Daniel Gillis; Nicolas Durish; and Alessandro Arezza. All Rights Reserved.