To design for humans means aligning your design with the actual HF capabilities of those users. Designers must determine the capabilities of users before they design an intervention for them.
Every product puts demands on its users' vision, hearing, strength, etc. If those demands exceed the users' capabilities, then those users will not be able to use the product, or will not use it well, or will not enjoy using it, or may be injured or even killed by it.
In principle, the wider the range of HFs for a particular design, the more potential users there are for the resulting product; however, this typically results in more complex products, which in turn increases costs and decreases durability and reliability. On the other hand, a very small range of HFs can allow the design of cost effective, efficient, and reliable products; however, this reduces the range of users who can use the product by typically excluding and marginalizing those users who are “far from average”.
One must therefore seek to balance the ranges of HFs so as to maximize the range of potential users while also making a product that is reasonably reliable, cost-effective, and efficient.
It doesn't matter if you create a truly “universal” design if it costs so much that only a handful of people can afford it. Nonetheless, there is a growing expectation - even with corporations - that designing for the broadest possible range of user (i.e., diversity) is essential for both corporate social responsibility and financial success; for instance, consider this case and this case. The challenge of design is to find that balance between all factors - both technical and human - to create the best possible product for a given situation.
Thus, one must study human capability to set appropriate ranges of design HFs, to in turn design a usable product.
Furthermore, not all possible HFs are relevant in a specific project. Thus, one must prioritize those HFs that are most relevant to the scope of a given design brief.
Example 1: Night vision devices are predicated on users having some minimal amount of vision; users who are completely blind are excluded by definition from this class of product. Sometimes, this kind of exclusion is unavoidable, but the rationale for such exclusions should be clear, well-documented, and not founded on biases or discriminatory principles.
Example 2: Both surgical clamps and locking pliers provide the same basic function, but you wouldn't want your surgeon operating on you with pliers. The difference is the scope and context in which the required function is to be implemented and the capabilities of the users in each case.
We refer to the overall scope of all HF ranges as the human factors envelope for a product.
A HF capability is the natural limit of a user's vision, hearing, or any other HF, beyond which the user cannot use a product.
If a product requires a user to lift a 20 kg weight from ground level, but the user cannot lift more than 15 kg from ground level, then the product's demand (20 kg lifting) has exceeded the user's capability (15 kg lifting).
To design a good intervention, designers must first consider the capabilities of their target users for all relevant HFs, then use those capabilities to guide development of the engineering requirements which in turn define the scope of performance of all suitable interventions.
Since no two people are exactly alike, working with HF capabilities is a statistical task. Designers consider a population of users and the statistical distribution of capability across that population. The goal then becomes determining a level of capability that will statistically inconvenience or harm the fewest possible members of a population.
In design contexts, we usually describe a HF capability with two values (which are equivalent but different ways of stating the capability): an actual measure of the capability, and a percentage of the population excluded at that measure of capability.
It may be that you cannot easily find both the actual measure and the population percentage. In such cases, providing one or the other is sufficient.
For instance, consider vision. Using the University of Cambridge's Exclusion Calculator, we can estimate the number of people in their 50s who will be excluded if you expect your users to read labels and text on your product that is comparable to regular-sized newspaper text.
In Canada, that amounts to almost 100,000 Canadians who will not be able to use the product.
Do you really want that?
Consider how one might use the blender in Figure 1.
Did you remember to consider situations where a user would have to walk a short distance while holding the blender's container, and stand while dispensing its content?
How many people do you think this simple and entirely reasonable expectation might exclude from a general population? Think about that before viewing some possible results below.
Begin by reviewing the various reference products you identified in your situation scan. Imagine watching a movie of various individuals using each reference product in your SUC. For each step of usage that you “see” in that movie, identify possible mismatches between the reference product and that user.
The goal of the analysis is to identify the worst case HF demand for each HF among the reference products. Your team may determine that reference product X has the worst case HF demand for vision, product Y has the worst case HF demand for strength, product Z has the worst case HF demand for hearing, etc.
You should therefore collaboratively decide as a team how HFs will be distributed among the members. Each team member will be in charge of at least one HF, and will review all the reference products to find the worst case HF demand for their HF(s) with respect to the SUC for which they are responsible.
To perform your analyses, use the tools provided for assessing human factor demands and capabilities.
If you cannot find specific sources for the specific HFs you have identified, you can use the following generic scale. This scale is meant to identify the percentage of your targeted user population that you exclude from being able to use a design. The scale is based on a normal distribution, which is a reasonable “best-guess” for many sufficiently large populations.
The five acceptable levels for this scale are:
It's important to remember, however, that there may be excellent reasons for excluding significant number of potential users. It's up to you to justify that.
For instance, one reason for excluding many people from becoming astronauts is simply that the physical rigours of launch given the best available technology would kill (or at least seriously harm) them.
Teams are expected to use the specific methods given above wherever possible. If information is missing, teams may use the generic scale.
When reporting your work, you must include:
Once you've determined the worst case HF demands, you now collaboratively decide whether and by how much your team will decrease the HF exclusion rate of the intervention you will design.
For any given HF, you may decide to (1) leave the HF exclusion rate as you determined it, or (2) change it so as to decrease the exclusion of your intervention.
You need to discuss this in your teams because you may find it necessary to negotiate which HFs are improved and by how much.
Let's say that you've identified the worst case HF demand for strength arises from the case of an elderly person having to lower one of the reference products (a “blender”) from a high kitchen shelf.
Let's also say that based on information available for that reference product, you used the available tools to determine that the reference product excludes 20% of elderly users. That is, you determine that the lightest of the reference products in your situation scan still excludes 20% of elderly users in the situation of lowering the blender from a high shelf.
Finally, let's say no other HF (as determined by other team members) excludes more than 5% of elderly users.
The team may decide that they want to match that exclusion rate for strength - i.e., lower the exclusion rate for strength from 20% to 5%.
When reporting this work, you must:
Once the team has reached agreement on the revised exclusion rates, you can now calculate (or at least approximate) the actual HF capabilities of your target users. These capabilities will become the foundation of constraints that your intervention will have to satisfy.
You can then use the available tools to calculate the maximum weight that your intervention can have, so that only 5% of elderly users will be excluded. That maximum weight will be lighter than that of the reference product used to determine the original HF demand.
You will report this work in the form of a Human Factors & Personas chart. An example is given below. Note the column marked
MINIMUM REQUIRED CAPABILITY; this is the column where you set the HF capabilities as you have determined them.
At this point in the process, each team needs to only complete the
MINIMUM REQUIRED CAPABILITY column as shown below. The rest of the chart will be completed later.
Each team needs only one HF&P chart. A template chart is available for you to download.
Deliverables are described for each step described above.
In the body of your design report, include:
In an appendix of your report, include all other deliverables as indicated in the sections above. This ought to include: three charts (for vision, hearing, and strength, and as defined in the relevant documents for HF tools and methods), appropriate justifications, a reasonable summary of findings, use of the Cambridge Exclusion Calculator, etc.
You are encouraged to use extended point form when reporting this work.
This step is not something teams do only once.
You may not cover all of the possible HFs in the first pass through your design. This is reasonable and expected. You will have opportunity later in the project to revise, enhance, and correct this part of your work. You may find it necessary to add new HFs to your work later in the project.
As you proceed with your project, you will discover all kinds of errors and oversights pertaining to the HF capabilities. Every team is expected to update their HF capabilities to correct errors, include new situations and cases, etc.