UX RESEARCH | ILLUSTRATIVE ENGAGEMENT
Can a technician control the service response when the mobile workflow is interrupted?
Testing alert interpretation, action recording and handoff clarity before an elevator service application enters a wider pilot.
CLIENT SITUATION
An elevator equipment company was redesigning the mobile workflow used to receive service alerts, record an action and hand a job forward.
DECISION REQUIRED
Decide which workflow changes were necessary before piloting the application across two different service conditions.
Why the interaction mattered
A service response rarely happens in a quiet, continuous session. A technician may read an alert while travelling, lose connectivity at a site, receive a second assignment or hand the job to another person. The client needed to know whether the interface preserved meaning and responsibility as those interruptions occurred.
The research focused on the interaction itself. It did not assess the technical diagnosis, mechanical work or safety of an elevator.
The questions the client needed answered
INTERPRET
Can the user identify equipment state, urgency and ownership before acting?
RECOVER
Does the workflow preserve progress and confidence after an interruption or network loss?
HAND OFF
Can the next person distinguish work completed from permission to return the unit to service?
Hypothetical engagement frame
18 PARTICIPANTS
14 field users and 4 coordination roles
SICILY, ITALY
Palermo, Catania and selected regional routes
3 SCENARIOS
Alert intake, interrupted entry and handoff
6 WEEKS
Recruitment through focused retest
Note: This is a hypothetical example showing how August Research could structure the engagement. The organisation, participant counts, findings and recommendations are not presented as actual client outcomes.
PARTICIPANT AND OUTREACH DESIGN
Recruit around the response responsibility
The sample covers the people who receive, act on and verify the job record, then varies the conditions under which they perform that work.
Participant structure
8 breakdown response technicians
Regularly accept urgent service alerts and document corrective actions
6 maintenance technicians
Perform planned work but rotate into reactive service coverage
2 service dispatch coordinators
Assign, redirect and monitor active jobs across a region
2 regional service supervisors
Review handoffs, exceptions and readiness for job closure
Selection parameters
Direct involvement in alert acceptance, action entry, reassignment, review or closure
Newly qualified, mid experience and highly experienced users
Dense metropolitan routes in Palermo and Catania, with longer travel to surrounding and inland sites
Users with recent experience of weak signal, offline entry or delayed synchronisation
Single brand and mixed portfolio service environments where permitted
Organisation approved handsets, protective cases, gloves and notification settings
What the outreach looks like
1. SOURCE
Client approved field teams and authorised partners across Palermo, Catania and regional coverage areas
2. SCREEN
Short role and recent task verification without revealing the test path
3. SCHEDULE
Sessions grouped around shifts, travel and approved access across Sicily
4. CONSENT
Prototype, recording, confidentiality and workplace permission confirmed
Why independent research adds value
Technicians may hesitate to criticise a company tool in front of managers or may describe a workaround as normal practice. A neutral moderator can observe the behaviour first, then explore uncertainty without linking the conversation to performance assessment.
RESEARCH METHOD
Interrupted Response Reconstruction
A scope specific application of Interaction Consequence Testing that examines what happens when the user's attention, connection or ownership changes mid task.
Controlled test environment
Sessions would use a client approved training unit, non operational test rig or controlled prototype environment. The application would contain fictitious equipment and service records. No participant would perform live safety critical work as part of the research.
Three scenario families
SCENARIO | BACKGROUND GIVEN TO THE USER | OBSERVED DECISION |
|---|---|---|
ALERT INTAKE | A priority alert is assigned while the technician is travelling to another planned job. | What is checked before accepting responsibility, travelling or redirecting the job |
OFFLINE ACTION ENTRY | Connectivity drops immediately after an action note and supporting evidence are entered. | Whether the user understands what is stored, synchronised, duplicated or still incomplete |
HANDOFF AND CLOSURE | The approved work is complete, but another role must verify the record before service status changes. | Whether work completion, equipment availability and authorisation remain distinct |
How each session is carried out
01 UNGUIDED START
The participant receives a neutral task brief and begins without being shown the intended route.
02 CONTROLLED INTERRUPTION
A realistic connection, notification or reassignment event is introduced at a defined point.
03 RECOVERY ATTEMPT
The moderator observes whether the user resumes, repeats, abandons or seeks help.
04 ASSISTANCE LADDER
Only the minimum prompt needed to continue is introduced and recorded.
05 DECISION REPLAY
The participant reviews key moments and explains what each cue meant at the time.
06 FOCUSED RETEST
A revised interaction is tested against the same consequence and recovery conditions.
Evidence captured
ACTION PATH
Taps, sequence, reversals and repeated entry
INTERPRETATION
What the user believed about status and ownership
RECOVERY
Trigger, assistance level and recovered state
CONSEQUENCE
Delay, record ambiguity, handoff gap or avoided error
QUESTION DESIGN
Observe first, then ask for the reasoning
Questions are framed around the scenario the participant has just completed. The moderator does not ask for a preferred design before the behaviour is visible.
Example task background
TASK PROMPT
You are travelling to a planned visit when a priority service alert is assigned. The unit is unavailable and the building contact expects an update. Using the prototype, decide what you need to know, take responsibility or redirect the job, and record the next action.
Sample questions after the task
When you first opened the alert, what did you believe had already been checked or confirmed?
Tests interpretation of the starting state without asking whether the screen was clear.
Which information did you look for before accepting the job, and what did you do when it was not immediately visible?
Reconstructs the evidence threshold and any workaround.
At the point the connection dropped, what did you believe had been saved? What on the screen led you to that conclusion?
Links confidence to a visible cue rather than a general opinion.
You returned to the workflow after the interruption. How did you decide where to continue?
Examines resumption logic, memory burden and duplicated action.
What did 'work complete' and 'return to service' mean to you in this task? What, if anything, distinguished them?
Tests whether the two states remain conceptually separate.
If another technician received this record now, what might they understand correctly and what might they need to verify?
Tests the quality of the handoff from the next user's perspective.
Questions for coordination roles
Q07
Looking only at this handoff record, what would you verify before assigning the next action?
Identifies information required for supervision and continuity.
Q08
At what point would you call the technician rather than rely on the application record?
Reveals where the interface stops carrying sufficient operational meaning.
ILLUSTRATIVE FINDINGS
Where the workflow lost meaning
Hypothetical task evidence from the 14 field technicians shows how a small label or state cue can create a larger handoff consequence.
Observed breakpoints in the test scenarios
Cue to consequence reconstruction
CUE
Acknowledged
MEANING
I own the job
ACTION
Travel begins
STATE GAP
Dispatch sees only 'viewed'
CONSEQUENCE
Duplicate assignment risk
Priority pattern
PRIORITY | INTERACTION CHANGE | DECISION EFFECT |
|---|---|---|
1 | Separate viewed, accepted and assigned states | Clarifies responsibility before travel or reassignment |
2 | Show saved locally and synchronised as different states | Reduces repeated entry and uncertainty after signal loss |
3 | Separate work complete, review complete and service status | Protects the handoff between technical action and authorisation |
DECISION AND DELIVERY
Changes to make before the pilot
The output is a focused workflow decision, not a generic usability score.
Illustrative decision
PROCEED AFTER TARGETED REVISION
Retain the overall workflow, but revise ownership states, offline confirmation and closure logic before a two condition field pilot. Retest the three affected paths with field technicians and coordination roles.
What the client receives
Interrupted Task Trace
Annotated sequence showing the cue, interpretation, action, interruption and recovered state
State Language Register
Terms that users understood consistently, misunderstood or treated as equivalent
Handoff Consequence Map
Where record ambiguity changes responsibility, follow up or closure
Retest Acceptance Checks
Observable conditions the revised prototype should satisfy before pilot entry
Delivery sequence
WEEK 1
Scope, prototype and screening
WEEK 2
Recruitment and environment setup
WEEKS 3-4
Task sessions and daily evidence review
WEEK 5
Consequence analysis and design workshop
WEEK 6
Focused retest and decision readout
Timing is indicative and depends on participant response, shift access, workplace permissions, prototype readiness, travel across Sicily, safety induction and the availability of an approved test environment.
FAQ
Does this study validate elevator safety?
No. It evaluates how users understand and control the application workflow. It does not replace engineering verification, safety certification, cybersecurity review, regulatory assessment or the client's authorised operating procedures.
Can live field observation be included?
Yes, when the client can provide the required access, permissions and safety controls. Critical interaction testing would still be separated from live safety work.
Contact Us
Discuss your UX research question
Tell us the user, critical task, product or interface, development stage, operating conditions, priority markets and decision you need to make. August Research will design the participant outreach, test environment, research method and decision outputs around the interaction that matters.
