Overview
- The problem
- Finding a place, inspecting a product, and checking an ingredient photo are different tasks. The challenge is connecting them without making dietary information look more certain than its evidence.
- My contribution
- Product Designer. The documented work covers mobile discovery, filters and details, photo-check guidance, result states, points and purchase flows, and account destinations.
- The outcome
- Published on iOS and Android by eftax Co., Ltd. I also report a 1,296% increase in user-acquisition conversion from HaloDish landing-page design and implementation.
Problem
Original mobile screens cover discovery, ingredient-photo guidance, uncertainty, points, purchases, and return paths. Official store destinations document publication. The separately reported landing-page acquisition result is not an app-usability or food-classification result.
The design challenge
The central challenge is connecting discovery with enough information to support a considered choice. Finding a nearby place is different from inspecting a packaged product, and both are different from photographing an ingredient list. The interface needs clear routes between those tasks without implying that every green label represents the same kind of evidence.
- Make restaurants, prayer spaces, stores, and products discoverable from one starting point.
- Support both visual comparison and geographic exploration.
- Explain what a photo check needs before asking someone to use the camera.
- Present uncertain results as a distinct state rather than forcing a positive or negative answer.
- Expose the points cost and purchase confirmation before commitment.
My Role
- Company / product context
- eftax Co., Ltd. · HaloDish
- Users
- People living in or visiting Japan who are exploring halal, vegan, or vegetarian options, nearby prayer spaces, and stores.
- My role & scope
- Product Designer. The documented work covers mobile discovery, filters and details, photo-check guidance, result states, points and purchase flows, and account destinations.
- Evidence available
- Original project narrative and design artifacts retained in this case study.
Process
The design record connects list and map discovery, information detail, photo capture and confirmation, and multiple result states. It does not publish a chronological iteration study or classifier evaluation.
A clear entry into a broad product
The onboarding sequence introduces places and the Food Check as separate capabilities. Skip and step indicators let the design explain the concept without making every introductory screen an unavoidable gate. The main navigation then provides home/explore, products, checking, tourist-spot, and profile destinations.
Two actual onboarding screens establish different tasks within the same app.- Choose a location
- Browse or search
- Filter the options
- Inspect the details
- Save or navigate
The published listings describe restaurant discovery, ingredient checking, product lookup, prayer spaces and stores, and tourist-spot exploration. The Figma examples below focus on the flows documented in the supplied design file.
Key Decisions
Dietary information can be incomplete or ambiguous. The interface needs to show uncertainty rather than imply a guarantee. Lists and maps serve different discovery tasks; photo input also requires visible guidance and cost before commitment.
Key design decisions
Let the task choose the discovery mode
Lists help compare options; maps support geographic exploration. A shared search and category structure connects the two without changing the user's task.
View the list, map, and filter designsExplain the input before asking for a photo
Ingredient-versus-barcode examples, visible points costs, and a retake/confirm step make the required input and commitment inspectable before analysis.
View the photo-input and confirmation screensShow uncertainty instead of a forced verdict
A distinct Doubtful result and ingredient-level annotations give ambiguous evidence its own state. This documents the interface response, not classification accuracy.
View the result and uncertainty states
Trade-offs
The main trade-off is breadth versus clarity. HaloDish connects lifestyle discovery, ingredient checks, community activity, and a resource model; those relationships are useful only if the primary task remains easy to find. Contribution moderation also needs to distinguish participation from information verification.
Final Solution
The mobile design connects finding a place or product to inspecting evidence and, where relevant, checking an ingredient photo. Original screens preserve uncertain results, purchase context, and empty states alongside the main path.
Discovery through lists, maps, and filters
The restaurant list puts images, distance, opening state, ratings, and condition labels next to each place. The map view keeps the same search and category structure but changes the comparison from a vertical list to spatial clusters. Switching presentation is a change of exploration mode, not a move to a separate product.
List and map views share a recognizable search and category header.Filters distinguish sorting, radius, place details, conditions, cuisines, and payment methods. Reset and Apply separate editing criteria from committing them. The visible categories also expose a data-model question: certification, availability of options, ownership, and facilities are different attributes and need different supporting evidence.
Grouped criteria and an explicit Apply action make the filter surface a focused task.Information behind a place or product
Place details expand a result into photos, condition indicators, Overview/Menu/Reviews tabs, quick information, location actions, and opening hours. The overview includes a dish-specific note rather than relying only on restaurant-wide labels. Suggest edit introduces a correction route for information that may change.
The two detail surfaces answer different questions: visiting a place and inspecting a product. Open either source screen for its full content.The packaged-product design includes ingredients, notes, shop links, a disclaimer, and a last-updated field. These create space for explaining provenance and limitations. Maintaining consistency between ingredient text, dietary labels, and certification evidence is an important ongoing content-quality requirement; the sample screenshots are not classification validation.
Make the labeling limits inspectable
The source includes a dedicated How We Label Products page. It separates its labeling approach, definitions, limitations, and user responsibility. In particular, the design copy distinguishes listed-ingredient review from manufacturing, supply-chain, and cross-contamination verification.
The app's own explanation is preserved as a design artifact, not endorsed as a certification or food-safety standard.This is a crucial trust boundary for the product. A badge should communicate both its meaning and the basis for displaying it. The case study presents the labeling information architecture, not an independent verification of the example products.
Guide the ingredient-photo task
Food Check tells the user to photograph written ingredients rather than a barcode. The entry screen pairs correct/incorrect examples with camera and upload actions, and displays the points cost beside each action. That guidance sits before capture, where a misunderstanding can still be prevented.
Input guidance and a retake/confirm step give the photo flow explicit decision points.The documented sequence proceeds through capture, ingredient cropping, analysis, and a result. The analysis screen communicates ongoing work, while the later screens expose the detected ingredient list. Food Checker is a listed feature of the published app; these Figma states illustrate its design without establishing model accuracy or performance.
A dedicated processing state bridges the photo task and its result.Treat uncertainty as a real result
The result designs separate halal and vegan status, then list the detected ingredients. Alongside a positive example, the file includes a Doubtful result with annotations on specific ingredients. That distinction is important: missing or ambiguous evidence is not the same as a confirmed match or mismatch.
Both are interface examples. The classifications are not independently validated, and the positive/uncertain screens are not accuracy-test results.The UX requirement is to make input quality, data provenance, ambiguity, and rechecking behavior understandable. Ingredient-level explanations matter because an uncertain result should not become an unexplained verdict. This remains an ongoing validation topic rather than a measured outcome claimed here.
Connect the wallet to the task cost
The points wallet separates Earn, Spend, and History. Earning routes include check-ins, community contributions, and watching ads. The history design associates balance changes with actions and timestamps, while the Food Check entry reveals its cost before capture. Together they attempt to make the resource model visible rather than deducting points silently.
Balances and rewards are example values. These frames are not financial records or evidence of actual transactions.The purchase design then shows a selected pack, a confirmation sheet with an order total and payment method, and a completion state with a receipt and route back to the wallet. The source also contains biometric, loading, and card-entry variants; this case study highlights the main decision and completion points.
The selected pack precedes payment confirmation.The published Google Play listing identifies in-app purchases. These screens document the design states, not a payment-security audit or current pricing.Return paths, editorial help, and empty states
Profile organizes reviews, place contributions, liked places, favorite products, and the food-profile entry. Saved products provide a direct return path to a prior choice, while the article-detail design supports a longer reading mode outside the result list.
Account activity and saved content have dedicated destinations rather than being buried in discovery.
Editorial content is shown as an example reading surface; its dated venue recommendations are not current travel guidance.The source also includes a home state with no local restaurants, prayer spaces, or stores. Each empty collection names the missing content and suggests selecting another location, while product and editorial sections remain available. This documents one recovery route, not a complete set of offline or permission-error states.
Empty local collections retain the broader product context and a suggested recovery action.Outcomes
HaloDish is documented as published on iOS and Android by eftax. I also report a 1,296% increase in user-acquisition conversion from the HaloDish landing page I designed and implemented. That outcome belongs to landing-page acquisition, not to the app's usability or classification accuracy.
What supports these numbers
- Verification status
- Owner-reported result; not independently verified
- Measurement period
- Not available
- My contribution
- Landing-page design and implementation
- Evidence available
- Owner-supplied resume and original project narrative. No before/after rates, analytics export, or attribution model is available.
Landing-page user-acquisition conversion
- Reported result
- Increased by 1,296%
- Baseline & comparison
- Baseline and measurement period not published.
- Source & scope
- Reported by Insan for landing-page design and implementation, not app usability or classifier accuracy.
Evidence & limitations
Publication is verified; archived screens may differ from the current app. The landing-page outcome is reported by Insan without baseline rates, measurement periods, or underlying analytics included here. Example classifications, balances, prices, and ratings are design content, not accuracy tests or impact metrics. No app-usability-study results are claimed.
Publication and acquisition growth do not establish dietary accuracy, app task success, or attribution for later releases.
A shipped product that continues to evolve
Reported landing-page acquisition outcome
Alongside the app work, I designed and implemented the HaloDish landing page. I report a 1,296% increase in user-acquisition conversion rates for that landing-page work.
This is a reported marketing outcome for the landing page, not an app-engagement, retention, or download-growth metric. Baseline rates, measurement periods, and underlying analytics are not included in this case study.
The confirmed delivery outcome is public availability on iOS and Android. Visitors can move from this design story to the published product through the store links below.
The App Store release history describes continued changes to home and Explore, search, products, points, profile, sign-in, and article readability. It also records a newer fallback that shows popular places outside supported locations. That is evidence of ongoing product iteration, not proof that every archived Figma screen matches the current release, or that each update can be attributed to this design work.
What needs validation
The following is a proposed validation plan, not research already conducted:
- Test whether first-time users can distinguish place discovery, product lookup, and photo checking.
- Evaluate switching between list and map, applying/resetting filters, and recovering from empty results.
- Check comprehension of label provenance, certification examples, disclaimers, and doubtful results.
- Validate photo-input guidance and design unreadable, unsupported-language, denied-permission, and failed-analysis states.
- Test understanding of points costs, depleted balances, purchase cancellation, failure, and duplicate confirmation.
- Continue reviewing source-data consistency, contribution moderation, accessibility, and localization as the app evolves.
Learnings
- What worked in the design
- Discovery, input guidance, cost, and uncertainty form one connected task rather than separate finishing details.
- What I would change next
- Keep acquisition and app-task measures separate. Test photo-input comprehension, uncertainty interpretation, and the route from a shortlist to inspectable detail.
Delivery and design takeaways
The confirmed outcome is a publicly available iOS and Android app. The design record shows connected discovery and checking journeys, while the store history documents continued product iteration. Publication does not establish that every archived screen is in the current release or attribute every update to this work.
- Discovery and inspection need different information depths: a useful shortlist still needs a route to detailed notes and provenance.
- Uncertainty belongs in the product model, not just in a disclaimer after a confident-looking result.
- Input guidance, visible cost, and confirmation are part of the task itself, not finishing touches around it.
