SehatQ | Centralize Geolocation
SehatQ’s location settings were fragmented across Store, doctor booking, and healthcare-service journeys. I helped design a centralized address experience so users could set, save, and reuse one preferred location across relevant services.
The problem
SehatQ is a health application that offers various features, including doctor booking, hospital or clinic services booking, and pharmacy shopping. To help users find nearby doctors, hospitals, stores, or pharmacies, the application requires users to provide access to their location through GPS or by manually entering their address.
Users who had already set a location in one service were asked to enter it again in another. Some did not know that Store settings controlled nearby doctor and healthcare-service recommendations. In a healthcare context, this inconsistency added friction at the moment users were trying to access care and weakened confidence in the recommendations shown.
Why this mattered
Location was shared product infrastructure, not a Store-only preference. It influenced service discovery, availability, and whether users trusted SehatQ to understand where they needed help.
What we knew
User complaints and an audit of the existing journey showed separate entry points, unclear dependencies, and repeated setup. The address could only be configured inside Store and saved during checkout, while other services depended on that hidden state.
Core insight: Users should not have to understand SehatQ’s internal product boundaries to manage one real-world location.
Design challenge
How might we create one understandable location experience across SehatQ services, while accommodating existing product flows and data that were not yet synchronized?
The fragmented experience
Our current address management condition is quite complicated. Users can only set their address within the Store product. To save their address, users can only do so when they reach the checkout page. However, for other products such as doctor booking and hospital services, all address settings rely on the settings in the Store product.
Unfortunately, this inconsistency flow make our user confuse and not all users are aware that they need to set their address in the Store to find nearby doctors or healthcare facilities. Let's take a look at the following simplified journey diagram.
This the previous journey of the geolocation feature
Learning from comparable products
The design argument
The design direction treated location as a shared platform capability. The goal was not simply to add another address screen, but to create a consistent mental model across services: set a location once, see where it applies, and change it without hunting through Store.
Create a shared location state. Once selected, the active address remained available when users moved between Store, doctor booking, and healthcare-service journeys. This required cross-service coordination and a phased delivery plan.
Three decisions that shaped the solution
1. Make the active location visible and contextual
The design shows the active address within the relevant service journey, making the location used for nearby recommendations visible. Users can access location settings from that context instead of having to find them inside Store.
2. Offer flexible ways to set a location
The address-management flow lets users save and manage multiple addresses without reaching Store checkout. Saved addresses can be reused across relevant services, with the aim of reducing repeated address entry.
3. Let users save and manage multiple addresses
Each entry point used the same predictable interaction model: show the current address, explain its effect on the service, and let users change or save it without navigating through Store checkout.
Validation
Before release, we tested the proposed application flow with approximately 12 active SehatQ users. A UX Researcher led the scenarios and sessions, while I supported the study, observed how participants completed the tasks, and used the findings to refine the design. Participants followed several scenarios involving finding the feature, setting or changing an address, and managing saved addresses. The recorded findings were:
of the respondents liked the new design, which was perceived as more comfortable to use.
respondents found it easy to locate the feature and determine the address they wanted to input.
respondents understood how to change their address and save multiple addresses.
Furthermore, the collaboration among teams or "tribes" also played a crucial role in the success of this project. Through brainstorming sessions to determine the timeline, division into multiple phases, and providing feedback to each other, team collaboration became a key aspect.
Outcome and reflection
The centralized location changes were released. Although no formal post-launch metric was available, the team observed fewer reviews and feedback mentioning confusion about location and address management. Because this was not measured against a defined baseline and evaluation period, I treat it as a directional qualitative signal rather than a quantified product outcome.
Reflection: The strongest move was treating location as shared infrastructure rather than a Store setting. The work also reinforced the importance of aligning interaction design with shared data and dependencies across services.
