Travel Request Form Redesign

System & Process Improvement Proposal

Context

The current business travel request process lacks structure, validation, and clarity. Employees frequently submit incomplete or incorrect forms, approvers must manually re-verify information, and the system provides minimal guidance on what belongs where.

The core issue is not the interface — it is the lack of a structured, predictable process that clarifies responsibilities, validates data early, and guides users step by step.

Identified Problems

1. No descriptions or guidance

Fields are unlabelled or unclear. Users do not know:

  • what information is required,
  • why specific fields matter,
  • how the data will be used downstream.

The result: incorrect submissions, confusion, and unnecessary back-and-forth.


2. Missing client/domain validation

The system does not automatically:

  • detect which client the employee is currently assigned to,
  • restrict the domain selection to valid options,
  • verify cross-domain travel scenarios.

Employees can submit travel requests under incorrect clients, forcing managers to re-check what the system should validate automatically.

3. Duplicate verification

The same data is:

  • entered by the employee,
  • informally checked,
  • formally reviewed,
  • and approved — often without a clear boundary between these steps.

There is no defined moment when:

  • the employee’s responsibility ends, and
  • the approver’s responsibility begins.

This leads to rework and inconsistent decisions.


4. Lack of clear process boundaries

The process blends input, validation, and approval into one block.
Users cannot see:

  • which stage they are in,
  • what happens next,
  • what is expected of them.

5. Poor correction and resubmission experience

When a request is returned for changes:

  • feedback is scattered across comments or emails,
  • users must guess what to fix,
  • corrections are often incomplete,
  • requests bounce back multiple times.

The system should never force users to search for feedback.

Proposed Solution

A Step-Based Wizard with System Validation and Clear Responsibility Splits
Instead of one unstructured form, the travel request process becomes a wizard with:

  • clearly defined stages,
  • system-driven constraints,
  • early validation,
  • and meaningful navigation.

The UI is secondary — the process structure is the real improvement.

Wizard Structure (4 + 1 Steps)

 Step 0: Feedback & Next Steps (only when corrections are required)

A dedicated pre-step visible only when the request was returned for edits.

It contains:

  • who returned the request,
  • why it was returned,
  • required corrections (checklist),
  • links to relevant steps,
  • a clear explanation of what must be done before resubmission.


Example: 
Your travel request was returned for correction.

Requested by: Project Manager
Required changes:
• Client selection does not match your current assignment
• Travel dates must align with project timeline
• Provide justification for cross-domain travel

Continue to Step 1

----end of example---

This becomes the user’s starting point for any resubmission — no guessing.

Step 1: Context

  • Employee details (auto-filled)
  • Current client assignment (auto-filled)
  • Domain selection (restricted dropdown)
  • Optional justification for cross-domain travel (only if allowed)

The system enforces validity upfront.

Step 2: Travel Purpose

  • Purpose of travel
  • Relation to project work
  • Additional justification (only if needed)

This ensures the request aligns with real project needs.

Step 3: Travel Details

  • Dates
  • Destination
  • Transport
  • Accommodation
  • Cost-related information (if relevant)

Structured input reduces misinterpretation.

Step 4: Review & Confirmation

A complete summary with:

  • all entered data,
  • validated fields,
  • highlighted exceptions.

The employee confirms correctness:

“I confirm that the above information is complete and accurate.”

This is the final step before the approver becomes responsible.


Navigation Logic

  • Users can freely move between steps.
  • They can jump directly to a flagged field.
  • Step 0 appears only when corrections are required.
  • Validation occurs early, not after submission.

Clear Responsibility Split

Employee

  • Inputs correct data
  • Reviews and confirms accuracy
  • Fixes issues explained in Step 0

System

  • Restricts invalid combinations
  • Verifies assignment and domain consistency
  • Ensures required fields are complete
  • Provides structured, centralized feedback

Manager / Approver

  • Approves necessity, not technical correctness
  • No longer rechecks basic validity the system can enforce

Expected Outcomes

  • Fewer incorrect or incomplete submissions
  • Faster approval cycles
  • Clearer ownership of each process stage
  • Significantly reduced back-and-forth
  • Higher data quality for compliance and reporting

Summary

This is not a cosmetic form redesign.
It is a process-level upgrade that introduces clarity, guidance, validation, and structure into the travel request workflow.

The wizard with Step 0 ensures:

  • users understand what they need to fix,
  • the system prevents avoidable mistakes,
  • managers evaluate only what truly requires judgment.

This redesign reduces operational load and makes the entire approval process predictable, transparent, and respectful of the user’s time.


 

My Role

I identified the systemic gap, defined the problem space, designed the operational model, and translated it into a scalable solution framework.

© Zofia Szuca 2024
Brand and product designer