Hello there.

My name is Mrs. Dhami.

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

Now, the big question for today is, how do we write a fantastic design specification that we can use throughout our iterative journey so that we can make effective design decisions, which consequently means that we design a fantastic and successful design solution.

So hard hats on.

Let's get cracking.

Our outcome for today is we will be able to collate design requirements to form a specification and make design decisions.

Our keywords today are specification, design requirements, design decisions, and iterative.

A specification is a collection of design requirements.

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

Design decisions are a deliberate choice to meet a requirement or solve a problem, and iterative is the refining and improving.

So we are in the iterative journey, a journey where we constantly refine and improve.

So to create a fantastic product or solution outcome, we have two learning cycles today.

First of all, we're gonna define a specification and then we are going to go on to make effective design decisions which come from the specification.

So let's start with defining a specification.

The big picture for our iterative journey today is we are going to collate your design requirements from your research to form a specification.

We're then going to go on to justify your design requirements if you've not already done so.

And then we're going to explore how your design requirements could be measured throughout your iterative design journey.

So let's remind ourselves.

A specification is a collection of design requirements, and then design requirements are something which is needed or wanted to make a product successful.

Research is a key element throughout the iterative design journey, and you've probably done a fair bit of that already.

Now, you may have defined many of your design requirements throughout your initial research, or you may need to revisit the research you have carried out.

You may also develop further design requirements throughout your iterative journey, as you may need to do further research as we go through too.

A specification is a collection of, A, design opportunities, B, design decisions, or C design requirements.

Have a think.

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

Fantastic if you've got C.

A specification is a collection of design requirements, and design requirements are something which is needed or wanted to make a product successful.

Andeep said, "I found out that my 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." So my question to you is, how could Andeep's research be turned into design requirements? Have a little think.

Come back to me when you've got an answer, and we will explore that together on the next slide.

Hopefully you've thought of a few design requirements.

Now, if we take Andeep's research and we highlight the words arthritis and struggles, we could easily turn that into a design requirement and say the product must help people suffering with movement restrictions to open common sized jars easily and efficiently.

Next word we could highlight could be wet.

The product could include grip, so it is easier to use with wet hands.

And then lastly, she often drops things.

Let's turn that into a design requirement.

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

Now take note.

Notice how each one of those three design requirements provides a justification but does not describe a specific solution.

Therefore, it doesn't tell me exactly what the product should look like, what it should do, and how it should be packaged.

Instead, it keeps away from a specific solution.

This is great as it avoids design fixation, which means, when you get onto the design stage, you'll still be able to produce lots and lots of varied design ideas.

Successful design requirements develop from your own research.

They are justified, so they provide a why.

They are specific, but without describing a specific solution.

That therefore avoids design fixation.

And also, they can be measured.

And I'll go into a bit more detail about the measuring in our next learning cycle.

As we said at the start, a specification is a collection of design requirements.

Lucas chose to present his specification as a charter of design requirements and chose his own headings relevant to his design brief.

Now, you can display them in a chart, but you don't have to.

It's up to you.

Laura chose to also display her design requirements in a chart, but she decided to add a column with justification.

Let's take a little look.

She says it must hold food for a packed lunch hygienically.

The justification being adequate sealing prevents leaks and spills.

She then says the design requirement is the materials need to be sustainable and easy to clean, and her justification is to prevent illness from mould or bacteria.

And her last design requirement in this section is the product must be between 200 millimetres and 300 millimetres.

And her justification, again, is so that it can fit inside a backpack.

Think about each of the design requirements you have made, or discovered, or written, or are about to write, and think about how you can justify them.

The justification should be able to come from your research.

Aisha says, "This is going to take me ages to write all these design requirements." Is her statement true or is it false? Have a think.

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

Well done if you got false, and why is that? Design requirements come from your research and you already have a lot of research, so you already have the basis, And perhaps you might have already discovered them as you went through, and you might have recorded some of them, so you might already be halfway there.

All specifications will be presented differently, according to your individual design brief.

If you choose to present your specification as a chart, you may want to consider which headings are relevant for you.

So for example, you could have priority of design requirements, where the design requirements have developed from.

For example, which bit of research did they come from? Their applicability to primary users or stakeholders, date of when you define them, because they'll happen throughout the whole design process.

A justification and a method of measuring.

Sophia says, "I collated my design requirements and realised that I really need relevant anthropometric and ergonomic research." Now, as you define your specification, you may identify areas for further research, and that's okay.

Further research can be carried out throughout any stage of the iterative design journey.

Subheadings could be used to check relevant areas have been considered in the specification.

You may recognise some of these subheadings from your design and technology education throughout the past few years.

So we have got environment, cost, aesthetics, manufacture, ergonomics, lifecycle, safety, user materials, function, form, and size.

You may want to pause the video, have a good read of these and think back.

Have you considered all of these relevant areas when you are writing your design requirements for your specification? And if you haven't, you've still got time to do that extra research and include them in if they are relevant for your design brief.

Onto task A.

Number one, collate your design requirements from your research into your specification.

Part two, identify any missing design requirements and conduct any further relevant research to inform these.

Part three, justify each of your design requirements if you haven't done so already from your research.

Number four, prioritise your design requirements.

Which ones are the most important? And lastly, present your specification however you wish.

Good luck.

Your answers could include, number one, collate your design requirements from your research into your specification.

Remember to look through all of your research so you don't miss anything out.

Number two, identify any missing design requirements and conduct any further relevant research to inform these.

Research can be carried out at any stage of your iterative journey.

Number three, remember to justify each of your design requirements from your research if you haven't done so already.

