Entry-Level UI Designer Interview Preparation Guide

Direct answer

Strong candidates use this question to show they can update their own belief when evidence disagrees with it, not to show off a big win. Pick a real story where you had genuine conviction, the test data actually contradicted it, and you can say exactly what changed your mind and what the after-state measured.

Structured elaboration

STAR stands for Situation, Task, Action, and Result: Situation sets the context, Task is what you were trying to achieve, Action is what you specifically did, and Result is the measurable outcome. For this question, weight Action and Result heavily. The interviewer is really asking three things: how much evidence did you have and was it enough to trust, what did the team give up by reversing course, and did the thing you promised actually move after the change.

Worked example

Situation. I designed a compact summary card for an account dashboard, prioritizing scannability by hiding secondary details behind a "see more" toggle. Going in, I believed it was the stronger layout.

Task. Validate the design before it shipped into the shared component library, since other product teams would reuse the pattern.

Action. I ran a moderated usability test (a facilitator watches and interviews people using the product live) with 8 participants doing a realistic task: find whether there was a pending charge on the account. 6 of the 8 participants never found the pending-charge indicator at all, because it was hidden behind the toggle; among the 2 who did find it, time-to-find averaged about 30 seconds. I ran the older, more exposed layout as a counterbalanced second condition inside the same sessions rather than quoting a remembered number for it, and there 8 of 8 found the charge, averaging roughly 10 seconds. Both of those averages are over successful finds only, and I say so whenever I quote them: a task nobody completes has no completion time, so an unqualified "average time-to-find" silently drops the failures and flatters whichever design failed more. I brought the recordings and the count, 6 of 8 missed it, to the team instead of my impression, and proposed two options: keep the compact layout and add a persistent status indicator outside the toggle, a small change, or revert to the fully expanded layout, a bigger visual cost but zero discoverability risk. I recommended the persistent indicator as the smaller, testable change.

Result. After adding the indicator, a follow-up test with 8 new participants, run under the same moderated protocol and the same task wording, found 7 of 8 could locate the pending charge, averaging about 12 seconds among those 7. The headline I reported was the find rate, 2 of 8 to 7 of 8, not the seconds, and the reason is worth stating because it is the part people get wrong: matching the participant count across rounds is not the same as matching the basis. The 30-second before average is computed over only the 2 people who succeeded, the fastest and luckiest slice of the round, while the 12-second after average is computed over 7 of 8. Read naively, that comparison actually understates the improvement, since the 6 who never found the charge contribute no time to the before number at all. If you want a timing comparison that is genuinely on one basis, either cap every unsuccessful attempt at the task time limit and average over all 8 in both rounds, or report the find rate and quote the timings only for the finders with the denominator attached, which is what I did. The team adopted the indicator into the shared component library.

Trade-offs and pitfalls

• The temptation is to tell this story as "I was wrong, I'm humble," which undersells the actual skill being tested: reading evidence rigorously enough to change a real decision, not admitting fault.
• Be honest about sample size. 6 of 8 is a real, useful signal for a usability problem this consistent, but it is not the same as proof from a large-sample A/B test (an experiment that shows two versions to different groups of real visitors and compares an outcome metric at scale). Say so if asked, rather than inflating a small study into "we proved."
• A design that loses a usability test is not automatically wrong everywhere. Name what you kept from your original idea, such as the compact scannability goal, and what specifically needed a different solution.

Direct answer

A component library needs four kinds of confidence, each answering a different question: does the logic work (unit tests), do the pieces work together (integration tests), does it still look right (visual regression), and is it accessible (automated a11y checks plus periodic manual review). Run the fast, deterministic ones on every pull request and push the slower or more manual checks to a scheduled cadence, so contributors get quick feedback without every PR waiting on a full audit.

Structured elaboration

Test types, when they run, who owns them

Ownership matters because it decides who is blocked by a failing check: an engineer should not be the sole approver of a visual regression diff on a component's intentional redesign, and a designer should not be expected to debug a failing unit test.

Deciding what is actually necessary

Start from the question "what would let a change ship with confidence," not "what testing tools exist." A component library specifically needs to guard against three failure modes: broken behavior, broken visuals, and broken accessibility. Each failure mode maps to one of the layers above; if a proposed test does not clearly guard against one of the three, it is probably not worth the maintenance cost of writing and keeping it green.

