This chapter provides practical guidance on the recommended sizing of common screen objects in Board applications.
While readability guidelines focus on typography, contrast, and visual clarity, this chapter focuses on the size and proportions of interface components themselves. Appropriate sizing helps preserve usability, visual consistency, and readability while reinforcing the hierarchy established through screen structure.
The goal is not to define fixed dimensions, but to provide practical reference ranges that support consistency across different screen types and resolutions.
1. Understanding Object Size
Object sizing defines the dimensions of individual components within a screen. While space allocation determines how much screen space is assigned to a content area, object sizing determines how individual elements appear within that space.
Appropriate sizing helps preserve readability, usability, and consistency across different screen types and resolutions. Components that are too small may become difficult to read or interact with, while oversized components can consume unnecessary space and reduce overall layout efficiency.
When defining component sizes, designers should consider:
Readability: Content should remain legible under different viewing conditions and scaling scenarios.
Usability: Interactive components should remain easy to identify and interact with.
Consistency: Similar components should follow similar sizing patterns across the application.
Proportion: Component sizes should remain appropriate relative to the surrounding elements and available space.
2. Recommended Sizes by Component
Recommended sizes provide practical reference ranges for common Board components. These values are not intended as fixed specifications, but as guidance for maintaining readability, usability, and visual consistency across different screen types and resolutions.
Component sizing should always be considered together with screen purpose, available space, and responsive behavior. The goal is to ensure that components remain functional and visually balanced without consuming unnecessary space.
KPI cards are designed for rapid recognition and should be sized according to the importance of the information they communicate.
KPI Type | Recommended Size | Typical Usage |
|---|
Small KPI | 160 × 100 px | Supporting metrics |
Medium KPI | 220 × 120 px | Dashboard KPIs |
Large KPI | 300 × 160 px | Primary metrics and executive dashboards |
Guidelines:
- Use larger KPI cards only for the most important metrics.
- Avoid displaying too many large KPIs simultaneously.
- Maintain consistent proportions within KPI groups.
KPI size should reflect the amount of information being displayed
Charts should be large enough to support comparison, trend analysis, and label readability.
Chart Type | Recommended Size |
|---|
Small Supporting Chart | 300 × 180 px |
Medium Chart | 500 × 300 px |
Large Analytical Chart | 700 × 400 px or larger |
Guidelines:
- Avoid using charts that become unreadable due to limited space.
- Reserve larger chart sizes for primary analytical content.
- Ensure labels, legends, and axes remain readable after scaling.
Chart size should support their analysis and readability
Data Views and Flex Grid tables often are the primary analytical component of a screen and should receive sufficient space to support efficient scanning, analysis and comparison, and data entry.
As a general guideline:
- Primary tables should display 12–20 visible rows whenever possible.
- Supporting tables should display at least 6–8 visible rows.
- Keep data-entry columns visible without scrolling when possible.
Displaying an appropriate number of rows and columns helps preserve comparison efficiency, improve data entry workflows, and reduce excessive scrolling.
Table object sizes should be considered in parallel with font size, as shown in Accessibility & Readability.
Component | Recommended Size |
|---|
Supporting Table | 400–500 px height |
Primary Table | 600–900 px height |
Guidelines:
- Data Views should generally receive more space than supporting charts.
- Avoid excessive scrolling caused by insufficient table height and width.
- Prioritize visible rows over decorative content.
Data Views should provide enough visible rows to support efficient comparison and analysis without excessive scrolling.
Interactive elements should remain comfortable to use and clearly recognizable across different resolutions and scaling conditions.
Buttons
Recommendation | Value |
|---|
Minimum Height | 32 px |
Recommended Height | 40–48 px |
Filters and Selectors
Recommendation | Value |
|---|
Minimum Height | 28 px |
Recommended Height | 36 px |
Tabs
Recommendation | Value |
|---|
Minimum Height | 32 px |
Recommended Height | 40 px |
Menu Object
Recommendation | Value |
|---|
Minimum Height | 36 px |
Recommended Height | 36–44 px |
Guidelines:
- Interactive components should remain easily clickable after scaling.
- Maintain consistent sizing across similar controls.
- Avoid reducing component size to compensate for dense layouts.
Maintaining recommended heights ensures interactive elements are easy to click, scan, and distinguish at any zoom level or screen density.
Maintain recommended component sizes to ensure interactive elements remain easy to click, scan, and distinguish across different screen densities.
Absolute dimensions are useful references, but component sizing should also be considered relative to other elements on the screen.
As a general principle:
- Primary analytical components should be larger than supporting components.
- Data Views and planning tables typically receive the largest share of the working area.
- KPI cards should support rapid recognition without dominating the layout unnecessarily.
- Supporting charts, alerts, and contextual information should remain visually secondary.
- Similar components should maintain consistent proportions across screens.
These principles should be applied consistently across related screens to reinforce familiarity, predictability, and visual balance throughout the application.
Component sizes should be considered together with the number of objects displayed on a screen. Adding more components often requires smaller objects, which can reduce their readability and make the interface harder to scan, compare, and interpret.
In most cases, fewer well-sized components provide a clearer and more effective user experience than a larger number of compressed components.
Designers should avoid reducing component sizes to accommodate more content. When space is limited, prioritize the most important information and use progressive disclosure to make secondary content available when needed.
3. Quick Reference
Component | Recommended Value |
|---|
Top Bar | 48–80 px (height) |
Side Panel | 280–360 px (width) |
Small KPI | 160 × 100 px |
Standard KPI | 220 × 120 px |
Large KPI | 300 × 160 px |
Supporting Chart | 300 × 180 px |
Standard Chart | 500 × 300 px |
Primary Chart | 700 × 400 px |
Supporting Table | 400–500 px (height) |
Primary Table | 600–900 px (height) |
Buttons | 40–48 px (height) |
Selectors | 36 px (height) |
Tabs | 40 px (height) |
Menu Object | 36–44 px (height) |
4. Key Takeaways
- Component sizes should support readability, usability, and consistency.
- Recommended dimensions should be adapted to the purpose of the component.
- Larger components should be reserved for primary analytical content.
- Data View and Flex Grid tables should provide sufficient visible rows and columns for efficient analysis and data entry.
- Interactive components should remain comfortable to click after scaling.
- Prioritize a smaller number of appropriately sized components over fitting more compressed elements onto the screen.
