Tableau Quiz: Responsive Dashboards
10 questions · exam conditions
0:00
Responsive DashboardsQuestion 1 of 10

An author creates separate desktop and phone layouts for a dashboard. In the phone layout, the Sales worksheet is positioned below the filter controls. Later, the author changes the worksheet's color encoding and number formatting, but does not change dashboard positioning.

What should the author expect after the worksheet changes?

The new formatting appears only in the default layout because each device layout stores an independent worksheet copy.
The new formatting appears in both layouts, while the phone-specific position of the worksheet remains unchanged.
The phone layout returns to its automatically generated arrangement when the shared worksheet formatting changes.
The new formatting appears only after the author deletes and recreates the phone-specific device layout.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Responsive Dashboards

Practice Responsive Dashboards in Tableau with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Responsive Dashboards, giving you a quick way to practice the rules, question types, and explanations that matter most for Tableau.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

An author creates separate desktop and phone layouts for a dashboard. In the phone layout, the Sales worksheet is positioned below the filter controls. Later, the author changes the worksheet's color encoding and number formatting, but does not change dashboard positioning.

What should the author expect after the worksheet changes?

  1. The new formatting appears only in the default layout because each device layout stores an independent worksheet copy.
  2. The new formatting appears in both layouts, while the phone-specific position of the worksheet remains unchanged. (correct answer)
  3. The phone layout returns to its automatically generated arrangement when the shared worksheet formatting changes.
  4. The new formatting appears only after the author deletes and recreates the phone-specific device layout.
Explanation: Tableau dashboards use a shared worksheet model — when you add a worksheet to a dashboard, both the default and device layouts reference the same underlying worksheet object. This means worksheet-level properties like color encodings and number formatting are defined once and reflected everywhere the worksheet appears. Because the worksheet itself changed (not the layout), both the desktop and phone layouts will immediately display the updated formatting. At the same time, layout-specific properties — such as where the worksheet is positioned on the phone screen — are stored separately within each device layout and are completely unaffected by worksheet-level edits. This is exactly what B describes: new formatting propagates to both layouts, while the phone's custom positioning stays intact. A is wrong because it assumes each layout stores an independent copy of the worksheet. Tableau doesn't duplicate worksheets per layout — it shares a single source, so formatting changes are never isolated to one layout. C is wrong because custom device layouts do not "reset" when worksheet content changes; Tableau preserves your manual positioning unless you explicitly remove the device layout or choose to regenerate it. D introduces a false prerequisite — deleting and recreating the phone layout is never required for formatting updates to appear, and doing so would actually destroy your custom positioning. A helpful rule of thumb: think of device layouts as controlling where things appear, while the worksheet itself controls what those things look like. Changes to "what" always flow through; changes to "where" stay local to each layout. Keep this separation clear and these questions become straightforward.

Question 2

A published dashboard includes desktop, tablet, and phone layouts. A user opens the dashboard on a laptop, but it is embedded in a narrow portal panel whose available display area is similar to a tablet viewport.

Which result is most consistent with responsive device-layout behavior?

  1. The desktop layout must appear because Tableau selects layouts solely from the computer's operating-system device class.
  2. The tablet layout can appear because layout selection is based on the available display area rather than only the physical device. (correct answer)
  3. The phone layout must appear because every embedded dashboard defaults to the smallest available device layout.
  4. The default layout must appear because device-specific layouts cannot be selected inside an embedded portal.
Explanation: When you see a question about Tableau's device layouts, the key concept to anchor on is what drives layout selection — and the answer is available display area (width), not the physical device type or operating system. Tableau's responsive layout engine measures the pixel width of the space the dashboard actually occupies. If that rendered width falls within the range associated with a tablet layout, Tableau will serve the tablet layout — regardless of whether the viewer is sitting at a desktop computer, a laptop, or any other physical machine. This is exactly what happens in the scenario: the laptop is embedded in a narrow portal panel that mimics a tablet viewport, so B is correct — the tablet layout can appear because selection is driven by available display area. A is wrong because Tableau does not query the operating system's device classification. A desktop OS does not lock you into the desktop layout; the rendered container width is what matters. C is wrong on two counts: embedded dashboards do not default to the smallest layout, and "must" is too absolute — layout selection is conditional on measured width, not embedding status alone. D is wrong because device-specific layouts absolutely can be selected inside embedded contexts; embedding does not disable responsive behavior, it simply constrains the available width, which is precisely the input Tableau uses. A useful study tip: on Tableau exam questions, watch for answer choices that use absolute language like "must," "always," or "cannot." Tableau's responsive behavior is width-based and contextual, so those rigid claims are almost always the distractor.

