Kat McGowan

Home

/

Blog

/

Turns out ‘Understand feedback’

August 28, 2025

Turns out ‘Understand feedback’ isn’t a real learning objective

I’m currently designing my first learning module - a short course on how to give constructive feedback at work. It’s part of a self-directed project where I’m exploring Learning Design and documenting what I learn along the way.

When I started building my first learning module, I did what I’d usually do in a UX project: try to understand the problem first.

I wanted to know

What problem are we solving?
Who’s affected?
What’s happening now, and what’s the impact?
What do we want people to be doing instead?
What kind of change are we hoping for? and,
How will we know if it’s working?

In UX, we’d call this discovery or early research. In Learning Design, it’s often part of a Needs Analysis. Different labels, same idea: step back and understand the why before jumping into the what.

What I learned from this

I realised that most people want to give good feedback at work, they just don’t always know how to do it without it sounding awkward, critical, or fake.

And when it comes to receiving feedback? That’s a whole other matter. Especially if you weren’t expecting it, or if the delivery misses the mark.

So, I knew the module had to focus on:

Building confidence
Normalising the idea of feedback
Giving people simple tools they could actually remember and use

That’s where the learning objectives come in.

From user goals to learning objectives: is it the same thing?

In UX, I’m used to defining user goals and mapping them to business goals. So when it came to writing learning objectives, I wondered, is this basically the same thing?

Sort of. But I had to shift the focus slightly. In learning design, it’s less about completing a task, and more about supporting behaviour change. That means being really clear about what learners need to be able to do, not just what they need to know.

That’s where Bloom’s Taxonomy helped.

Bloom’s is a framework that sorts learning outcomes by complexity - from remembering facts to creating something new. Each level includes action verbs to make your objectives more specific and observable.

Here’s the general flow:

So here’s where I landed

By the end of this course, learners will be able to:

Identify the key traits of constructive vs. unhelpful feedback(Bloom’s: Understand/Analyse)
Use a simple framework (like SBI or COIN) to deliver clear, respectful feedback(Bloom’s: Apply)
Reflect on feedback without defensiveness(Bloom’s: Evaluate)
Ask for feedback that supports specific goals or outcomes(Bloom’s: Apply/Evaluate)

I’ll probably keep refining these objectives as the course takes shape. But starting here gave me:

A clearer direction for the course
A filter for what to include (and what not to)
A way to stay focused on behaviour change, not just information

One of the objectives I landed on was giving people a simple structure they can use to actually deliver feedback. That’s where frameworks like SBI and COIN come in - easy to remember, and genuinely helpful when you’re in the moment.

So, how might those frameworks look when using them in practice, say, in a design review?

SBI: Situation–Behaviour–Impact

Positive example:

Situation: “In this morning’s design review…”
Behaviour: “…you walked the team through your updated UI flow for the onboarding screen.”
Impact: “It really helped clarify the user journey and got the team aligned on next steps.”

Constructive example:

Situation: “During today’s design review…”
Behaviour: “…you presented the updated flow but skipped over the rationale behind the navigation changes.”
Impact: “That made it harder for the team to give focused feedback, and a few people left unsure about the direction.”

COIN: Context–Observation–Impact–Next steps

Positive example:

Context: “We’ve been working on this new feature flow for a few weeks now, and we’re heading into final review.”
Observation: “You’ve taken feedback from the last few sessions and iterated really thoughtfully on the visuals.”
Impact: “That’s helped move things forward faster and built more trust with the dev team.”
Next steps: “For the next round, it might help to bring in any open questions about interaction edge cases so we can tackle them early.”

Constructive example:

Context: “As we wrap up this sprint, we’ve had a few rounds of internal design critiques.”
Observation: “In the last two sessions, you didn’t ask for clarification when feedback was vague.”
Impact: “You might leave unclear on what to change - or miss a chance to advocate for your design thinking.”
Next steps: “Next time, feel free to ask for clarification or suggest an alternative if something doesn’t feel right.”

If you’re also coming into Learning Design from UX, this should feel familiar. We start with user needs, we define success, and we work backwards from outcomes. The difference is that you’re not just helping someone complete a task - you’re helping them change how they think or behave.

If you’re also coming into Learning Design from UX, this should feel familiar. We start with user needs, we define success, and we work backwards from outcomes.

Different space, same mindset. And a few new tools to learn along the way.

