Field Notebook

Glossary

71 terms across 6 tracks. Words are always visible; definitions fill in as you complete missions.

clone
Git Flow
git clone https://github.com/acme/design-tokens
Downloading the entire project — every file, every saved version, the full history — from the internet to your computer. Like downloading a Figma file, except it brings everything, not just the current state.

You'll clone a repo when you need to run something locally, test a design token change, or look at how components are actually structured in code — not just in Figma.
branch
Git Flow
git checkout -b redesign-tokens
Your own private copy of the codebase to work in. Changes you make on a branch don't affect anyone else until you decide to merge them in. Think of it like duplicating a Figma page to try something out — the original is untouched.

Engineers will ask "what branch are you on?" when something looks broken in a local preview. Your branch name tells them which version of the code you're seeing.
commit
Git Flow
git commit -m "update primary blue token"
A saved snapshot of your changes, with a short note explaining what you did. Not just a save — more like a labeled checkpoint you can always come back to. Like naming a version in Figma: "v3 — blue updated."

Good commit messages make design reviews easier. When a developer looks at the history of a file, clear messages tell the story of what changed and why.
HEAD
Git Flow

A marker that shows where you currently are in the codebase. It points to your active branch and your most recent commit. If the codebase is a book, HEAD is the page you have open.

If a developer says "HEAD is detached," it means you're in a weird read-only state. It sounds alarming. It's fixable. Now you know what they mean.
push
Git Flow
git push origin redesign-tokens
Sending your local commits up to the shared repository online, so others can see and access your branch. Nothing you've committed is visible to the team until you push.

"Did you push?" is something you'll hear when someone can't see your latest changes. Pushing is the act of making your work shareable.
pull
Git Flow
git pull
Downloading the latest changes from the shared repository to your local machine. If someone else updated a file while you were working, pull brings those updates to you.

Before you start working each day, pulling keeps you from working against an outdated version of the codebase.
pull request (PR)
Git Flow

A formal request to merge your branch into main. It's a structured review — your changes are shown, teammates can comment line by line, and someone with authority approves before anything merges. It's the peer review of code.

Designers are increasingly included in PR reviews for design token changes, copy updates, or anything that affects what users see. Knowing what a PR is means you can participate in that conversation.
merge
Git Flow
git merge redesign-tokens
Combining the changes from one branch into another. When a PR is approved, the merge happens — your draft becomes part of main. If two people changed the same line differently, you get a merge conflict (more on that in Level 3).

"It's merged" means the change is in. "It's in main" means the same thing. If something looks different in production than in your design, asking "did that PR merge?" is a completely valid question.
merge conflict
Git Flow

What happens when two people change the same part of the same file in different ways, and git can't figure out which version to keep. It's not an error — it's a flag that says "a human needs to decide this." Someone reads both versions and picks the right one.

Merge conflicts happen most often in shared files — design tokens, constants, config files. If you're updating tokens at the same time as an engineer, conflicts are likely. Knowing the term helps you follow the conversation when it happens.
.gitignore
Git Flow

A file that tells git which files and folders to pretend don't exist. Anything listed in .gitignore will never be committed, no matter what. It keeps the repo clean of auto-generated files, secrets, and large assets that don't belong there.

If you're ever working with a local dev environment and someone says "make sure that's gitignored," they mean: add it to this file so it doesn't accidentally end up in the repo.
revert
Git Flow
git revert a3f8c12
A safe undo. It creates a new commit that cancels out a previous one — without deleting anything from the history. Think of it like a tracked-changes undo in a Google Doc: the original is preserved, and the correction is logged.

Revert is the professional way to fix a mistake that's already been pushed. It's not embarrassing to use — it's what careful engineers do.
API
API Literacy
GET https://api.acme.com/pricing
A messenger that lets two pieces of software talk to each other. One side asks for something, the API carries the request to wherever the answer lives, and brings the answer back. Like a waiter between you and the kitchen — you never go into the kitchen yourself.

