A modern, executive-style Shiny dashboard analyzing UK train operations data from January to April 2024. This portfolio project demonstrates professional-grade data visualization, stakeholder communication, and full-stack R development capabilities using the Appsilon technology stack.

🔗 View the Live Dashboard:
UK Train Operations Dashboard on shinyapps.io

• R Shiny + shiny.semantic (Appsilon) | Modern UI framework based on Semantic UI
• ggiraph | Interactive visualizations with hover tooltips
• reactable | Professional data tables with search and pagination
• ggplot2 | Statistical graphics and custom styling
• dplyr + tidyr | Data manipulation and transformation
• bindCache | Performance optimization through reactive caching

The UK rail network serves millions of passengers daily, generating vast amounts of operational data on delays, revenue patterns, and customer behavior. However, this data often remains fragmented across systems, making it difficult for executives and operations managers to identify performance trends, diagnose delay drivers, or optimize revenue strategies.

This dashboard was developed to bridge that gap by transforming raw train operations data into an actionable intelligence platform that supports data-driven decision-making for three distinct stakeholder groups:

Executives — Monitor high-level KPIs, track performance trends, and identify strategic opportunities at a glance.

Operations Managers — Diagnose delay patterns, prioritize route-level interventions, and assess time-period performance to improve reliability.

Revenue Analysts — Review booking behavior, analyze pricing strategies, and identify revenue concentration risks across routes.

• Which routes generate the highest volume but may have revenue optimization opportunities?
• What are the primary drivers of delays, and do they vary by time of day?
• How does digital adoption compare to industry benchmarks?
• Where should we focus operational improvements for maximum impact?
• What revenue patterns suggest pricing power or competitive vulnerability?

By consolidating operations and revenue metrics into a single, user-friendly interface, this dashboard:

• Reduces time-to-insight from hours (manual reports) to seconds (interactive filtering)
• Enables cross-functional collaboration between operations and revenue teams
• Supports evidence-based discussions around resource allocation and strategic planning
• Demonstrates consulting-grade communication and technical execution

• Geographic Coverage: Major UK routes including London, Manchester, Birmingham, Edinburgh
• Temporal Granularity: Daily journey-level data with timestamp precision
• Categorical Dimensions: Route, Time Period, Ticket Type, Booking Channel, Delay Reason
• Numeric Metrics: Journey Count, Revenue (£), Delay Minutes, Booking Days in Advance

Identifiers

• journey_id — Unique identifier for each train journey
• route — Origin-destination pair (e.g., "London Euston → Manchester Piccadilly")

Temporal Fields

• date_of_journey — Journey date (YYYY-MM-DD format)
• time_period — Categorized time slot (Morning Peak, Evening Peak, Off-Peak Day, Off-Peak Evening, Night)

Operational Metrics

• is_delayed — Boolean flag for on-time performance tracking
• delay_minutes — Duration of delay (numeric)
• delay_severity — Categorized delay buckets (Minor, Moderate, Significant, Major)
• reason_for_delay — Root cause classification (Weather, Technical Issue, Staffing, etc.)

Revenue Fields

• revenue — Ticket price in GBP (£)
• ticket_type — Advance, Anytime, Off-Peak classification
• is_online — Digital vs. station purchase indicator
• days_in_advance — Booking window metric

Quality Checks Performed

• ✅ No missing values in critical fields (journey_id, route, date, revenue)
• ✅ All dates within expected range (Jan-Apr 2024)
• ✅ Revenue values validated (£5 minimum, £150 maximum)
• ✅ Delay minutes consistent with severity categories
• ✅ Route names standardized across dataset

Feature Engineering

• booking_category — Derived from days_in_advance (Same Day, Advance 1-7 days, Far Advance 8+ days)
• revenue_category — Derived from revenue (Budget <£15, Standard £15-25, Premium £25-40, High Value £40+)
• ontime_rate — Calculated as percentage of non-delayed journeys

Performance Optimization

• Applied bindCache() to all reactive computations
• Pre-aggregated summary statistics to reduce runtime calculations
• Optimized chart rendering with ggiraph's rescale feature

To provide a multi-persona analytics platform that balances executive simplicity with operational depth, enabling rapid insight discovery through interactive filtering and consistent visual language.

Progressive Disclosure — Start with high-level overview (Executive), drill into specifics (Operations, Revenue)

Persona-Driven Tabs — Each tab serves a distinct stakeholder need with appropriate metrics and granularity

Consistent Visual Language — Unified color scheme, hover effects, and info tooltips across all views

