elaizasebastianportfolio.

Aashirvad Cinemas, a regional film distributor in Kerala, relied on manual reporting from their field reps during movie releases. An earlier MVP had tried to digitize this process but failed due to poor alignment with real-world workflows.

During my internship at the studio, I worked on rethinking this system from the ground up. Through system mapping, critiquing the existing MVP, wireframing, and live testing during actual movie releases, we developed a more intuitive, task-aligned tool. Continuous feedback from field reps and managers directly shaped the final design.

Aashirvad Cinemas, a regional distributor in Kerala, relied on manual reporting from field reps during movie releases. An earlier MVP tried to digitize this but didn’t align with real workflows.

During my internship, I helped rethink the system from scratch. Through mapping, critiquing, wireframing, and live testing during releases, we built a more intuitive tool shaped by constant feedback from reps and managers.

CONTEXT

Aashirvad Cinemas is a major film production and distribution company based in Kerala. In addition to producing films, Aashirvad also oversees the release of movies across more than 300 theatres, relying on a network of field representatives to collect and report ticket sales data.

Currently, this data collection workflow is largely manual and informal, reps typically communicate sales figures through WhatsApp messages or phone calls to their managers. This unstructured process creates several challenges, including lack of accuracy, poor data traceability, limited real-time access, and difficulty maintaining historical records.

Aashirvad Cinemas is a major film distributor in Kerala, managing releases across more than 300 theatres with field reps collecting ticket sales data.

At present, the workflow is manual and informal, reps report figures through WhatsApp or calls. This results in inaccuracy, no traceability, limited real-time access, and difficulty maintaining records.

UNDERSTANDING THE SYSTEM

The distribution process begins when a movie is handed over by the producers to the distribution company, in this case, Aashirvad Cinemas, which then negotiates profit-sharing percentages with each theatre. Based on this agreement, daily collections are reported, and revenues are settled.

The distribution process starts when producers hand a movie to Aashirvad Cinemas, who negotiate profit-sharing percentages with each theatre. Daily collections are then reported and settled.

While the General Manager doesn't monitor every transaction, they often use intuition and experience to flag anomalies, for instance, if a theatre reports unusually low numbers for a popular film. However, these checks are not backed by a structured system of cross-verification, leading to gaps in accountability. Many inconsistencies go unnoticed unless they are glaringly obvious.

This reliance on manual judgement, informal communication channels, and lack of a unified digital system underlines the need for a more reliable, data-driven oversight mechanism.

The General Manager often relies on intuition to catch anomalies, such as unusually low reports for a popular film, but there is no structured cross-verification. This means many inconsistencies go unnoticed.

This dependence on manual judgment, informal communication, and lack of a unified system highlights the need for a more reliable, data-driven oversight mechanism.

REPRESENTATIVES KEY TASKS

Our taregt audience, the field representatives at Aashirvad, carry out several key tasks throughout a movie's release cycle, each of which plays a crucial role in data collection and revenue tracking.

Our target audience, the field reps at Aashirvad, handle several key tasks across the movie release cycle, each of which is crucial for data collection and revenue tracking.

Morning - Show Charting

> Visit assigned theatres to collect show schedules

> Note number of shows, timings, and screen allocations

> Share show details with the distribution team

> Sets the base for tracking the day’s performance

> Visit assigned theatres to collect show schedules

> Note number of shows, timings, and screen allocations

> Share show details with the distribution team

> Sets the base for tracking the day’s performance

Throughout the Day - Ticket Tracking

> Return to theatres after each show to collect ticket sales data.

> Record tickets sold by seat category (balcony, premium, general, etc.)

> Manage tight schedules, especially when covering multiple theatres

> Return to theatres after each show to collect ticket sales data.

> Record tickets sold by seat category (balcony, premium, general, etc.)

> Manage tight schedules, especially when covering multiple theatres

End of Day - Day Close & DCR Submission

> Fill out the Daily Collection Report (DCR)

> Summarize total tickets sold and gross revenue

> Record the theatre–distributor revenue split

> Include rep’s BATA (daily allowance) details

> Final submission marks official close of daily reporting

> Fill out the Daily Collection Report (DCR)

> Summarize total tickets sold and gross revenue

> Record the theatre–distributor revenue split

> Include rep’s BATA (daily allowance) details

> Final submission marks official close of daily reporting

⚠️ Workflow Challenges

• Reps often juggle multiple theatres and time-sensitive tasks.

• Many are older and familiar with smartphones for communication (e.g., WhatsApp) but not structured app-based systems.

• Their routines are informal, fast paced and unpredictable, with late night follow ups and mid day adjustments.

Any digital solution must respect this organic, real world workflow. If a tool is too rigid or unintuitive, it risks being abandoned, as was the case with the earlier failed MVP.

🚫 Why “Automation” Wasn’t the Answer