When a screen shows live data — prices, user names, search results — that data almost always comes through an API. If it's blank or wrong, the API is usually where the trail starts, not your layout.
endpoint
API Literacy
/api/pricing
One specific address on an API for one specific thing. An API can have many endpoints — one for prices, one for users, one for orders. Like individual items on a menu, each with its own name.

When an engineer says "that data comes from the pricing endpoint," they're naming the exact source feeding your screen. Knowing the word lets you ask "which endpoint?" instead of "where does this come from?"
request
API Literacy
fetch("/api/pricing")
The act of a screen asking an API for something. Every piece of live data on a page started as a request that went out somewhere. It's the question, before the answer.

In a browser's network tab you can watch requests fire as a page loads. For a designer, this is how you confirm a screen is even trying to get the data it's missing.
response
API Literacy

What an API sends back after a request. It might be the data you asked for, or a message saying something went wrong. The response is the answer to the question the request asked.

"The response came back empty" means the page asked correctly but got nothing useful. That tells you the problem is in the data, not your design — a distinction that saves hours.
status code
API Literacy
200 OK · 401 Unauthorized · 500 Internal Server Error
A three-digit number every API response includes to say how things went. 200s mean success, 400s mean the request had a problem, 500s mean the server itself failed. A one-glance summary of the outcome.

When something on a screen fails, the status code tells you whose fault it is. A 404 (not found) versus a 403 (not allowed) versus a 500 (server broke) point to completely different fixes — and different error states you might need to design.
JSON
API Literacy
{ "name": "Acme", "price": 49, "inStock": true }
A way of writing structured data as plain text, using labels and values inside curly braces. It's how most APIs send information back. Readable enough for a person, strict enough for a machine — like a very tidy bulleted list.

When you peek at the data behind a screen, it'll almost always be JSON. Being able to skim it lets you confirm whether a field you designed for actually exists in the data, or what it's really called.
headers
API Literacy
Authorization: Bearer abc123
Extra information attached to a request or response that isn't the main content — things like who's asking, what format they want, and proof of identity. Like the envelope around a letter: not the message itself, but everything needed to deliver and verify it.

You usually won't touch headers directly, but when a request fails for "auth" or "permission" reasons, a missing or wrong header is often why. Knowing the word helps you follow the debugging conversation.
authentication
API Literacy

The process of proving you are who you say you are before a system lets you in. The "are you logged in" check. Distinct from what you're allowed to do once inside — this is just the front-door ID check.

Auth states are design work — logged in, logged out, session expired, "please sign in again." Understanding what authentication is helps you design the moments when it succeeds, fails, or runs out.
REST
API Literacy
GET /users/42 · POST /orders
A widely used set of conventions for how APIs are organized and named. It makes APIs predictable — addresses follow patterns, and a standard set of verbs (get, create, update, delete) does the work. Less a technology, more an agreed-upon style.

When an engineer says "it's a REST API," they mean it follows familiar rules. For you, that predictability means the data behind your screens is organized in consistent, learnable ways.
webhook
API Literacy
POST /webhooks/payment-settled
A reversal of the usual direction — instead of your app asking an API for updates, the other service automatically notifies your app the moment something happens. Like the difference between checking your mailbox repeatedly and getting a text when mail arrives.

Webhooks power "it just happened" moments — a payment clears, a file finishes processing, a status flips. If a confirmation or notification you designed feels delayed or missing, a webhook is often the thing behind it.
rate limit
API Literacy
429 Too Many Requests
A cap on how many requests you're allowed to make in a given window of time. Go over it and the API politely refuses with a 429 until you slow down. It protects services from being overwhelmed — like a "one scoop per customer" rule.

Rate limits create real UX situations — "you're doing that too fast, try again in a minute." If a feature fails only under heavy use, a rate limit may be why, and you may need to design the slow-down gracefully.
payload
API Literacy
{ "orderId": 991, "status": "paid" }
The actual content carried inside a request or response — the meat of the message, as opposed to the addressing and envelope around it. When data is sent or received, the payload is the data part.

