Bachelor Thesis · Portfolio Case Study · 2026

Human-Agent Service Blueprint

From problem qualification to a justified Human-AI work system.

An evidence-based service-design method that helps teams move from a solution-led AI use case to a reasoned decision about task allocation, readiness, architecture, control, integration, and next steps. The result is an interactive web application, an offline workshop kit, and an exportable Decision Snapshot.

  • Service Design
  • Human-AI Collaboration
  • UX Research
  • Systems Design
  • AI Product Design
  • Web Prototype
Cover of the Human-Agent Service Blueprint bachelor thesis, featuring a screenshot of the interactive web application.
Interactive blueprint · portfolio summary

01 · The challenge

Start with the work, not the agent.

Many AI projects begin with an assumed solution: “We need an agent.” The research showed that the real bottlenecks often appear earlier—in problem understanding, roles, data access, handoffs, governance, and operational readiness. The Blueprint reverses that logic: qualify first, then shape the simplest system that can reliably do the job.

Not: “How do we build an agent?”
But: “Which form of automation is justified for this work system?”

02 · Research → Design

Patterns across real project work.

Six partner-supported project cases formed the research field. Participant observation and artefact analysis were brought together through cross-case thematic analysis and translated into a Design Science artefact.

06

Partner-supported cases

Observed in context and examined through the artefacts teams used to make work happen.

3

Research moves

Participant observation, artefact analysis, and cross-case thematic analysis.

1

Design Science artefact

A practical method for turning empirical patterns into reasoned design decisions.

  • Roles and handoffs
  • Data, process and integration
  • Trust, visibility and control
  • Low-code as bridge and stress test
  • Team and partner configurations

03 · The Blueprint

A guided process with room to revise.

  1. 01Orient
  2. 02Qualify
  3. 03Design
  4. 04Synthesis
  5. 05Decide
  6. 06Reflect

Design principles

  • Problem before technology
  • Qualify before building
  • Allocate tasks by complementarity
  • Use the minimally sufficient architecture
  • Make control visible
  • Design for verification and recovery
  • Shape integration together
  • Clarify lifecycle responsibility

04 · Digital implementation

A case evolves as decisions become clearer.

A linear macro process keeps the work legible while allowing teams to revisit and correct earlier decisions.

The Living Case Record carries the case state forward; adaptive next steps avoid a rigid completeness checklist.

The Service Canvas synthesises the work system, and a Decision Snapshot exports a portable milestone view.

Glossary guidance and persistent local cases support continued work; an Offline Workshop Kit enables the same method without the web application.

05 · Optional assistance

AI as a sparring partner, not an autopilot.

When asked, the optional AI Copilot reviews the current case, surfaces contradictions or evidence gaps, and proposes concrete additions. Each suggestion is reasoned, shown as a change preview, and applied only after explicit confirmation.

AI recommends evidence explains humans deliberate humans decide.

06 · Outcome

A Decision Snapshot made for the next conversation.

The export brings the current rationale and operating conditions into a portable format, so a decision can travel beyond the workshop or prototype.

  • Goal and system boundary
  • Solution category and maturity
  • Current decision and conditions
  • Human oversight and verification
  • Blockers, recovery, and fallback
  • Operational responsibility
  • Next test, action, and owner

The project connects qualitative research, service design, systems thinking, and digital product design in a practical tool for shaping early Human-AI work systems. Its contribution is not maximum automation, but clear boundaries, justified task allocation, and an architecture only as complex as the case actually requires.

Back to Semester 7