How We Evaluate Mobile Apps
Every verdict on this site traces back to one method. Here is which apps we pick, which tasks we run, and what has to work before we call a flow good.
A verdict without criteria is just an opinion. If you disagree with a conclusion, this page shows where our reasoning and yours part ways.
Selection first
How we choose which apps to cover
Selection starts with a pattern, not a brand. We look for a product that solves a common mobile problem in a way that is either notably effective or notably questionable, and where the design decisions are visible from the outside.
That means coverage leans toward apps with high daily use in Korea, since repeated tasks reveal structural decisions that occasional-use apps never have to make. We will sometimes cover a smaller product when it demonstrates a pattern more clearly than a larger one.
We do not cover an app because it is new, because it is trending, or because a company asked us to. There is no paid placement and no ranking that can be entered.
Fix the job
Starting from a task, not a screen
Every evaluation begins with something a real person would do. Finding a particular address. Completing a food order. Resuming an episode left unfinished. Paying with a stored card.
Fair comparison
Same job, then compare
Fixing the task first keeps the analysis out of pure aesthetics. Two apps can only be meaningfully compared when they do the same job. A screenshot comparison on its own tells you almost nothing.
Task-led review means testing in context, where addresses, transit names, and interruptions shape the flow.
The four criteria we apply
Applied in this order, on purpose. Structural problems cannot be fixed with polish.
Information architecture
Does the structure match the task, and can the user find the next step without guessing? We map the path before we judge the pixels.
Checked first
Visual hierarchy
Does attention land on the right element first, and does the layout hold up with dense or uneven content? Long place names and mixed scripts are part of the test.
Checked second
Interaction feedback
Does the interface confirm actions promptly, and does it preserve the user's place through loading, errors, and interruptions? Late feedback is a defect.
Checked third
Localization resilience
Does the design survive Korean addresses, transit naming, text expansion, and the mix of Hangul and Latin type on one line? This is a mobile UX criteria check, not a translation check.
Checked fourth
Evaluating typography before the state model tends to miss the expensive issues. We work top-down so fixes land in the right order and avoid rework.
State coverage is where most designs fail
The most revealing thing about a mobile interface is how it behaves when data is missing, slow, or wrong. Empty states, loading states, partial failures, and error recovery show whether the designer thought about the whole system or only the main path.
We check these explicitly for every flow in our app usability analysis. An app that handles the happy path beautifully and the error path carelessly is not a well-designed app, however good the screenshots look.
What we probe
Interrupted checkout, lost connection mid-search, empty history, expired session, and wrong address entry.
What passes
Place is preserved, progress is kept, and the next step is stated in plain language without losing entered data.
Localization review for the Korean market
Korean addresses have their own structure, transit systems use naming that affects search, and text expansion breaks Latin-only mockups. Our localization review checks whether the interface was designed for these conditions or adapted afterward.
The difference shows in edge cases: long place names, mixed scripts in one line, and formal and informal register in interface copy.
Context, not proof
Where Seoul Design Award material fits
Design competitions show what the field currently calls strong work. The Seoul Design Award is open to designers worldwide and accepts projects released within the last five years, across categories including UX/UI, AI-based design, and work aimed at social problems.
We reference that material as context for what juries are recognizing, not as proof a pattern is correct. An award means a jury found the work notable. It does not replace task-based evaluation.
Focus Stella as a worked example
Focus Stella is a Korean UX/UI project recognized in the 2026 UX Design Awards, listed with designers Yeonwoo Lee and Sujeong Kang. It is useful here because it shows current Korean work being judged on UX and product design quality in an international setting.
We use it as a case study for how award-level Korean projects handle flow and interaction, and what that standard implies for products that never enter a competition. The bar set by recognized work tends to raise expectations across the market.
What our evaluations cannot tell you
We can only assess what is observable in the interface. We do not see internal research, business constraints, engineering limits, or the options that were considered and rejected.
That gap matters. A flow that looks inefficient may be constrained by a backend system we cannot see. Where a choice seems wrong, we state what we observed and what we inferred, and keep those separate.
How to use these criteria on your own product
Run one core task on your own app and score it against the four criteria in order. Note every point where you had to guess, where feedback was late, or where a long string broke a layout.
That list beats a general design review because it is specific and ordered. Structure first, then hierarchy, then feedback, then localization. Fixing in that sequence avoids rework.
See prototyping and systems
Test where the task actually happens.
Dusk, one hand, poor connection, long address. If a flow survives that, it survives the studio.
Questions about the method
Short answers on independence, suggestions, and why the order is fixed. For anything else, write to the editors.
Send a correction to the editorsDo you accept payment to review an app?
No. There is no paid placement, sponsorship, or ranking entry. Apps are selected because they demonstrate a pattern, and verdicts are not shared with the companies before publication.
Can I suggest an app for evaluation?
Yes. The most useful suggestions name a specific task and explain what makes it difficult, rather than just naming a product. A short note on where you got stuck helps us reproduce the issue.
Why do you evaluate in a fixed order?
Structural problems cannot be corrected by visual polish. Checking information architecture first prevents spending time on typography and spacing in a flow that needs to be reorganized.
Put one task through the four checks.
Pick the flow your users repeat daily. Score it top-down, then compare it against the patterns we document.
Independent notes from Seoul — Ninoshvili Street 2, Batumi. No paid placement.