Designing eLearning for a Workforce Where 60 Percent of Learners Access Training on a Two-Year-Old Android Phone

Your eLearning module looks outstanding on the MacBook Pro in your Mumbai office.

It loads in under three seconds. The animations are smooth. The branching interactions respond instantly. The video plays without buffering. Your team reviews it, approves it, and releases it with confidence.

Two weeks later, the completion data arrives. Your frontline workforce in Nagpur, Patna, and Coimbatore is showing 23 percent completion. The drop-off happens within the first 60 seconds of every session. Learner feedback, where it exists at all, says some variation of the same thing: it does not load properly on my phone.

This is not an unusual story. It is, in fact, the most predictable outcome of a development process that builds eLearning on high-specification hardware and then deploys it to learners whose actual device is a two-year-old Redmi or Samsung Galaxy A-series phone running Android 10, with 2GB of RAM, intermittent 4G connectivity, and 4GB of free storage shared between twelve apps.

The gap between where eLearning is developed and where it is experienced by the majority of India’s working learner population is one of the most significant and consistently ignored design problems in corporate L&D.

This guide closes that gap.

The Scale of the Device Reality Problem in Indian Corporate L&D

Before designing for this reality, L&D teams need to understand it precisely because the gap between assumed device profile and actual device profile in most Indian organisations is substantially larger than most teams recognise.

The device distribution reality:

India’s smartphone market is dominated by budget and mid-range Android devices. As of the most recent available data, the majority of smartphones in use in India are Android devices priced below ₹15,000. These devices share a consistent set of hardware characteristics: 2GB to 4GB of RAM, octa-core processors with limited sustained performance, internal storage of 32GB to 64GB shared across the operating system, apps, media, and any downloaded content, and screens ranging from 5.5 to 6.5 inches at 720p to 1080p resolution.

These are not inadequate devices by the standards of their price segment. They are capable smartphones that handle messaging, social media, video consumption, and digital payments effectively. However, they are significantly less capable of running complex SCORM packages, rendering heavy JavaScript interactions, streaming high-resolution video, and processing the kind of layered animation that eLearning developers design on desktop authoring tools.

The connectivity reality:

India’s 4G network coverage is extensive but inconsistent in quality. A learner in an urban centre may have reliable 30Mbps 4G. The same learner’s colleague in a semi-urban area may have 2-5Mbps connectivity with significant packet loss during peak hours. A field sales representative moving between locations throughout the day will experience connectivity that varies from reliable broadband to effectively no signal depending on their location at any given moment.

Furthermore, many frontline workers and field staff are acutely data-conscious. Mobile data is a monthly expense they manage carefully. An eLearning module that consumes 100MB of data to complete is not just slow, it is a financial burden that learners will consciously avoid.

The usage context reality:

Frontline workers, field sales representatives, warehouse staff, and manufacturing supervisors, the segments of India’s workforce most likely to be accessing training on budget Android devices are also the segments least likely to have quiet, dedicated time for learning. Training happens in the margins of the working day: during a break between customer visits, while waiting for a shift briefing, on a commute. Sessions are short and frequently interrupted. Content that requires sustained, uninterrupted attention fails not just because of device limitations but because the usage context does not support it.

Why Standard eLearning Development Processes Produce Mobile-Hostile Content

Understanding why current development practices consistently produce content that fails on budget Android devices requires examining where the failure is introduced in the process.

Failure point 1: Development hardware.

eLearning is almost universally developed on desktop or laptop computers typically high-specification machines with dedicated graphics, 16GB or more of RAM, fast SSD storage, and reliable broadband connectivity. Authoring tools render content in this environment, and developers experience the module in this environment. The performance they experience during development is genuinely representative of the performance a MacBook user will experience. It is entirely unrepresentative of the performance a Redmi user will experience.

Failure point 2: Authoring tool defaults.

Most eLearning authoring tools — Articulate Storyline, Adobe Captivate, iSpring and others, have default output settings calibrated for desktop delivery. HTML5 output from these tools is functional on mobile browsers but is not optimised for low-specification mobile hardware. JavaScript interactions that run smoothly on a desktop processor run sluggishly on a budget mobile processor. Animations that are seamless on a high-refresh-rate laptop screen drop frames on a budget phone display. High-resolution images that load instantly on a broadband connection load slowly on 4G.