Pipeline placement

• On every PR (fast, blocking): unit, integration, the fast automated a11y subset, and visual regression only for the stories touched by the diff.
• Nightly (slower, non-blocking for individual PRs): full visual-regression sweep across every story, theme, and viewport; a fuller accessibility audit tool pass.
• Before shipping a new component or a significant visual change (manual, gated): a short manual accessibility pass with an actual screen reader and keyboard-only navigation, since automated tools reliably catch missing labels and low contrast but do not reliably catch a confusing focus order or an unannounced state change.

Worked example

A Tabs component is being added to the library.

1. Unit tests (engineer-owned) verify that arrow-key navigation moves focus between tabs and that the correct tab panel is shown for the active tab. These run on every PR in under a second.
2. Integration tests verify Tabs composes correctly when nested inside the library's Card component, since layout-context bugs only show up in composition, not in Tabs alone.
3. jest-axe runs against the rendered Tabs markup on every PR and would catch, for example, a missing role="tablist" or an unlabelled tab.
4. A Storybook story with all tab states (active, disabled, overflow with many tabs) is snapshotted; the PR run only checks the two states the diff touched, and the full state set runs on the nightly sweep.
5. Before merge, a designer and engineer pair for five minutes to tab through the component with the keyboard only and confirm focus does not visibly jump or disappear, since this is the kind of defect automated a11y tools do not reliably flag.

Trade-offs and pitfalls

• Requiring the full test suite, including a manual accessibility pass, on every single PR (including a one-line copy fix) slows contribution enough that people route around it; scale the required checks to the size and risk of the change.
• Automated accessibility tools catch a meaningful but incomplete slice of real accessibility problems (missing labels, contrast, invalid ARIA); treating a green axe-core run as "accessible" without ever doing a manual pass on new components is a common false sense of security.
• Assigning visual regression approval solely to engineers means intentional design changes get rubber-stamped by someone without the design context to judge them, and solely to designers means technical false positives (font-rendering noise) block PRs unnecessarily; shared ownership with a clear split (technical diff versus intentional visual change) avoids both failure modes.
• Skipping integration tests because "the unit tests all pass" misses the most common real-world bug class in a component library: two individually-correct components that misbehave only when composed together.

Direct answer

Budget, timeline, technical dependencies, legal or privacy requirements, and data quality or accessibility are the five categories worth checking on nearly every problem; each one, left unstated, tends to surface late and expensively rather than early and cheaply.

Structured elaboration

Budget: a fixed engineering or research budget changes the ambition level of the acceptable solution; a problem framed without it invites a proposal that's infeasible before anyone realizes it.

Timeline: whether there's a hard external deadline (a contractual commitment, a regulatory date) versus a soft internal target changes how much discovery is worth doing before committing to a direction.

Technical dependencies: constraints like "can't change the backend data model" or "must work within the existing authentication system" bound the solution space before design work starts; discovering them mid-build is expensive.

Legal or privacy: requirements like data-residency rules or consent requirements can eliminate entire categories of otherwise-reasonable solutions, and they're the category most likely to be assumed away by a team without direct legal expertise.

Data quality or accessibility: whether the data needed to measure success or diagnose the problem actually exists, and at what quality, determines whether an experiment-based approach is even possible, or whether you're starting from a smaller, more manual signal.

Worked example

Framing a project to "reduce fraud losses on the platform": surfacing budget (a fixed quarter of engineering capacity) changes the solution from a from-scratch machine-learning model to an incremental rules-based improvement to the existing system; surfacing legal (regulatory reporting requirements for declined transactions in certain jurisdictions) means any new decisioning logic needs an audit trail, which is easy to omit from a design that didn't ask this question up front; surfacing data quality (the labels for "confirmed fraud" are only reliable going back 6 months due to a past data-pipeline change) bounds how much historical data a model-based approach could actually train on, changing the realistic scope of what's achievable in the given timeline.

Two design-audience versions of this same checklist ask for an identical answer with different framing language ("what constraints should you record when framing a UX problem" and "list common constraints surfaced during problem framing for UI work"), confirming the checklist itself, not its phrasing, is the tested content.

Trade-offs and pitfalls

