dashboard-design

3 posts

datadog

How Datadog uses Datadog to gain visibility into the Datadog user experience (opens in new tab)

Datadog’s product designers use their own monitoring tools to supplement interviews with quantitative insight into user behavior. By applying Real User Monitoring (RUM) and Logs to design questions, they made decisions about fonts, component functionality, and time-range input based on actual usage. This “dogfooding” approach improved products while making design collaboration faster and more evidence-based. ## Choosing a Monospace Font - Datadog uses monospace text for logs, stack traces, source code, container IDs, and dense data views. - Previously, users received different system fonts through a generic font stack, including Consolas, Menlo, and Courier. - The team used the browser’s CSS Font Loading API and RUM to determine which fonts users were actually seeing. - They analyzed the results in RUM Analytics and shared them through a dashboard with designers and engineers. - Datadog selected **Roboto Mono** as the standard font and used RUM after launch to verify that the rollout worked as intended. - Matching the existing visual proportions was important because font-size and character-width changes could disrupt tightly designed tables and other interfaces. ## Simplifying the DraggablePane Component - DraggablePane lets users resize adjacent content panels, but its small handle contained several controls that created visual clutter. - Custom loggers were added to the component and its draggable handle to track how users interacted with each feature. - Logs showed that almost no users used the minimize and maximize buttons, despite the space they occupied. - The team removed those buttons and replaced their functionality with a double-click on the handle. - Datadog notes that custom actions in RUM now provide a more direct way to collect this kind of interaction data. ## Expanding Custom Time-Range Syntax - Datadog initially offered only preset ranges such as 15 minutes, 1 hour, and 1 day. - The DateRangePicker introduced text-based custom ranges, but early versions supported only limited patterns such as “{N} months” or explicit dates. - Logs captured invalid user-entered time expressions, along with the page and country associated with each request. - The most common unsupported input involved “weeks,” including phrases like “last 1 week” and “last 2 weeks.” - The team used these patterns to prioritize improvements to the parser. - After adding support for common previously invalid inputs, the error rate fell from roughly 10 percent to 5–6 percent. ## Dogfooding and Collaboration - Designers tracked behavior, analyzed results, built dashboards, and documented findings using Datadog products. - Keeping data collection, analysis, and presentation in one platform made design reviews more efficient. - Shared dashboards and documentation helped designers and engineers collaborate around concrete evidence rather than assumptions. - Using the product internally also gave the team direct experience with the platform from a user’s perspective. Datadog’s examples show that quantitative product data works best alongside qualitative research: interviews explain user needs, while RUM and Logs reveal how often behaviors occur and which improvements will have the greatest impact.

datadog

How Datadog uses Datadog to gain visibility into the Datadog user experience | Datadog (opens in new tab)

Datadog leverages its own monitoring tools to bridge the gap between qualitative user interviews and quantitative performance data. By "dogfooding" features like Real User Monitoring (RUM) and Logs, the product design team makes evidence-based UI/UX adjustments while gaining firsthand empathy for the user experience. This approach allows them to identify exactly how users interact with specific components and where current designs fail to meet user expectations. **Optimizing Font Consistency via CSS API Tracking** * To ensure visual precision in information-dense views like the Log Explorer, the team needed to transition from a generic system font stack to a standardized monospace font. * Designers used the Web API’s `Document.font` interface and the CSS Font Loading API via Datadog RUM to collect data on which specific fonts were actually being rendered on users' machines. * By analyzing a dashboard of these results, the team selected Roboto Mono as the standard, ensuring the new font’s optical size matched what the plurality of users were already seeing to avoid breaking embedded tables. **Simplifying Components through Interaction Logging** * The `DraggablePane` component, used for resizing adjacent panels, was suffering from UI clutter due to physical buttons for minimizing and maximizing content. * The team implemented custom loggers within Datadog Logs to track how frequently users clicked these specific controls versus interacting with the draggable handle. * The data revealed that the buttons were almost never used; consequently, the team removed them and replaced the functionality with a double-click event, significantly streamlining the interface. **Refining Syntax Support through Error Analysis** * When introducing the `DateRangePicker` for custom time frames, the team needed to expand the component's logic to support natural language strings. * By aggregating "invalid inputs" in Datadog Logs, the team could see the exact strings users were typing—such as "last 2 weeks"—that the system failed to parse. * Analyzing these common patterns allowed the team to update the parsing logic for high-demand keywords, which resulted in the component’s error rate dropping from 10 percent to approximately 5 percent. Leveraging internal monitoring tools allows design teams to move beyond guesswork and create highly functional interfaces. For organizations managing complex technical products, tracking specific component failures and interaction frequencies is an essential strategy for prioritizing the design roadmap and improving user retention.

datadog

Cheering on coworkers: Building culture with Datadog dashboards (opens in new tab)

Christian’s colleagues built a Datadog dashboard to remotely track his progress in a six-day, 850 km ultramarathon. They scraped live race data from the event website, converted it into Datadog metrics, and visualized his distance, ranking, and elapsed time alongside video and other dashboard elements. At publication, Christian was leading by more than 47 km with 44 hours remaining. ## Extracting Race Data - The event website regularly published runners’ statistics and race progress in plain HTML. - A Python crawler using `Requests` retrieved the webpage. - `BeautifulSoup` parsed the HTML to extract: - Current ranking - Total distance run - Elapsed time - Other race information ## Sending Metrics to Datadog - The team used the Datadog Python client and StatsD to emit metrics through the Datadog Agent. - For each runner, the script sent gauge metrics for: - `runner.distance` - `runner.ranking` - `runner.elapsed_time` - Metrics were tagged with each runner’s name, enabling individual tracking and comparisons. ## Building the Dashboard - The collected metrics were combined into a Datadog dashboard. - The dashboard included: - Live race statistics - A live video feed - Animated GIFs for entertainment - Visualizations of meaningful progress metrics - Screens displaying the dashboard were placed in the company’s New York and Paris offices so colleagues could follow and encourage Christian throughout the race. The project demonstrates how a lightweight web scraper, StatsD metrics, and a monitoring dashboard can turn publicly available data into a live, engaging team experience.