Modern Appsilon Stack — shiny.semantic for professional UI, moving beyond traditional shinydashboard

• Total Journeys | 31,653 journeys across 4 months
• Total Revenue | £742k in ticket sales
• On-Time Performance | 92.8% reliability rate
• Digital Adoption | 58.5% online ticket purchases

• Executive Takeaway Box — One-sentence consulting-style insight highlighting key opportunities
• KPI Cards — Four primary metrics with trend context and info tooltips
• Daily Performance Trends — Time-series chart showing journey volume over 4 months
• Top 5 Routes by Volume — Bar chart identifying network concentration
• Key Insights Panel — Digestible performance summary with emoji icons

• Operations KPIs — Delay rate, average delay, top delay cause
• Time Period Filter — Interactive selector for drilling into specific time windows
• Route Delay Analysis — Top 10 routes by delay rate (horizontal bars for readability)
• Delays by Time Period — Horizontal bar chart showing when delays occur most
• Delay Reasons — Top 8 causes with count visualization
• Delay Severity Distribution — Journey outcomes by delay magnitude
• Route Performance Details — Searchable table with color-coded delay rates

• Revenue KPIs — Average fare, advance bookings, peak premium, digital revenue share
• Booking Window Analysis — How advance booking affects journey volume
• Revenue by Time Period — Temporal revenue patterns
• Price Distribution — Ticket price categories and their frequency
• Channel Performance — Online vs. station comparison (journeys, revenue, avg price)
• Route Revenue Performance — Top 10 routes by total revenue with gradient coloring
• Route-Level Revenue Details — Comprehensive table with digital adoption metrics

Modular Design

app.R                    # Main application entry point
R/
  mod_executive.R        # Executive overview module
  mod_operations.R       # Operations analytics module
  mod_revenue.R          # Revenue intelligence module
data/
  processed/
    trains_clean.rds     # Pre-cleaned dataset

Key Technical Decisions

1. shiny.semantic over shinydashboard — Modern UI components, better mobile support, cleaner aesthetics
2. Modular server/UI pattern — Each tab is a self-contained module for maintainability
3. Reactive caching with bindCache() — All expensive computations cached for performance
4. ggiraph for interactivity — Consistent hover tooltips across all charts
5. Semantic UI modals — Native modal system (not shiny::modalDialog) for consistency

Core service reliability remains strong (92.8% on-time), while recent softness in journey volume (-4.1% MoM) and sub-benchmark digital adoption indicate near-term opportunities in demand stimulation and channel migration.

• 31,653 journeys generated £742k in revenue (£23.44 average fare)
• 92.8% on-time performance with 7.2% delay rate
• 58.5% digital adoption (Industry benchmark: ~65%)

• Manchester Piccadilly → Liverpool Lime Street is highest-volume route (5,128 journeys)
• Top 5 routes account for 28% of total network volume
• Revenue concentration risk: top 10 routes represent 45% of total revenue

• Morning Peak experiences highest delay rate (12.5%)
• Weather is the leading delay cause (42.8% of all delays)
• Technical Issues rank second (18.3% of delays)
• Average delay duration: 42.5 minutes (when delayed)

• Peak premium: +40.3% higher fares vs. off-peak periods
• Advance bookings: 12.1% of tickets purchased 8+ days ahead
• Digital channel: generates 51.6% of revenue despite 58.5% volume share (suggests lower avg fares online)
• Price distribution: 62% of tickets in "Budget" category (<£15)

The industry benchmarks shown below are illustrative reference points compiled from public transportation reports and industry summaries; they are not sourced from the synthetic datasetset itself.

1. Channel Migration Initiative

• Goal: Increase digital adoption from 58.5% → 65% (industry benchmark)
• Tactics:
  • Launch 5% discount for first-time online bookers
  • Improve mobile app UX based on user feedback
  • Partner with travel aggregators for wider online distribution
• Expected Impact: +£45k annual revenue (assuming channel cost savings)

2. Peak Period Capacity Management

• Goal: Reduce Morning Peak delay rate from 12.5% → 9.0%
• Tactics:
  • Add rolling stock capacity on top 5 morning routes
  • Implement dynamic crew scheduling during peak windows
  • Deploy predictive maintenance on high-utilization assets
• Expected Impact: +3.5% on-time performance, improved customer satisfaction

3. Revenue Optimization Program

• Goal: Increase advance booking rate from 12.1% → 18.0%
• Tactics:
  • Implement dynamic pricing with 10-15% advance purchase discounts
  • Launch email campaigns 14 days before popular travel dates
  • Test fare bundling (train + parking, train + hotel)
