Why the Parking App Became a Hangang Visit App

Parking was the starting point for Hangangjari, but few people decide whether to go to the Han River by looking only at parking.

At first, I thought solving the parking problem would be enough. Once I actually opened the app while preparing to go, other questions followed that remaining-space counts could not answer.

Even if I can take the car, I may change destinations if today’s event is too large. If there is a notice, another park may be the better choice. On days when I go by public transit, congestion and the locations of facilities matter before parking information.

• Are there events today?
• Is it crowded?
• Where are the restrooms and convenience stores?
• Are there announced controls or facility closures?
• If I go without a car, which station or stop should I use?

People who often visit the Han River tend to look up this information across several apps and websites by habit. But even Korean visitors can get confused when going to an unfamiliar park. For foreign tourists, the experience is even less friendly.

Search for “Hangang Park” and it can look like one place. In reality, Yeouido, Banpo, Ttukseom, Mangwon, and Jamsil differ in access, atmosphere, and crowd levels.

More importantly, people use the Han River in different ways.

For someone driving, remaining parking spaces and navigation matter. For someone arriving by public transit, park congestion, events, facilities, walking routes, and nearby points matter more than parking. A picnic with children, a bike ride, an evening walk, and an event visit all produce slightly different questions before leaving and after arriving.

That is why Hangangjari changed from a parking app into an app for choosing a Hangang park and finding what is needed after arrival. This was not about adding more features for their own sake. Following the questions users actually ask changed what needed to be placed near the front of the screen.

Inside the app, I split the experience into two screens based on the user’s question.

• Car screen: parking status, hourly parking changes, navigation, notifications
• General screen: park congestion, events, facilities, notices, public transit and walking directions, nearby facility search

Both screens deal with the same parks, but they start from different questions.

Screen	First question to answer	Information placed first
Car screen	Can I take the car right now?	Parking status, recommended candidates, navigation, notifications
General screen	Is this park a good choice today, and what can I find nearby?	Congestion, events, facilities, notices, public transit

Without separating the two screens, the interface grows too easily. Show parking, events, facilities, and notices all together, and the user returns to the same question: “So where should I go now?” Even after Hangangjari expanded, the important test was not how much information it contained, but whether it helped people choose and find things quickly.

The app showed more, but the direction stayed narrow. It put only the information needed immediately before and after a visit up front, and moved the rest behind it.

At one point, I also considered a much broader direction, such as a nationwide park outing app. At launch, I returned to the Han River. It was the place I knew best, the data sources were verifiable, and the problem was one I actually used.

For the first public version, I chose an app people could trust inside the Han River area over an app that only looked broader.

I asked again before adding features

While widening the parking app into an outing app, adding features recklessly would have made it scattered quickly. So before adding new information, I first asked whether it really helped before going to the Han River or while being there.

Events can become a reason to visit. Notices and control information reduce wasted trips. Facility information reduces wandering on-site. Congestion and weather help choose which park is better today.

On the other hand, polished introductory copy and general tourist information could look important, but I postponed them for the first release. Helping people choose quickly mattered more than increasing the amount of information.

This question also helped split the car screen and general screen. On the car screen, parking is the center. On the general screen, the situation of the park itself and what can be found there are the center. Even for the same Hangang park, the user’s question is different, so forcing everything into one screen would make it insufficient for both sides.

As the amount of possible information grew, I had to ask “what will help someone decide and find things faster?” before asking “what else can I add?” If that order is lost, a screen may look rich while making users hesitate and wander longer.

Each source updated at a different speed

At first, I thought I could simply connect official sources when they existed. In practice, each source had different quality and meaning. Some data updated often but had rough fields. Some was stable but slow for a pre-visit decision. Some existed in official lists but lacked enough explanation to show directly on screen.

Parking, events, notices, facilities, and real-time congestion all move at different speeds. They need different collection cycles, display methods, and failure messages.

For example, missing parking availability and missing event information mean different things. Missing parking availability shakes the decision to bring the car. Missing event information is closer to not finding an event that could become today’s purpose.

If both are displayed as the same “no information,” the screen becomes simpler, but the user leaves in a more uncertain state.

App copy has to be a promise I can keep

The thing I was most careful about during this process was wording. “Accurate Hangang information” is easy to say, but it is a large promise for an independent app that gathers public data.

“Helping people make decisions before and during a Hangang visit based on official public information” was more honest.

The way an app is described also becomes a development boundary. If I do not decide what can be shown, which values are only references, and how stale values should be described, the screen and API keep drifting.

Hangangjari is not an official app, so it should not speak more definitively than it can. The more independent the app is, the more carefully it has to separate what it knows from what it does not.

Only after that line was drawn did the public-data handling become clearer. The important part was not just whether data existed, but how confidently it could be shown.

I put update time and source next to the numbers

A public-data app looks simple at first: fetch data and show it. The harder part comes after that.

The hardest question was, “How much can I trust and show this information?”

Remaining parking spaces look like a number. Numbers feel definitive. But users may drive based on that number. Even if the app says 20 spaces remain, the situation may change before they arrive. A specific parking lot may update late, or an event or control may make operations different from usual.

So showing only a large number was risky. Remaining spaces needed to be shown with status, updated time, source, and hourly changes. Labels such as “available,” “normal,” “crowded,” and “full” should not replace the number as an answer; they should help users interpret the number.

Events and facilities were similar. There were usable official sources such as event and performance information from the Future Hangang Headquarters, Hangang news, announcements, facility data, and Seoul real-time city data. But each source had a different use and update cycle. Some were event lists, some were operational notices, and some were closer to current congestion or weather.

So the server did not mix sources into one lump. It separated them by how the screen needed to use them.

• Parking: remaining spaces and status needed to decide whether to bring the car now
• Real-time context: park congestion, weather, road conditions
• Events/programs: official schedules that can become a reason to visit
• Notices: operational changes, controls, and facility closures that can cause wasted trips
• Facilities: restrooms, stores, parking lots, and access points people look for on-site

Through this process, one standard emerged.

Do not claim to know everything. Show what is known and what is unknown separately.

Hangangjari is not an official app or an officially partnered app. It is an independent app that gathers public data and official information in a more readable form. That makes it even more important to show sources and limits together. This idea later influenced prediction, caching, localization, notifications, and incident response.

Looking back, expanding Hangangjari did not mean doing more things. It meant following the questions people actually ask before and during a Hangang visit, while honestly showing only what the app can answer. Once that boundary existed, parking, events, notices, and facilities stopped fighting each other on the same screen.