Why is each one of these relevant to the success of your design solution? Number four, prioritise your design requirements.

What are the most important design requirements which you must, must meet to be successful? They're the ones that you're gonna need to look at first.

And number five, present your specification, but please remember everyone's specification will look different, and that's okay.

Well done, folks.

Onto learning cycle two.

We are now going to use your specification to make effective design decisions.

The iterative design journey is a process of refining and improving ideas.

Throughout your iterative journey, you will need to return to your specification to check how your ideas are meeting your design requirements and identify what design decisions you need to make to ensure your solution is successful.

A design decision is a deliberate choice to meet a requirement or solve a problem.

We are going to explore a few techniques for measuring your design requirements in your specification.

You are not limited to the techniques we are about to share, and some will be right for measuring your design requirements, and others will not, and that's okay.

You may identify a design decision at any point when measuring.

Remember to record the design decision so that you don't forget it and show how you solve that design decision in your iterative journey.

Good luck.

Time for a quick check in.

Which statements are correct about design decisions? A, they can only be made by the primary user.

B, they can be made throughout the iterative design journey.

C, collated, they make a specification.

D, they help to make a more successful design solution.

Have a think.

Pause the video.

Come back to me when you are ready.

Well done if you got B and D.

design decisions can be made throughout any stage of the iterative design journey, and they also help to make a more successful design solution.

A great way to measure some of your ideas against your design requirements is to get feedback.

So you could get primary user, stakeholder, or expert feedback, which gives us their opinions.

This is a good idea for identifying inclusivity and accessibility considerations, and moral and social considerations.

When you get this feedback, it is likely to make you make design decisions.

And as you can see that I've put at the bottom left, I've put record any design decisions when measuring so that it helps you to make successful decisions, to take your ideas forward and create a more successful solution.

At certain stages of your iterative design journey, you are likely to produce some prototypes.

So a great way to measure your prototypes against your design requirements is to test them.

So it's a great idea for trying out ideas, or solutions, or products, getting primary user, stakeholder, and expert opinions, and identifying ergonomic considerations.

And you can see on the right here is me testing out a few different ergonomic handles that have been designed by some of my students out of modelling clay.

And again, you've got it.

Record any design decisions when you are measuring.

You are going to be making those decisions.

Is it ergonomic? Is it easy to hold? Does it feel comfortable in the grip? Record those design decisions so that they go into your iterative journey.

True or false? I write my specification after research and then refer back to it once the product has been made.

True or false? Have a think.

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

Well done if you got false.

And why is that? Well, design requirements collated into your specification should be used throughout the iterative journey and not just at the end, so to test concepts and make effective design decisions to creatively develop the product into a successful design.

They are your criteria.

They are your requirements.

It's what is needed or wanted to make a successful product, so use them as your benchmark.

Some of your design requirements may need you to actually provide some measurements.

So, for example, you might need to test if a solution fits into a particular space or a particular area, or is of a particular weight.

It avoids guesswork and provides you with objective data.

Now, this is really good for making design decisions because you might say, actually, the solution needs to be a lot smaller to fit into a specified space, or it might need to be made more lightweight so it's easy to carry around.

Make sure that you record these design decisions when you make them so that you work out your design to fulfil your design requirement, making it ultimately a more successful product.

Sometimes a visual inspection is what is needed to start with when measuring against a design requirement.

So Lucas does a quick visual check of his cardboard prototypes.

It provides him with instant feedback and enables him to identify early flaws.

This means that Lucas can quickly make some design decisions easily and straightforward.

So remember, please record those design decisions when you are doing a visual inspection.

You may need to do some safety tests on your ideas.

Now, this is a really good idea for ensuring the product or solution does not pose any threats, and that it is compliant with any regulations.

As you do this, find the ones that are relevant to you, and of course it's going to make you make design decisions.

Remember to record these.

Laura returns to her specification, which she collated in learning cycle one.

But what you can see is she has added a final column called method of measuring.

So she has added the test she will conduct to her specification.

I won't read the whole thing out again.

Feel free to pause it.

But for the first design requirement, for function, her method of measuring is to test the product in use.

For her second design requirement materials, she is going to gather primary user feedback as her method of measuring.

And lastly, for her design requirement of size, she is actually going to measure the product, measure the prototypes.

Well done, Laura.

Hopefully, the techniques we have just shared have inspired you to think about how you could test and measure your design requirements.

Onto task B.

Number one, define iterative design.

Two, identify how each of your design requirements could be measured.

Number three, define design decision.

Good luck.

Have a go.

Come back to me when you've got some answers.

Your answers could include, for part one, iterative design is the process of refining and improving so to develop a successful product.

Two, identify how each of your design requirements could be measured.

So for example, you could gain feedback from your primary user by asking them to hold and test the comfort of a prototype.

And lastly, a design decision is a deliberate choice to meet a design requirement or solve a problem.

These are made throughout the iterative design journey to develop a successful product.

Well done for all of your hard work.

This brings us to the end of our lesson.

Let's summarise what we have found out.

A specification is a collection of design requirements.

Design requirements are something which is needed or wanted to make a product Successful.

Successful design requirements develop from your research, are justified and provide a why, are specific, but remember, do not describe a specific solution, so therefore avoid design fixation, and they can be measured in a variety of ways.

Throughout your iterative journey, you will need to return to your specification to check how your ideas are meeting your design requirements, and identify what design decisions you need to make to ensure your solution is successful.

Well done with all of your hard work today and good luck with your iterative design journey.

Take good care.

Bye, bye, bye.