E-Commerce Restaurant Website

SushiStore

A UI/UX retrospective translating branch-aware menus, orders, membership, reservations, and payment logic into an appetizing customer experience.

At a glance

Role
UI direction · interaction design · frontend refinement
Team
5 students
Timeline
10 weeks · 2025
Platform
Responsive web application

Challenge

Make a multi-branch sushi system feel appetizing, transparent, and easy to transact with.

My contribution

I shaped the interface direction around the existing data model and refined the customer-facing narrative for menu, order, and membership flows.

Evidence boundary

This is a documented project and retrospective redesign, not a claim of primary research or measured usability impact.

01 · Starting point

A database project had the ingredients for a product story.

SushiStore began in Advanced Database Systems. Our main task was to model how a multi-branch sushi restaurant stores, connects, and retrieves operational data, from dishes and menus to reservations, orders, invoices, memberships, promotions, and reviews.

The original brief

Model the restaurant before styling the experience.

The team followed the conceptual, logical, and physical database process. The website then became a working surface for those relationships.

The opportunity

Turn invisible rules into visible confidence.

Branch availability, discount eligibility, payment state, and booking confirmation all affect what a customer should see and do next.

The reframing

The data model defines what exists. UX defines what matters now.

This case study focuses on the customer-facing layer: sequence, hierarchy, feedback, recovery, and the moments where trust is won or lost.

02 · What we knew

I separated documented system rules from design assumptions.

The project had strong operational evidence, but it did not include primary user research. Making that distinction explicit keeps the case study credible and makes the retrospective decisions easier to evaluate.

3
Design layers

Conceptual · logical · physical

10+
Core domains

Menu, orders, booking, payment, and more

2
Experience sides

Customer and staff operations

0
Validated metrics

No fabricated completion or satisfaction claims

Evidence boundary for the SushiStore case study
DocumentedAssumed for designNot validated
Branches, menus, dishes, orders, invoices, promotions, membership, booking, reviewsCustomers want a simple path from branch to checkoutWhich content users find first or trust most
Availability, invoice, membership, and reservation statesPeople benefit from seeing rules before submittingTask success, comprehension, accessibility
A responsive web application was implementedFood imagery and clear hierarchy support appetite and choiceMobile usability or real-world conversion

Evidence

The database report and working website documented the objects, relationships, statuses, and operational workflows.

Insight

That evidence explained what the system could do, but not how a customer should understand the system while ordering.

Design response

Use job stories and retrospective recommendations instead of inventing interviews, personas, quotes, or success rates.

03 · Visual direction

The interface needed to feel like a restaurant before it behaved like software.

The original visual language borrowed the confidence of Tokyo Deli: red, black, white, strong food imagery, and compact navigation. I kept that energy while giving SushiStore its own name and a more explicit system for transaction states.

SushiStore
Eat first / ask later

A warm, direct identity for a high-consideration transaction.

01 / Accent#E6242B
02 / Surface#1B1B1B
03 / Surfacewhite
04 / VoiceDirect
and appetizing

Appetizing

Let food and red accents carry the invitation.

Large surfaces, close-up imagery, and a warm white background create space for the menu to feel desirable rather than administrative.

Contemporary

Use contrast to make the next action obvious.

Near-black surfaces hold navigation and status; red is reserved for action, attention, and the few moments that need emphasis.

Direct

Say what the system knows in human language.

Branch names replace IDs. A receipt explains a total. A booking shows whether the restaurant still needs to confirm it.

04 · Translation

Three database stages became one interface principle.

The database process was not background decoration. Each stage created a different design obligation: understand the domain, protect consistency, then expose only the information that helps a customer decide.

  1. Conceptual01

    Name the restaurant's objects.

    Branches, menus, dishes, orders, invoices, members, bookings, and reviews define the domain of the experience.

    Output: shared vocabulary

  2. Logical02

    Keep relationships consistent.

    Normalization and relational links protect which menu belongs to which branch and how an order connects to its invoice.

    Output: reliable states

  3. Physical03

    Support the critical queries.

    Stored procedures, triggers, indexes, and query testing make operational actions possible at the speed an interface expects.

    Output: responsive actions

  4. Interaction04

    Reveal the right consequence.

    The UI turns rules into selectors, availability badges, price breakdowns, progress, and recovery messages.

    Output: customer confidence

Simplified domain mapThe model is larger
than the interface
Branchwhere
Menuwhat
Dishdetail
Orderhow
Invoicepay
Memberbenefit

The interface turns entities into four customer questions: where am I ordering, what can I choose, how much will it cost, and what happens next?

