User personas & jobs-to-be-done

Status: draft Author: Agent C (frontend bucket, round 1) Reviewers: Sophia Mann, Andrew Kent; Agent E (cross-cutting); round-2 critique agent Last updated: 2026-05-10

Context

The LBZF computer-vision product currently has zero users. Phase I deploys in July 2026 into a Pereira garment factory whose head industrial engineer (Ronald Gonzalez Suarez) is replacing a working manual stopwatch + whiteboard + Excel loop with our system. A product replacing a working analog workflow has to be measurably better on Ronald’s terms or he stops using it after a week. There is no fallback plan if Ronald abandons the system.

Source artifacts anchoring this doc:

docs/overview/people.md (stakeholder roster)
docs/factory/current-state.md (the whiteboard + INDICADORES ABRIL.xlsx + lost-time-codes loop)
docs/factory/operations.md (the 44-operation Ref22 Slim sequence Ronald measures against)
Granola transcripts 2026-04-26, 2026-04-29, 2026-05-02, 2026-05-10

Goals

One concrete persona per real stakeholder, not aspirational “users”.
For each persona: device, language, daily frequency, the one decision they make from the product, the artifact they use today, and the failure mode that would make them quit.
Make Ronald’s persona the most detailed, because his adoption is the project’s single point of failure.
Surface adoption risks specific enough that they can be tested against before July 2026.

Non-goals

Marketing personas. These are operational specs for designers and engineers, not segmentation for sales.
Persona for “operators” (the 22 sewers on the Angela module). Operators are subjects of the system, not users — they don’t log in.
Persona for future Phase II line supervisors. Stubbed in but not deeply specified.

Proposed approach

Five concrete personas (one per real stakeholder), plus two stubs (line supervisor, end-customer/future-tenant). Each persona is structured identically:

Identity & role
Device & context
Language
Frequency of use
The one decision they make from this product
What they currently do (the analog/Excel artifact)
What would make them stop using the new system
Adoption risk score (1–5; 5 = if this persona quits, the project fails)

Persona 1 — Ronald Gonzalez Suarez (Head Industrial Engineer, LBZF Pereira)

Adoption risk: 5/5 — primary failure mode of the entire project.

Identity & role. Industrial engineer responsible for line balancing, lost-time coding, and daily efficiency reporting across the four LBZF modules. The person who walks the floor with a stopwatch when Angela falls behind. The author / maintainer of INDICADORES ABRIL.xlsx and Ref22 Slim - Angela.xlsx. He owns the lost-time taxonomy (C001–C022) and is the single human keeper of the standard-time data the CV system replaces.
Device & context. Probably a Windows desktop in the engineering office adjacent to the production floor. Possibly a tablet on the floor for spot-checking a module, but unconfirmed — OPEN: does Ronald carry a tablet today, or is the whiteboard-walk strictly stopwatch + paper? — owner: Armando (factory liaison) → Ronald, target: before 2026-05-13 Argentina demo. Office probably has air conditioning (per v1.9 plan, the Jetson lives in this room).
Language. Spanish only. No documented English fluency. All Drive shares from his account (ingenierialbarton@gmail.com) are Spanish-titled. All UI he touches must be es-CO native. English fallbacks in error states are unacceptable.
Frequency of use. Daily, multiple times per day. The whiteboard is updated hourly today — the CV dashboard must support at minimum hourly check-ins, ideally a live “is the line on pace right now” glance at any time.
The one decision. “Which workstation/operation is causing the module to miss meta this hour, and what lost-time code should it be assigned?” Everything else in the UI is supporting evidence for that one decision.
What he currently does.
- Hourly: walks past each module’s whiteboard, sees hora / meta / real / % attainment, mentally compares.
- When real < meta for several hours: takes a stopwatch and times each operation at each workstation. Compares to the SAM column in Ref22 Slim - Angela.xlsx “Balanceo” tab.
- End of shift: enters units, total minutos productivos, eficiencia, rendimiento into INDICADORES ABRIL.xlsx.
- End of day: codes lost time using C001–C022 (rework / mechanic / quality / materials / personal / operational).
- Reports up to Mariana monthly as a static spreadsheet.
What would make him stop using the new system. Ranked by likelihood:
1. The system makes him do more work, not less. If the dashboard requires him to re-enter what’s already on his whiteboard, he reverts to the whiteboard.
2. It silently disagrees with the floor. If the dashboard says Angela produced 320 units and his head count says 310 and there’s no obvious explanation of the delta, he stops trusting the dashboard.
3. The Excel export doesn’t match INDICADORES ABRIL.xlsx’s format byte-for-byte. He hands the spreadsheet to Mariana monthly. If our export looks different he has to manually retype it.
4. Spanish is bad. Machine-translated terms, mismatched garment vocabulary (e.g., “puño” rendered as “fist” rather than “cuff”), wrong gender agreement on operator names.
5. It goes down for an hour during a shift and there is no way for him to reach Sophia in time. Falls back to whiteboard, never comes back.
6. The lost-time codes don’t appear, or appear in a different order than C001–C022.
7. He cannot see the live video to verify what the system claims. If station 7 says ”20s cycle time” and he wants to eyeball it, he must be able to click into the video for that station.
Adoption risk score: 5/5. Without Ronald, there is no Phase I.

