From fragmented training to a service-level diagnosis
Interviews, weekly surveys and field observation informed a collaborative research report, four system-level themes and a high-level service blueprint.
Read case study →UX Research · Enterprise & complex systems
Making complex work easier to understand.
I study how people work across complex services and products, then turn research evidence into clearer priorities, workflows and product requirements.
João Botelho · Based in Portugal · Open to remote and international opportunities
Explore selected work ↓About meSelected work
Research grounded in real workflows.
Two detailed case studies show research in specialist environments: understanding a training service and translating manufacturing workflows into product requirements. A further section highlights strategic desk research and a mixed-method research plan that was completed before the study itself was cancelled. Team contributions, recommendations, planned work and verified outcomes are clearly distinguished.
Turning manufacturing research into product requirements
An interview and prototype walkthrough revealed workflow issues, integration dependencies and requirements carried into product planning.
Read case study →Case study 01 / Technical training service · April 2026
From fragmented training to a service-level diagnosis.
Using mixed-method research to understand why a specialist training programme was difficult to deliver consistently—and where the service needed to change.
The question behind the work
The training experience brought together participants with different starting skills, instructors, programme organisers and teams responsible for equipment and delivery. The problem was not reducible to course materials or individual teaching performance: disruptions across planning, resources and ownership affected what learners could practise.
Our research question was how training was experienced and delivered in practice, which issues were structural rather than isolated, and what would make the service more predictable and relevant to participants.
My contribution—within a team
I conducted research for the training project and collaborated with the Experience Design team on analysis and outputs. The report, synthesis, journey work and personas were collaborative deliverables; I contributed to some personas, rather than designing the entire set independently.
The team-authored internal report documents the research approach, grouped findings, proposed improvements and a high-level service blueprint. Both the report and the blueprint were collaborative deliverables.
Research design · reconstructed summary
Interviews
Interviews with trainees and instructors captured their experiences, expectations and obstacles.
Weekly surveys
Repeated questionnaires collected feedback on learning progression and the training experience.
Field observation
Four days of contextual observation provided evidence of training activities and operational constraints alongside participants’ accounts.
Documented study scope: the report describes four trainee profiles and two instructor profiles, as well as the three methods above. Profile counts are not presented here as a total number of interviewees.
Source: team-authored research report, April 2026. The graphic is an anonymised reconstruction; it contains no original screenshots or participant data.
How the evidence was organised
From participant feedback to four connected service problems.
The team grouped findings under four themes. The report explicitly describes them as interconnected symptoms of missing service infrastructure—not four unrelated usability defects.
Planning
Objectives remained high-level, participant needs were not sufficiently profiled beforehand, and plans struggled when disruptions arose.
Recommendation Agree a detailed plan, learner prerequisites, milestones and readiness criteria before the programme begins.
Resources
Availability and readiness of training equipment were not reliably verified in advance, reducing hands-on practice and prompting improvisation.
Recommendation Establish dedicated training inventory and systematic pre-training readiness checks.
Instruction
Materials and scenarios were not always current or relevant; progression lacked consistent checkpoints and relied heavily on instructor judgement.
Recommendation Validate learning content, improve accessibility and introduce structured assessments.
Governance
Responsibilities and hand-offs were insufficiently defined, so preparation, escalation and support often happened reactively.
Recommendation Assign accountable service ownership with clear roles, sign-offs and escalation paths.
The themes and recommendations reflect the team's report. Language and scenarios are generalised to avoid disclosing sensitive operational details.
The key synthesis. Planning, resources, instruction and governance were linked. Revising course content alone would not address disruptions caused by resource readiness, unclear ownership and weak coordination across the service.
Making the system visible
Looking beyond the learner's immediate experience.
A separate collaborative as-is journey artefact mapped the learner perspective in greater detail. The research report included a high-level service blueprint covering the lifecycle below and proposed developing a more detailed service blueprint as a next phase. These are different deliverables, not proof that the future operating model was implemented.
Training lifecycle · conceptual reconstruction (not the original blueprint)
Perspective
Before · Prepare
During · Deliver
After · Follow up
Participant
Needs and starting skill understood
Training, practice and feedback
Assessment and continued support
Visible service
Programme expectations and schedule
Instruction and progress checkpoints
Certification and support contact
Behind the scenes
Role alignment, resource checks, content readiness
Equipment, instructor support, issue escalation
Ownership, lessons learned and improvement
This is a generic illustration of the service layers discussed in the report, not a reproduction of internal stage names, procedures or systems.
Complementary artefacts
Keeping different user perspectives in view.
Collaborative synthesis boards captured challenges across internal and external training. The team also developed and reviewed role-based personas. I contributed to some of these personas; the full set and its revisions belong to the team.
01
New trainee
Needs a clear progression path and support while developing foundational skills.
02
Experienced trainee
Needs training adapted to prior experience and relevant practice.
03
Instructor
Needs timely preparation, usable content and dependable delivery resources.
04
Training manager
Needs coordination, resource visibility and predictable delivery.
These role summaries are anonymised, newly written representations—not original persona cards or participant photographs.
What was delivered
The team consolidated findings into a report containing the research plan, evidence sources, four connected themes, recommendations and a high-level training lifecycle blueprint.
The team proposed a governance model, a more detailed service blueprint and monitoring of the next training iteration as future work.
What I can—and cannot—claim
Documented outcome: a service-level diagnosis and proposals to inform redesign. Not verified: subsequent adoption, delivery of the proposed future model, improved certification or measured operational impact.
Reflection: a problem that appears to concern training content may also depend on the service behind it—planning, ownership, resource readiness and coordination.
Case study 02 / Manufacturing software · July 2026
Turning manufacturing research into product requirements.
Understanding how quality professionals work across fragmented systems and what an enterprise product needs to support.
The problem
The quality-management experience sat within a complex operational environment. Processes crossed system boundaries, requirements changed as work progressed, and some decisions were handled through manual workarounds. The research needed to uncover how the work actually happened and where the proposed product experience did not reflect it.
My contribution
I conducted a remote semi-structured interview with one quality engineer. The discovery guide estimated 40 minutes; the session also included a prototype walkthrough outside that guide. I contributed to the team-authored analysis, merging session notes, checking the synthesis against the transcript and connecting findings to product requirements and follow-up actions.
Research-to-decision process · conceptual reconstruction
01 / RESEARCHInterview + prototype walkthrough
02 / SEPARATEDiscovery vs. evaluative observations
03 / SYNTHESISETeam-authored findings + implications
04 / CONNECTRequirements, owners + next steps
Illustrative diagram created for this portfolio; no proprietary data or internal artefacts are reproduced.
Research scope matters.The interview involved one participant at one site. The findings reflect that participant’s account and feedback on the prototype; they cannot establish organisation-wide patterns. Discovery and evaluative observations were explicitly distinguished in the team report.
Selected findings
Four documented problems and their implications for the product
Quality requirements entered the process too late.
Inspection requirements could be defined reactively rather than at the point when new items were introduced.
Implication → Connect quality definition to an earlier stage of the workflow.
Live work could retain outdated instructions.
Instructions associated with work already in progress did not automatically reflect later approved revisions.
Implication → Establish an explicit version policy that preserves traceability.
Exceptions relied on external coordination.
Failure handling could require further decisions and authorisation beyond a simple pass/fail state.
Implication → Define exception states, ownership and audit requirements.
Critical information lived across tools.
Some essential data and supporting workflows were maintained outside the platform.
Implication → Clarify data ownership and integration dependencies.
These are generalised descriptions of documented findings. Specific internal workflows, identifiers, locations and system architecture have intentionally been excluded.
Prototype feedback
What the proposed interface needed to account for
NavigationMatch users’ reference points
Prioritise the identifiers people actually use to locate work.
VisibilityShow relevant work first
Make queues sensitive to the user's assigned area or scope.
InteractionReflect actual task rules
Reduce redundant steps and accommodate evidence beyond failure cases.
Conceptual summary; not a product prototype or an implemented design.
From research to planning
The team-authored analysis connected evidence to existing development initiatives, new data requirements, cross-system dependencies and specific follow-ups. Some related work was included in planning; other items required clarification or remained in the backlog.
A useful distinction emerged: discovering a problem within a workflow did not necessarily mean that this particular product should own the solution.
Outcome and limitations
Documented outcome: the research informed requirements and planning. I did not follow implementation and cannot claim that features were delivered or that usability or business metrics improved.
What I learned: enterprise research must connect users’ work to ownership, product scope and system dependencies, without overstating what a single interview can establish.
Other selected research
Different research questions require different evidence.
Two shorter projects show work outside the main case studies: strategic secondary research into organisational models, and the design of a mixed-method study for an internal HR platform. They are presented according to what was actually completed.
Benchmarking distributed ownership models
Exploring how organisations distribute ownership, autonomy and decision-making across teams—and what those models may imply for talent management.
The brief
I was asked to identify organisations using approaches comparable to Dynamic Shared Ownership, assess whether relevant competitors were using similar models, understand how those organisations structured ownership and decision-making, and identify implications for talent management and emerging organisational trends.
My approach
I conducted desk research across technology and defence-sector organisations and synthesised the findings into a comparative matrix. The matrix allowed different organisational approaches to be compared across common dimensions such as autonomy, decision rights, accountability, governance and talent implications.
What the synthesis highlighted
- Greater team autonomy requires clear accountability and decision rights.
- Distributed ownership changes expectations around leadership, individual responsibility and collaboration—not only reporting lines.
- Governance remains important even when decision-making is decentralised.
Output: comparative benchmark and strategic synthesis intended to inform internal discussion. This was desk research and organisational benchmarking; it did not include employee interviews or primary user research.
Designing a mixed-method study for an HR platform
A research plan to understand platform adoption, daily friction, configuration gaps and opportunities for improvement across employees, managers and People teams.
The research questions
The study was designed to understand how and when people used the platform, why some users avoided it, which workflows created friction or workarounds, where configuration did not reflect team reality, and which improvements would have the greatest impact.
Planned evidence streams
- Usage analytics and support-ticket analysis.
- UX audit, workflow mapping and service blueprint.
- Organisation-wide survey covering use, satisfaction, confidence and missing functionality.
- Semi-structured interviews and real-task walkthroughs with employees, managers and People/leadership.
Planned synthesis
The three-week plan culminated in triangulation across data sources, a friction map, impact-versus-effort prioritisation, an adoption baseline and an executive set of recommendations.
Project status: the research plan was completed, but the project was cancelled before fieldwork began. No interviews were conducted and no research findings, adoption baseline or product outcomes are claimed.
About
A research mindset shaped across disciplines.
I moved formally into UX Research after a career spanning automotive journalism, corporate communications and international SEO/content strategy. The roles are different, but they share a core discipline: asking precise questions, interpreting evidence, understanding audiences and communicating findings so teams can act.
My recent UX work has focused on complex industrial, training and employee-experience contexts, combining primary research with research planning and strategic secondary research. I am particularly interested in enterprise products and specialist domains where useful research means understanding both people and the systems around their work.
My earlier experience complements—rather than substitutes for—my more recent UX Research practice.
InterviewingDiscoveryEvaluative researchResearch synthesisStakeholder communicationComplex workflowsResearch-to-requirementsResearch planningDesk research & benchmarkingInternational collaboration