When an engineer says "the payload changed," the shape of the data your screen receives is different — a renamed field, a missing value. That can break a display even when nothing visually obvious failed.
server
Cloud & Infrastructure

A computer that's always on, whose job is to hold a website or app and hand it out to anyone who asks. When you visit a site, a server somewhere sends it to your browser. Your own laptop is not the server — it's a visitor with a private draft.

"It works on my machine but not on the server" is one of the most common phrases in software. It means your local copy and the live copy differ — a gap that explains a lot of "but it looked fine when I made it" moments.
hosting
Cloud & Infrastructure

Renting space on always-on servers so your site is available to the public around the clock. Instead of running your own computers, you pay a provider to keep your site online. Like renting a storefront rather than constructing the building yourself.

Where a site is hosted affects how fast it loads and how it gets updated. When someone says "I'll deploy it to our host," they mean putting the latest version onto those public servers.
environment
Cloud & Infrastructure
staging.acme.com vs acme.com
A separate, complete copy of a site or app kept for a specific purpose. Common ones: development (where it's built), staging (where it's rehearsed and reviewed), and production (the live version real users see). Same software, different stages.

Knowing which environment you're looking at prevents the classic confusion of reviewing a change on the wrong copy. "Is that on staging or prod?" is a question that resolves a surprising number of "it looks wrong" reports.
DNS
Cloud & Infrastructure
acme.com → 192.0.2.10
The internet's address book. It translates a human-friendly name like acme.com into the numeric address of the actual server. You type a name; DNS quietly looks up where that name lives and points you there.