Persona 2 — Mariana Saker (CEO, LBZF, Sophia’s aunt)

Adoption risk: 4/5 — she funds Phase II. If she does not see clear value by August 2026, Phases II–III do not happen.

Identity & role. CEO and executive sponsor. Family relationship to Sophia accelerates gating decisions, but it does not lower the bar for the product itself — if anything it raises Sophia’s personal stake.
Device & context. Phone primarily (assumption — OPEN: confirm Mariana’s preferred device, owner: Armando → Mariana, target: 2026-05-13). Laptop in the office occasionally. Likely iOS based on Colombian executive defaults, but unconfirmed.
Language. Spanish primary. Likely some English; do not assume.
Frequency of use. A few times per week, not daily. Glance-and-go. Weekly review, monthly board-style summary. She does not have time to navigate three levels of menu.
The one decision. “Are the four modules on pace this week, and if not, is Ronald already on it?” Translation: she wants a status indicator and reassurance that the engineer is handling exceptions — she does not want to be the engineer.
What she currently does. Receives monthly INDICADORES exports from Ronald. Probably emails or messages directly when a number looks bad. No real-time visibility today.
What would make her stop.
1. It takes more than 10 seconds to find “is Angela on pace today”. The home view must answer that in one glance.
2. The dashboard makes the factory look bad to outsiders. If she shows it to a buyer or partner and a worker’s face is on screen with no productivity number next to her station, that’s a worse impression than the spreadsheets.
3. It contradicts Ronald. If Mariana opens it on a Tuesday and Angela is “red” but Ronald hasn’t called her, she has to call Ronald to ask why — friction.
4. It requires installing Tailscale. If lbzfai.com cannot show her the data directly and she has to install an enterprise VPN to see her own factory, she will not use it.
Adoption risk score: 4/5.

Persona 3 — Sophia Mann (Project lead, admin, dev)

Identity & role. Castilleja sophomore, InspiritAI fellow, first author on the IEEE paper, admin user of the system in production, primary engineer in development.
Device & context. MacBook Air M1 (insufficient for ML fine-tuning per the 2026-04-29 Sam meeting). California. Eventually AWS or a new laptop.
Language. English.
Frequency of use. Daily during development; less frequent post-deploy.
The one decision. “Is the system healthy, and is there anything I need to push to Ronald or escalate to Andrew?” Operates the system from California through Tailscale.
What she currently does. Builds the system. Reads INDICADORES. Reads Granola transcripts. Writes design docs.
What would make her stop. N/A — she is the maintainer. The relevant question for her persona is: “what UI does the admin need that is not in Ronald’s view?” Answer: deployment status, model version, camera health, audit log of role changes, manual data-correction tools, the ability to impersonate Ronald for QA.
Adoption risk score: 1/5 (she is the builder).