Surfacing every constraint category on every problem, exhaustively, before any work starts adds real overhead, and for a small, well-understood problem it's disproportionate; the categories are a checklist to consult, not a mandatory five-section document for every request. The bigger risk is the opposite: skipping legal or data-quality checks specifically, because they require pulling in someone outside the immediate team, is the most common way a project discovers a blocking constraint late, after design or even engineering work has started.

Direct answer

"Fill container," "hug contents," and fixed size are a design tool's Auto Layout sizing behaviors: they control how a layer's own size responds when its content or its parent changes. They work alongside the older, separate constraints system (pin left, right, top, bottom, center, or scale), which controls where a layer sits and how it stretches when its parent frame is resized, whether or not that parent uses Auto Layout at all. For a header with a fixed logo on the left, fixed action icons on the right, and a center area that should adapt, the combination that gets it right is: logo and icon group set to a fixed or hug-contents size so they never distort, and the center area set to fill the remaining space, so it's the only part that grows or shrinks as the header's width changes.

Structured elaboration

Fixed size: the layer keeps an exact pixel width or height regardless of content or container. Use it for anything that must never distort, like a logo mark.

Hug contents: the layer's size is computed from what's inside it, so adding a longer label grows it just enough to fit, and shrinking the content shrinks it back. Appropriate for a text label or an icon group whose natural size is the size you want.

Fill container: the layer expands to take whatever space is left in its parent after fixed- and hug-sized siblings have claimed theirs. Appropriate for the one element in a row that should absorb any extra or missing space.

Classic constraints: available on any layer, whether or not it's inside an Auto Layout frame. Pinning a layer's edges to its parent's edges (left, right, top, bottom, center, or scale) means that when the parent resizes, pinned layers move or stretch relative to those pins. This is the tool to reach for on a plain frame that isn't using Auto Layout, or for a layer that needs parent-relative behavior the sizing modes above don't directly express.

Applying this to the header: place the logo, center area, and icon group inside one horizontal Auto Layout frame. Logo: fixed or hug contents, so it never stretches or shrinks. Icon group: the same, so icons stay crisp and evenly spaced. Center area (a search field, nav links, or a page title): fill container, so as the header's overall width changes across breakpoints, the center area absorbs that change while logo and icons hold their exact size at both ends. If the header is a plain, non-Auto-Layout frame instead, the equivalent with constraints is: logo pinned left, icon group pinned right, and the center element constrained to both left and right at once (a "stretch" constraint), so its width recalculates as the parent frame's width changes while the two ends stay anchored.

Worked example

A header is 1200 pixels wide on desktop: logo fixed at 120px, icon group fixed at 96px (three 32px icons), leaving 984px for a center search field set to fill container. At a 768px tablet breakpoint the header narrows to 768px: logo and icons stay exactly 120px and 96px, unchanged, since they're fixed or hug-sized, and the search field, set to fill container, recalculates to 552px automatically, with no manual repositioning. Built without Auto Layout, using constraints instead, the equivalent setup pins the logo left, the icon group right, and gives the search field a left-and-right stretch constraint, so narrowing the parent frame from 1200 to 768px stretches the field to the same 552px. The visible result is identical; what differs is the mechanism, a recalculated relationship versus a constraint recomputed on parent resize.

Trade-offs and pitfalls

Setting the center area to hug contents instead of fill container is a common mistake: it will size to its own placeholder text rather than expanding to use the available header width, so the layout won't look adaptive at all until that's corrected. Applying constraints to a layer nested directly inside an Auto Layout frame usually has no effect, since the parent's own sizing modes take priority for direct children; mixing the two systems on the same layer is a frequent source of "why isn't this resizing the way I expect" confusion, so it's worth knowing which system actually governs a given layer before debugging it. For a header with more than three zones, logo, nav links, search, and an avatar, for example, a single fill-container element in the middle usually isn't enough on its own, and that typically calls for nested Auto Layout frames rather than forcing one flat row to do everything.

Direct answer

A persona is a research-backed composite profile of a real user cluster: goals, behaviors, pain points, and context, used to align a team's mental model of who they are designing for. It is useful when it is grounded in real research and treated as a working hypothesis; it becomes dangerous the moment it hardens into an unquestioned fact, because then it excuses decisions ("our persona would not need that") instead of informing them.

Minimal evidence-backed template for a consumer mobile product (kept to six fields on purpose)