You rarely touch DNS, but it explains why a brand-new domain "isn't working yet" (the address book hasn't updated everywhere) or why staging and production sit at different web addresses.
CDN
Cloud & Infrastructure

A worldwide network of servers that each keep a copy of your site's files, so visitors download from the location nearest them instead of one central place. Like a chain of local warehouses instead of shipping everything from one headquarters.

CDNs are why heavy assets — big images, fonts, video — can still load fast globally. If you're shipping large visuals, "put it on the CDN" is often the difference between snappy and sluggish.
cache
Cloud & Infrastructure
Cache-Control: max-age=3600
A saved, ready-to-serve copy of something so it doesn't have to be created or fetched fresh every time. The first visit does the work; later visits get the stored copy instantly. Like keeping a frequently used file on your desk instead of the archive room.

Caching is why your updated design sometimes doesn't appear until a hard refresh — the browser or CDN is still serving a stored older copy. "Try clearing your cache" means you're seeing an old saved version, not that the change failed to deploy.
load balancer
Cloud & Infrastructure

A traffic director that spreads incoming visitors across several servers so no single one gets overwhelmed. When a page suddenly gets popular, the load balancer shares the crowd. Like opening more checkout lanes as a store fills up.

Load balancers are why a site can survive a launch spike or a viral moment without falling over. You won't configure one, but it explains how "the site stayed up under huge traffic."
latency
Cloud & Infrastructure

The delay between asking for something and starting to get it — the travel and reaction time, separate from how big the thing is. Even a tiny file has latency if it's coming from far away. Distance, congestion, and detours all add to it.

Latency shapes how "instant" an interaction feels. A button that waits on a far-away server can feel laggy no matter how snappy your animation is — which is why loading and optimistic states matter in your designs.
downtime
Cloud & Infrastructure

Any stretch of time when a site or service isn't working for users. It might be fully down or badly degraded. The opposite of uptime, and the thing every team works to minimize. Measured in minutes that feel like hours.

Downtime is when your error states, status pages, and fallback designs earn their keep. The screens you design for "when things break" are invisible until the worst moment — then they're everything.
failover
Cloud & Infrastructure

Automatically switching to a backup system when the main one fails, so service continues with minimal interruption. Like a generator kicking in the instant the power cuts. The user ideally never notices the handoff.

Failover is why a site can wobble for a moment and recover instead of staying dead. It explains the brief "blip" users sometimes see — a momentary error before things snap back to normal.
logs
Cloud & Infrastructure
[02:11:04] ERROR db connection timeout
A timestamped, running record of what a system did — every notable action, warning, and error, in order. When something breaks, the logs are the security-camera footage you rewind to see what happened just before.

"What do the logs say?" is the first question in most outages. You won't read raw logs daily, but knowing they exist helps you understand how teams pinpoint when and where something went wrong.
incident
Cloud & Infrastructure

An unplanned disruption serious enough to warrant a coordinated response. Teams declare an incident, assign roles, fix it, then write a "what happened and why" review afterward. The formal, structured version of "something's on fire."

Incidents often produce action items that touch design — better error messaging, a status page, clearer alerts. Understanding the incident process helps you contribute the user-facing pieces of the response.
CI
CI/CD & Dev Process

The practice of automatically building and checking code every time someone changes it, so problems are caught immediately instead of piling up. Each change gets vetted on arrival, like a spell-checker that runs the instant you finish a sentence.

CI is why a tiny mistake in a shared file gets flagged within minutes. When your design token or copy change "fails CI," it means an automatic check caught something before it reached users.
CD
CI/CD & Dev Process

The automated step that takes code which has passed all checks and releases it — to staging, or all the way to production — without someone manually pushing it out. The second half of the assembly line: once it passes inspection, it ships itself.

CD is why an approved change can go live within minutes of merging, no manual upload required. It explains how "I merged it and it was live almost instantly" actually happens.
build
CI/CD & Dev Process
npm run build
Assembling all the separate source files into the final, optimized version that actually runs. The raw ingredients get cooked into the finished dish. If anything's malformed, the build fails before it produces anything.

"The build is broken" means the site can't even be assembled, so nothing can ship — including your changes. A broken build blocks everyone, which is why a stray typo in a shared file gets urgent attention fast.
pipeline
CI/CD & Dev Process

The ordered series of automated steps code passes through from "just changed" to "live," each one a checkpoint that can pass or fail. Like a factory line with inspection stations — clear one to reach the next.

When your PR runs a pipeline, you can see exactly which stage passed or failed. That visibility lets you tell the difference between "my code is wrong" and "an unrelated test is flaky" without guessing.
feature flag
CI/CD & Dev Process
if (flags.newCheckout) { ... }
A switch that turns a feature on or off without changing the code that's already shipped. The feature can be live in the codebase but hidden from users until you flip it on — for everyone, or just a chosen few. A dimmer switch for functionality.

Feature flags are a design superpower: they enable gradual rollouts, A/B tests, and "show this to 5% of users first." If you're planning a phased launch, flags are the mechanism that makes it possible.
deploy
CI/CD & Dev Process

The act of pushing a version of the code out to a running environment so it actually takes effect — most importantly to production, where users meet it. Building is cooking the dish; deploying is serving it to the table.

"When's the next deploy?" tells you when your merged change will actually reach users. Merged and deployed aren't the same — work can be approved and waiting for the next release window.
rollback
CI/CD & Dev Process

Returning a live site to its previous working version after a bad release — a fast, whole-system undo. Instead of fixing the new problem under pressure, you restore the last version everyone knows was fine.

Rollback is the safety net behind shipping fast. It's why teams can take risks on a release — if something's badly wrong, they can revert in moments. It also means a fix you saw live might briefly disappear if a deploy gets rolled back.
environment variable
CI/CD & Dev Process
STRIPE_KEY=sk_live_...
A setting that lives outside the code and can differ per environment — staging versus production, for example. The same code reads these values to behave correctly in each place. Like the same appliance plugged into different outlets with different voltages.

Environment variables explain why staging can point at test data while production points at the real thing, using identical code. When something behaves differently across environments with no visible code change, a differing variable is often why.
code review
CI/CD & Dev Process

The step where another person reads your proposed change, asks questions, suggests improvements, and approves before it merges. The human quality check that sits alongside the automated ones. Peer review, for code.

Designers increasingly take part in code reviews for token, copy, and UI changes. Knowing what a review is — and that comments are normal, not criticism — lets you participate confidently instead of feeling audited.
linting
CI/CD & Dev Process
eslint src/
An automatic checker for style and consistency — formatting, naming, small mistakes — separate from whether the code works. It keeps a codebase looking uniform no matter how many people touch it. Like a grammar checker for code.

Linting is the engineering cousin of a design system's rules — automated consistency enforcement. A "lint error" on your change is usually a quick formatting fix, not a sign anything's actually broken.
test
CI/CD & Dev Process
expect(button.color).toBe(token.primary)
An automated check that confirms a specific piece of the app behaves the way it's supposed to. Run them all and you quickly learn whether a change broke anything. Like a checklist that re-verifies itself every time the work changes.

When a change "breaks tests," it means an automatic check noticed different behavior. That's often good — it surfaces ripple effects of your change instantly, like discovering one token touches 47 components.
coverage
CI/CD & Dev Process
Coverage: 84% of statements
A measure of how much of the code is watched by tests. High coverage means most changes will trip a test if they break something; low coverage means problems can slip through unnoticed. A gauge of how well-guarded the code is.

Coverage explains why some changes get loud, immediate feedback and others sail through silently. Well-covered areas catch your mistakes early — a feature, not a frustration.
authentication
Security & Compliance
(login that proves identity — "authn")
Proving you are who you claim to be, usually by logging in. The front-door ID check before a system trusts you at all. Distinct from what you're then permitted to do.

Every login, signup, password reset, and "session expired, sign in again" flow is authentication design. Knowing the term — and that it's separate from permissions — sharpens how you design the "who are you" moments.
authorization
Security & Compliance
(permission check — "authz")
Deciding what an already-identified user is allowed to do or see. You can be authenticated (logged in) but not authorized (not permitted) for a specific action. The ID check gets you in the building; authorization decides which doors open.

"You don't have access to this" states are authorization design. Mixing it up with authentication leads to confusing messages — telling someone to log in when they're already logged in and simply lack permission.
HTTPS
Security & Compliance
https://acme.com
The secure version of the web's basic protocol. The "S" means the connection between browser and server is encrypted, so data can't be read or tampered with along the way. The little lock icon in the address bar is its visible badge.

HTTPS is a baseline trust signal users have learned to look for. A missing lock or a "not secure" warning actively undermines confidence — which is why every page handling real data needs it.
encryption
Security & Compliance
(scrambling data so only a key can read it)
Turning readable information into scrambled nonsense that only someone with the right key can turn back. It protects data both while it travels and while it's stored. Like writing in a cipher only the intended reader can decode.

Encryption underpins the "your data is safe" promises in your UI. Understanding it lets you design honest security messaging — and know when phrases like "end-to-end encrypted" are accurate versus marketing.
PII
Security & Compliance
(name, email, SSN, address — Personally Identifiable Information)
Any data that can identify a specific real person — names, emails, phone numbers, government IDs, home addresses. It's governed by stricter handling and legal rules than ordinary data because exposing it can harm real people.

Whenever a form collects PII, you're designing something with legal and ethical weight. Knowing what counts as PII helps you design appropriate consent, clarity, and "why we need this" reassurance.
data retention
Security & Compliance
(policy: "delete logs after 90 days")
The rules for how long different kinds of data are kept and when they're deleted. Good practice is to keep sensitive data only as long as genuinely needed, then remove it. Less "store everything forever," more "hold only what's necessary, only as long as necessary."

Retention shapes features like "download your data" and "delete my account." Understanding it helps you design honest, compliant flows around what happens to a user's information over time.
zero trust
Security & Compliance
(verify every request, trust none by default)
A security approach that assumes no request or user is automatically safe — even from inside the network — and verifies everything every time. The opposite of "you're in the building, so you must be fine." Trust is earned per action, not granted by location.

Zero trust can mean more frequent verification in the UI — re-confirming identity for sensitive actions, step-up auth. Knowing the principle helps you design those checks as reassurance rather than friction.
vulnerability
Security & Compliance
(an exploitable weakness, e.g. an unvalidated input)
A weakness in a system that someone could exploit to cause harm — steal data, break something, get unauthorized access. Found and fixed before bad actors find them, ideally. A gap in the fence, located before anyone climbs through. (Often shortened to "vuln" in conversation.)

Some vulnerabilities start as design gaps — a confusing field, a missing confirmation, an oversharing default. Recognizing that helps you see when a design choice is also a security choice.
penetration testing
Security & Compliance
(authorized simulated attack — "pen test")
Hiring skilled people to attack your own system on purpose, with permission, to find security holes before real attackers do. They think like an adversary so the weaknesses get patched first. A controlled break-in, run by the good guys.

Pen test findings often include UX-adjacent issues — exposed controls, weak confirmations, oversharing. Knowing the term helps you understand where some security-driven design changes originate.
compliance
Security & Compliance
(meeting standards like SOC 2, GDPR, HIPAA)
Meeting the formal security and privacy rules your industry, customers, or laws require. It's often a prerequisite to selling to certain clients or operating in certain markets. The documented proof that you handle data responsibly.

Compliance drives real UI requirements — consent banners, data-export tools, audit trails, specific disclosures. Understanding it helps you see why certain "boring" screens are non-negotiable rather than optional polish.
access control
Security & Compliance
(role-based permissions: who can do what)
The system of deciding who is allowed to see or do what, and enforcing it. It keeps sensitive actions and data limited to the right people. The set of rules behind "you have permission" and "you don't."

Access control is interface design as much as backend logic — which controls appear, which are disabled, what an under-permissioned user sees. Designing these states clearly is how access control becomes usable instead of confusing.
audit log
Security & Compliance
[2026-06-27 14:03] user:42 changed role of user:88
A secure, tamper-evident record of who did what and when within a system — especially sensitive actions. When something needs accounting for, the audit log is the authoritative history. A logbook you can't quietly edit.

Audit logs frequently need a human-readable interface — for admins, reviewers, or auditors. Designing that history to be scannable and trustworthy is real, compliance-relevant design work.
database
Data & Databases
(e.g. PostgreSQL, MySQL)
An organized store where an app keeps all its information so it can be saved, found, and updated reliably. Far more structured than a pile of files — more like a well-run warehouse with labeled shelves. Almost every app you use sits on top of one.

Every piece of real data in your designs — a username, a saved draft, a setting — lives in a database. Understanding that helps you reason about what's stored, what's temporary, and what has to persist between sessions.
table
Data & Databases
users, workspaces, orders
A single collection of one type of thing inside a database, organized like a spreadsheet — columns define the kinds of info, rows are individual records. One table for users, one for orders, and so on.

Tables often map closely to the "objects" in your design — users, projects, messages. Thinking in tables helps you align your information architecture with how the data is actually structured.
schema
Data & Databases
(the structure: tables, fields, relationships)
The blueprint of a database — which tables exist, what fields each one holds, and how they relate. It defines the *shape* of the data before any actual data fills it in. The floor plan, not the furniture.

When you map out what information a feature needs and how its pieces relate, you're sketching a schema. Collaborating on it early prevents mismatches between what you designed and what the data can actually support.
field
Data & Databases
email, created_at, workspace_name
A single piece of information in a record — one column of a table. A user record might have fields for name, email, and signup date. The smallest labeled unit of stored data. (Also called a column.)

Every piece of data you put on a screen corresponds to a field. Knowing this helps you ask precise questions — "is there a field for that?" — instead of assuming data exists that was never stored.
query
Data & Databases
SELECT SUM(amount) FROM sales WHERE month = 'June'
A specific request to a database for specific information. "Give me all orders from yesterday," "count active users." The database answers exactly what you ask — which means a poorly framed query returns confidently wrong results.

Most data on a screen arrives via a query. When numbers look wrong but the layout is right, the query is a prime suspect. Knowing this helps you point engineers upstream instead of doubting your own design.
SQL
Data & Databases
SELECT name FROM users WHERE active = true
The standard language for asking databases questions and getting data back. Readable enough that the intent is often clear even to non-engineers — SELECT name FROM users reads almost like English. The lingua franca of structured data.

You don't need to write SQL, but recognizing it helps you follow data conversations and even sanity-check what a screen is *supposed* to be pulling. It demystifies where your numbers come from.
primary key
Data & Databases
id: 4471 (unique per row)
A unique identifier for each record in a table — no two rows share one. It's how the database tells records apart with certainty, even if other details match. A fingerprint for a row.

Primary keys are why "two users named Alex Smith" never get confused by the system. They explain how an app reliably references the exact item you selected, even among look-alikes.
foreign key
Data & Databases
workspace_id: 4471 (points to a row in another table)
A field in one table that points to a specific record in another, creating a relationship between them. It's how a database connects related things — this order belongs to that customer. The thread linking two tables together.

Foreign keys are the data version of relationships you design constantly — a comment belongs to a post, a task belongs to a project. Understanding them clarifies how connected data is wired, and how a wrong link produces wrong results.
migration
Data & Databases
ALTER TABLE users ADD COLUMN avatar_url
A controlled, versioned change to a database's structure — adding a column, renaming a table, reshaping how data is organized. Migrations let the schema evolve over time without losing or corrupting existing data. Each one is a tracked, reversible step.

When you add a new field to a feature — a profile bio, a new status — a migration is what makes room for it in the database. Understanding this helps you grasp why "a small new field" can still require real engineering coordination.
index
Data & Databases
CREATE INDEX ON orders (customer_id)
A behind-the-scenes shortcut that lets a database find specific rows fast, without scanning the entire table. Like the index at the back of a book — jump straight to the right page instead of reading all of them. Essential as data grows large.

Indexes are often why one screen loads instantly and a similar one lags. When a list or search feels slow, "is that column indexed?" is a surprisingly relevant question for a designer to understand.
seed data
Data & Databases
(sample records loaded for testing/demos)
Fake but realistic data created to fill an app during development, testing, or demos — kept entirely separate from real user records. It lets you see how a feature looks "full" without touching or risking actual data. A stunt double for the real thing.

Good seed data is a design ally — it's how you preview empty, sparse, and overflowing states. Asking for realistic seed data (long names, edge cases) helps you design for reality instead of tidy placeholder text.
data integrity
Data & Databases
(constraints that keep data valid and consistent)
The guarantee that data stays accurate, consistent, and uncorrupted — no broken links between records, no half-finished changes, no contradictions. The systems and rules that keep the warehouse honest. When it fails, you get impossible states.

Data integrity failures surface as weird UI — an order with no customer, a comment on a deleted post, a count that doesn't add up. Recognizing these as integrity issues helps you report them precisely instead of as one-off "glitches."

Glossary

clone

branch

commit

HEAD

push

pull

pull request (PR)

merge

merge conflict

.gitignore

revert

API

endpoint

request

response

status code

JSON

headers

authentication

REST

webhook

rate limit

payload

server

hosting

environment

DNS

CDN

cache

load balancer

latency

downtime

failover

logs

incident

CI

CD

build

pipeline

feature flag

deploy

rollback

environment variable

code review

linting

test

coverage

authentication

authorization

HTTPS

encryption

PII

data retention

zero trust

vulnerability

penetration testing

compliance

access control

audit log

database

table

schema

field

query

SQL

primary key

foreign key

migration

index

seed data

data integrity