Website study / An example for Field engineering
Northfield Works
Can an engineering buyer explain a site problem before anybody has to translate it three times?
A technical business needs more than an impressive machine. Its website has to help an operations colleague identify a relevant service, pass on enough useful detail and understand what the engineering team will do next. This concept makes that handover the centre of the brief.
- The buyer
- Describe the fault
- The website
- Find the right route
- The working side
- Prepare the visit
Connection diagram · proposed system, not measured results
01 / Behind the website
Several people. One site problem.
The initial visitor might not be the person who signs the order. A useful engineering website would help people move the same problem between operations, procurement and a technical reviewer without losing its meaning.
- 01
The operations lead
Wants to know whether the team works on a relevant problem and what information to gather safely.
- 02
The technical reviewer
Needs equipment context, constraints and a reliable brief before deciding whether a visit is appropriate.
- 03
The purchasing colleague
Needs scope, responsible contacts and a clear quotation route without an unsupported emergency-response promise.
The uncertainty to remove
A specialist can infer meaning from a technical component that a purchasing colleague cannot name. We would investigate that vocabulary gap before choosing service labels or form questions.
Recognisable service routes may reduce the need to recall a precise engineering term. This is not permission to diagnose equipment from a photograph or use confidence-building design as a substitute for competence and scope.
02 / Behind the website
Every visible choice should earn its place.
The navy-and-yellow composition has a strong technical character. Its deeper value would come from making service fit and the first brief easier to understand, not from implying performance through impressive equipment imagery.
- 01
Lead with the site problem
The heading frames the customer’s issue before presenting the supplier’s capabilities. Service descriptions would define the supported work and important exclusions.
Check it: Ask an operations participant which service appears relevant and what they still cannot determine.
- 02
Show the first two actions
Describe the site, then outline the work: a modest sequence can make the first contact less intimidating without concealing later technical review.
Check it: Ask a non-engineer to prepare a brief from a scenario; record missing safety-critical context separately.
- 03
Keep technical detail available
The equipment illustration can draw interest, while plain language, evidence and documents should carry the actual capability explanation.
Check it: Check whether a technical buyer can find the specific capability evidence without relying on the hero image.
Method behind these choices: How People Read Online: New and Old Findings (source, new tab).
03 / Behind the website
Follow a brief from the first report to the engineer.
The discovery work would inspect permitted, redacted examples of real enquiries and the clarification messages they generated. A website cannot fix a handover we have not understood.
- Trace recent cases
Compare a useful brief, an incomplete brief and a request that was outside scope. Remove unnecessary personal or commercially sensitive information.
- Map responsibility
Find who can describe equipment, approve access, assess safety, confirm scope and authorise cost. One long form may be the wrong answer.
- Prototype a guided brief
Try short grouped questions and an optional document route. Show why each question is being asked and allow uncertainty where a non-specialist cannot know.
- Review the handover
Ask an engineer to judge completeness against an agreed rubric, then watch an operations colleague complete the same brief without coaching.
Three realistic tasks for a prototype
Check service fit
Decide whether a supplied site scenario appears within the stated service scope.
Record correct route selection and any invented assumptions about availability.Submit an adequate brief
Provide location, equipment context, observed symptoms and access constraints using a safe example.
Score completeness against the engineering team’s predefined checklist.Understand the next step
Explain whether the submission books a visit, requests review or creates a quotation.
A mistaken belief that a visit is confirmed is an important failure, even if the form submits.
What would make this an honest evaluation?
Use the same brief-quality rubric before and after a prototype test. A shorter completion time is not an improvement if important technical or access information is lost.
For a controlled field comparison, account for case mix: a complex installation and a simple inspection are not equivalent enquiries. Keep response time, brief quality and commercial outcomes as separate measures.
Research practice: Using moderated usability testing (source, new tab).
04 / Behind the website
Original words. A reason for every page.
Original service pages would connect practical problems with verified capability. Interviews and permitted historical enquiries would reveal how engineers and purchasing staff describe the same need.
| Question or search intent | Original page response | Evidence to gather first |
|---|---|---|
| “pump fault finding support” | A scoped service explanation covering suitable issues, what to prepare and what is outside the offer. | Actual capability, geography, competence evidence and review process. |
| “engineering site visit brief” | A preparation guide explaining equipment context, access and the information requested. | The engineer’s real checklist and the safest wording for non-specialists. |
| “equipment installation support” | A clear capability page with typical responsibilities and the route to a reviewed quotation. | Approved work scope, dependencies and genuine permissioned examples. |
Search research would separate emergency intent from planned work. The site should not attract an emergency query with a promise the business cannot fulfil.
Technical text, service metadata and enquiry labels would be written together. A content owner would review changes so a new search phrase does not quietly broaden the engineering service being offered.
Search phrases here are research seeds, not verified search volumes, rankings or traffic forecasts. Keyword research would validate demand, location, language and competition before publication.
05 / Behind the website
Make the assumptions visible.
Here the useful commercial question is administrative effort rather than an invented sales uplift. The model values recovered staff capacity; it does not assume that payroll or downtime automatically falls.
Change the assumptions
What could fewer clarification loops mean?
Use a realistic monthly brief volume and minutes of handling per brief.
Illustrative calculation · not a forecast
- Capacity difference / month
- 1,040 min
- Equivalent staff hours / month
- 17.33 h
- Indicative capacity value / month
- £780
The arithmetic, openly shown
Minutes difference = briefs × (current minutes − future minutes)Hours difference = minutes difference ÷ 60Capacity value = hours difference × assumed hourly value
Negative figures mean the assumed new process takes more time. Capacity value is not a cash saving, profit, reduced salary cost or evidence of safer engineering work.
From an attractive calculation to a trustworthy decision
A baseline would use timed handling observations across a representative period. Define whether each clarification includes reading, calling, chasing documents and rekeying data so the comparison counts the same work.
Reclaimed time is useful only if the team can redeploy it. Report whether work was genuinely removed, shifted to a client or transferred to another department; include the extra time needed to review any automated suggestions.
06 / Behind the website
Turn an enquiry into a reviewable technical brief.
The proposed backend would organise information and responsibility. It would support qualified people rather than automatically deciding whether equipment is safe or work should proceed.
- 01
Guided site brief
Ask conditional questions according to the service route and preserve “not known” answers for review.
Information in: Location, equipment category, symptoms and approved supporting files.
Useful output: A structured record that highlights gaps without guessing missing facts. - 02
Review and allocation desk
Assign a named person to check scope and request clarification before any commitment is made.
Information in: Brief, reviewer availability and service boundaries.
Useful output: A visible owner, review status and next action. - 03
Visit preparation pack
Prepare a consistent summary of approved scope, access details and required documents.
Information in: Human-reviewed brief and agreed site arrangements.
Useful output: A versioned pack with responsibilities and outstanding dependencies. - 04
Service history and reminders
Connect follow-up notes and agreed maintenance dates to the right asset and customer.
Information in: Authorised engineer updates and approved reminder dates.
Useful output: Traceable records and human-controlled follow-up tasks.
Permissions, human decisions and things that can go wrong
Access documents and site photographs can contain sensitive information. A real system would need upload validation, restricted access, retention decisions and an audit trail. Public forms should never expose engineer notes or another customer’s equipment records.
Failed notifications need an owner and retry behaviour. An overdue review should be visible; an automation must not invent a safe working method, confirm attendance or mark a technical task complete without the appropriate human decision.
Potential software only. These modules are not running behind the pictured website. Requirements, integrations, data protection, capacity, cost and support would be agreed before a real build.
07 / Behind the website
Evidence informs the idea. Testing earns confidence.
This is the closest of the six concepts to a multi-role B2B procurement journey. Even here, broad buyer research is context for asking better questions, not a performance forecast for a local engineering firm.
- Agree the brief-quality rubric
Decide which fields affect review quality, which are optional and which require specialist confirmation.
- Separate speed from correctness
Record handling minutes and completeness together; a fast but misleading brief is a poor result.
- Keep decisions attributable
Test who reviewed scope, approved a change and accepted responsibility for the next step.
Read the sources and the limits of each one
Learning about users and their needs (source, new tab)
Investigate users’ goals, current approach and difficulties. Treat untested internal opinions as assumptions.
Scope: Public-service research guidance includes people who use, provide and support a service.
Limit: Transferable practice guidance, not a B2B revenue experiment or a claim that research has already been conducted for these concepts.
How People Read Online: New and Old Findings (source, new tab)
People commonly scan for information, with reading depth varying by task, motivation, focus and person.
Scope: The publisher summarises eyetracking research spanning 13 years, more than 500 participants and over 750 hours.
Limit: Reading is not always shallow and no single scanning pattern fits every page. This is not a measured sales uplift for these concepts.
Memory Recognition and Recall in User Interfaces (source, new tab)
Visible choices and contextual cues can support recognition instead of asking people to recall information unaided.
Scope: A cognitive-psychology explanation applied to menus, search and interface content; published January 2024.
Limit: A design heuristic, not proof of universal behaviour or a specific conversion increase. Labels still need testing with the intended audience.
Using moderated usability testing (source, new tab)
Observe actual or likely users attempting believable tasks to reveal language, navigation and interaction problems.
Scope: Guidance covers recruitment, neutral task instructions, consistent discussion guides and accessible sessions.
Limit: Small qualitative tests expose contextual problems; they do not establish population conversion rates or commercial causation.
Creating helpful, reliable, people-first content (source, new tab)
Create original, useful content for an intended audience, drawing on genuine knowledge and clear sourcing; apply SEO to help that content be discovered.
Scope: Google’s published content self-assessment guidance, including purpose, originality, accuracy and trust.
Limit: Guidance is not a ranking guarantee. Length, exaggerated claims and copied summaries do not substitute for useful information.
SEO Starter Guide (source, new tab)
Write useful original content, anticipate the words different readers search for, and connect related pages with descriptive links.
Scope: Official introductory guidance on content, discoverability, images, search titles, snippets and site organisation.
Limit: Google does not guarantee indexing or first place. Search snippets may come from page text rather than the meta description; keyword repetition is not a sound strategy.
Involving Users in Evaluating Web Accessibility (source, new tab)
Working with disabled users reveals practical barriers; combine it with standards-based accessibility evaluation.
Scope: Guidance covers user evaluation, assistive technology, reporting scope and cautious interpretation of small studies.
Limit: User testing alone does not establish WCAG conformance, and a few participants cannot represent every disability or access need.
Web Vitals (source, new tab)
The published good-experience thresholds are LCP at most 2.5 seconds, INP at most 200 milliseconds and CLS at most 0.1.
Scope: Assess the 75th percentile of real page loads, separately for mobile and desktop, across all three Core Web Vitals.
Limit: These are performance targets, not measured results for the concepts. A laboratory result is diagnostic and is not equivalent to representative field data or a sales forecast.
B2B Website Usability: public research overview (source, new tab)
B2B websites need to support product comparison, shared purchasing decisions and customers’ tasks after purchase.
Scope: The public overview describes representative business users testing 293 B2B websites in the US, UK and Singapore using several qualitative research methods.
Limit: Only the public overview was accessed; the paid report was not. Its findings do not validate these fictional concepts or quantify their outcomes.
2025 B2B Buyer Experience Report (source, new tab)
94% of surveyed buyers said they ranked their shortlist before engaging with sellers.
Scope: Nearly 4,000 buyers across North America, APAC and EMEA. Qualifying purchases were at least $25,000 in the previous two years; the median was $200,000–$300,000.
Limit: Retrospective, self-reported higher-value B2B purchases. This is not representative of every small business enquiry and does not show that a website treatment causes sales.
Your business would have its own starting point
Bring the handover that keeps going wrong.
Darren can start with a redacted enquiry and a plain explanation of the delay. That is a stronger starting point than ordering a feature before the process is understood.