Professional development

Learning objectives

Blooms taxonomy

Turns out ‘Understand feedback’ isn’t a real learning objective

I’m currently designing my first learning module - a short course on how to give constructive feedback at work. It’s part of a self-directed project where I’m exploring Learning Design and documenting what I learn along the way.

When I started building my first learning module, I did what I’d usually do in a UX project: try to understand the problem first.

I wanted to know

What problem are we solving?
Who’s affected?
What’s happening now, and what’s the impact?
What do we want people to be doing instead?
What kind of change are we hoping for? and,
How will we know if it’s working?

In UX, we’d call this discovery or early research. In Learning Design, it’s often part of a Needs Analysis. Different labels, same idea: step back and understand the why before jumping into the what.

What I learned from this

I realised that most people want to give good feedback at work, they just don’t always know how to do it without it sounding awkward, critical, or fake.

And when it comes to receiving feedback? That’s a whole other matter. Especially if you weren’t expecting it, or if the delivery misses the mark.

So, I knew the module had to focus on:

Building confidence
Normalising the idea of feedback
Giving people simple tools they could actually remember and use

That’s where the learning objectives come in.

From user goals to learning objectives: is it the same thing?

In UX, I’m used to defining user goals and mapping them to business goals. So when it came to writing learning objectives, I wondered, is this basically the same thing?

Sort of. But I had to shift the focus slightly. In learning design, it’s less about completing a task, and more about supporting behaviour change. That means being really clear about what learners need to be able to do, not just what they need to know.

That’s where Bloom’s Taxonomy helped.

Bloom’s is a framework that sorts learning outcomes by complexity - from remembering facts to creating something new. Each level includes action verbs to make your objectives more specific and observable.

Here’s the general flow:

So here’s where I landed

By the end of this course, learners will be able to:

Identify the key traits of constructive vs. unhelpful feedback(Bloom’s: Understand/Analyse)
Use a simple framework (like SBI or COIN) to deliver clear, respectful feedback(Bloom’s: Apply)
Reflect on feedback without defensiveness(Bloom’s: Evaluate)
Ask for feedback that supports specific goals or outcomes(Bloom’s: Apply/Evaluate)

I’ll probably keep refining these objectives as the course takes shape. But starting here gave me:

A clearer direction for the course
A filter for what to include (and what not to)
A way to stay focused on behaviour change, not just information

One of the objectives I landed on was giving people a simple structure they can use to actually deliver feedback. That’s where frameworks like SBI and COIN come in - easy to remember, and genuinely helpful when you’re in the moment.

So, how might those frameworks look when using them in practice, say, in a design review?

SBI: Situation–Behaviour–Impact

Positive example:

Situation: “In this morning’s design review…”
Behaviour: “…you walked the team through your updated UI flow for the onboarding screen.”
Impact: “It really helped clarify the user journey and got the team aligned on next steps.”

Constructive example:

Situation: “During today’s design review…”
Behaviour: “…you presented the updated flow but skipped over the rationale behind the navigation changes.”
Impact: “That made it harder for the team to give focused feedback, and a few people left unsure about the direction.”

COIN: Context–Observation–Impact–Next steps

Positive example:

Context: “We’ve been working on this new feature flow for a few weeks now, and we’re heading into final review.”
Observation: “You’ve taken feedback from the last few sessions and iterated really thoughtfully on the visuals.”
Impact: “That’s helped move things forward faster and built more trust with the dev team.”
Next steps: “For the next round, it might help to bring in any open questions about interaction edge cases so we can tackle them early.”

Constructive example:

Context: “As we wrap up this sprint, we’ve had a few rounds of internal design critiques.”
Observation: “In the last two sessions, you didn’t ask for clarification when feedback was vague.”
Impact: “You might leave unclear on what to change - or miss a chance to advocate for your design thinking.”
Next steps: “Next time, feel free to ask for clarification or suggest an alternative if something doesn’t feel right.”

If you’re also coming into Learning Design from UX, this should feel familiar. We start with user needs, we define success, and we work backwards from outcomes. The difference is that you’re not just helping someone complete a task - you’re helping them change how they think or behave.

If you’re also coming into Learning Design from UX, this should feel familiar. We start with user needs, we define success, and we work backwards from outcomes.

Different space, same mindset. And a few new tools to learn along the way.

Professional development