Failure point 3: Testing on representative devices.

The most reliable predictor of mobile eLearning performance failure is the absence of testing on the actual devices the learner population uses. Most L&D teams test mobile compatibility by opening the module in a desktop browser’s device emulation mode, which simulates screen size and touch interaction but does not simulate the processing constraints of a budget Android device. Others test on an iPhone or a recent-generation Android device, which is significantly more capable than the two-year-old budget devices used by the majority of their learner population.

Failure point 4: Performance metrics tracked incorrectly.

Completion rates and time-on-module metrics that come from LMS reporting do not distinguish between learners who completed the module and learners who abandoned it at 60 seconds because it failed to load. Many platforms record a partial attempt or no attempt at all for learners who were dropped by loading failures, making the performance problem invisible in the data until someone looks closely at the distribution of completion events.

The Complete Design Framework for Low-Specification Android Delivery

The following framework addresses every dimension of eLearning design that affects performance on budget Android devices, from content architecture through technical production to testing and deployment.

Dimension 1: Content Architecture — Design for the Interrupted Session

The first design principle for low-specification Android delivery is not technical, it is structural. Content must be architected for the reality of how these learners will actually engage with it.

Segment ruthlessly:

No module delivered to a predominantly mobile learner population should exceed seven minutes of content. For frontline and field workforces, five minutes is a more realistic upper limit for a single uninterrupted session. This is not a compromise on learning quality, it is a design constraint that forces the kind of focused, single-objective content architecture that produces better learning outcomes than longer, topic-surveying modules.

Each five to seven-minute module should address one learning objective. One concept. One skill application. One decision scenario. Nothing more.

Design for save-and-resume at the screen level:

Learners on budget Android devices in variable connectivity environments will be interrupted. The phone call arrives. The supervisor needs them. The bus reaches their stop. The module closes.

Design every module so that progress is saved at the screen level, not at the module level. A learner who completes the first three screens of a seven-screen module and is interrupted should return to screen four. A learner who must restart the entire module because their session was interrupted will frequently not restart at all.

Front-load the value:

The first 20 seconds of any mobile module must deliver enough value or enough engagement that the learner commits to continuing. If the first 20 seconds are a logo animation, a welcome screen, and a list of learning objectives, learners on low-specification devices who are also managing interruptions will abandon before the learning begins.

Open with the specific situation the module addresses. Open with the decision the learner will practise. Open with the professional consequence the module is designed to prevent. Make the relevance immediate.

Remove everything that is not essential:

Every element on every screen of a mobile module should survive this test: does this element directly serve the learning objective of this screen? If the answer is anything other than a clear yes, remove it. Decorative animation, supplementary visual detail, contextual background information that does not change the learning outcome, all of it adds to page weight, processing demand, and cognitive load without adding to learning value.

Dimension 2: Visual Design — Optimise for Small Screens and Low Processing Power

Design at mobile resolution from the beginning:

Do not design at desktop resolution and adapt for mobile. Design at 360×640 pixels, the most common resolution for budget Android devices, from the first screen. Every visual decision should be made at this resolution. Text size, button dimensions, image placement, and interactive element spacing all need to be calibrated for a screen this size in the hands of a learner who is navigating with their thumb.

Text size non-negotiables:

Body text must be a minimum of 16 pixels and 18 pixels is safer for learners whose device display settings may be non-default. Heading text must be visually distinct from body text without relying on subtle size differences that disappear on a small screen. Never use text smaller than 14 pixels for any content element, including captions, labels, and instructional text.

Button and interactive element sizing:

Every tappable element must be at least 44×44 pixels, the minimum touch target size recommended by both Apple and Google human interface guidelines. Smaller targets produce missed taps, accidental activations, and learner frustration that has nothing to do with the content.

Limit simultaneous on-screen elements:

A budget Android device rendering multiple simultaneous animated elements, a character, a background, a progress bar, animated text reveals, and an audio waveform, is a device under significant processing stress. Limit simultaneous animated elements to two per screen. Prefer sequential reveals over simultaneous animations.

Use flat design over gradient-heavy rendering:

Gradient fills, complex drop shadows, and multi-layer visual effects require significantly more rendering power than flat colour design. Flat, clean visual design is not a style compromise on mobile, it is a performance decision. It also improves readability at small screen sizes.

Scale images appropriately:

