Hello there, my name is Mrs. Darmie.

Thank you for joining me for your design and technology lesson today.

Now, the big question for today is what do our primary user and stakeholders need and want from a design solution? We are going to share lots and lots of different research strategies today, and you are going to be able to pick which ones might be right for your design brief or design opportunity.

So seat belts on, let's get cracking.

Our outcome for today is we will be able to select the appropriate strategy to gather data from users regarding their needs and wants.

Our keywords for today are primary user, stakeholder, needs, wants, and design requirements.

Now we'll go through most of these as we work our way through the slides, but let's quickly recap on primary user and stakeholder.

Primary users are the main person that you are designing for, whereas stakeholders are a person, group, or organisation with an interest in a project.

Feel free to come back to this slide at any point during today's lesson.

We have two learning cycles today.

Firstly, we are going to define primary user and stakeholder groups, and then we are going to investigate user needs and wants.

So let's get started with defining.

The big picture for your iterative journey today is, first of all, we're going to explore your primary users and stakeholders in more detail.

Then we're going to identify their needs and wants to shape potential design requirements.

There's a lot of words in those two sentences.

Let's take a little look in a bit more detail.

So needs are the essential requirements of the person, whereas wants are something desired but not essential for the product or solution to work.

Now, identifying and researching needs and wants enables us as designers to compile design requirements.

These are to evaluate your ideas against and consequently make successful design decisions in your iterative journey.

And I'm going to be showing you how to formulate those later on.

Quick check-in.

I would like you to match the definition to the keyword.

So our keywords are wants, design requirements, and needs.

So A, first definition is something desired but not essential.

B, the essential requirements of the person.

And C, something which is needed or wanted to make a product successful.

Have a think, come back to me when you've managed to match them up.

So let's take a look at our answers.

A, something desired but not essential is someone's wants.

B, the essential requirements of the person are their needs.

And design requirements are something which is needed or wanted to make a product successful.

Well done if you got those right.

You have already identified your primary user and some stakeholders in your design brief.

Your design brief provides the focus for moving forward in your iterative journey.

And you can refer back to this at any point, and we encourage you to do that.

Lucas says, "Who else could I consider researching?" Great question, Lucas, have a little think.

Come back to me when you've got an idea.

Hopefully you've thought of a few different groups.

Let's recap some of those groups.

So primary users, that is who you are designing for and who directly interacts with a product, service or experience.

Stakeholders are a person, group, or organisation with an interest in a project.

We have clients, a person, group, or organisation that seeks expertise or solutions, for example, a brand.

We have target market, a specific group of consumers identified as the most likely audience for a product, service or experience.

And then we have customers, the individual who purchases or pays for the product, service or experience.

Though they may not necessarily be the end primary user.

Think of a toy.

Quite often the primary user is a young child, but the customer is more likely to be a parent or carer.

Now take note, all of the one, two, three, four, all of the bottom four are examples of stakeholders.

Stakeholders covers all of those things.

So all of clients, target market and customer.

Jun says, "My design brief identifies that my primary user suffers from eczema.

I know nothing! Who could be my potential stakeholders?" Now, you might be in a similar position to Jun.

You might not know too much about the design opportunity that you have identified in your design brief, but that is fine.

You're going to do loads and loads of research.

So who could be Jun's potential stakeholders? Have a little think.

Come back to me when you've got an answer.

So Aisha says you could Jun, talk to a range of people who suffer with eczema.

You could find chats on social media groups, search forums, contact experts such as health professionals.

So for example, you could pop into a chemist.

You could research expert facts and figures in books, newspapers and journals.

What a huge variety there.

What I'd like you to do is just take a minute to think, who do you need to talk to for your design brief? Come back to me when you've had a think.

As you research the needs and wants of your primary user and stakeholder groups, identify and record potential design requirements.

Now, I ask you to do this because you are going to collate these design requirements into your specification further along the line.

So what is a design requirement? A design requirement is a statement that identifies what a product or solution can do to be successful and meet the needs and wants of the primary user or stakeholders.

Include a justification when stating your design requirements.

Andeep found out that his 70-year-old primary user suffers with arthritis and struggles to open jars by herself, especially when her hands are wet in the kitchen.

She often drops things.

How could Andeep turn this research into design requirements? Sam says, "State and justify your design requirements, but don't describe a specific solution.

This avoids design fixation!" This is a great tip, Sam.

So let's put this into practise and write some actual design requirements.

So let's take Andeep's research and turn it into design requirements.

First of all, I've highlighted the word arthritis and struggles.