Question 3

An author uses Device Preview to inspect a dashboard at a phone-sized viewport but does not add or save a phone-specific layout. The default dashboard remains a wide, fixed desktop design.

What is the most likely published result for phone users?

  1. Tableau permanently stores the previewed arrangement as a phone layout even though the author did not add one.
  2. Tableau removes all floating objects and publishes an automatically tiled phone layout without author intervention.
  3. Phone users receive the default layout because previewing a device size alone does not create a device-specific layout. (correct answer)
  4. Publishing is blocked because every fixed desktop dashboard is required to contain a saved phone layout.
Explanation: When working with Tableau's Device Designer, it's important to distinguish between previewing a device layout and creating one. Previewing simply lets you see how your existing dashboard would appear at a given screen size — it makes no permanent changes to your workbook. Because the author only previewed the phone viewport without clicking "Add Phone Layout" and configuring a saved version, Tableau has no phone-specific layout to publish. When phone users access the dashboard, Tableau serves the default desktop layout — exactly what answer C describes. This is the expected behavior: Tableau only delivers a device-specific layout when the author has explicitly created and saved one. Answer A is wrong because previewing is a read-only inspection tool. Tableau does not auto-save or store any arrangement from a preview session — no implicit layout is created behind the scenes. Answer B describes Tableau's automatic responsive behavior in a different scenario (the Automatic layout option), but this doesn't strip floating objects or restructure a fixed-size dashboard without author action; the claim that it publishes a tiled phone layout "without author intervention" misrepresents how the feature works. Answer D is entirely fabricated — Tableau imposes no such publishing requirement. Fixed desktop dashboards publish freely regardless of whether device-specific layouts exist. A useful pattern to remember: on Tableau exam questions about Device Designer, always ask yourself whether the author completed the full workflow — adding, configuring, and saving the device layout. Previewing is step zero, not the finish line. Any question describing an incomplete workflow likely leads to the default layout being served.

Question 4

A dashboard's desktop layout displays a map, a detailed crosstab, six filters, and explanatory text. On phones, the stated user task is to check a regional KPI and then open details only when necessary. Initial testing shows long load times and substantial scrolling.

Which phone-layout strategy best aligns responsiveness with the stated user task?

  1. Retain every object in the desktop order and set all worksheets to Fit Entire View to avoid changing the analysis.
  2. Place the crosstab first because detailed data should always precede summary information on smaller screens.
  3. Prioritize the KPI and essential controls, simplify the initial phone layout, and provide a deliberate path to details. (correct answer)
  4. Shrink all dashboard objects proportionally so the full desktop layout appears on one phone screen without scrolling.
Explanation: When designing phone layouts in Tableau, the guiding principle is task alignment: the layout should be structured around what the user actually needs to accomplish on that device, not simply mirror the desktop. Here, the stated task is checking a regional KPI quickly, then drilling into details only if needed — this is your north star for evaluating every option. Answer C directly serves that goal. By surfacing the KPI and essential controls first, you reduce load time and eliminate unnecessary scrolling. Making details accessible but not immediately visible respects the "progressive disclosure" pattern — users get what they need fast, with a deliberate path to more when they want it. This is exactly what mobile-first thinking looks like in Tableau's device designer. Answer A fails because retaining every desktop object in its original order ignores mobile constraints entirely. Fit Entire View doesn't solve load time or scrolling — it just compresses everything into an unusable visual mess. Answer B inverts the correct priority. Detailed data (the crosstab) should come after summary information on small screens, not before — mobile users need orientation before depth. Answer D is a common trap: proportional shrinking sounds like a clean solution, but it produces a cluttered, illegible layout that defeats usability. One screen does not mean one good experience. Study tip: On phone layout questions, watch for answers that prioritize visual completeness over user task efficiency. Tableau's device-specific layouts exist precisely so you can redesign the experience — not just resize it. If an answer sounds like it avoids making decisions, it's almost always wrong.

