What makes a product truly useful?
It’s not the number of features or sleek design, but its ability to solve real user problems. And to understand those problems, dashboards alone won’t cut it—you need to talk to people, observe their actions, and see where the interface helps and where it hinders.
That’s why we use methods like Customer Development and UX testing. The first helps uncover user motivations and context; the second reveals actual usage scenarios before launching new features.
The Intercity team traveled to Morocco to meet inDrive users and test a redesigned form for booking intercity rides. This wasn’t just a business trip—it was a deliberate step toward rethinking an outdated, single-screen solution.
Despite its apparent simplicity, that format caused cognitive overload. On small screens, key fields like date or comments were often hidden behind scrolls, leading users to skip important steps. UX research showed:
Earlier research led us to a step-by-step format: address entry, tariff selection, price setting, and additional details.
“As a product designer, I often see how overloaded interfaces quietly complicate user journeys. We aimed not just to refresh the visuals, but to rethink the whole experience. The step-by-step form helped distribute cognitive load, focus attention, and make the booking process more natural.”
– Sergey Goltsov, Senior Product Designer, Intercity
After prototype testing, we entered the development phase and built a dev version of the new form. With it, the team went to Morocco for final UX testing in conditions close to real use. This was the last step before the A/B test, ensuring the new format truly solved the issues and could be scaled globally.
1. Preparing the Research
Before the trip, we set clear goals: test whether the new step-by-step form met user expectations and identify interface pain points. We were interested in visual perception and real-world behavior.
We focused on three user groups:
- Intercity ride passengers,
- Pool route users,
- Hybrid users coming from other inDrive verticals.
We compiled a list of Morocco’s most active users and scheduled interviews in advance.
The research focused on four key screens:
- Main screen,
- Route selection,
- Tariff selection,
- Final booking screen.
We had hypotheses for each. Would users notice the auto-filled departure point and know how to change it? Would they understand trip types or the “Where to?” button?
On the route screen, we looked at how users interpreted addresses, distinguished between trip formats, and responded to recommended pricing.
The final screen was tested for clarity around price logic, “now” vs. “scheduled” time, the comment field, and error messages for incomplete fields. We also tested the map component, often underused due to its small size.
In Pool mode, we checked if users could manually input prices. In hybrid scenarios, we looked for confusion caused by switching UI formats.
We also involved teams in India and Pakistan, sharing the prototype and research goals to run UX sessions with local users. This gave us valuable cross-cultural feedback to assess the universality of the interface.
2. Conducting Interviews
Each session included a designer, product manager, and business developer, offering multiple perspectives and fast documentation. Our Morocco-based business developer played a key role—coordinating, translating, and solving logistics thanks to his fluency in Arabic, French, and English.
Ramadan brought challenges. We had planned to test Pool rides in real conditions, but demand was low. Evening iftars also limited availability, so all interviews happened during the day. Despite this, we completed four interviews as planned—in Casablanca, Rabat, and Marrakesh—alternating interviews, fieldwork, and travel to better understand real-world usage.
“We had to adjust our plans around Ramadan and local schedules, which made organizing interviews a bit tricky. But the feedback we gathered was very valuable — both from a product perspective and a business one, as it helped uncover some users and drivers issues.”
– Oussama Sabir, BDS Intercity – Morocco
“It was a tough trip to organize. Ramadan made recruiting difficult—users had limited availability during the day, and evenings were off-limits. Without our local bizdev, we wouldn’t have been able to get such high-quality feedback. This showed how crucial local context and trusted partners are.”
– Maxim Sivtsev, Senior Product Manager
Besides scheduled interviews, we conducted impromptu field sessions at train stations in Casablanca and Marrakesh. Local inDrive users were friendly and open—most readily agreed once we explained the purpose. Declines were rare—one due to a train arrival, and some concerns from women about video recording (we clarified we only recorded the phone screen and hand gestures, not faces).
All interviews followed a structured flow. We introduced ourselves, explained the study, and got consent. Participants were then asked to book an intercity trip using the test version of the new form. No instructions were given except for tech-related issues—we wanted to test interface intuitiveness.
After the task, we asked follow-up questions on their impressions, difficulties, and general experience, and participants received a small cash reward. Sessions lasted under an hour. All interactions were recorded, and screen captures saved for analysis.
We conducted interviews in quiet locations—cafés, homes, near cars. Participants varied in behavior: from those who prebook regularly to frequent Pool users. Overlapping scenarios revealed behavior variability and added richness to the findings.
For Arabic speakers, we tested the form in RTL mode with full localization to mimic real use. Most users navigated the form easily. Core tasks were completed without hints—showing the step-by-step format worked well.
However, some hypotheses were only partially confirmed. Users didn’t always notice the “Where to?” button, struggled with recommended pricing, or missed the option to edit the address on the final screen. Some had difficulty manually entering prices or finding fields for scheduling and baggage comments.
We compiled a hypothesis table with updated statuses—some validated, some needing revision, and others passed to backlog or A/B test plans. We also noted extra findings, like:
- Low Pool-order volume,
- Confusion about pickup time when pre-scheduling,
- No bargaining after ride acceptance in Morocco,
- Autocomplete issues.
These insights shaped our next steps and design revisions.
3. Results and Takeaways
Being on the ground gave us firsthand insight into user needs and real constraints. For example, when we tried booking a ride ourselves from Casablanca to Marrakesh, it took over an hour to find a driver.
We also witnessed conflict: a traditional taxi driver blocked our inDrive ride and threatened the driver. Our driver warned us that the “taxi mafia” in Marrakesh doesn’t tolerate ride-hailing and could damage his car. We had to cancel the trip and rebook from a different location.
This incident not only shows the tension between new services and local players but also highlights the need for direct market exposure to understand real dynamics.
Field research revealed that many use inDrive daily to commute between cities. We uncovered several UI pain points:
- Some tried booking intercity rides through the “city” vertical instead of “City to City,”
- Most users relied on auto-filled pickup points and confirmed details via phone,
- The recommended price was treated as a guideline but often adjusted manually,
- 24-hour time format confused some users—they preferred “7 PM” over “19:00,”
- The “Comments” field was only filled when clearly visible.
Despite minor gaps, users were able to complete the booking flow without issue. This proves the new step-by-step form is ready for scaling. Based on these findings, we’ll make final UI tweaks and launch the A/B test to validate performance at scale.