Learning by doing

Blooms taxonomy

Turns out ‘Understand feedback’ isn’t a real learning objective

I’m currently designing my first learning module - a short course on how to give constructive feedback at work. It’s part of a self-directed project where I’m exploring Learning Design and documenting what I learn along the way.

When I started building my first learning module, I did what I’d usually do in a UX project: try to understand the problem first.

I wanted to know

What problem are we solving?
Who’s affected?
What’s happening now, and what’s the impact?
What do we want people to be doing instead?
What kind of change are we hoping for? and,
How will we know if it’s working?

In UX, we’d call this discovery or early research. In Learning Design, it’s often part of a Needs Analysis. Different labels, same idea: step back and understand the why before jumping into the what.

What I learned from this

I realised that most people want to give good feedback at work, they just don’t always know how to do it without it sounding awkward, critical, or fake.

And when it comes to receiving feedback? That’s a whole other matter. Especially if you weren’t expecting it, or if the delivery misses the mark.

So, I knew the module had to focus on:

Building confidence
Normalising the idea of feedback
Giving people simple tools they could actually remember and use

That’s where the learning objectives come in.

From user goals to learning objectives: is it the same thing?

In UX, I’m used to defining user goals and mapping them to business goals. So when it came to writing learning objectives, I wondered, is this basically the same thing?

Sort of. But I had to shift the focus slightly. In learning design, it’s less about completing a task, and more about supporting behaviour change. That means being really clear about what learners need to be able to do, not just what they need to know.

That’s where Bloom’s Taxonomy helped.

Bloom’s is a framework that sorts learning outcomes by complexity - from remembering facts to creating something new. Each level includes action verbs to make your objectives more specific and observable.

Here’s the general flow:

So here’s where I landed

By the end of this course, learners will be able to:

Identify the key traits of constructive vs. unhelpful feedback(Bloom’s: Understand/Analyse)
Use a simple framework (like SBI or COIN) to deliver clear, respectful feedback(Bloom’s: Apply)
Reflect on feedback without defensiveness(Bloom’s: Evaluate)
Ask for feedback that supports specific goals or outcomes(Bloom’s: Apply/Evaluate)

I’ll probably keep refining these objectives as the course takes shape. But starting here gave me:

A clearer direction for the course
A filter for what to include (and what not to)
A way to stay focused on behaviour change, not just information

One of the objectives I landed on was giving people a simple structure they can use to actually deliver feedback. That’s where frameworks like SBI and COIN come in - easy to remember, and genuinely helpful when you’re in the moment.

So, how might those frameworks look when using them in practice, say, in a design review?

SBI: Situation–Behaviour–Impact

Positive example:

Situation: “In this morning’s design review…”
Behaviour: “…you walked the team through your updated UI flow for the onboarding screen.”
Impact: “It really helped clarify the user journey and got the team aligned on next steps.”

Constructive example:

Situation: “During today’s design review…”
Behaviour: “…you presented the updated flow but skipped over the rationale behind the navigation changes.”
Impact: “That made it harder for the team to give focused feedback, and a few people left unsure about the direction.”

COIN: Context–Observation–Impact–Next steps

Positive example:

Context: “We’ve been working on this new feature flow for a few weeks now, and we’re heading into final review.”
Observation: “You’ve taken feedback from the last few sessions and iterated really thoughtfully on the visuals.”
Impact: “That’s helped move things forward faster and built more trust with the dev team.”
Next steps: “For the next round, it might help to bring in any open questions about interaction edge cases so we can tackle them early.”

Constructive example:

Context: “As we wrap up this sprint, we’ve had a few rounds of internal design critiques.”
Observation: “In the last two sessions, you didn’t ask for clarification when feedback was vague.”
Impact: “You might leave unclear on what to change - or miss a chance to advocate for your design thinking.”
Next steps: “Next time, feel free to ask for clarification or suggest an alternative if something doesn’t feel right.”

If you’re also coming into Learning Design from UX, this should feel familiar. We start with user needs, we define success, and we work backwards from outcomes. The difference is that you’re not just helping someone complete a task - you’re helping them change how they think or behave.

If you’re also coming into Learning Design from UX, this should feel familiar. We start with user needs, we define success, and we work backwards from outcomes.

Different space, same mindset. And a few new tools to learn along the way.

Professional development

Learning objectives

Blooms taxonomy