GLOBAL KNOWLEDGE ARK

Engineering & Technology · Engineering Design Methods & Trade-offs

User research, needs and measurable design requirements

A shared repair room needs a carrier for returning small hand tools to storage. Someone requests a lightweight box with a lid. Another person wants a tray without a lid. Before choosing either, watch what people actually carry, where they put it down, and what makes the return difficult.

Use the opening design, measurement, sketching and everyday-materials ideas as support. This chapter introduces its own comparison tools and explains the simple weighted sums and cost equations when needed. All users, observations, test results, prices, dimensions and energy values are constructed teaching cases. None is a product specification, legal compliance assessment, real study or population capability limit.

Back to the chapter

After reading, you can

Turn observations of a task into justified requirements with explicit checks.

01

Ask about the task before asking for a favourite product

User research gathers evidence about people, activities and circumstances. For the carrier, observe a complete return: selecting tools, moving them, passing through the doorway, setting them down and finding the correct storage positions. Ask people to explain a recent difficult return. A neutral question such as “What happened when you reached the door?” leaves more room for discovery than “Would a lid solve that problem?”

Interview accounts reveal experiences and reasons; observation shows what happens in the observed setting. Neither is a complete picture alone. A person may forget an uncommon difficulty, and a quiet demonstration may miss crowding at the end of a session. Compare evidence across users and conditions, including people who stop using the existing arrangement.

02

Keep the evidence and its interpretation distinct

Recruit for relevant differences: carrying technique, hand use, reach, vision, familiarity with the room, and responsibility for cleaning or repair. One convenient group of confident volunteers does not represent everyone. Explain the activity and obtain informed agreement before observing or recording people. Retain only information needed for the research question, with an appropriate plan for access and retention.

Suppose an imagined observation notes that a person sets the carrier on the floor before opening a door. “The handle is uncomfortable” is one possible explanation, not the observation itself. Ask what led to the action. The person may need a free hand for the door, lack a suitable shelf, or prefer to avoid spilling. Record competing explanations until evidence distinguishes them.

03

Connect a need to a checkable condition

A requirement states something the proposed solution must do or satisfy. Give it an identifier, a reason and a verification method. In this teaching project, R1 might require containing the agreed tool set through a defined carrying-and-set-down trial without a tool escaping. The set, motion sequence, payload, surface and observation method belong in the test definition. “Secure” by itself supplies none of them.

A numerical target needs justification. It may come from an observed task, an interface dimension, a budget or an applicable rule. Do not invent a threshold merely because a form needs a number. Where evidence is missing, record a provisional assumption and assign a check. A requirement that conflicts with another requirement or cannot be verified needs revision.

The figure connects one observation to two possible responses and a requirement. This trace prevents the team from treating the first suggested object as the only solution. It also lets a later reviewer ask whether the requirement still serves the original need.

One observation can lead to different design responsesAn observation branches into two possible interpretations and responses, while the requirement retains a task outcome rather than specifying either response.Observation: carrier is set down at the doorInvestigate carrying interactionInvestigate doorway interactionRequirement: complete the defined return with tools retained
Observed: carrier set down at door. Possible response A: change carrier grip. Possible response B: provide a shelf or change door interaction. Requirement: complete defined return task while retaining tools. Competing explanations still need evidence.

Make “easy to carry” testable

For this constructed project, the intended payload is eight tools of 0.25 kg each, giving 8 × 0.25 = 2.0 kg. A provisional complete-carrier mass limit is 3.0 kg. Subtracting the payload leaves a 1.0 kg allowance for the empty carrier. This is a project assumption to examine with users, not a universal safe carrying limit.

Give the empty-mass limit its own check by measurement, and assess carrying separately through a representative task trial. Passing the 1.0 kg allowance cannot prove acceptable grip, balance or doorway use. A requirement set must retain those different questions instead of hiding them inside one mass number.

Try the reasoning

  1. Why ask about a recent return rather than ask whether people want a lid?

    Show the answer and reasoning

    A recent task can reveal several causes and constraints. Asking about a lid steers the discussion toward one proposed solution.

  2. Is an observed pause proof of discomfort?

    Show the answer and reasoning

    No. It is evidence of a pause. Ask and examine context before deciding which explanation it supports.

  3. Does a carrier mass below 3.0 kg establish that every user can carry it comfortably?

    Show the answer and reasoning

    No. That constructed project limit does not establish individual capability, grip quality, balance, duration or accessibility.

What to carry forward

Trace requirements to a real task and state how each will be checked. Keep unsupported thresholds visible as assumptions.

References

Teaching resources and research supporting this lesson’s explanations and examples.

  1. GOV.UK User research community2 sources
    1. User research for government services: an introductionGOV.UK User research communityReference guidegov.ukRead source
    2. Getting informed consent for user researchGOV.UK User research communityReference guidegov.ukRead source
  2. NASA2 sources
    1. Systems Engineering Handbook — 4.1 Stakeholder Expectations DefinitionNASAReference guidenasa.govRead source
    2. Systems Engineering Handbook — 4.2 Technical Requirements DefinitionNASAReference guidenasa.govRead source