1. Name and one-line archetype
2. Primary goal in this app
3. Key behaviors and context of use (when, where, and how they use the phone)
4. Top pain point, stated as a root cause rather than a symptom
5. Source and confidence: research method plus sample size, for example "8 interviews plus 40k sessions of analytics"
6. Success metric tied to this persona

Keep it to one page and link out to the raw research for anyone who needs the detail. Before calling it evidence-based, triangulate: look for at least one qualitative source (interviews or usability sessions) and one quantitative source (analytics or survey) that agree, and watch for saturation, meaning interviews stop surfacing new themes, as the signal that you have gathered enough.

Three anti-patterns to avoid, each with its remedy

• Proto-persona presented as fact: a profile built purely from stakeholder assumptions gets shown without labeling it as unvalidated. Remedy: mark unvalidated personas as a hypothesis until a small targeted study backs them, and date-stamp every version.
• Overloaded biography: a fake name, stock photo, and hobbies that have no bearing on the product. Remedy: cut anything that would not change a design decision; if removing a detail would not change what you build, it does not belong.
• One-size-fits-all persona: either a single persona that averages away real behavioral differences, or so many personas nobody can hold them in their head. Remedy: split only where behavior actually diverges in ways that change the design, and cap the active set at two to four personas per product.

Common misuses when presenting to product teams

Presenting a persona as a literal individual rather than a range invites the room to argue about that one person's preference instead of the underlying need. Treating one persona's feedback as validation for the entire user base is another common slip, as is pulling the persona out only when it supports a decision the team already made. The fix in each case is the same: present the persona as a distribution ("most users in this cluster...") and always show the evidence alongside it, not the persona alone.

Trade-offs and pitfalls

Keep the persona a living artifact, not a static one: name a revisit cadence, for example every 6 to 12 months or after a major research round, so it stays useful to designers and PMs rather than fossilizing into wall art nobody checks against reality.

Approach (as a UX Designer)
I prioritize clarity, scannability, and task-orientation: labels should use words users say, avoid jargon, and surface the most common user goals.

Three concrete do / don’t examples

1. Do: “Order status”. Don’t: “My Transactions”

• Why: “Order status” matches user intent when they want to track shipments; “My Transactions” is banking jargon and hides discoverability. I’d validate with tree tests to confirm.

2. Do: “Gift cards & balance”. Don’t: “Store Credit”

• Why: Many shoppers think “gift card” first. Combining common term + function reduces cognitive load and helps users find redeemable value faster.

3. Do: “Returns & exchanges”. Don’t: “After‑purchase options”

• Why: Users scan menus for concrete actions. Explicit verbs (Returns, Exchanges) make affordances obvious, improving success in task-driven flows.

Design notes

• Prefer user language from research, use verbs for actions, keep labels 1–3 words, and test with first-click and tree tests for unfamiliar domains.

I treat the single brand color as a seed to derive from systematically, using hue, saturation, and lightness math, rather than picking each additional color by eye. That keeps the palette looking like one coherent system instead of a grab-bag of colors that happened to look nice individually.

Deriving the palette

• Primary. I generate a tonal ramp (a set of lighter and darker versions of the same hue) from the brand color, typically 7 to 9 steps from a very light tint down to a very dark shade, so the brand hue can be used for backgrounds, default states, hover states, and text-on-color, not just one flat swatch.
• Secondary. Rather than picking a secondary color on taste, I rotate the brand hue by a fixed amount, commonly 30 degrees for an analogous "cousin" color that feels related but distinguishable, keeping saturation and lightness close to the primary's so the two feel like they belong together.
• Semantic colors (success, error, warning). These follow near-universal convention over brand-matching: green for success, red for error, amber or orange for warning. What I do tune to the brand is the saturation and lightness "family," so if the rest of the palette is fairly muted, the semantic colors are muted too instead of being pure, jarring stoplight colors that look like they belong to a different product.
• Neutrals. I build 9 to 10 steps from near-white to near-black for text and backgrounds, often with a very slight tint of the brand hue at low saturation (2 to 5 percent) so the grays feel warm or cool in a way that's consistent with the rest of the palette instead of looking dead and generic.

A worked example

