UI/UX Designer Jobs

1. Use semantic HTML first — a real <button> beats a div with a handler.
2. Everything usable by keyboard, with a visible focus ring and logical order.
3. Give images meaningful alt text; decorative images get empty alt.
4. Meet 4.5:1 contrast for body text; don't signal state by colour alone.
5. Test with a screen reader and automated tooling — neither alone is enough.

Watch out: Sprinkling ARIA onto non-semantic markup instead of fixing the markup.

At senior level: Bake a11y into the design system and CI so it can't regress.

1. Understand the problem and the constraints before sketching anything.
2. Research: talk to users, review data and look at prior art.
3. Diverge with low-fidelity concepts; don't fall for the first idea.
4. Prototype and test with real users; iterate on what breaks.
5. Hand off with specs and states, then measure after launch.

Watch out: Presenting only polished final screens with no reasoning.

At senior level: Show how you influence product strategy, not just execution.

1. Separate the work from yourself — the design is a hypothesis.
2. Ask clarifying questions to find the underlying concern.
3. Anchor the discussion on user goals and evidence, not taste.
4. Where you disagree, propose a test rather than arguing.
5. Follow up with what you changed and why.

Watch out: Defending every decision instead of listening for the real problem.

At senior level: Describe running critique sessions that raise the whole team's quality bar.

1. Write the decision you need to make first — that scopes the research.
2. Pick the cheapest method that answers it: 5 usability sessions beats a 500-person survey for finding usability problems.
3. Recruit from existing users or support tickets to save days.
4. Synthesise into patterns, not anecdotes, and share the raw clips.
5. State clearly what the research does and doesn't tell you.

Watch out: Running research with no decision attached — it becomes a report nobody uses.

At senior level: Build a continuous research habit so you're never starting cold.

1. Start from tokens: colour, type, spacing — the primitives everything composes from.
2. Build components with defined states and clear usage guidance.
3. Document when NOT to use a component, not just when to.
4. Version it and treat consumers as customers.
5. Measure adoption — an unused system is a cost, not an asset.

Watch out: Treating it as a Figma library rather than a shared product with code parity.

At senior level: Discuss governance, contribution models and deprecation strategy.

1. Start from user need and frequency of use — daily habits justify an app.
2. Check what native capability you actually require (camera, offline, push).
3. Weigh acquisition friction: web has no install step.
4. Factor in build and maintenance cost across two platforms.
5. Often the answer is web first, app once retention is proven.

Watch out: Choosing an app because it feels more serious, with no usage evidence.

At senior level: Frame it as a portfolio bet with a measurable trigger for building the app.