Overview
- The problem
- A vague food request needs to become a shortlist someone can inspect. The interface must support preferences without making chat the only way to discover or revisit a dish.
- My contribution
- Product Designer. The Figma work covers conversation states, Explore, dish details, saved collections, preference editing, account settings, and desktop/mobile adaptations.
- The outcome
- A documented desktop and mobile design concept. The screens establish connected flows; they do not establish a launched service or a working recommendation engine.
Problem
The Figma concept shows conversation, Explore, dish details, Saved, editable food preferences, and desktop/mobile layouts. These are scenario and interaction artifacts, not validated personas, user interviews, or a working recommendation engine.
The design challenge
The central question is how a food-discovery interface can help someone move from a vague desire, such as comfort food nearby, to a shortlist they can inspect. The design must accommodate preferences without forcing every decision through either a long filter form or an open-ended chat.
- Offer a starting point when someone does not know what to type.
- Keep the preferences influencing a recommendation visible and editable.
- Separate discovery from the more detailed information needed to assess a dish.
- Let people preserve a promising option instead of restarting the search later.
My Role
- Company / product context
- DiverMenu · Personal design concept
- Users
- People exploring dishes through a stated request or visual browsing. This is the scenario shown by the concept, not a research-validated persona.
- My role & scope
- Product Designer. The Figma work covers conversation states, Explore, dish details, saved collections, preference editing, account settings, and desktop/mobile adaptations.
- Evidence available
- Original project narrative and design artifacts retained in this case study.
Process
The connected journey and desktop/mobile adaptations show how conversation, browsing, and saving can support the same choice. The archive does not contain a tested comparison of recommendation approaches.
A connected discovery journey
The persistent desktop navigation separates conversation history from Explore, Saved, Profile, and Settings. Chat is one entry point, not the entire product. The journey can begin with a prompt or a cuisine category, then converge on dish details and a saved collection.
- Set preferences
- Ask or browse
- Compare dishes
- Inspect details
- Save and revisit
The welcome state pairs a message composer with two concrete starting prompts.The sign-in design offers email and password alongside a Google option, with password visibility, recovery, and account-creation links. It is presented here as the designed account entry, not evidence of a working authentication service.
Account access uses familiar sign-in and recovery affordances.Key Decisions
Chat should not be the only discovery route. Structured browsing and editable preferences provide control when a prompt is vague. Preference matching must not be presented as evidence of dietary suitability or safety.
Key design decisions
Offer a browsing route alongside conversation
Cuisine categories and quick filters give people a starting point without requiring a perfect prompt. Both discovery modes converge on comparable dish information.
View the Explore and save-feedback designMake personalization inspectable
A food profile separates preference groups and provides editing routes, suggested values, custom entry, and an explicit save action instead of hiding all context in the conversation.
View the food-profile and preference editorsTurn a recommendation into a reusable shortlist
A dedicated Saved destination retains the dish information needed to revisit a choice. Detailed pages provide a separate place to inspect ingredients and source information.
View the saved-dishes collection
Trade-offs
The important trade-off is between conversational convenience and trustworthy detail. Preferences can help narrow a search, but they cannot substitute for reliable source information. A production experience would also need to distinguish unavailable information from a negative finding, and personal taste from a safety constraint.
Final Solution
Conversation leads to inspectable details, Explore offers an alternative entry, and Saved supports a return visit. Preference and account controls expose context that would otherwise remain hidden in a chat.
Conversation that leads to a shortlist
A sample request specifies nearby comfort food, chicken, and an exclusion. The response exposes a summary of profile preferences before presenting dish cards. Each card includes a dish, restaurant, price, tags, detail access, and a save affordance, giving the conversation a visual comparison layer.
Profile context sits above the results. One source card contains an unfinished image placeholder, preserved here as part of the design artifact.Follow-up actions make the next move explicit: directions, favorites, similar dishes, or changed filters. The next conversation state explains why one option might fit the request. This is a useful interaction pattern, but the example's confident allergy wording is a validation risk, not a safety result this case study endorses.
A second conversational turn adds reasoning to the shortlist rather than replacing the visual results.Browsing when the user wants to explore
Explore supports a different mode: quick preference filters, cuisine categories, and a visual dish feed. Cuisine tiles help someone start without composing a prompt, while prices, restaurant names, and ratings stay attached to individual dishes. Chat and browsing use comparable dish information so the mental model does not have to change between them.
The Explore surface includes a saved-state change and a confirmation with a direct route to Saved.More detail before making a decision
The dish-detail design expands a card into a larger image, description, restaurant attribution, distance, rating, and price. It then separates allergen information, a symbol legend, and ingredients into readable sections. The visual distinction between ingredient presence, cooking use, and shared production environments shows an attempt to communicate different kinds of information rather than collapsing them into one badge.
The full source detail screen is preserved at natural proportions. Open the image to inspect the smaller labels.The source also includes a verification label and a date. These are interface examples, not independently established restaurant verification. A production version would need clear provenance, update rules, an unknown-data state, and carefully qualified recommendation language before making reliability claims.
A saved collection closes the loop
Saved dishes retain the image, restaurant, price, distance, and rating from the browsing experience. Filled hearts communicate which options belong to the collection, and the separate Saved destination makes returning to a shortlist different from searching for it again.
A dedicated collection turns a temporary browsing choice into something a person can revisit.Preferences the user can inspect and change
The food profile groups eating preferences, liked food, disliked food, mood, and allergens. Rather than keeping personalization entirely implicit, the overview shows which preference areas are configured and provides individual editing routes. A visible Food Profile toggle gives the concept a way to expose whether personalization is active.
The profile separates general account information from the food preferences used by the experience.The liked-food editor combines selected chips, common suggestions, and custom entry for cuisines and dishes. An explicit Save Preferences action marks the commit point. This balances quick setup with room for preferences that are not represented by a fixed suggestion list.
Suggested values and custom entry coexist in the same preference-editing pattern.Settings and account control
Settings separates appearance, privacy and security, data and storage, and account removal. The design includes location permission, password changes, two-factor authentication, data download, and cache clearing. The account-deletion action is visually separated from ordinary preferences.
Account controls are grouped by purpose, with destructive action isolated at the bottom.The two-factor flow includes an authenticator-code verification step with a disabled action before input. These screens document intended states and affordances; they do not establish that security, data export, or deletion are implemented.
A verification step gives the security flow a distinct completion gate.The same experience on a smaller screen
Mobile replaces the persistent sidebar with menu access and a compact top bar. Cuisine browsing becomes a two-column collection, result cards become a vertical sequence, and follow-up actions wrap below the recommendation. The conversation composer remains a clear continuation point.
Actual mobile frames from the source file. Scroll each preview or open it at full size.Outcomes
The result is a connected desktop and mobile interface concept. Launch, recommendation quality, user satisfaction, and business impact are not established.
Evidence & limitations
Design evidence only. Restaurant information, ratings, prices, and dietary labels in the screens are illustrative. No interviews, usability results, recommendation accuracy, or business impact are claimed.
The screens do not establish the quality or trustworthiness of generated recommendations.
What needs validation
The following is a proposed validation plan, not research already conducted:
- Test whether a first-time user can reach a useful shortlist through both a prompt and browsing.
- Check whether people understand which profile preferences affect results and how to change them.
- Evaluate comprehension of ingredient symbols, source attribution, and unknown or outdated information.
- Test saving, revisiting, and continuing a conversation on mobile and with keyboard or assistive technology.
- Define loading, no-result, permission-denied, missing-image, and unavailable-data states before implementation.
- Validate the information model and revise overconfident dietary language before any production release.
Learnings
- What worked in the design
- Conversation is connected to structured comparison, editable preferences, and a reusable shortlist.
- What I would change next
- Prototype ambiguous requests, preference corrections, no-result cases, and source inspection before evaluating recommendation quality with real users.
Delivery and design takeaways
The deliverable is a connected interface direction across desktop and mobile: conversation, browsing, preferences, detailed information, and saved dishes. It is a design concept, not evidence of launch, recommendation accuracy, dietary suitability, or measured usability improvement.
- Conversation is more useful when it connects to structured comparison and inspectable detail rather than becoming the whole product.
- Personal taste and safety constraints need different evidence and language; preference matching cannot establish dietary suitability.
- Visible preference editing and a saved collection make personalization and return visits user-controlled parts of the journey.