Question 5

A designer changes a dashboard from Fixed size to Automatic size. The dashboard contains several floating buttons positioned precisely along the right edge. During testing, some buttons overlap charts in narrow browser windows.

Which conclusion should the designer draw?

  1. Automatic dashboard sizing changes the canvas dimensions, but it does not guarantee that precisely positioned floating objects will reflow safely. (correct answer)
  2. Automatic dashboard sizing converts all floating objects to tiled objects, so the overlap indicates a worksheet rendering defect.
  3. Automatic dashboard sizing preserves the original aspect ratio, so every object should shrink uniformly in narrower windows.
  4. Automatic dashboard sizing applies only after publication, so overlap in authoring preview cannot indicate the published behavior.
Explanation: When working with Tableau dashboard sizing, it helps to understand what "Automatic" mode actually does versus what it doesn't do. Automatic sizing tells the dashboard canvas to expand or contract to fill the available browser window — but it says nothing about how individual objects within that canvas are repositioned or resized. This is the key insight: floating objects in Tableau are anchored by absolute pixel coordinates. When you switch to Automatic sizing, the canvas dimensions flex, but floating objects stay locked to their original coordinates. Buttons placed at x=1200px remain at x=1200px regardless of whether the browser window is 1400px or 800px wide. In a narrow window, those buttons will inevitably collide with other content — exactly what the designer observed. Answer A correctly captures this: Automatic sizing changes canvas behavior, but it provides no reflow logic for floating elements. Answer B is wrong because Automatic sizing does not convert floating objects to tiled objects. Floating and tiled are separate layout modes the designer must configure explicitly — the sizing setting doesn't touch this. Answer C describes behavior closer to a fixed "Range" sizing mode with aspect-ratio constraints, not Automatic, which makes no uniformity promises across objects. Answer D is wrong because Automatic sizing applies both in authoring preview and after publication — there's no publish-only activation gate. A useful rule of thumb: in Tableau, layout mode controls the canvas; object type (floating vs. tiled) controls object behavior. These are independent settings. When you see overlap issues after switching to Automatic, always investigate whether the culprit is floating objects that lack reflow logic — that's the classic trap this question tests.

Question 6

A dashboard contains a detailed explanatory text object that is useful on desktop but consumes most of the first phone screen. The author wants to exclude the text from the phone presentation while retaining it on desktop and tablet.

Which action best satisfies the requirement?

  1. Delete the text object from the default dashboard so that Tableau can regenerate every device layout consistently.
  2. Float the text behind the phone dashboard because hidden floating objects do not consume layout space.
  3. Replace the text with a worksheet caption because captions are automatically suppressed on phone layouts.
  4. Make the text unavailable in the phone-specific layout while retaining the object in the other layouts. (correct answer)
Explanation: Tableau's device-specific layouts are the core concept here. When you build a dashboard, Tableau lets you create separate layouts for desktop, tablet, and phone — and critically, each layout can include or exclude objects independently. This means you have granular control over what appears on each device without touching the other layouts. The best approach is D: use the phone layout editor to remove the text object from the phone-specific layout while leaving it intact on desktop and tablet. Tableau's device designer lets you do exactly this — you can select an object within a particular device layout and mark it as hidden or remove it from that layout entirely, without affecting the default or other device layouts. This is the clean, purpose-built solution for the problem described. A is wrong because deleting the object from the default dashboard removes it everywhere. Tableau device layouts inherit from the default, so destroying the source object defeats the entire purpose — you'd lose the text on desktop and tablet too. B describes a misconception about floating objects. Floating an object behind another doesn't suppress it from a layout — the object still exists and occupies the visual space in the phone view. There is no "hidden floating" behavior that automatically removes content from device layouts. C is a fabricated feature. Tableau does not have a rule that automatically suppresses worksheet captions on phone layouts. Captions behave the same across device types unless you explicitly configure each layout. Your study tip: remember that device layouts in Tableau are additive and independent — changes to one layout don't cascade to others, which is exactly what makes per-device customization possible.