A 2000×1500 pixel image scaled down to display at 300×225 pixels on a mobile screen is still a 2000×1500 pixel image that the device must download and process. Export every image at the size it will actually be displayed, not at the highest available resolution. A mobile screen displaying an image at 300 pixels wide does not benefit from a source image wider than 600 pixels.

Dimension 3: Media Optimisation — The Non-Negotiable Technical Decisions

This is the dimension where most mobile eLearning performance problems originate and where the most impactful improvements can be made without changing a single instructional design decision.

Video:

Video is the single largest contributor to mobile eLearning page weight and the primary cause of loading failures on limited connectivity.

For mobile-primary delivery, the following video specifications are non-negotiable:

• Maximum resolution: 720p (1280×720). 1080p is unnecessary on a budget Android screen and doubles the file size without any visible quality improvement.
• Encoding: H.264 (MP4). This is supported across all Android devices and produces the best quality-to-file-size ratio for this use case.
• Bitrate: 500-800 kbps for 720p video. This produces acceptable quality on a mobile screen while keeping file size manageable.
• Maximum video length within a module: 3 minutes for a single clip. Longer videos should be broken into shorter segments.
• Captioning: mandatory, embedded, not as a separate file. Many learners watch videos without audio in shared or noisy environments.
• Offline availability: video must be available for download for offline viewing. Streaming-only video excludes learners with unreliable connectivity.

Audio:

Audio narration is typically a much smaller contributor to file size than video, but it still requires optimisation for mobile delivery.

• Format: MP3 at 128 kbps for narration. This produces clear speech audio at a file size that does not create loading problems.
• Provide a transcript: not just as an accessibility measure but as a practical alternative for learners who cannot use audio in their current context.
• Make audio optional: never require audio for module completion. A learner without earphones in a shared workspace should be able to complete the module through text and visual content alone.

Images:

• Format: JPEG for photographic content at 75-80% quality. PNG for graphics with transparency or text. WebP where the target Android version supports it.
• Maximum file size per image: 150KB for background images, 80KB for content images, 40KB for icons and small graphic elements.
• Total image payload per screen: aim for under 300KB per screen.

Animations:

• Prefer CSS animations over JavaScript animations for simple transitions, CSS animations are processed by the GPU rather than the CPU on most Android devices, producing smoother performance.
• Limit GIF use entirely, GIFs are memory-intensive and produce poor performance on budget Android. Use CSS or Lottie animations instead.
• Every animation must have a clear instructional purpose. If removing the animation does not change what the learner learns, remove it.

Total module file size:

A mobile eLearning module intended for a budget Android learner population should target a total published file size of under 5MB for a five to seven-minute module without embedded video, and under 20MB for a module with one or two short video segments. These targets require deliberate optimisation at every production stage, they will not be achieved by default authoring tool output settings.

Dimension 4: Offline Functionality — Making It Non-Optional

For any learner population where connectivity is variable or data is a cost concern, offline functionality is not a feature enhancement. It is a prerequisite for meaningful training delivery.

What genuine offline functionality requires:

A module is not offline-capable because it can be opened in a browser without a live connection. It is offline-capable when:

• All content including media, downloads completely to the device before the learner begins
• Progress and assessment data is stored locally on the device when no connection is available
• Progress and assessment data syncs automatically to the LMS when connectivity is restored
• The sync process is invisible to the learner, they do not need to manually trigger it or be online at the moment of completion

How to achieve this:

Progressive Web App (PWA) architecture with service worker implementation enables offline caching and background sync for web-based eLearning. Dedicated mobile app delivery with embedded SCORM or xAPI handling enables the same for app-based LMS deployment. Both require technical implementation that goes beyond standard SCORM package publishing, but both are achievable within current authoring and LMS capabilities.

At minimum, for organisations that cannot implement full offline functionality immediately, design modules to load completely before the learner begins, rather than loading content progressively as the learner advances. A learner who loads the module on Wi-Fi before leaving the office and then completes it on a bus without connectivity should be able to do so if the module has fully loaded.

Storage management:

Budget Android devices have limited available storage. Design offline-available modules with storage consumption in mind. Provide learners with clear information about download size before they initiate a download. Allow learners to delete downloaded modules after completion. Design module libraries with selective download capability, so learners can download what they need for the current period without filling their device storage.