Take a brand blue at hue 210°, saturation 70%, lightness 45% (roughly #2273C3). For an analogous secondary, I rotate the hue by 30° and keep saturation and lightness fixed:

$$H_{secondary} = H_{brand} - 30^\circ = 210^\circ - 30^\circ = 180^\circ$$

That gives hue 180°, saturation 70%, lightness 45%, a teal (#22C3C3) that clearly relates to the brand blue without being a random unrelated color. For a success green, I'd start from convention (roughly hue 140-150°) and match the family's saturation and lightness weight rather than deriving it mathematically from the brand hue, since color meaning has to win over brand-matching there; something like hue 145°, saturation 55%, lightness 38% (#2C9658) reads clearly as "success" while still sitting in the same moderately saturated tonal family as the rest of the palette.

How many colors is too many

The test I use for "does this look like a rainbow": every saturated hue on the screen should have a distinct, nameable functional role you could point to (this is the brand accent, this is the error state). If a single screen regularly shows more than three or four saturated hues at once, something is likely being used decoratively rather than functionally, and that's the palette losing discipline.

The simpler, primary-and-secondary-only version

If the ask is just "derive a primary and secondary from one brand color" without the full semantic and neutral set, the same hue-rotation approach still applies: rotate ±30° for an analogous secondary that feels related, or a full 180° for a higher-contrast complementary secondary meant to be used sparingly as an accent rather than a base color.

A lightweight way to hand this off

Once the palette exists, I attach a short usage note next to it (for example, "primary is for default buttons and links; secondary is for secondary actions and badges only, never the dominant color on a screen"), so other teams know the intent without needing a formal naming or versioning system, that level of governance is a separate exercise from getting the palette itself right.

Direct answer

Treat the first ninety days as three distinct feedback phases rather than one long ramp: the first thirty days is mostly listening and asking calibrated questions of a wide set of people, the next thirty is testing that understanding through visible small contributions and targeted follow-up questions, and the last thirty is asking for a harder, more evaluative read now that there's real work to point to. At each phase, write down what you heard and what you changed because of it, so the loop is visible, not just felt.

Structured elaboration

• Days one to thirty: who and what. Talk to your manager (what does success look like at thirty, sixty, and ninety days, what's the biggest risk if this goes wrong), two or three peers doing similar work (what do you wish someone had told you when you started, what's the thing that trips people up here), and, if relevant, a couple of people upstream or downstream of your work (what do you actually need from this role that isn't written down anywhere). Questions here are deliberately open and low-stakes: "what should I be paying attention to that I don't know to ask about yet?"
• Days thirty-one to sixty: who and what. After producing something real, a first change, a first analysis, a first design, a first proposal, ask more targeted questions of whoever reviewed it: "was this the right level of detail," "did I miss context I should have had," "is there a pattern in what you're correcting that I should watch for?" This is also when to bring a specific check-in back to your manager: "here's what I've done, here's what I'm still unsure about."
• Days sixty-one to ninety: who and what. Ask for a more evaluative read, since there's now enough of a track record for the answer to be specific rather than generic: "if you were coaching me for the next quarter, what's the one thing I should focus on?" Ask this of your manager and at least one peer whose judgment you trust, since a manager's view and a peer's view often surface different things.
• Tracking that you're acting on it. Keep a simple running log, one line per piece of feedback: what was said, who said it, and what you changed or decided not to change and why. Bring this log into one-on-one check-ins with your manager (a regular short meeting between you and your manager), especially around the day-thirty and day-sixty marks, so your manager sees the pattern, not just individual points, and so you have to be honest with yourself about whether you actually followed through.

Worked example

The questions above stay constant, but what "producing something real" means in days thirty-one to sixty varies by the kind of work. For someone in a data-facing role, the first real deliverable is often getting the data model and who-needs-what-from-it right, so the targeted day-forty-five question becomes, "does my understanding of how this data actually gets used match reality," checked against a specific report or query. For someone in a design role, early feedback is often more about building credibility through a couple of small, well-executed pieces of work before asking for a harder critique, since a design opinion carries more weight once colleagues have seen competent delivery. For someone building technical proposals, such as an architecture document, a natural day-forty-five checkpoint is asking for feedback specifically on the early proposal itself and on communication style, since how something is proposed matters as much as what's proposed when you're new to a team. In every case, the log entry looks the same: what was said, what changed.

Trade-offs and pitfalls

Asking only your manager and skipping peers misses the day-to-day texture a manager doesn't see. Asking the same broad question the whole ninety days, instead of narrowing it as you get more context and more real work to point to, wastes the growing specificity available to you. Collecting feedback but never visibly acting on it reads as performative rather than genuinely coachable. And waiting until day ninety to ask for anything evaluative wastes the early window when small corrections are cheapest to make.

The mediocre version of this story picks a low-stakes example dressed up as high-stakes, "I wasn't sure which font to use," or describes a decision that was actually well-supported by data and calls it "incomplete information" for the sake of having a ready story. A strong answer has a decision where the missing information was real and the cost of being wrong was real too.

STAR (Situation, Task, Action, Result) skeleton to fill in:

• Situation: the deadline and context, and why the decision couldn't wait for full information.
• Task: what decision specifically had to be made, and by when.
• Action: what was missing or conflicting, how you assessed and mitigated the risk, how you filled the gap (an assumption, a proxy metric, or a small experiment or pilot), and how you documented and communicated the assumptions and trade-offs to stakeholders.
• Result: what happened, what you monitored afterward specifically in case you were wrong, and what changed afterward as a result.

Worked example: Situation: two weeks before a major customer's contract renewal, a data pipeline feeding both the billing team's invoicing system and the customer-success team's usage dashboards started producing numbers that disagreed with each other by about 12%, and nobody could say with certainty which one was correct in the time available. Both teams needed an answer within 48 hours: billing to send an accurate invoice, customer success to brief the account team before the renewal call. Task: decide which number to trust and ship, or delay the invoice, within 48 hours, with only partial diagnostic access, since the original raw event logs for the disputed window had already rotated out. Action: I mapped what was missing (no way to directly re-derive the raw events) and what conflicted (two independently computed aggregates). I used a proxy: the customer's own self-reported usage from their admin console as a third, independent check, and it landed within 2% of the billing team's number, not customer success's. That gave a defensible basis to trust the billing number, and to flag the customer-success dashboard as the likely-wrong one pending a fuller audit. I documented the assumption explicitly in a shared doc, which number was trusted, why, and the residual 2% uncertainty, and got sign-off from both the billing lead and the customer-success lead before sending anything, rather than deciding unilaterally, since a wrong invoice hits billing's numbers and a wrong dashboard hits customer success's credibility with the client, two different teams carrying two different kinds of exposure. Result: the invoice shipped on time and was later confirmed correct by a full pipeline audit. Customer success used the corrected number for the renewal call instead of the stale dashboard. I set a follow-up alert comparing the two source aggregates daily for the next month specifically to catch a recurrence early in case the proxy-based call had been wrong. Rather than treating it as a one-off, I wrote the incident into the team's on-call runbook as a named decision pattern, when two aggregates disagree with a hard deadline, check against an independent third source before picking one, so the next person facing this doesn't have to invent the approach from scratch.

A shorter version of the same shape shows up in machine learning work: a model's offline evaluation metric looks strong, but a second, independently computed slice of the evaluation set disagrees on one important segment, and a launch deadline is close. The same move applies: find an independent proxy, for example a small manual review of predictions on the disputed segment, document the assumption and the residual risk explicitly, and set a specific post-launch metric to monitor so a wrong call gets caught fast.

What separates a strong answer from a mediocre one on this specific question: a mediocre answer stops at "I made a judgment call and it worked out." A strong answer shows the actual mechanism used to fill the information gap, a proxy, not a guess, names who else had stakes in being wrong and how they were brought into the decision rather than just informed after the fact, and describes a concrete afterward-monitoring step, not a claim that it simply turned out fine.

I know the problem is framed well when the team can explain it without jumping to a solution.

A strong problem frame includes three things:

• The user problem. What is the user trying to do, and where are they getting stuck?
• The business goal. Why does solving this matter now?
• The constraints. What limits exist, such as time, technology, legal, or brand?

Success criteria are the measurable signals that tell us whether the work helped. I try to define one primary metric and a few guardrails. A guardrail is a metric that should not get worse while the main metric improves, such as support contacts, error rate, or time to complete.

Concrete example: if onboarding completion is 50 percent today, I might set the goal to raise it to 60 percent, while keeping support tickets and drop-off after day one flat or better. That is better than saying, "make onboarding nicer," because the team can test against something real.

If I cannot write the problem and success criteria in plain language, I keep researching before I design.