Question 7

A dashboard has a fixed desktop size of 1,300 by 800 pixels. On phones, users must scroll horizontally to reach a filter, and several floating legends cover data marks. The author must preserve the existing desktop presentation.

Which approach best addresses the phone usability problem while minimizing changes to the desktop experience?

  1. Change the default dashboard to Automatic sizing and retain the current floating-object positions for every device.
  2. Add a phone-specific layout, reorganize essential objects vertically, and omit nonessential legends from that layout. (correct answer)
  3. Reduce the default dashboard to a fixed phone width and rely on browser scaling for desktop displays.
  4. Set every worksheet to Fit Entire View and keep the current dashboard arrangement for all devices.
Explanation: When a Tableau dashboard needs to serve multiple device types, think about device-specific layouts — Tableau's built-in feature that lets you tailor the visual arrangement for desktop, tablet, and phone independently, without breaking the original presentation. That's exactly what makes B the right choice. Adding a phone layout creates a separate canvas where you can stack objects vertically (eliminating horizontal scrolling) and hide floating legends that would otherwise obscure marks on a small screen. Crucially, this layout is completely isolated from the default desktop layout, so the fixed 1,300×800 arrangement your stakeholders depend on remains untouched. Here's why the other options fall short. A switching to Automatic sizing on the default dashboard changes how the desktop experience scales — it no longer respects the fixed pixel dimensions the author needs to preserve, and floating objects won't reposition themselves intelligently for phones anyway. C is essentially the inverse problem: shrinking the default to a phone width forces desktop users into a cramped view, and relying on browser scaling produces blurry or awkwardly zoomed results rather than a true desktop layout. D setting worksheets to Fit Entire View only controls how chart content fills its container; it does nothing to fix horizontal scrolling caused by layout structure or move legends out of the way on a phone. Study tip: On Tableau exam questions involving multi-device usability, the phrase "preserve the existing desktop presentation" is almost always a signal that device-specific layouts are the correct tool — they let you solve phone or tablet problems surgically, without touching the default.

Question 8

A tablet dashboard looks acceptable in portrait orientation. In landscape orientation, however, a fixed-width filter panel leaves excessive unused space while the main chart remains narrow. The dashboard must work in both orientations.

What should the author do before publishing?

  1. Validate both orientations in Device Preview and adjust the tablet layout's sizing and object allocation for the available range. (correct answer)
  2. Validate only portrait orientation because Tableau rotates the rendered portrait layout without recalculating available dashboard space.
  3. Create a second workbook for landscape tablets because a device layout cannot be evaluated at different viewport dimensions.
  4. Convert every object to floating because floating objects automatically redistribute unused width after an orientation change.
Explanation: When a dashboard must support multiple device orientations, your job is to think about viewport dimensions as a variable — portrait and landscape represent meaningfully different width-to-height ratios, and your layout must be intentionally designed for each. Tableau's Device Preview exists precisely for this purpose: it lets you simulate how your dashboard renders across different device types and orientations before publishing. The correct approach, A, is to use Device Preview to validate both portrait and landscape orientations, then adjust object sizing and allocation within the tablet layout so the filter panel and chart use the available space appropriately in each case. Tableau gives you one device layout (tablet) that you can tune to look correct across the orientation range — you don't need separate workbooks. B is wrong because Tableau does not simply rotate the portrait layout and call it done. Orientation changes alter the available canvas dimensions, and Tableau does not automatically recalculate object sizes or positions. Assuming portrait validation is sufficient would leave the landscape layout broken, exactly as described in the passage. C is wrong because device layouts are not limited to a single fixed viewport. You don't need a second workbook — Device Preview lets you evaluate the same layout at different dimensions within the same workbook. Creating separate workbooks for this is unnecessary and introduces maintenance overhead. D is wrong because floating objects do not automatically redistribute unused space when orientation changes. Floating objects use fixed pixel coordinates and dimensions, so they are actually more likely to cause layout problems across orientations, not fewer. For the exam, remember: Device Preview + layout adjustments is always the right tool for multi-orientation tablet design — never assume Tableau handles orientation adaptation automatically.