• Expected Impact: +£28k annual revenue through improved yield management

4. Delay Root Cause Reduction

• Goal: Reduce weather-related delays by 25%
• Tactics:
  • Invest in weather monitoring systems at high-impact locations
  • Pre-position maintenance crews during adverse weather forecasts
  • Improve track drainage on routes with highest weather delays
• Expected Impact: +2% on-time performance, reduced compensation costs

This project showcases proficiency in:

• Modern R Shiny Development — Modular architecture, reactive programming, performance optimization
• Front-End Design — shiny.semantic, custom CSS, responsive layouts, UX best practices
• Data Visualization — ggplot2, ggiraph, reactable, statistical graphics, color theory
• Business Intelligence — KPI design, dashboard UX, stakeholder communication
• Software Engineering — Git workflow, code organization, documentation, maintainability

This project demonstrates ability to:

• Translate business questions into technical requirements — Persona-driven design process
• Communicate with non-technical stakeholders — Executive summary, consulting-style insights
• Think strategically about data products — Feature prioritization, user workflow optimization
• Balance technical excellence with practical constraints — Performance vs. complexity tradeoffs

1. User-Centered Design Matters The decision to create three distinct tabs for different personas was crucial. Early iterations had a single "one-size-fits-all" view that satisfied no one. By separating Executive, Operations, and Revenue, each stakeholder got exactly the information they needed at the right granularity.

2. Performance Optimization is Essential Initial load times were 8-10 seconds. By implementing bindCache() on all reactive computations and pre-aggregating summary statistics, I reduced this to <2 seconds. Users will not tolerate slow dashboards, no matter how insightful.

3. Consulting Language Opens Doors The executive takeaway box ("Core service reliability remains strong...") consistently gets the most positive feedback. Speaking the language of business stakeholders—using terms like "softness," "sub-benchmark," and "near-term opportunities"—immediately establishes credibility.

4. Modern Frameworks Matter Moving from traditional shinydashboard to shiny.semantic modernized the entire aesthetic. Hiring managers and consultants notice these details. It signals awareness of industry trends and willingness to learn new tools.

5. Documentation is Part of the Product This README is as important as the dashboard itself. It demonstrates thinking, process, and communication skills. Many portfolio projects have great code but poor documentation, missing an opportunity to showcase analytical reasoning.

# Install required packages
install.packages(c(
  "shiny", "shiny.semantic", "dplyr", "tidyr", 
  "ggplot2", "ggiraph", "reactable", "scales", 
  "glue", "forcats"
))

# Clone the repository
git clone https://github.com/poncest/uk_train_dashboard.git
cd uk_train_dashboard

# Launch the app
shiny::runApp()

uk_train_dashboard/
├── app.R                          # Main application entry point
├── R/
│   ├── mod_executive.R            # Executive overview module
│   ├── mod_operations.R           # Operations analytics module
│   └── mod_revenue.R              # Revenue intelligence module
├── data/
│   └── processed/
│       ├── trains_clean.rds       # Main dataset
│       ├── daily_summary.rds      # Pre-aggregated daily metrics
│       ├── route_summary.rds      # Route-level aggregations
│       └── time_period_summary.rds # Time period aggregations
├── www/
│   └── (future: custom CSS, images)
├── screenshots/
│   ├── executive_overview.png
│   ├── operations_analytics.png
│   └── revenue_intelligence.png
├── README.md                       # This file
└── .gitignore

# Deploy to shinyapps.io
rsconnect::deployApp(
  appName = "uk_train_operations",
  forceUpdate = TRUE
)

Steven Ponce
Data Analyst | R Shiny Developer | Business Intelligence Specialist

🔗 Portfolio Website: stevenponce.netlify.app
🐙 GitHub: @poncest
💼 LinkedIn: stevenponce
🐦 X (Twitter): @sponce1

License: MIT License - Feel free to use this code for learning or portfolio purposes.

Disclaimer: This is a portfolio demonstration project using synthetic data. It is not affiliated with any UK rail operator, National Rail, or transportation authority. All insights and recommendations are illustrative examples for showcasing analytical capabilities.

Data Source: Synthetic dataset created for educational purposes. No real customer or operational data was used.

Project Published: December 2025
Last Updated: December 18, 2025
Version: 1.0.0

• Appsilon — For developing shiny.semantic and pushing modern Shiny design patterns
• Posit Community — For comprehensive R Shiny documentation and examples