Persona 4 — Andrew Kent (Mentor, admin)

Identity & role. Technical mentor since 2026-05-02. Brown alum; ex-Form AI (factory CV; direct industry fit). Provides direction; reviews architecture; admin access for sanity checks.
Device & context. Laptop; California (or wherever). Sees the system through Sophia’s eyes most of the time; occasionally direct.
Language. English.
Frequency of use. Weekly (mentor sessions cadence); ad-hoc during demos.
The one decision. “Is Sophia on track to ship a real thing by July, and is the architecture defensible enough to demo to the ITBA team and Mariana?”
What he currently does. Mentor calls (Granola-recorded), Drive comments, repo reviews.
What would make him stop. N/A — he is a mentor, not a user. The relevant UI need is the same admin surface Sophia gets.
Adoption risk score: 1/5.

Persona 5 — ITBA research team (Raul Marino, Carlos Bibian, Rodrigo Díaz, Esteban Roitberg, Cristian Mateos Diaz, Rodrigo Ramele)

Identity & role. Six PhDs in Buenos Aires; collaborating on the IEEE paper; receiving twin hardware on 2026-05-15 to run a parallel deployment in their lab. They are not on the LBZF factory floor.
Device & context. University workstations in Buenos Aires.
Language. Spanish primary (Argentine, not Colombian — different idioms; same enough for UI text).
Frequency of use. Project-bound, not daily ops. Heavy during paper-writing windows; light otherwise.
The one decision. “Does our twin reproduce LBZF’s numbers, and can we cite LBZF’s aggregate metrics in the paper?”
What they currently do. Wait for hardware; coordinate with Sophia through Andrew + Drive shares.
What would make them stop.
1. Access to LBZF’s live data is unclear. They need a defensible answer to “can I see the Angela module live or only aggregate end-of-day numbers?” — see open question in ../technical/frontend/auth0-roles-and-access.md.
2. Their own twin’s data is not segregated from LBZF’s in the UI, making it impossible to cleanly publish.
3. English-only UI on the twin makes copy-paste comparisons to LBZF screenshots inconsistent for the paper.
Adoption risk score: 3/5. ITBA dropping out hurts the paper, not Phase I deployment.

Persona 6 — Armando Mann (Factory liaison, hardware ferry)

Identity & role. Sophia’s father. Logistics, hardware ferrying California → Buenos Aires → Pereira. The only documented relay to Ronald (Ronald has no email/calendar presence in Sophia’s connected services).
Device & context. Bilingual phone + laptop; mobile in transit.
Language. EN/ES bilingual.
Frequency of use. Coordination layer, not daily product user.
The one decision. “Is Sophia’s next ask of Ronald defensible enough that I should forward it?”
What he currently does. Drive shares, Granola invites, Slack-like coordination through informal channels.
What would make him stop. N/A — he is family + project staff.
Adoption risk score: 2/5. If Armando is unavailable, Ronald-coordination breaks and the project slows.

Stub persona 7 — Future line supervisor (per-module, Phase II+)

Read-only view of their own module’s status. Spanish only. Likely tablet on the floor. The view inherits from Ronald’s view but is scoped to one module, no write actions, no exports, no admin. Specified for completeness; not blocking Phase I.

Stub persona 8 — Future tenant operator (multi-tenant, if it ever happens)

Andrew’s phrase “all the nested pages users will see on the platform” could imply multi-tenant SaaS. This is not in Phase I scope. Stubbed here so that role and route conventions don’t paint us into a single-tenant corner — see ../technical/frontend/lbzfai-evolution-plan.md §“Tenancy posture”.

Alternatives considered

One generic “factory user” persona. Rejected — Ronald and Mariana have orthogonal needs (one operational, one executive). Conflating them loses the design constraint that Ronald’s view must look like a richer INDICADORES ABRIL.xlsx.
Add real operator personas. Rejected for Phase I — operators don’t log in. Reconsider for Phase II if behavioral monitoring’s outputs are surfaced to operators (e.g., a per-operator feedback screen, which has its own labor-law implications — coordinate with Agent E).
Drop ITBA from persona list. Rejected — ITBA is the paper co-author; their UX needs (data segregation, language) shape Auth0 roles and the data sharing model. They are real users of the system, even if not on the factory floor.