Dimension 5: Navigation and Interaction — Designing for Thumb Use

Every interaction in a mobile eLearning module is a thumb interaction. This is not a trivial observation. The ergonomics of thumb navigation on a 6-inch screen in portrait orientation place the comfortable touch zone in the lower two-thirds of the screen, with the upper corners and edges being the hardest areas for one-handed thumb navigation.

Navigation placement:

Place all primary navigation controls — Next, Back, Menu, Submit, in the lower portion of the screen within comfortable thumb reach. Never place critical interactive elements in the upper corners of the screen.

Swipe versus tap:

Swipe gestures for page navigation are natural on mobile, but they conflict with the natural scrolling gesture when content extends below the visible screen. Choose one or the other for a given module and be consistent. If the module uses swipe for page navigation, design every screen to fit within one screen height. If the module uses tap-based navigation, swipe can be used for scrolling long-form content.

Form inputs:

Minimise text input requirements on mobile. If assessment requires text input, limit fields to short responses. Ensure that all text input fields are tall enough to be tapped without accidental adjacent element activation. Specify the correct keyboard type for each input field, numeric keyboard for number inputs, standard keyboard for text, so the device does not require the learner to switch manually.

Touch feedback:

Every interactive element must provide immediate visual feedback when tapped, a colour change, a subtle scale animation, a border highlight. On a device that may take 200-400 milliseconds to register a tap response due to processing constraints, visual feedback that confirms the tap was registered prevents double-tapping and learner frustration.

Dimension 6: Testing Protocol — The Devices You Must Test On

The most important rule for mobile eLearning testing is simple and almost universally ignored: test on the actual devices your learners use.

Build a device testing library:

Every organisation deploying eLearning to a predominantly mobile learner population should maintain a small library of the actual device models used by that population. For most Indian corporate L&D teams, this means acquiring and maintaining:

• A current-year budget Redmi or Realme device (representative of the newest budget devices)
• A two-year-old Samsung Galaxy A-series device (representative of the mid-tier of the learner population)
• A three-year-old budget Android device with 2GB RAM (representative of the lower end of the learner population)

These three devices cover the realistic distribution of the learner hardware profile. Every module must be tested to completion on each device before release.

Connectivity simulation testing:

Test every module under simulated real-world connectivity conditions:

• Full 4G (simulated at 15Mbps): represents best-case connectivity
• Moderate 4G (simulated at 5Mbps): represents typical connectivity in semi-urban areas
• Poor connectivity (simulated at 1Mbps with 200ms latency): represents variable connectivity during field use
• Offline: complete the module after loading on a Wi-Fi connection, then switch to flight mode

Most desktop browsers support network throttling in developer tools, but this simulation does not replicate the full performance constraints of a budget Android device. Test on actual devices with actual connectivity whenever possible.

Performance benchmarks:

For every module released to a predominantly mobile learner population, establish and track these performance benchmarks:

• Time to first meaningful content on 5Mbps 4G: target under 5 seconds
• Time to full module load on 5Mbps 4G: target under 15 seconds
• Module file size: target under 5MB without video, under 20MB with video
• Completion rate on budget Android devices: compare against desktop completion rate as a quality signal

Practical Toolkit: What to Do in Your Authoring Tool Right Now

For teams using standard authoring tools, the following practical interventions produce immediate performance improvements on budget Android devices.

In Articulate Storyline:

• Publish to HTML5 only, Flash output is unsupported and modern HTML5 output is more efficiently optimised
• Reduce the slide dimensions to 720×1280 for portrait mobile or design responsive using Articulate Rise instead
• In publishing settings, compress media using the built-in compressor and then further compress images manually before importing
• Disable all unnecessary slide transitions, fade transitions add processing overhead that budget Android handles poorly
• Limit the number of objects animated simultaneously on any slide to two

In Articulate Rise:

• Rise outputs inherently responsive content that performs better on mobile than Storyline by default
• Use Rise’s built-in media compression on all video uploads
• Limit the number of interactive blocks per lesson, knowledge check blocks perform better than complex interactive content blocks on budget Android
• Use continue blocks strategically to enforce completion of each section before loading the next, this prevents devices from attempting to load all content simultaneously

In Adobe Captivate:

• Use the responsive project type rather than the blank project type for any mobile-targeted module
• Enable the HTML5 tracker rather than SCORM for modules where the LMS supports it — it produces lighter output
• Compress all images to JPEG at 75% quality before importing
• Disable slide preloader animations

