MTDC is Maharashtra's official tourism arm — with a digital experience that hadn't kept up
The Maharashtra Tourism Development Corporation runs resorts, water parks, holiday camps, and adventure activities across the state. For years, their digital presence was limited to a website that did one thing: let users book rooms. No mobile app. No self-service tools for staff. No unified system for managing aquatic activity bookings or BnB properties.
When Stratzi.ai brought me onto this project, the brief sounded straightforward. It wasn't.
What began as "fix the website" became: redesign the website, build a mobile app from scratch (v2), design the CMS, the property management system, the BnB admin portal, and the aquatic activities admin portal — all as a coherent ecosystem. The website was a collaborative effort with the design team; the mobile app, CMS, and all admin portals were designed solo.
What I inherited
The existing website allowed users to browse and book rooms, but that was it. Staff managed bookings manually. There was no mobile experience. Aquatic activity bookings and BnB properties were handled through phone calls and spreadsheets. A previous designer had started the mobile app (v1) with the team — but usability and navigation were inconsistent, and it needed a full redesign before development.
Six surfaces. Two roles.
This project had a team of designers. Here's exactly what I owned and what was collaborative:
✦ Designed entirely solo. ◆ Collaborative work with the design team.
Users were booking the wrong dates — and no one had noticed
The most critical UX issue wasn't something MTDC flagged in the brief. I uncovered it during my review of the booking flow.
"They didn't pick dates — they just booked."
The room booking flow had a date picker with default values — check-in and check-out set to the same day. Users were completing bookings without ever selecting their actual travel dates, resulting in single-day reservations that didn't match their intent.
This was a silent failure. Bookings were going through. Revenue was being recorded. But guests were arriving with a different expectation than what the system had logged.
Date picker defaulted to today's date for both check-in and check-out. No visual prompt forcing the user to change it. Users skipped it and booked.
Date fields left intentionally blank on load. Mandatory validation before proceeding. Clear visual cue drawing attention to the date step as the first required action.
Other problems identified
Content visibility: Key information — activity timings, property amenities, location details — was buried or inconsistently structured across property pages. Users couldn't make informed booking decisions without digging.
No mobile experience: A significant portion of Indian tourism traffic comes from mobile. The app v1 was inconsistent and unintuitive — navigation patterns changed between sections, and the booking flow had too many steps.
Zero staff tooling: MTDC staff had no digital tools. Aquatic activity bookings, BnB check-ins, and content updates were all manual — phone calls and spreadsheets.
Understanding what tourism users and MTDC staff actually needed
Stakeholder alignment
I worked directly with MTDC officials and an internal PM to understand operational constraints — what staff could realistically manage, what booking rules existed, what content MTDC owned vs. needed to update frequently. This shaped the CMS and admin portal architecture significantly.
Benchmarking
I reviewed booking flows from MakeMyTrip, Airbnb, Maharashtra Tourism's peer state portals, and international government tourism sites to identify patterns that worked — particularly around date selection, activity discovery, and availability display.
State tourism portals in India consistently under-invest in the discovery phase — they show listings before users know what's available near them, in their budget, or for their group size. I restructured MTDC's content hierarchy to lead with destination and activity type before showing specific properties.
Website — Property Detail Page
The property detail page consolidates all booking-critical information — images, room options, pricing, location, amenities, and reviews — in a single structured layout, reducing the need to navigate away before committing to a booking.
MTDC Mahabaleshwar detail page — property overview, room pricing, location map, and availability check
How I tackled six surfaces across solo and team work
The biggest risk on a solo project of this scope is inconsistency — making decisions in isolation that clash later. My process was built to prevent that.
Ecosystem IA first, screens second
Before touching Figma, I mapped every surface, user role, and content relationship. This single document governed all subsequent design decisions. When a field appeared in the CMS, it appeared consistently in the app and website too.
Design system before screens
I built a shared component library — typography, colour, buttons, cards, form elements, data tables — that all six surfaces drew from. This wasn't optional at this scope; it was the only way to maintain consistency and move fast simultaneously.
Website (desktop + mweb) — redesign & missing screens
Worked alongside the design consultant team to redesign website elements, design missing screens, and implement client-requested modifications — ensuring visual consistency with the established design language across desktop and mobile web.
Mobile app v2 — full redesign
Reviewed v1 with fresh eyes. Restructured navigation, simplified the booking flow from 7 steps to 4, and designed a consistent interaction model across all app sections. Added activity discovery as a first-class feature alongside room booking.
Admin portals — CMS, PMS, BnB, Aquatic
Designed with MTDC staff as the primary user — not technical users. Prioritised clarity, scanability, and error prevention. Used role-based access logic to surface only what each staff type needed. Annotated every interaction and edge case directly in Figma for developer reference.
Stakeholder reviews & iteration
Ran review cycles with MTDC officials and the internal PM at each major milestone. Captured feedback, prioritised changes, and documented decisions directly in Figma to maintain a clear design rationale trail.
MTDC What's New — upcoming events across Maharashtra with filterable listings by location, month, and organiser
A coherent digital ecosystem — built for three types of users
For visitors — Website & Mobile App
A discovery-first experience that helps users find the right MTDC property or activity before they commit to booking. The redesigned booking flow addresses the date-selection problem directly — dates are required, prominent, and visually foregrounded before any other booking detail.
App home — destination hero, category navigation, and trending stays
Property detail — imagery, location, about, and booking CTA
For MTDC staff — CMS & Admin Portals
Three admin surfaces designed for non-technical users. The CMS lets staff update property listings, images, and activity details without developer intervention. The BnB and Aquatic admin portals replace spreadsheets with structured booking management — filterable by date, property, and status.
Aquatic admin portal — booking management with filterable status, location, and export functionality
For the admin portals, I intentionally matched visual patterns from the visitor-facing website — same card structure, same status colours, same date format. Staff who used the public website would feel immediately oriented in the admin view. This reduced the learning curve without requiring any training documentation.
Figma file structure
Every screen was annotated with interaction notes, edge cases, and state variations directly in the Figma file. Developers on the app team referenced these annotations throughout QA — reducing back-and-forth significantly. The v2 Figma file was specifically called out by the team as substantially easier to navigate than v1.
What shipped, what improved, what's still in progress
"The version 2 of the mobile app is much cleaner and easier to use. The Figma file is much easier to navigate and the annotations and comments about the desired interactions are easy to refer to."
— Internal design team, Stratzi.ai
What I'd do differently
"If I had more time…"
I would have run structured usability tests with actual MTDC visitors — specifically around the activity discovery flow and the date picker fix — before finalising the designs. The date-selection problem was caught through my own review, not user research. A round of moderated testing with 5 users would have surfaced additional friction points I may have missed.
I also would have liked to run a card sorting exercise with MTDC staff before finalising the CMS information architecture. The structure I used was logical, but staff mental models around content types (properties vs. activities vs. packages) may differ from mine. A single workshop session would have validated or refined those assumptions early.
Finally — given the scope — I would push to have a second designer at the start of the project to pressure-test decisions before they scaled across all six surfaces. Working solo at this scale means some assumptions only get challenged late.