The Widget Was Not a Smaller Version of the App

Hangangjari treated widgets as important from the beginning. Still, before building one, I thought of the widget as an add-on beside the app.

Open the app for details, look at the widget for a quick summary. Pick one favorite park and check it quickly from the home screen.

Once I started using it, my thinking changed.

Use had already begun before the app opened. A user sees a number while passing the home screen, sees a state on the lock screen, and checks again before picking up the car key. If the widget is ambiguous at that moment, the user is more likely to look elsewhere than open the app.

The decision to go to the Han River is not made after opening the app. Before leaving home, before holding the car key, while waiting for the elevator, or while glancing at the lock screen or home screen, the decision has already started to lean one way.

That moment does not need much information.

Is this park okay today? Can I take the car? Can the parking lot handle it right now? Are there event or congestion signals? Is the information stale?

Inside the app, I can show a lot. In the moment before leaving, the screen has to help with a glance. That is why the widget had to be a surface checked first outside the app, not a tiny app screen.

A widget is not always the newest screen

When I started taking widgets seriously, the first thing I had to accept was that a widget is not always real time. iOS widgets refresh within system policy. They are not screens the app can redraw whenever it wants.

If I treat a widget like a real-time dashboard that always shows the current server value, the design becomes unstable. The widget should help users make a quick decision from the last confirmed snapshot, say when values are old, and lead naturally into the app when users want to check more.

Accepting this premise changed the UI copy. I became careful with the word “real time” and treated updated time as more important. For a widget to earn trust, it should not pretend to always be current. It should be honest about when the displayed value was confirmed.

The widget kept only glanceable values

Most of the widget work was not adding information. It was removing it.

The general mode widget kept only information that answers “Is this park worth going to today?”, such as congestion, weather, fine dust, and event signals. The parking widget kept only information close to “Can I bring the car?”, such as recommended parking lot, remaining spaces, status, and updated time.

The app can show facility lists, notices, full addresses, directions, forecast changes, and more. In a widget, that slows the decision.

So I first defined the widget’s questions.

• General mode widget: Is this Hangang park worth visiting today?
• Car mode widget: Can I take the car right now?

Once these questions were fixed, the screen changed. Large numbers, short status, updated time, and minimal supporting signals remained. Details such as nearby facilities or route exploration were not placed in the widget; when users wanted more, the widget opened directly into the relevant park and mode.

The criteria for a good widget differed from the app screen.

Criterion	App screen	Widget
Amount of information	Broad enough for comparison and detail.	Only what is needed in a single glance.
Freshness expression	Can show source and state by section in detail.	Shows updated time and stale state briefly.
Action	Leads to detail exploration, directions, and settings.	Leads into the app or is closed after a glance.
Good result	The user finds the needed information.	The user decides faster without opening the app.

So I decided it was fine even if the widget did not increase app session time. If the pre-departure check became shorter, the widget had done its job.

This changed how I evaluated the widget. “Did it bring users into the app?” mattered less than “Could users decide without opening the app?” If someone glanced once before leaving and moved, it was okay even if the app never opened.

Information removed from the small screen

There were many things I wanted to add to the widget but removed: park descriptions, long notices, facility lists, multiple events, and detailed forecast charts. They matter in the app, but they slow decisions in a widget.

In the parking widget especially, I struggled between showing the most important candidate and showing every candidate fairly. Listing every parking lot in tiny text increases the amount of information.

But users right before departure want to know which lot to go to. It was better for the widget to put the recommended candidate and status first, then move detailed comparison into the app.

The general mode widget was similar. Weather, congestion, events, fine dust, and notices all look important. But if they all have equal weight on one small surface, nothing remains in memory. Facility lists that are useful on-site belong in the app screen. The widget should keep only the values that answer whether this park is okay today.

Stale numbers had to be labeled in the widget too

Widgets are convenient, but they are also risky. Users do not read them for long. A wrong value shown prominently can mislead more easily than the app screen.

In Hangangjari widgets, updated time and stale-state labels mattered. A widget does not always guarantee the newest value immediately. The system has a refresh schedule, the network can fail, and sometimes the widget has to show the last stored snapshot first.

So I did not want the widget to feel like a real-time dashboard.

Instead, it shows the last confirmed value quickly, says when it is old, and leads into the app when the user wants to check again.

This decision affected implementation. The app and widget read the same data differently. The app is a place to scroll, compare, and enter detail screens. The widget is a one-glance surface based on the last snapshot.

So the app stores a separate widget snapshot through an App Group, and when a user enters from the widget, it connects naturally to the selected park and mode.

A widget is not a reduced app. It is the first surface a user sees before moving.

Once this standard was clear, many decisions became easier. Widgets are not less important because they are smaller than the app. They handle an even faster moment, so they have to be designed more carefully.

Thinking about the widget simplified the app too

Putting the widget at the center made the app’s role clearer.

The widget is quick checking. The app is comparison and detail. Notifications are changes in conditions the user chose. Directions are the final move into actual travel.

With this separation, the touchpoints do not compete. The widget does not try to finish everything, and the app does not push every piece of information onto the first screen.

It had to be okay to stop after seeing only the widget

It is easy at first to think a good product should make users open the app more often. For Hangangjari, it was close to the opposite. If someone can look only at the widget and decide “Let’s go to Banpo instead of Yeouido” or “Let’s leave the car today,” that is a success even without opening the app.

There are still moments that need detail. Comparing parking-lot locations, checking event information, or opening directions needs the app. But if every decision requires opening the app, the widget loses its meaning.

That is why Hangangjari treats widgets as important. The goal of the widget is not to increase app usage time, but to reduce unnecessary checking before going to the Han River. If users wander less and decide faster, the widget has done its job.

What I learned while building Hangangjari is that the center of a mobile product is not always inside the app icon. In a user’s life, the home screen, lock screen, notifications, and map-app handoff are all moments of meeting the app.

This is especially true for widgets. Users are not trying to explore Hangangjari for a long time. They want to decide quickly whether they can go now.

So Hangangjari’s widget was not an extra. It was close to the center of the product. When the check before opening the app improved, the moment of opening the app became more natural too.

Looking back, taking the widget seriously clarified Hangangjari’s character. It was not a screen meant to keep people around longer. It was a screen meant to reduce hesitation before leaving. The widget was the touchpoint that revealed that character first.