In this edition of Field Notes, Rauno shares the design process behind improving project cards in a dashboard interface. The work touches on information density, context menus, and the challenge of designing widgets that are both useful and visually coherent.
Tightening the Card
The first step was tweaking the padding and co-locating information to reduce the vertical space occupied by each card. Some data was also omitted. For example, the team realised that the project branch, which is generally always "main," did not need to be shown on the card.
The reasoning is straightforward: these cards occupy a lot of space on the screen. It is easier to digest cards when there are fewer rows and information is tight and terse. The before-and-after comparison showed a clear improvement, even gaining an extra row in the grid.
Context Menus
Another change was to the project card shortcut menu. At first, it seemed like it would simply clean up the card since the ellipsis button repeats a lot. But the team later realised that they want to use more context menus in the future. They have an obvious benefit over an explicit 24x24 control because you can activate a context menu from anywhere on the surface.
There is a tiny issue with affordance and learning curves, but apps like Linear make it work. The mitigation against context menu discoverability is to place the same actions in the detail view behind a regular dropdown menu. This way, no one misses out on anything; the context menu is just a shortcut.
The Widget Challenge
Projects are rich with metadata, but the card only shows the most essential information. Everyone uses the dashboard for different insights. More security-conscious users might want to always keep a pulse on the Firewall status. Others might want page performance insights like LCP, web analytics metrics, or alerts related to projects.
The team threw a bunch of different forms of widgets against the wall, but nothing seemed right. They were trying to find the layout and visual form of widgets. It just did not seem to fit in that corner well at all, with a background or without. They quickly realised that it is useful to have widgets be visually distinct characters from each other and not just differentiated by text or color. This makes them easier to scan.
The Unlock
The unlock came when the team used two rows instead of one. Now they are less likely to collide with the labels on the left and have a more reasonable amount of space to work with. The right corner becomes a rectangular area that is satisfyingly tight instead of floating without purpose or relative alignment to anything else.
From there on, they had a pattern to follow. Now it was just a matter of making all the various widgets.
The Menu Question
The team went back and forth on whether the menu should contain data or not. They thought it would be helpful because this way you could use the menu to preview data from other widgets without changing the project card widget itself. When a project has no data, the widget switcher gives a useful overview over platform features and even helps you enable them.
Key Takeaways
- Information density matters. Tight, terse cards are easier to scan and digest.
- Context menus are powerful but require mitigation for discoverability.
- Widgets should be visually distinct characters, not just differentiated by text or color.
- Two rows can unlock a layout pattern that makes widgets feel purposeful and aligned.
- Previewing data in menus can be useful, especially when a project has no data.