Why Every UI UX Designer Should Practice Explaining Their Model Aloud

Interview Insights · UI UX Designer

Why Every UI UX Designer Should Practice Explaining Their Model Aloud

SECTION 01Two kinds of model every designer should be able to name

The word 'model' sounds like machine learning, but in design interviews it comes up constantly in another form. The first kind is the mental model: the picture in a user's head of how something works. People expect a shopping cart to hold anything they add until they remove it. They expect 'delete' to remove one copy, not every copy.

The second kind is the system model or object model: how you, the designer, decided to structure the product. Which things exist (orders, items, addresses), how they relate (an order has many items), and where each lives in navigation. A design breaks when these two models disagree. Your job, and your interview story, is about finding that gap and closing it.

PRODUCT: Food delivery app

User mental model:
  'My cart is my cart. I can add from any restaurant.'

System model (original design):
  One cart per restaurant. Adding from a second
  restaurant silently cleared the first cart.

What I saw in testing:
  Users added items from two places, reached checkout,
  and found half their items missing.

Fix:
  Keep one-cart-per-restaurant (business rule), but show
  a clear dialog: 'Start a new cart? Your items from the
  first restaurant will be removed.' with Keep / Replace options.

"In testing, people treated the cart like a single basket.
The system actually kept one cart per restaurant, so adding
from a second place wiped the first. That was a mental model
mismatch. We could not change the business rule, so I made
the rule visible: a confirmation dialog before anything is
removed. The fix was not a new screen. It was showing the
system model at the moment it clashed with the user's."

Notice that the spoken version names the model explicitly. Interviewers listen for that vocabulary because it shows you think in structures, not just pixels.

SECTION 02Object modelling: explaining the nouns before the screens

Object-oriented UX is a practical way to build a system model before drawing screens. You list the objects users care about, their attributes, how they relate and what actions they allow. It sounds technical, but it is just careful thinking written in a table.

In an interview, this is gold. When asked 'why did you put the reviews tab inside the product page and not on the home screen?', a candidate with an object model can answer: 'Because a review belongs to a product. It has no meaning on its own.' A candidate without one says 'it looked better there'. Below is an object map for a simple course-booking app, the kind of artefact you can practise explaining.

OBJECT MAP - course booking app

Course  1 --- *  Batch
Course  1 --- *  Review
Batch   1 --- *  Booking
Learner 1 --- *  Booking
Learner 1 --- *  Review

Navigation follows the map:
  Home -> Course list -> Course detail
          Course detail -> Batches (pick one) -> Booking
          Course detail -> Reviews
  Profile -> My bookings -> Booking detail

Rule I used: every screen is either a list of one
object, the detail of one object, or an action on one.

"Before I drew any screen I listed the objects: course,
batch, booking, learner and review. A course has many
batches, and a booking connects a learner to one batch.

That is why 'seats left' sits on the batch card, not the
course card. Seats belong to a batch. Early on I had it on
the course page and testers assumed every batch was full
when only one was. The object model made that bug obvious."

If you have never made an object map, try it on a product you already designed. You will often find a field sitting on the wrong screen, and that discovery itself becomes a strong interview story.

SECTION 03Defending your information architecture without sounding defensive

The navigation model is where interviewers push hardest. They will point at a menu and ask 'why is Settings here?' or 'why five tabs and not four?'. The weak response is to defend taste. The strong response is to point to evidence: a card sort, a tree test, a usage pattern or a constraint.

Card sorting tells you how users group things in their heads, which is their mental model made visible. Tree testing tells you whether people can find items in your proposed structure, which tests your system model. Being able to explain both, and what each one told you, puts you well ahead of candidates who only talk about visual design.

OPEN CARD SORT - 12 participants, 30 cards

Strong groups (most people agreed):
  - Order history, Track order, Reorder   -> 'My orders'
  - Saved cards, UPI, Refunds             -> 'Payments'
  - Coupons, Bank offers, Referral        -> 'Offers'

Split opinion:
  - Addresses: half put it in Profile, half in Payments

Decision: Addresses under Profile, and a shortcut to
it from checkout so the other half still find it.
Next: tree test to confirm.

"I did not want to guess the menu, so I ran an open card
sort. Most people grouped coupons and referrals together,
separately from orders, so 'Offers' became its own tab.

Addresses split the group. I put it under Profile and added
a shortcut at checkout, because that is where people
actually need it. Then I tree-tested the structure to check
that people could find addresses either way."

The numbers in a card sort summary are your own study numbers, so only quote what you actually ran. If you have not run one, say so and explain how you would, rather than presenting assumed results.

SECTION 04Model explanation kit for your next design interview

Use this kit on one project you plan to present. Build a quick object map, write the mental model gaps you found, and rehearse a short explanation. Each tab takes about thirty minutes.

OBJECT MAP TEMPLATE

Product: ____________________

Object 1: ________
  Attributes: ______________________
  Belongs to / has many: ___________
  Actions: _________________________

Object 2: ________
  Attributes: ______________________
  Belongs to / has many: ___________
  Actions: _________________________

(repeat for 3 to 6 objects)

Check: is every attribute on the right object?
Check: does navigation follow the relationships?

MENTAL MODEL MISMATCH LOG

| Users expected        | System actually did     | Fix              |
|-----------------------|-------------------------|------------------|
| ____________________  | ______________________  | ________________ |
| ____________________  | ______________________  | ________________ |

For each row, note the evidence:
  quote / test observation / support ticket / analytics

Pick your best row. That is your opening story
when someone asks 'what did you learn from research?'

TWO-MINUTE MODEL REHEARSAL

0:00  The product and its core objects (one sentence)
0:20  One mental model users had
0:40  Where the system model disagreed
1:10  How you closed the gap (design change)
1:40  How you checked it worked, or would check

Record it. Then answer these out loud:
  - Why is the main navigation structured this way?
  - Which attribute did you move, and why?
  - What evidence would change your structure?

SECTION 05Habits that make your design model easy to explain

A clear model is easier to explain because it was clear before you opened Figma. These habits help.

• List nouns before drawing — Write the product's objects on sticky notes first. Screens that come later usually need fewer revisions.
• Use the user's words — Label objects with terms users said in research, not internal team names. It keeps your system model close to their mental model.
• Draw one relationship diagram — A simple boxes-and-lines map of objects is a powerful portfolio artefact and takes little time to make.
• Run one cheap structure test — Even a small online card sort or tree test gives you evidence for navigation choices that you can quote honestly.
• Name the business rules — Write down the rules you could not change, such as one cart per restaurant. Explaining constraints shows maturity.

SECTION 06Interview Q&A — UI UX design model

SECTION 07Test yourself — UI UX design model quiz

SECTION 08Frequently asked questions

SECTION 09Related reads