Open questions

OPEN: Does Ronald use a tablet on the floor today, or only the office desktop + paper? — owner: Armando → Ronald, blocking: Argentina presentation, target: 2026-05-13. Affects whether Ronald’s dashboard needs a tablet-responsive layout in Phase I or just desktop.
OPEN: Mariana’s primary device — iOS phone? Android phone? Or laptop only? — owner: Armando → Mariana, blocking: mobile-first design assumption, target: 2026-05-20.
OPEN: Does Ronald speak/read any English? — owner: Sophia (next Granola-recorded call to confirm; failing that, ask Mariana), blocking: localization spec finalization, target: before Phase I deploy. Default until confirmed: es-CO only on Ronald’s surfaces.
OPEN: Who is the “production engineer (TBD)” listed in docs/overview/people.md? — owner: Sophia → Ronald (via Armando), blocking: nothing immediate, target: when needed.
OPEN: Local technical contact for Jetson restart procedure — who is it? — owner: Sophia + Ronald, blocking: deployment runbook, target: before July 2026 deploy.

Cross-bucket dependencies

From hardware/ML (Agent A or D): confirmation of which camera angles the dashboard will display. Wireframes assume one tile per workstation; if the camera-per-workstation assumption changes (e.g., two cameras at the pocket-attach station), the dashboard grid changes.
From backend/integration (Agent B): the data contract for cycle events, per-workstation pace, per-module efficiency. The persona analysis assumes the backend can produce “current real vs meta for this hour” cheaply.
From business/cross-cutting (Agent E): confirmation that Ronald’s lost-time taxonomy (C001–C022) is allowed to surface in the UI (it’s plant-internal data, not customer-confidential). And the legal review on showing worker faces (see Mariana persona above) — Agent E owns the Colombian labor-law thread.

What’s weak in this doc

Ronald’s persona is built from second-hand artifacts, not from a conversation with Ronald. All Ronald data is via Drive shares + Mariana/Armando relay. The risk that this entire doc is well-intentioned-but-wrong about how Ronald actually thinks is real. Single most important round-2 reviewer action: get a 30-minute Spanish-language call with Ronald and confirm the “one decision he makes” framing.
Mariana’s persona is even thinner than Ronald’s. Her device, frequency of use, and tolerance for tooling friction are guesses anchored on “executives of medium-size LatAm family businesses” — not data.
The adoption-risk scoring is impressionistic. “5/5 = project fails” is a category, not a measurement. There is no defined threshold for what abandonment looks like (one week of non-use? one month? a single missed export?). This needs to be operationalized before we can say “we hit our adoption target”.
No persona covers the people being measured. The 22 named Angela-module operators are subjects of the system. We have not articulated how the product treats their preferences, dignity, or right to view their own data. This is a labor-law-adjacent gap; see Agent E.
ITBA is treated as one homogeneous persona when it’s six different people with different roles. Round 2 should split if the data-sharing answer turns out to be different for different ITBA roles (e.g., a PI vs. a grad student).

Rollout

Argentina demo (2026-05-13): show this doc to Andrew and the ITBA team during the trip. Use Ronald’s persona as the narrative spine for the demo — “the person we’re building for”.
Pre-July 2026: validate Ronald and Mariana personas in a Spanish-language call with each. Update doc.
Phase I (July 2026 deploy): personas accepted; UX docs frozen for build.
Phase II (Aug 2026+): add operator and line-supervisor personas with real data from the first months of operation.

Appendix / references

docs/overview/people.md
docs/factory/current-state.md
docs/factory/lbzf.md
INDICADORES ABRIL.xlsx (Drive: 1oo5s4R70XXXK4zeeCsEMNNJcnXrvEUKV)
Ref22 Slim - Angela.xlsx (same folder)
Granola transcripts: 2026-04-26, 2026-04-29, 2026-05-02