Mistakes I made designing mobile UX on unstable Wi-Fi across three countries

When my Figma file failed to sync for the third time at a coworking space in Mexico City, I sat staring at my laptop screen for a long while. Two in the afternoon. The cursor was frozen, and the components in the left panel were stuck as gray boxes, half-loaded. I'd been working on the onboarding flow for an accommodation booking app aimed at Southeast Asian travelers, and ironically, I was designing in the very environment my target users would face: unstable internet.

Something started going wrong from that point on. This is a story about the assumptions I got wrong while designing mobile UX across Mexico, Portugal, and Thailand, and the approaches I'd take differently now.

The Illusion of Being Connected

When I worked in Boston, I always designed on top of a stable internet connection. Whether it was my home Wi-Fi or a café, the connection almost never dropped. So naturally, that assumption seeped into my designs. Every screen in the app was built on the premise of a server response, and the handling for an offline state amounted to nothing more than a single error message. "Please check your internet connection." I thought that one sentence was enough.

Two days of working at a coworking space in Roma Norte shattered that illusion. The Wi-Fi didn't cut out entirely. Instead, it kept cycling through a state where it was technically connected but excruciatingly slow. When I tested the app prototype, the loading spinner would spin endlessly, and users couldn't tell whether the screen was frozen or still loading. The real problem wasn't "no connection" but the middle ground of "connected yet practically useless."

If I were doing it now, I wouldn't divide connection states into just online and offline. I'd design for three separate scenarios: slow connection, intermittent connection, and fully offline. For slow connections especially, instead of a loading indicator, I'd adopt the default approach of showing cached data first and quietly updating it when new data arrives.

Only User-Testing in My Own Environment

After moving to Lisbon, I mostly worked out of a small café near the Alfama district. Lisbon's internet was far more stable than Mexico City's, so I felt confident running user tests. I showed the prototype to four other digital nomads I'd met locally and collected feedback. The results were quite positive. Responses like "the onboarding flow is intuitive" and "the screen transitions are smooth."

The problem was that these tests took place over the café's stable Wi-Fi. On top of that, every single participant was someone like me, using a MacBook and the latest smartphone. The app's actual target audience was backpackers traveling through Southeast Asia, and neither the devices they'd likely use nor their network conditions were reflected at all.

The user testing in Lisbon did nothing except reinforce my confirmation bias. People similar to me, in an environment similar to mine, gave me the feedback I wanted to hear.

If I were doing it now, I'd deliberately degrade the testing environment. I'd set Chrome DevTools' network throttling to "Slow 3G" and, whenever possible, run tests on a budget Android phone from two or three years ago. Instead of a comfortable café in Lisbon, I'd simulate the Wi-Fi in a guesthouse lobby on Bangkok's Khao San Road. I'd also ask actual backpackers to participate rather than digital nomads. People whose phone screens are cracked, whose storage is nearly full, and who have to decide what to delete before installing one more app.

What I Encountered in Thailand

By the time I arrived in Bangkok, I was already one week away from the project deadline. I set up at a coworking space near Silom. The Wi-Fi here was unpredictable. Fine in the morning, then slowing to a crawl around 2 PM when people flooded in. Some days, turning on a VPN killed the connection entirely, and turning it off blocked access to certain services.

This is where I made my most painful mistake. Pressured by the deadline, I put off the offline mode UX with a "we'll polish it later." I skipped the entire design for how to handle data users created while offline. Temporarily saved booking information, search filter settings. I didn't draw out a single flow for how to resolve conflicts between local data and server data when the app came back online.

The result was predictable. When the prototype I delivered to the client was tested in real-world conditions, problems poured in. Favorited accommodations saved while offline disappeared after reconnecting, and hitting the back button on the search results page brought up a blank screen. The client was disappointed, and I had to redesign the offline flow from scratch in my Bangkok accommodation, where the air conditioning barely worked through the humid night.

If I were doing it now, I'd start by designing offline not as an "exception" but as the "default state." I'd first build the structure so that core features work offline, then treat an online connection as a bonus layer for syncing data. This approach is called offline first, and I was already familiar with the concept. I'd just dismissed it with "that doesn't apply to my project."

One more thing. I still remember a brief conversation I had with a Thai developer sitting next to me at the Bangkok coworking space. He offered to take a quick look at my prototype on his phone, so I handed it over. On the very first screen, he asked, "This loading screen, what can the user do here?" Nothing. Just a spinning loader. He smiled and said, "If you open this app on the Bangkok subway, you'll be staring at this screen for a good 30 seconds."

Those 30 seconds are the 30 seconds you lose a user. Something I never would have felt on Boston's stable Wi-Fi.

After the deadline, I returned to Boston and reflected on the project. What I realized was that the mistakes I'd made across three countries all stemmed from a single root. I'd mistaken my own environment for a universal one. I'd unconsciously assumed that my Wi-Fi speed, my device performance, and my usage patterns were the same as my users'. The more a designer's environment differs from the user's, the more deliberately you must test under uncomfortable conditions. I thought being a digital nomad meant I was experiencing diverse environments, but I actually failed to fold those experiences into my designs.

Now, whenever I start a new project, there's one thing I do first. I turn off the Wi-Fi. Then I see how the app looks. That's where the design begins.