How To Do Good Human Factors.
Invented scenarios, worked end to end the way a real programme would be. How the problem is framed, which standards apply, which methods are chosen and why, and what the results mean. The practice is the lesson. ErgoSphere is the instrument.
Plan 0: do 1 to 7 in order. Return to 3 if 5 raises a question the chosen methods cannot answer. Exit at 7 when every finding has a requirement, an owner and a clause.
- 1Frame the problemWhat changed for the human
- 2Establish the standards basisWhat applies, clause by clause
- 3Choose the methodsAnd record the roads not taken
- 4Run the analysisWhere ErgoSphere appears
- 5Interpret the resultsAgainst a criterion, not a gut
- 6Write the user requirementsFindings wound back into the design
- 7Close outOwner, date, clause, issued
Three Scenarios. One Way of Working.
Each worked example opens with the problem as a client would put it, then follows the seven nodes above to an issued deliverable. The method chain is shown in the order it was run. Where a method was considered and not used, the page says why. Every method that is used gets a step-by-step card, from building the first node of an HTA to reading the last tab of the comparison. Screenshots come from the shipping build, and every page names the build they were taken from.
-
EXAMPLE 01Rail
The Graph Goes Digital
Network control · paper train graph to digital, telephone authorities unchanged
Controllers plan in pencil, issue in red and record in blue on a paper graph, and issue every train authority by telephone. The change puts the graph on a screen and leaves the telephone where it was. The client asked for a workload score. The answer was a count: five error modes out, four in, and a change in what kind of error the controller can see.
Method chain- HTA
- SHERPA
- ErgoDelta
- ErgoDesign
AS 7470:2024, governingISO 11064-4 as criteria -
EXAMPLE 02Aviation
Two Controllers, One Drone
Drone control in the battlespace · handed forward, employed, handed back before the move
Nobody doubted the drone could be flown from the forward station. The question was the two handovers, and the one that lands on top of everything else the Forward Controller has to do. An HTA of the role found it. An ACT-R model of the hand back answered it before the rig could.
Method chain- HTA
- ErgoAct
- NASA-TLX
- SART
MIL-STD-1472H, governingSTANAG 4586 read -
EXAMPLE 03Mining
The Fifth Screen
Remote operations centre · new truck bay interlocks
The engineering answer was to put the new monitor where there was room. The Human Factors answer starts with where the operator's eyes already go, what the west window does to that screen at four in the afternoon, and which of the new alarms actually need a person.
Method chain- Link Analysis
- ErgoDesign
- ErgoGlare
- ErgoAIR
- SHERPA
ISO 11064, governingEEMUA 191Site hazard plan
Seven Nodes. Every Example.
Good Human Factors is not a method. It is a sequence of decisions, each one written down.
The tree at the top of this page is a Hierarchical Task Analysis of the practitioner's own job. It is drawn that way on purpose. HTA is the first thing most of the examples do, and the notation is easier to learn by reading a page written in it than by reading a definition. The top goal is the deliverable. The plan says the order. The seven subordinate goals are the sections of every example, and each example numbers its steps from them: 4.1, 4.2 and so on.
- 1
Frame the problem
The client asks for a sign-off. The practitioner asks what changed for the human. Set the system boundary, name the roles and the modes of operation, and write down the question the work has to answer before any method is chosen. Most bad Human Factors work went wrong here, silently, on day one.
- 2
Establish the standards basis
Find what applies, in order of authority: mandated by the regulator, the governing standard, the client's own safety management system, then good practice. Read the governing standard section by section and decide, in writing, which clauses apply to this change and why. The clauses screened in become the project's requirements against the standard, the ones the close-out must answer. Applicability is a professional judgement and it is recorded as one.
- 3
Choose the methods
Match the method to the question, to the data you can actually get, and to the confidence the audience needs. Record the choice and the roads not taken. Two methods that triangulate beat one that has to be argued for. A method chosen because it is the one you know is the most common quiet failure in the profession.
- 4
Run the analysis
Decompose the task once and let every method read the same structure. This is the band where ErgoSphere appears: the screenshots, the field names, the sequence of work inside the app. Every method also gets a "How to" card: the steps of the method itself, and under each one the same step as it is done in the app. A reader who wants only the practice can skip the app lines and lose nothing of the lesson.
- 5
Interpret the results
A score is not a finding. Read every output against a criterion, an accepted band, a published threshold or a before-and-after comparison, and say what it means for the people who will operate the system. Where two methods disagree, the disagreement is the finding.
- 6
Write the user requirements
Now the findings wind back into the design. Every finding that needs a control becomes a requirement a designer can build to and a tester can verify: who, shall, what, under which condition, verified how, with the analysis row as its source. The few that come straight from a clause of the standard are written here too, so the set is one set. The requirement is the bridge between the finding and the design change, and between the standard and the close-out. Without it, the report can only say "we looked", which is not a claim anyone can check.
- 7
Close out
Every finding gets a severity, an owner, a target date, and a trace back to the clause and the requirement it answers. The Early Human Factors Analysis and the Integration Plan are compiled from the work, not written after it. The deliverable is issued under a revision letter, not emailed as an attachment.
Invented Scenarios. Real Practice.
Every worked example in the Workbook is set in a scenario written for the purpose. The rail network, the RPAS unit and the mine do not exist. No client, site, programme or person is behind any of them, and the figures are illustrative. What is real is the practice: the order of work, the decisions, the disagreements between methods and the mistakes a practitioner actually makes. The scenarios were built so those could be taught without touching anything under a client agreement, which is where real programme work stays.
These are not case studies. A case study is an account of a real programme, written with the people who ran it. Those will come from ErgoSphere users, and they will be labelled as such.
The examples teach practice, not compliance. A method can align to a standard, and an analysis can produce the evidence a clause asks for. Whether a system complies is a claim its owner makes, on that evidence, to its regulator. The Workbook shows how to build the evidence so the claim survives being read.
- Studying Human Factors?The Students page carries the why behind the methods, the reading, and a free seat on the full platform while you are enrolled.
- Try a method in the browserHTA, RULA, NASA-TLX and SART run free on this site with no sign-up. Follow an example with the free HTA tool open beside it.
- See what the client receivesEach example ends in an issued deliverable. The free Viewer opens it: the task tree, the findings and the report, live.
The Workbook Grows.
New worked examples are added as they are written. If there is a problem worth teaching from, or a method you would like to see walked end to end, say so. The best examples start as a question from someone who has to do the work on Monday.