Turning this into a design requirement reads as, the product must help people suffering with movement restrictions to open common sized jars easily and efficiently.

Notice how I haven't used the word arthritis in the design requirement, but opened it up to any people with movement restrictions.

Next one, the product could include grip so it is easier to use with wet hands.

This is an idea, this is a suggestion, and it's backed up with justification because in his research he says, when her hands are wet in the kitchen.

Next requirement comes from the last sentence, she often drops things.

So the product should be able to withstand being dropped on the floor multiple times as my primary user frequently drops things.

There again is that justification.

Notice too, how the design requirements do not describe a specific solution.

I'm not saying what the product should look like, what it should be.

I'm keeping it open.

So this avoids design fixation.

Alex says, "I already know what my primary user would like, no need to research!" So my question to you is, why is it important to research the needs and wants of your primary user and stakeholders? Is it A, to make the process longer? B, you may discover something you did not know before.

C, to design a product based only on your personal preferences, or D, to use the findings to create design requirements.

Have a think.

Come back to me when you have got an answer.

Okay, well done if you got B and D.

It's important to research the needs and wants of your primary user and stakeholders because you may discover something you did not know before.

And then of course you are going to use those findings to create design requirements.

Onto task A.

Number one, define primary user.

Two, define stakeholder.

Number three, identify the difference between a need and a want.

Number four, what is a design requirement? And lastly, identify your potential primary user, stakeholders, clients, target market and customer from your design brief.

Good luck, come back to me when you've got some answers.

Answers could include.

Number one, a primary user is the main person that you are designing for.

Number two, a stakeholder is a person, group, or organisation with an interest in a project.

Number three, a need is an essential requirement of the person, whereas a want is something desired but not essential.

And number four, a design requirement is something which is needed or wanted to make a product successful.

It should not describe a specific solution so to avoid design fixation.

Part five, I asked you to identify your primary user and stakeholder groups for your design brief.

So let's take an example context, an outdoor music festival.

Primary user could be a 21-year-old student who is a fan of live music and camping.

Stakeholder could be the local government who own the park or land that the festival will take place on.

Client could be a brand who will sponsor the festival like a drinks or mobile phone company or brand.

Target market could be a group of young adults aged 18 to 35 with a collective interest in live music and cultural events.

And the customer could be the parents of a 16-year-old boy or girl who have bought the ticket for their son or daughter to attend the festival.

Now obviously yours won't look exactly like this.

You will have to apply it to your design brief.

Well done with all of your hard work on this.

Now that we have had chance to define our primary user and stakeholder groups, it's now our chance to investigate their needs and wants.

So let's get cracking.

We are going to explore a few strategies for researching your primary user and stakeholder needs and wants.

Now, please remember, you are not limited to the strategies we share.

There are far more strategies that you could use too.

Some will be right for your context and others will not.

You may wish to revisit your design brief to adapt or to keep you focused.

Please take lots of photos and videos and record the information you collect.

And remember, you are very likely to come across potential design requirements.

Please identify these design requirements at any point, but remember to record it or them.

Remember, design requirements are what does your design need to do to be successful? You could record these as statements or you could record in a chart, that's entirely up to you.

Good luck.

A great idea is to use interviews of your primary user or stakeholders.

This is great for identifying their opinions.

It's also good for identifying inclusivity and accessibility considerations and moral and social considerations.

Take a look at Lucas's work on the right.

He interviewed his gran and his family friend.

Now he presented his interview with pictures, but also with all the results from his interview, all the answers, and then his own evaluation.

And this is really key.

Now do what Lucas also did though, and he remembered to record his design requirements that came from this interview.

Don't forget to do the same if you choose to do an interview.

Observations are a great way to observe an unfamiliar process or activity.

It often highlights problems which you might not have thought of before.

And it's great to watch the interactions of primary users and stakeholders.

And here's two lovely examples for you.

Top one is of a post box being emptied and how it looks inside.

I bet not many of you have seen the inside of a post box.

Secondly, here is a young child opening and closing a variety of different water bottles.

It's really interesting to see how she interacts with each one and the difficulties perhaps that you can see she faces With that last one, she needs quite a lot of strength to open up that purple bottle.

Remember, if you do an observation, record any potential design requirements that you might identify.

Clearly, with the water bottle, the design requirement would be, that it is easy to open and close by a young child.

It's really easy to draw out some of these conclusions from observations.

Other interactions with primary users and stakeholders include emails, texts, video calls, and letter writing.

Now Laura says, "How do I record these examples into my NEA?" A great question, Laura.