Question 9

A company tests a dashboard on one large-screen phone and concludes that the phone layout is complete. Users later report clipped filter labels on smaller phones and excessive blank space on wider phones.

Which testing practice would most directly have reduced this risk?

  1. Publish to a staging server and rely on end-user feedback because authoring preview cannot replicate real phone rendering accurately.
  2. Test only the default desktop layout because device layouts inherit all spatial behavior from the default layout.
  3. Measure the physical diagonal size of each target phone because screen diagonal determines which device layout Tableau selects.
  4. Preview several representative phone dimensions and verify labels and controls at the smallest and largest expected widths. (correct answer)
Explanation: When building dashboards for mobile in Tableau, the phone layout is a separate, fixed-width view that you size and arrange independently. Because phones vary significantly in screen width — from compact models under 360px to larger phablets exceeding 420px — a dashboard that looks perfect on one device can clip labels or leave awkward gaps on another. Questions like this are testing whether you understand that mobile testing must account for the range of real device widths, not just a single sample. D is correct because previewing several representative dimensions — especially the smallest and largest expected widths — directly catches the exact problems described: clipped labels at narrow widths and excess whitespace at wide widths. This systematic range-testing is the standard best practice for phone layout validation in Tableau. A is wrong because it conflates preview accuracy with test coverage. Tableau's device preview is a reliable tool for checking layouts; the problem in the scenario wasn't that the preview was inaccurate — it was that only one size was ever checked. Skipping preview in favor of end-user feedback introduces risk rather than reducing it. B is wrong because phone layouts in Tableau do not inherit spatial behavior from the desktop layout. The phone layout is built independently with its own object placement and sizing, so testing only desktop tells you nothing about phone rendering. C is wrong because Tableau's device layout selection is based on screen width in pixels, not the physical diagonal size of the device. Measuring diagonal inches is irrelevant to how Tableau routes rendering. As a study tip, remember: mobile testing in Tableau means testing a width range, not a single device. If a question describes a mobile layout problem, look for the answer that addresses variability across screen widths.

Question 10

A phone layout has four tiled objects: a title, two KPI worksheets, and a chart. The author wants the objects to remain in a predictable top-to-bottom order as the available width changes slightly among phone models.

Which design is most likely to provide the intended behavior?

  1. Place the objects in a vertical layout container and allocate space within that structured tiled arrangement. (correct answer)
  2. Convert the objects to floating and assign identical horizontal coordinates so Tableau infers their vertical order.
  3. Place each object in a separate horizontal container and allow all containers to overlap at narrow widths.
  4. Use a fixed desktop-sized dashboard and depend on the phone browser to preserve the top-to-bottom reading order.
Explanation: When designing dashboards for mobile in Tableau, the core concept being tested is how layout containers control object positioning as screen dimensions vary. The question to ask yourself is: what mechanism enforces a consistent stacking order regardless of width? Vertical layout containers are precisely built for this. When you place objects inside a vertical container, Tableau arranges them top-to-bottom in a fixed sequence and redistributes space automatically as width changes. This makes option A the correct design — the title, KPIs, and chart will always stack predictably, which is exactly what the author needs. Option B is a trap for students who confuse floating behavior with structured layout. Floating objects use absolute coordinates, meaning they don't reflow at all — they overlap or drift unpredictably at different screen widths, which breaks mobile layouts rather than stabilizing them. Option C compounds this problem: nesting objects in separate horizontal containers and allowing them to overlap defeats the purpose of using containers entirely. Horizontal containers arrange objects side-by-side, not top-to-bottom, and overlapping at narrow widths signals a broken layout, not a responsive one. Option D is perhaps the most common misconception — a desktop dashboard scaled down by the phone browser is not a phone layout. The browser will shrink or clip content, and reading order is not preserved in any meaningful interactive sense. Tableau's Phone layout editor exists specifically because desktop designs don't translate reliably. Your study tip: remember that vertical containers = vertical stacking with reflow, and that floating objects are the enemy of responsive mobile design on the Tableau exam.