Key Takeaways

Designing eLearning for a workforce where the majority of learners access training on a budget Android phone is not a technical challenge with a single solution. It is a design philosophy that must pervade every decision from content architecture through visual design, media production, interaction design, and testing protocol.

The learners who access training on two-year-old Redmi phones are not edge cases to be accommodated. In most Indian corporate L&D contexts, they are the majority. Designing for the MacBook Pro and hoping it works on the Redmi is not a strategy, it is a guarantee of the 23 percent completion rate that arrives two weeks after a confident release.

The design principles in this guide, ruthless content segmentation, mobile-resolution visual design, aggressive media optimisation, genuine offline functionality, ergonomic interaction design, and representative device testing, are not advanced or experimental. They are the foundational requirements for eLearning that actually works for the learners it is supposed to serve.

Build for the device in the learner’s hand. Everything else follows from that.

Build eLearning That Works for Your Entire Workforce, Not Just Your Headquarters — Partner With Learning Owl

At Learning Owl, we design and develop eLearning with the actual device profile of the target learner population as a primary design constraint, not an afterthought. Our mobile eLearning development process includes device profile analysis, representative device testing at every production milestone, media optimisation to defined file size targets, and offline functionality architecture for learner populations with variable connectivity.

Our mobile eLearning services include mobile-first eLearning development for frontline and field workforces, budget Android device optimisation for existing eLearning libraries, offline-capable module development, microlearning development for interrupted-session learning contexts, multilingual mobile eLearning in Hindi and major Indian regional languages, and full eLearning development for pan-India deployment across diverse device profiles.

Whether you are building a new training programme for a field sales force, redesigning content that is failing on your frontline workforce’s devices, or developing a mobile learning strategy for an organisation where the majority of learners are not at a desk, Learning Owl builds eLearning that works where your learners actually are.

Because eLearning that does not load is not eLearning. It is a completion problem waiting to be discovered.

Frequently Asked Questions About Mobile eLearning for Budget Android Devices

Q1. Why does eLearning that works on desktop fail on budget Android phones?

eLearning that works on desktop fails on budget Android phones because desktop and budget Android devices have fundamentally different hardware capabilities. A typical development desktop or laptop has 16GB or more of RAM, a dedicated GPU, a fast-multi-core processor, and SSD storage. A budget Android phone has 2-3GB of RAM, no dedicated GPU, a lower-performance processor, and slower flash storage. Complex JavaScript interactions, layered animations, high-resolution images, and streaming video that run smoothly on desktop hardware exceed the processing and memory capacity of budget Android hardware, producing slow loading, dropped frames, and in severe cases, browser crashes. Additionally, mobile connectivity is typically slower and more variable than the broadband connection used during development, compounding the performance problem.

Q2. What is the target file size for a mobile eLearning module designed for budget Android devices?

A mobile eLearning module designed for budget Android devices should target a total published file size of under 5MB for a five to seven-minute module without embedded video, and under 20MB for a module including one or two short optimised video segments. These targets require deliberate optimisation at every production stage. Images should be exported at display resolution rather than native resolution. Video should be encoded at 720p with a bitrate of 500-800 kbps. Audio should be compressed to MP3 at 128 kbps. Animations should be implemented in CSS rather than JavaScript where possible. These targets will not be achieved by default authoring tool output settings, they require active optimisation decisions throughout production.

Q3. How do you implement genuine offline functionality in mobile eLearning?

Genuine offline functionality in mobile eLearning requires more than simply designing content that can be opened in a browser without a live connection. It requires complete content download to the device before the learner begins, including all media files, local storage of progress and assessment data when no connection is available, and automatic background sync of that data to the LMS when connectivity is restored. This is achievable through Progressive Web App architecture with service worker implementation for web-based delivery, or through dedicated mobile app delivery with embedded SCORM or xAPI handling for LMS-connected deployment. Both approaches require technical implementation beyond standard SCORM package publishing but are within current capability for most eLearning development teams and LMS platforms.

Q4. How should you test eLearning performance on budget Android devices?