At first glance, it may seem logical to bypass field reps entirely and have theatres report data directly to Aashirvad through an automated platform. But in reality, this approach isn’t viable. Field representatives are backed by a strong regional labor union that protects their roles in the distribution process. Any attempt to remove or replace them with technology would meet significant resistance.

The design challenge, therefore, wasn’t to replace reps, it was to build a digital tool that works with them, enhancing their workflow without disrupting their role or pace.

⚠️ Workflow Challenges

• Reps juggle multiple theatres and time-sensitive tasks.

• Many are older, used to WhatsApp-style communication, but not structured apps.

• Routines are fast, informal, and unpredictable, with late-night follow-ups and mid-day changes.

Any solution must adapt to this reality. If it feels rigid or unintuitive, reps will abandon it, just like the earlier failed MVP.

🚫 Why “Automation” Wasn’t the Answer

It might seem easier to have theatres report directly to Aashirvad, but reps are protected by a powerful labor union. Removing them isn’t an option. The challenge wasn’t replacing reps, but designing a tool that supports their workflow while respecting their role.

PAIN POINTS OF PREVIOUS MVP

Before the redesign began, the studio I interned with had already developed a first MVP to digitize Aashirvad’s reporting process. It aimed to replace the reps’ informal workflows (like WhatsApp and phone calls) with a structured reporting app. Despite working technically, the MVP failed in real world testing and was ultimately rolled back. The issue wasn’t functionality, but a mismatch with how reps actually work.

Before this redesign, the studio I interned with had already developed an MVP to digitize Aashirvad’s reporting process. It was meant to replace reps’ informal workflows, like WhatsApp and phone calls, with a structured app. While it worked technically, it failed during real-world testing and was eventually rolled back. The issue wasn’t functionality but the fact that it didn’t align with how reps actually worked.

💡 What We Learned

The original MVP was designed from the outside in, based on assumptions, not embedded understanding. This realisation led us to rethink the system from scratch. We redefined the user flows to include show charting, ticket tracking, on the go editing, show management, and flexible day close options, all based on how reps actually work. Flexibility, adaptability, and realism became the design priorities.

💡 What We Learned

The MVP was designed from the outside in, based on assumptions instead of first-hand understanding. This realization pushed us to rethink the system from scratch. We redefined user flows to include show charting, ticket tracking, on-the-go editing, show management, and flexible day close options, all grounded in the actual routines of field reps. The focus shifted to flexibility, adaptability, and realism.

IDEATION AND WIREFRAMING

After identifying the shortcomings of the initial MVP and mapping out the reps’ daily workflows, we realized the system needed more than just better UI, it needed a more collaborative and flexible structure.

👥 Recognizing the Operator Role

One of the most important insights from MVP testing was the emergence of the operator role, a

support team responsible for monitoring reps, verifying reports, and offering real-time assistance. Although informal during the first rollout, we understood this role would be critical for long-term success.
This led us to design a parallel dashboard for operators, enabling oversight without micromanagement.

After mapping reps’ workflows and critiquing the failed MVP, it became clear the system needed more than better UI, it needed a collaborative, flexible structure.

👥 Recognizing the Operator Role

A key insight from MVP testing was the emergence of the operator role, a support team monitoring reps, verifying reports, and providing real-time help. Though informal at first, this role proved critical for long-term success, leading us to design a parallel operator dashboard.

📊 Mapping the Core Workflow

To understand the interaction between reps and operators, we mapped the system at an event level, rather than screen-by-screen. The core flow looked like this:

1. Show Chartning (rep)

2. Charting Checkpoint (operator)

3. Ticket Entry (rep)

4. Entry Checkpoint (operator)

5. Day Close Submission (rep)

6. Final Checkpoint (operator)

This helped us frame the interdependence between them, especially on high-pressure release days. Here I have provide an example of one of such event flows, show charting:

📊 Mapping the Core Workflow

Instead of screen-by-screen, we mapped the system at an event level:
1. Show Chartning (rep)

2. Charting Checkpoint (operator)

3. Ticket Entry (rep)

4. Entry Checkpoint (operator)

5. Day Close Submission (rep)

6. Final Checkpoint (operator)

This flow highlighted the interdependence between reps and operators, especially on release days.

✏️Wireframing & Layout Exploration

I led multiple iterations of wireframes with three goals:

> Simplify navigation across all three core tasks (charting, entry, day close)

> Keep everything accessible from a single, scrollable screen (minimize clicks)

> Ensure the layout worked intuitively on mobile

We explored modular layouts with a fixed outer frame and adaptive inner content, allowing task-specific views without constant page-switching.

✏️Wireframing & Layout Exploration

I led multiple iterations with three goals:

> Simplify navigation across charting, entry, and day close.

> Keep everything on a single scrollable screen.

> Make the layout intuitive on mobile.

We tested modular layouts with a fixed frame and adaptive inner content, reducing clicks and context-switching.

FINAL UI

🧱 Building the Design System

To ensure consistency and scalability, I created a flexible design system that retained familiar visual cues from the previous MVP, helping returning users feel oriented. It included:

> Color palette, typography, iconography

> Button styles, interaction states

> Reusable components like dropdowns and form fields

This system became the foundation for the final UI.

🧱 Building the Design System

To ensure consistency and scalability, I built a flexible design system that retained familiar cues from the MVP, so returning users felt oriented. It included colors, typography, iconography, button styles, interaction states, and reusable components like dropdowns and form fields.

🤝 Design Reviews & Collaboration

The final designs were refined through multiple review cycles with the CEO (who led workflow decisions) and the dev team. Their input helped align UX decisions with technical feasibility and rollout constraints.

🤝 Design Reviews & Collaboration

The final designs were refined through multiple review cycles with the CEO, who led workflow decisions, and the dev team, who ensured technical feasibility. This collaborative process aligned UX with real-world constraints and became the foundation for the final UI.

1. Log In & Control Panel

> Phone number → OTP login

> Once verified, users land directly on Show Charting

> Persistent top header for task switching (no full-page reloads)

1. Log In & Control Panel

> Phone number → OTP login

> Once verified, users land directly on Show Charting

> Persistent top header for task switching (no full-page reloads)

2. Show Charting

> First screen by default — addresses the biggest gap in the original MVP

> Select screen → Add shows with dropdown time selectors

> Easy editing with delete icons and confirmation popups

> Submits trigger success popups for feedback and trust-building

2. Show Charting

> First screen by default — addresses the biggest gap in the original MVP

> Select screen → Add shows with dropdown time selectors

> Easy editing with delete icons and confirmation popups

> Submits trigger success popups for feedback and trust-building

3. Ticket Sold

> Mirrors the previous MVP, which users liked

> Reps enter ticket counts and editable prices per seat category

> Pulled dynamically based on selected screen and showtimes

> Submissions are confirmed with consistent UI feedback

3. Ticket Sold

> Mirrors the previous MVP, which users liked

> Reps enter ticket counts and editable prices per seat category

> Pulled dynamically based on selected screen and showtimes

> Submissions are confirmed with consistent UI feedback

4. Day Close

> Final step to submit daily financials

> Input BATA, Distributor’s Share %, and Kerala Flood Cess (KFC)

> Submitting locks the data to preserve integrity

> Confirmation screen provides final reassurance

4. Day Close

> Final step to submit daily financials

> Input BATA, Distributor’s Share %, and Kerala Flood Cess (KFC)

> Submitting locks the data to preserve integrity

> Confirmation screen provides final reassurance

TESTING AND FEEDBACK

To validate the redesigned system, the app was tested during the live releases of two films:

🎬 Phase 1: Get Set Baby (Feb 2025)

> Reps used the app alongside manual methods to compare accuracy

> Initial days required hand-holding (calls, clarifications)

> Over time, support requests dropped significantly

> All three core tasks (charting, entry, day close) were completed successfully

Issue observed:

> Reps wanted a summary screen before closing the day

> Some skipped tasks → led to incomplete data

Solutions introduced:

> Validation pop-up to prevent early day close

> Toast messages to explain why edits weren’t saved post submission

> Early A/B testing on UI elements (e.g. summary layout, pop-ups)

To validate the redesigned system, the app was tested during the live releases of two films:

🎬 Phase 1: Get Set Baby (Feb 2025)

> Reps used the app alongside manual methods to compare accuracy

> Initial days required hand-holding (calls, clarifications)

> Over time, support requests dropped significantly

> All three core tasks (charting, entry, day close) were completed successfully

Issue observed:

> Reps wanted a summary screen before closing the day

> Some skipped tasks → led to incomplete data

Solutions introduced:

> Validation pop-up to prevent early day close

> Toast messages to explain why edits weren’t saved post submission

> Early A/B testing on UI elements (e.g. summary layout, pop-ups)

🎬 Phase 2: Thudarum (April 2025)

> Included all updates based on Phase 1 feedback

> New "History" section added for reviewing past entries

> Reps now trusted the system and relied on it as part of their workflow

Reported outcomes:
> Improved accuracy and confidence

> Fewer errors and better traceability

> App data consistently matched manual records, boosted trust

🎬 Phase 2: Thudarum (April 2025)

> Included all updates based on Phase 1 feedback

> New "History" section added for reviewing past entries

> Reps now trusted the system and relied on it as part of their workflow

Reported outcomes:
> Improved accuracy and confidence

> Fewer errors and better traceability

> App data consistently matched manual records, boosted trust

✨WHAT I LEARNT

This was my first real-world project where I saw my designs come to life and be used by actual people, which made the process incredibly meaningful. I learned that great design doesn’t happen in isolation; it requires working with users, not just designing for them. I also realized how important it is to stay flexible, not getting too attached to first ideas and being open to continuous feedback.

Collaborating closely with developers gave me a deeper appreciation for how technical constraints shape design decisions. More than anything, this project taught me how to balance user needs with real world limitations, and that’s something I’ll carry into every project going forward.