Well, screenshots of text messages and screenshots of the highlights of videos can easily be put into your NEA, but also videos and gifs can also be included into your NEA.

But please do ask your teacher about how to add these successfully into yours.

Now remember, just like before, you will come across different potential design requirements.

Please do record these so that you don't forget them later.

It's a great idea to record relevant anthropometric data and then ergonomic considerations.

So you might identify certain pieces of anthropometric data which are suitable for your design brief.

That could be examples such as hand span, head circumference, and grip strength.

Then it's also really good to watch and observe your primary user using a product so that you can identify the ergonomic difficulties that they might find.

So if you take the three pictures beneath from Lucas, this is a bit of a zoom in at his gran who is trying to open three different bottles in three different ways.

And he was observing the difficulties that she found with each one of those and writing down the results.

Now, just like before, you know it well now, please record any potential design requirements that come from this research.

Quick check then.

Watching a child open a range of bottles is an example of A, interview, B, observation, C, ergonomic interaction, D, anthropometrics.

Have a little think.

Come back to me when you've got an answer.

Well done if you managed to get B and C.

Watching a child open a range of bottles is an example, not only of observation, but also ergonomic interaction.

How do they interact with it ergonomically? Depending on your design brief, you might need to take a few other measurements.

Now let's give a few examples here that could perhaps be the measurements of a pet.

Perhaps like the image, you need the height of a pet for maybe a pet going underneath something.

You might also need to find the size of certain identified objects such as the book here or the size of a certain space, like the space underneath this church pew.

This is a really good idea for recording required relevant data that is suitable and relevant to you.

Now, don't forget, I think this is starting to sink in now.

Don't forget to record any potential design requirements that your solution must do to be successful.

Second, resources are a really great way to find out more information about your primary user and stakeholder too.

You could try news articles, forums, social media groups.

It's a really good idea for highlighting current trends and user opinions and also facts and figures.

Jacob has a really good tip.

He says, "Remember to include any web links to facts or articles as proof of your research!" And you've got it, record any design requirements.

What have you found out? What have your researched that your design needs to do to be successful? Sofia says, "My primary user takes her dog to many music festivals.

She struggles to find shade for her dog and he often overheats." Which design requirements could come from Sofia's research? A, must be water resistant.

B, must be camouflage.

C, must be lightweight and compact.

D, must use UV resistant materials.

Have a think.

Come back to me when you've got an answer.

Well done if you got C and D.

From Sofia's research, it must be lightweight and compact and must use UV resistant materials.

Well done if you got that right.

Onto task B.

Now, I want you to do everything based on your design brief.

So number one, create a list of ideas that you would like to research about your primary user or stakeholders needs and wants.

What do you want to find out? Part two, formulate a plan to research each point from your list.

Consider the ideas we have explored together, all those different strategies.

Which ones would be suitable for your iterative journey? Prioritise your plan.

What do you need to do first? And then lastly, it is your chance to conduct your research, record your findings, and don't forget, record those potential design requirements.

Design requirements being what does your design need to do to be successful? Good luck, I'll see you back soon.

Your answers will all look different depending on what your design brief is.

So hopefully for part one, you produced a list of ideas that will be useful to research your primary user and stakeholder needs and wants.

For example, how your primary user interacts with a particular product.

Then hopefully you formulated a plan to research each point from your list.

I asked you to consider the ideas we have explored together.

Which ones would be suitable for your iterative journey.

For example, would a video call or observations be suitable? And then obviously prioritising your plan.

Out of everything that you want to find out, what do you need to do first? And lastly, hopefully you have conducted your research.

Hopefully you've also remembered to record your findings and the potential design requirements.

Remember that requirements are statements that identify what a project can do to be successful and meet the needs and wants of your primary user and stakeholders.

State and justify your design requirements without describing a specific solution.

This avoids design fixation.

For example, my product must include grip so that it does not slip with wet hands.

And just remember, everybody's research will look very different.

Yours will not look like the person sat next to you, and that is okay.

That is exactly what we want.

Well done.

That draws our lesson to a close.

Well done with all your hard work today.

Let's summarise what we have found out.

A primary user is the main person that you are designing for.

A stakeholder is a person, group, or organisation with an interest in a project.

A need is an essential requirement of the person, whereas a want is something desired but not essential.

Observations, interviews, gathering anthropometric data and researching forums and news articles are some of the ways to explore needs and wants.

A design requirement is something which is needed or wanted to make a product successful.

Remember to record these when you discover one.

Well done.

I hope to see you at another lesson soon.

Take good care, bye bye bye.