The most reliable way to test eLearning performance on budget Android devices is to test on the actual devices your learner population uses, not on device emulators in a desktop browser. Organisations deploying eLearning to predominantly mobile learner populations should maintain a small testing device library that includes current-year budget devices, two-year-old mid-tier budget devices, and three-year-old lower-end budget devices representative of the realistic distribution of their learner population. Each module must be tested to completion on each device type before release, under simulated real-world connectivity conditions including moderate 4G, poor connectivity, and offline after initial loading. Desktop browser device emulation simulates screen size but does not replicate the processing constraints that determine actual performance on budget hardware.

Q5. What authoring tool settings most improve mobile eLearning performance on budget Android devices?

The authoring tool settings that most significantly improve mobile eLearning performance on budget Android devices include publishing to HTML5 only with no legacy Flash output, designing at mobile resolution from the start rather than scaling down from desktop dimensions, using the built-in media compression tools and then applying additional manual compression to all images before import, limiting simultaneous animated objects to two per screen, disabling unnecessary slide transition animations, and for Articulate users specifically, using Rise for modules with predominantly linear content as it produces inherently more mobile-optimised output than Storyline for these use cases. Beyond authoring tool settings, manually compressing all images to display resolution and encoding all video to 720p at 500-800 kbps before importing into the authoring tool produces greater performance improvements than any combination of in-tool settings alone.

Q6. How do you design eLearning navigation for thumb use on a mobile phone screen?

Designing eLearning navigation for thumb use requires placing all primary navigation controls, including Next, Back, Menu, and Submit, in the lower portion of the screen within comfortable one-handed thumb reach. Avoid placing critical interactive elements in the upper corners and edges of the screen, where they are harder to reach with a thumb. All tappable elements must be at least 44×44 pixels to prevent missed taps and accidental activations. The navigation model should remain consistent throughout the module, using either swipe-based or tap-based navigation, not both. It should also avoid conflicts with the natural scrolling gesture for long-form content. Every interactive element must provide immediate visual feedback when tapped, such as a colour change or brief animation. Budget Android devices may take 200–400 milliseconds to register a tap response, so feedback that confirms the tap prevents double-tapping and learner frustration.

Q7. What completion rate gap should L&D teams expect between desktop and budget Android users for standard eLearning?

L&D teams deploying standard, unoptimised eLearning to learner populations who access training on budget Android devices typically observe completion rates 30–50 percentage points lower among mobile learners than desktop learners, depending on the content’s complexity, media weight, and interaction design. A module that reaches 85 percent completion among desktop users frequently reaches only 40–55 percent among budget Android users accessing the same content. The gap is widest for modules with streaming video, complex JavaScript interactions, and large total file sizes. However, the gap narrows significantly, often to under 10 percentage points, when teams specifically design and optimise content for budget Android delivery using the principles in this guide. Therefore, tracking completion rates separately by device type is one of the most informative signals available for diagnosing mobile eLearning performance problems.

Q8. Is microlearning always the right format for budget Android learners?

Microlearning modules of three to seven minutes, addressing a single learning objective, are the most appropriate format for budget Android learners in most corporate training contexts. However, they are not universally superior regardless of the learning objective. They are most appropriate when the learning objective involves focused knowledge application, a specific procedure, or a discrete decision scenario. This content can be meaningfully addressed in a short, focused interaction. They are less appropriate for learning objectives that require the learner to develop judgment across a complex, multi-faceted situation. Such objectives may require longer sustained engagement, even when delivered on a mobile device. In these cases, the right approach is not to force the content into a five-minute module. Instead, segment it into a carefully sequenced series of five-minute modules that build on each other. This approach maintains the performance advantages of short individual modules while serving the depth of the learning objective.

The NEP 2020 Competency Framework: What It Means for K-12 Digital Content Developers in Practice

The National Education Policy 2020 has been analysed extensively. Education researchers have written about its vision. Policy commentators have assessed its ambition. State governments have published implementation roadmaps. EdTech platforms…

eLearning Outsourcing Risks: 6 Pitfalls to Avoid Before You Sign a Vendor

Handing your training projects to an external team sounds like an easy win. You get faster delivery, access to specialists, and a lighter load on your internal team. But many…

Designing eLearning for a Workforce Where 60 Percent of Learners Access Training on a Two-Year-Old Android Phone

Your eLearning module looks outstanding on the MacBook Pro in your Mumbai office. It loads in under three seconds. The animations are smooth. The branching interactions respond instantly. The video…