My progress
Menu

UI/UX Product Designer · entry diagnostic

UI/UX Product Designer: entry diagnostic

Ten questions on the core lessons this path builds on. It is for your own planning: it doesn't unlock anything, and it doesn't replace the final examination. Each explanation links to the core module to revisit if you got it wrong.

10 questions · for your own planning · it does not unlock anything and does not replace the final examination ·

1. A page has <input id="phone" type="tel"> and the text "Mobile number" above it in a <p>. What's the best fix so the text is the

Why each option is right or wrong

  • “Put the text in the input's placeholder attribute instead of the paragraph” (Incorrect): A placeholder disappears while typing and isn't a proper label.
  • “Make the paragraph bold, so that people see it belongs to the field” (Incorrect): Bold text still isn't linked to the field.
  • “Add title="Mobile number" to the input, which shows a tooltip” (Incorrect): Tooltips are hard to find, especially on phones.
  • “Use <label for="phone">Mobile number</label> instead of the <p>” is correct.

    A label linked with for names the field for screen readers and makes the text clickable.

    • Bonus: a bigger tap target.
    • Later: visible labels on every field (UX5, UX7).

📖 Revise: Module 13: Forms and Inputs

2. Which HTML structure gives a page a clear outline for screen reader users?

Why each option is right or wrong

  • “Every heading written as a <div> with large bold text” (Incorrect): Styled divs look like headings but aren't announced as headings.
  • “Several <h1> elements, one for each section of the page” (Incorrect): One main heading per page is clearer; sections use <h2>.
  • “No headings at all, with bold paragraphs used instead of headings” (Incorrect): Without headings, screen reader users can't navigate by section.
  • “One <h1>, then <h2> for each section and <h3> within them” is correct.

    Headings in order let people jump through the page and understand its structure.

    • Also: header and main landmarks.
    • Kit: one h1 per page (test 9).

📖 Revise: Module 12: Webpage Content

3. A container is set to width: 600px. What happens on a phone 360 pixels wide?

Why each option is right or wrong

  • “The browser shrinks the container to fit the screen on its own” (Incorrect): A fixed width stays fixed.
  • “The text inside gets smaller automatically to fit the box” (Incorrect): Text size doesn't change because of the container.
  • “Nothing, as phones show a desktop layout at 600 pixels anyway” (Incorrect): With the viewport meta tag, phones use their real width.
  • “The page scrolls sideways, because the box is wider than the screen” is correct.

    Fixed widths don't adapt. max-width: 600px with width: 100% would.

    • Check: 320 pixels wide (WCAG reflow).
    • Later: mobile-first layout (UX5).

📖 Revise: Module 16: Responsive Websites

4. Which CSS gives a gap between the label and the field that matches a spacing scale?

Why each option is right or wrong

  • “margin-bottom: 7px on the label, chosen by eye on this screen” (Incorrect): Values chosen by eye drift from screen to screen.
  • “Adding three &nbsp; characters after the label text in the HTML” (Incorrect): Spaces in text aren't a reliable way to make layout gaps.
  • “A transparent image 7 pixels high placed under every label” (Incorrect): An old trick that adds clutter and isn't needed with CSS.
  • “margin-bottom: var(--space-1) on the label, from the spacing tokens” is correct.

    A custom property from a token keeps spacing consistent.

    • Change once: in the tokens file.
    • Later: design tokens (UX9).

📖 Revise: Module 14: Introduction to CSS

5. A layout needs a heading at the top, a list of cards and a button at the bottom, in one column on phones. What's the simplest approach?

Why each option is right or wrong

  • “Absolute positioning for every element at a fixed pixel position” (Incorrect): Absolute positions break as content and screens change size.
  • “A table with one row for each element, to hold them in place” (Incorrect): Tables are for data, not layout.
  • “Floats on every element, cleared with an empty div after each one” (Incorrect): Floats are an older technique and aren't needed here.
  • “Normal flow, or flexbox with flex-direction: column and a gap” is correct.

    Elements stack in source order and adapt to any width.

    • Wider screens: CSS grid for columns.
    • Later: layout grids (UX6).

📖 Revise: Module 15: Page Layouts

6. A button's click handler is attached to a <div>. What doesn't work?

Why each option is right or wrong

  • “Clicking it with a mouse, because divs can't receive clicks” (Incorrect): Divs can receive mouse clicks.
  • “Changing its colour on hover, because divs don't support hover styles” (Incorrect): Hover styles work on divs.
  • “Showing text inside it, because divs can only hold images” (Incorrect): Divs can hold text.
  • “Reaching it with Tab and pressing it with Enter or Space” is correct.

    A div isn't keyboard-focusable or announced as a button; <button> is.

    • Kit: the starter's time slots.
    • Later: keyboard and focus (UX7).

📖 Revise: Module 19: Browser Interactions

7. Data arrives as [{"time": "10:00"}, {"time": "10:30"}]. How do you read the second time in JavaScript?

Why each option is right or wrong

  • “data.time[1], which picks the second value of the time key” (Incorrect): time belongs to each object, so pick the object first.
  • “data[2].time, as it's the second item in the list” (Incorrect): Lists count from 0, so the second item is index 1.
  • “data["10:30"], using the value itself as the key” (Incorrect): The array is read by position.
  • “data[1].time, which is "10:30"” is correct.

    Index 1 is the second object, and time is its field.

    • Kit: data/clinics.json has a list of clinics with slots.
    • Later: realistic prototype data (UX8).

📖 Revise: Module 25: APIs and JSON

8. A component library has a Button component used across an app. Why is that better than styling each button separately?

Why each option is right or wrong

  • “Separate styles load faster, since each page has less CSS to read” (Incorrect): The difference is small; consistency matters more.
  • “Components let each team pick a different colour for buttons” (Incorrect): The point is consistency, not variety.
  • “Browsers require a component library before they show any buttons” (Incorrect): Browsers don't.
  • “Changes and fixes made once reach every button across the app” is correct.

    Shared components keep the product consistent and accessible.

    • Example: one focus style for every button.
    • Later: design systems (UX9).

📖 Revise: Module 32: Components and Props

9. A booking form stores the patient's phone number. What's the most important privacy step?

Why each option is right or wrong

  • “Ask for the number twice, so mistakes are easier to catch” (Incorrect): That's about accuracy, and asking twice annoys people.
  • “Store the number in the page's URL so it's easy to find again” (Incorrect): URLs are saved in history and logs, which exposes the number.
  • “Show the full number on every page so the patient can check it” (Incorrect): Showing it everywhere exposes it to anyone nearby.
  • “Collect only what's needed, say why, and limit who sees it” is correct.

    Minimising, explaining the purpose and limiting access are core privacy principles.

    • Law: India's DPDP Act, 2023.
    • Later: masking on screen (UX7) and consent in research (UX2).

📖 Revise: Module 79: Privacy and Data Protection

10. A product team has an idea for a new feature. What should come before building it?

Why each option is right or wrong

  • “A launch date, so that everyone knows when it's due” (Incorrect): A date doesn't show whether the idea solves a real problem.
  • “A full set of high-fidelity screens for every page” (Incorrect): Polished screens before understanding the problem often get redone.
  • “Hiring more developers to build the feature quickly” (Incorrect): Speed doesn't help if the feature isn't needed.
  • “Checking the problem is real for users, and how success will be measured” is correct.

    Evidence about the problem and an agreed measure stop teams building the wrong thing.

    • Methods: interviews, testing, analytics.
    • Later: problem statements (UX1).

📖 Revise: Module 97: Product Development

← PreviousPath guide
ProLearners Assist