# Digitalising IBS Travel Reimbursements > A reimbursement process researched from the inside, translated into requirements, and rebuilt as a working application. - **Case study:** https://yazdanjoo.de/projects/digitalising-ibs-travel-reimbursements - **Author:** Sanaz Yazdanjoo (UX Engineer) - **Role:** Solo — UX Research, Usability Engineering, UI Design & Frontend Development - **Year:** 2026 - **Timeline:** 2026 · ongoing - **Status:** in progress - **Context:** In-house project - **Summary outcome:** Research mapped 13 steps, reversed a priority, surfaced 6 missed problems, and carried the 9-actor colour model into the demo. From paper forms and scattered Excel files to one traceable reimbursement workflow ## About I spent more than a year administering this reimbursement process as a project assistant — collecting paper receipts, consolidating several Excel files, checking attendance, and calculating reimbursements. That gave me deep process knowledge, but I treated it as a set of assumptions to test rather than as research evidence on its own. I combined insider observation with expert interviews, an administration working meeting, an ongoing participant survey, and artefact analysis, then translated the verified problems into requirements and a working application. The demo is deployed for team feedback; formal usability evaluation is still pending. ## Challenge Travel reimbursement depended on paper attendance records, several Excel files, manual calculations, and hand-offs across nine actors. The same information was copied repeatedly, creating delays and opportunities for mistakes. Participants had no reliable confirmation after submitting documents, no visible calculation, and no claim status. In the ongoing survey, 4/6 respondents did not know how their amount was calculated, 5/6 had no reliable way to know whether their documents had arrived, and 4/6 named processing time as their main difficulty. One traced claim remained unpaid after 43+ days. The failure was structural, not clerical. ## Solution I replaced the fragmented workflow with one role-based application for attendance, supporting-document submission, reimbursement calculation, approval, and claim tracking. Participants can upload documents and see the state of their claim; staff work from the same attendance and reimbursement data instead of copying information between spreadsheets. Calculations are rebuilt from shared rules and the formula trace remains visible to reviewers. The participant upload flow is designed for phone use, while responsive support across the full authenticated application is still in progress. The current system covers the workflow up to payment; the final accounting payment step remains outside the application. ## Design I carried the research model into the interface instead of inventing a separate visual language. The role colours from the AS-IS swimlane map became the application role palette, supported by a compact type scale, status chips, note states, buttons, and form states. This keeps the same actor cues visible from research artefact to working screen. ## Wireframes I used low-fidelity wireframes to resolve information hierarchy and workflow logic against the numbered requirements before applying visual styling. The high-fidelity version kept the same structure and added the final attendance vocabulary, morning/afternoon states, role cues, exception highlighting, and completion feedback. The comparison below shows the same attendance-month screen from sketch to wireframe to deployed view. ## Methodology The research-to-build chain is explicit. I treated insider observations as hypotheses, checked them through interviews, the administration working session, the ongoing participant survey, and artefact analysis, then clustered the evidence into a 25-problem register with evidence grades. Those problems became numbered requirements, information architecture, state rules, and wireframes. One example closes the loop: 4/6 respondents did not understand the reimbursement calculation → transparent calculation became a requirement → one shared calculation module now produces a visible formula trace → automated tests protect the requirement links. The same traceability also exposes gaps: confirmation after submission is only partially implemented, so the page does not present it as solved. ## Process - **discover: Turn insider knowledge into testable questions** — I combined more than a year of process observation with two expert interviews, one administration working meeting, an ongoing anonymous participant survey (n=6), and document analysis. - Insight: Because I already knew the workflow, the research goal was to challenge my assumptions, not to confirm them. - **define: Map the failure and grade the evidence** — The AS-IS map exposed 13 steps, four return loops, and nine actors. Thematic clustering produced a register of 25 documented problems, each linked to its evidence source. - Insight: Survey findings also changed the roadmap: I had treated phone-width support as secondary, but participants reported that phone submission mattered. Responsive participant use moved up the priority list; the full signed-in phone layout is still in progress. - **design: Translate findings into explicit product rules** — The problem register became numbered requirements, a role-based information architecture, an explicit claim state model, and low- and high-fidelity wireframes. - Insight: The service map covers nine actors. Seven composite, evidence-backed role profiles document the perspectives used during design; five roles directly work through dedicated application views. - **deliver: Carry the same requirements into working code** — I built the role-based application in React and TypeScript with shared calculation rules, an explicit claim state machine, access controls, local data adapters, and automated tests. - Insight: Example: 4/6 survey respondents did not understand the reimbursement calculation. That became a requirement for transparent amounts, implemented as one shared calculation with a visible formula trace and protected by automated checks. - **deliver: Deploy first, measure the change next** — The demo is deployed for stakeholder feedback. Guided tasks, pseudonymous local event logging, and an end-of-session questionnaire are already built into the application for the formal usability evaluation. - Insight: No post-launch improvement is claimed yet. The evaluation instruments exist; the user sessions have not run. ## Results The current evidence describes the existing process and the mechanisms implemented in the replacement. The working demo is deployed for team feedback, and internal testing has already exposed three instrumentation bugs. Formal usability sessions have not run, so I do not claim reduced processing time, fewer errors, better usability, or adoption yet. Those outcomes will be reported only after the evaluation is completed. ## Limitations - The participant survey is currently n=6, self-selected, and so far limited to the blended/online cohort; the in-person cohort and travel-pass holders are not yet represented. - Two expert interviews represent project management and accounting. Lecturers were not interviewed; their part of the workflow is mapped from artefacts and my own process observation. - The 43+ day figure is one traced claim. It was still unpaid when observation stopped, so it is a minimum for that case — not an average or a distribution. - Formal usability evaluation of the new system has not run. The page therefore reports implemented mechanisms and baseline evidence, not measured improvement over the paper process. ## Participant Voices > "No, I just take the amount as it comes." > — Survey respondent on checking the reimbursement calculation · translated from German > "The processing time is the hardest part for me." > — Survey respondent · four of six named processing time as their main difficulty · translated from German > "I don’t check it." > — Survey respondent on knowing whether submitted documents arrived · translated from German ## Key Numbers - **13** — steps in the AS-IS reimbursement process - **4** — return loops in the mapped process - **9** — actors across the end-to-end service - **43+** — days in one traced claim · minimum for that case, not an average ## Methods - Insider process observation (>1 year) - Expert interviews (n=2) + administration working meeting - Ongoing anonymous participant survey (n=6) - Document & artefact analysis - Thematic analysis / evidence grading - Stakeholder & AS-IS process mapping - Requirements traceability - Built-in usability evaluation instrumentation ## Tech Stack - React - TypeScript - Vite - Tailwind CSS - Vitest - Node.js / Fastify - SQLite - ExcelJS - Nextcloud WebDAV - Figma Make - Claude Code (AI-assisted development) ## Skills & Topics UX Research · Stakeholder Interviews · Survey Design · Thematic Analysis · Process Mapping (UML) · Requirements Engineering · Requirements Traceability · Information Architecture · State Machine Modelling · Wireframing · Design Systems · Prototyping · Usability Evaluation (instrumented) · React · TypeScript · Node.js / Fastify · Automated Testing (Vitest) · Privacy by Design · GDPR / DSGVO