Most dashboards pass the test of being correct and still vanish from memory. The presenter went through 2,108 dashboards on Mobbin and found the fundamentals nearly everywhere: clear hierarchy, good spacing, useful charts. The gap between those competent screens and the ones worth remembering lies in what the dashboard does with the data, not in how tidy it looks. Insight beside the chart, not just the history The first pattern is anticipation. A line chart that shows what happened is the baseline. The dashboards that stick place the next step next to it. In the presenter's words, a standout dashboard does not stop at showing you what happened; it shows you what to do about it. Origin is the example given: a weekly recap that is easy to understand, sitting alongside a daily market brief with valuable insights. The consequence is a change in what a designer has to decide. Instead of asking which chart to draw, the question becomes which recommendation belongs next to the chart and how plainly it can be stated. Runner takes a similar route after a workout, packaging stats into highlights that give the user a sense of accomplishment. Those highlights are not new data; they are the same numbers arranged so the reader can act on them or feel rewarded by them. Where the pattern stops The material does not establish how often these recommendations are right, or whether users trust them more than the raw chart. The evidence is a curated set of screens chosen by one reviewer. A careful reader should treat the pattern as a design observation with a clear rationale, not as a measured lift in comprehension. Breaking the visual mold and coining metrics The second theme is departure from the look that most dashboards share. Shopify's live view monitors store visitors across the globe in real time, and the presenter notes that every dot is a real person browsing the store. Visitors, a web analytics tool, wins attention by being clean where most dashboards look busy. Front uses a heat map in which darker squares simply mean busier hours, so the encoding does its job without a legend that demands study. Playfulness is the other lever. Cake placed a literal birthday cake inside its ownership donut chart. Mercury, instead of showing an empty table after bills are paid, lets the user play a game. The presenter's point is that none of these were templates; someone asked how to make the data make sense so users get it instantly. Proprietary metrics extend the same logic over time. Duolingo made streaks a thing, and Oura gives users a readiness score. When an Apple user says they closed their rings rather than that they worked out for 30 minutes, the metric has entered daily language. The presenter argues that once that happens, a user is very unlikely to switch to another product. That is a strong claim, and the material offers no retention figures to test it. Playful states and the cost of novelty The playful examples are measured in anecdote, not in outcomes. Cake and Mercury are described from the screen, with no usage data attached. A designer should ask whether the playful element helps a user reach the decision the dashboard exists for, or whether it competes with that decision. Where AI fits and the screenshot test The third theme looks forward. The presenter describes the familiar moment of staring at a dashboard asking what changed or what caused this spike. That is the gap AI is filling, sometimes as subtle as a single prompt right below the chart, and sometimes as a full AI layer you can talk to alongside your data. On Mobbin, AI dashboards get about twice the saves and exports of the average dashboard screen, which the presenter reads as designers collecting them as references. That saving behavior is evidence of interest, not of usefulness. Saves measure what designers want to borrow; they do not show that users answer their questions faster. The chapter's promise is to tell which metrics belong on a dashboard and how to arrange them so people can act at a glance. The presenter's closing test does that work in one line: would I screenshot this, and why? The dashboards worth screenshotting were not the prettiest ones. They were the ones that knew what to leave out and looked good doing it. Apply that test to a draft by asking which metric answers a decision, which one only decorates the screen, and whether a single view tells the user what the product does, how they are doing, and what to do next. Put the next recommendation beside the chart, so the dashboard answers what to do and not only what happened. Use encodings a user can read without a legend, such as the heat map where darker squares mean busier hours. Name a metric only when users will adopt it into daily language, as with Duolingo streaks or Oura's readiness score. Treat playful elements as tests: keep them only if they help the user reach the decision the dashboard serves. Run the screenshot test on every draft: would you screenshot this, and why?