The data model is larger than the interface. Good UX is the act of choosing what not to show yet.

05 · Core flow

The ordering journey became a sequence of small reassurances.

The customer does not experience tables or procedures. They experience a series of questions: where am I ordering, what is available, what will it cost, and what happens after I pay?

  1. 0101

    Select a branch

    Human-readable name, distance, opening state, and branch context persist while browsing.

  2. 0202

    Explore the menu

    Category, search, food imagery, price, and availability help the customer choose without trial-and-error.

  3. 0303

    Review the order

    Quantity, promotion eligibility, membership benefit, VAT, and delivery fee are visible before confirmation.

  4. 0404

    Pay once

    The invoice moves through one clear state, with a receipt that confirms what was recorded.

  5. 0505

    Track what happens next

    Preparing, on the way, and delivered are service states, not hidden backend values.

  6. 0606

    Keep the relationship

    Points, feedback, and booking history make the next visit easier to understand.

07 · Deep dive 02

A cart should explain the total, not expose the invoice.

The underlying project had cart, order confirmation, payment records, promotions, and membership rules. The UX opportunity was to transform those technical states into one calm checkout narrative.

Order #0284

A transparent checkout

2 × Salmon Nigiri₫180,000
1 × Miso Soup₫55,000
Subtotal₫235,000
VAT₫22,795
Delivery fee₫20,000
Total270.745đ
Live statusConfirmed
Tap a stage to preview the feedback loop. The receipt is a narrative, not a payment record.
How data rules become checkout feedback
System ruleCustomer riskInterface response
One invoice is paid onceA payment action can feel ambiguous or repeatable.Disable the completed action and return a receipt with a status.
Total depends on VAT and benefitsA long decimal total or hidden discount weakens trust.Use a readable breakdown and explain why a benefit applies.
Only confirmed orders are preparedThe customer may not know whether the restaurant has accepted the order.Separate Reviewing, Confirmed, Preparing, and On the way.

Trust is a visual state. A price breakdown and an order timeline are part of the product logic.

08 · Deep dive 03

A membership rule becomes useful when people can see their progress.

The data model included membership tiers, accumulated spend, promotions, and points. A logged-in customer should not need to re-enter a membership ID just to understand the relationship they already have with the restaurant.

SushiStore
Member no. 0042

Your membership

Silver

73 / 100 pointsGold next

27 more points to reach Gold

Visible relationship

Progress is more motivating than a lookup form.

Show the current tier, points, next threshold, validity, benefits, and the reason a discount was applied. The customer should be able to answer “what do I get?” without knowing the schema.

Retrospective audit

The original specification described Silver and Gold discounts as 3% and 5%, while one interface view showed 5% and 10%. I treat this as a traceability issue between business rules and customer-facing copy, not as a validated user finding.

09 · Backstage

The best customer states depend on staff actions behind the scenes.

SushiStore was not only a landing page. Staff workflows updated menu availability, processed orders, confirmed bookings, maintained memberships, and produced reports. I kept that operational layer visible as a service relationship, not a gallery of admin screens.

Customer experienceStaff actionData state
Dish shown unavailableUpdate menu statusMENU.STATUS
Order is preparingProcess orderORDER.STATUS
Discount appearsMembership updatedMEMBER.TIER
Booking confirmedStaff confirmsBOOKING.STATUS

Booking

Show pending confirmation as a real state.

A request can be submitted before a staff member confirms it. The customer deserves a next step instead of silence after pressing submit.

Stores

Replace internal tables with visit decisions.

Distance, opening state, parking, contact, directions, menu, and booking are more useful than a manager employee ID.

Analytics

Keep reports readable without hiding detail.

Operational dashboards can lead with KPIs and trends, then keep the sortable table as supporting evidence.

10 · Outcome

SushiStore proves that database thinking can strengthen visual design.

The most valuable outcome is not a claim that the original website was validated. It is the translation from operational rules into a brand experience where a customer can choose, transact, and recover with less uncertainty.

What I kept

The data model as a source of product truth.

Branches, statuses, discounts, invoices, and bookings are not implementation trivia. They explain why the interface needs certain selectors, badges, and feedback.

What I changed

The emphasis from records to decisions.

Human-readable context, strong hierarchy, clear price explanations, visible progress, and stateful feedback make the same system feel more like a restaurant.

Next iteration

Validate the three highest-risk moments.

I would test branch selection and menu findability, checkout comprehension, and booking confirmation with real restaurant customers before expanding the redesign.

SushiStore does not just show that I can draw an ER diagram. It shows that I can turn a complex data system into an experience that feels appetizing, understandable, and trustworthy.