Pronto
Redesigning the Dashboard to Lift Engagement and Fit Users' Roles
- My role
- Lead Product Designer
- Team
- 1 Product Owner1 Project Manager2 Front-End Engineers2 Back-End Engineers
Image placeholder
Pronto dashboard showing configurable, role-based widget layout
Drop a 2x PNG export here
Active dashboard engagement rose 50% and session dwell time rose 22% after the dashboard moved from one fixed layout to a configurable, role-based system.
50%
Active dashboard engagement
22%
Session dwell time
The problem
The dashboard is the first screen every user lands on after login, meant to update them on their projects at a glance and act as a springboard into deeper areas. Its static, generic layout ignored the logged-in user's role and usage pattern, which showed up as low engagement. This work coincided with moving the navigation to the top of the product and a full rebrand, so the dashboard couldn't be treated in isolation from either.
Discovery
Engagement analytics showed which widgets users interacted with and which they ignored, and support tickets flagged people rebuilding the same information elsewhere because the dashboard didn't surface it for them. The pattern was consistent: the generic layout wasn't wrong for everyone, it was optimal for no one.
Image placeholder
Engagement analytics by widget, before redesign
Drop a 2x PNG export here
Scoro, Teamwork, and Monday were benchmarked to see how each treated the dashboard as a landing screen. All three used modular, user-customisable widgets rather than a single fixed layout, which confirmed this was an established category expectation and set the baseline the redesign needed to meet.
Image placeholder
Scoro dashboard, competitor benchmark
Drop a 2x PNG export here
Image placeholder
Teamwork.com dashboard, competitor benchmark
Drop a 2x PNG export here
Image placeholder
Monday.com dashboard, competitor benchmark
Drop a 2x PNG export here
The decision
Decision
User-configured widgets over a smarter default
The alternative was a single, better-tuned default layout, redesigned once by role and shipped as-is. It was ruled out because a fixed layout, however well-tuned, would still be wrong for some fraction of every role the moment usage patterns shifted, which is exactly what had happened to the original dashboard.
Instead, the core decision was to let users configure and reorder their own widgets. From there, every dashboard, widget, and page was scored against rebrand, top-nav, and new-feature needs, then given a redevelopment timing: keep as-is, rebuild, or cut.
Information architecture work mapped the platform's navigation and the structure behind each dashboard, from the top-level nav down to individual widget placement, and defined the dashboard edit flow: the widget library, drag-to-reorder, default filters, and how users would switch between and customise their own dashboards.
Low-fidelity wireframes explored how each dashboard would work for different roles, from project manager to finance, resource, and operations managers through to clients. Sketching each layout by hand surfaced which widgets each role needed to see first, before any structure was committed to high-fidelity design.
Image placeholder
Low-fidelity dashboard wireframes by role
Drop a 2x PNG export here
Two dashboard prototypes were tested on UsabilityHub, and the open feedback was coded into recurring positive and negative themes. A Venn diagram mapped which qualities were unique to each prototype and which overlapped. The shared positives, colour, clarity, and readability, set the direction for the final design.
Image placeholder
UsabilityHub prototype testing, theme comparison
Drop a 2x PNG export here
The checkable number: one grid, every layout
Every dashboard layout is built on the same foundational 12-column grid, so widget widths range from a single column to full width while staying aligned to a shared structure. A single view can carry from one to four widgets across without breaking column alignment or needing a bespoke arrangement each time.
Image placeholder
2-column dashboard layout on the shared 12-column grid
Drop a 2x PNG export here
Image placeholder
3-column dashboard layout on the shared 12-column grid
Drop a 2x PNG export here
Image placeholder
4-column dashboard layout on the shared 12-column grid
Drop a 2x PNG export here
Each widget was designed as a self-contained module that could sit in any column position without breaking the shared layout, spanning finance widgets, resource widgets, reviews and tasks widgets, activity feeds, and project alerts, each built to surface the most relevant information first for the role viewing it.
Dashboard Manager
The Dashboard Manager is where the configuration decision becomes something users can act on. From the homepage, they can set any dashboard as their own, duplicate or edit it, then drop widgets into fixed grid positions, reorder them, and set view and edit permissions per user or group.
Image placeholder
Dashboard Manager, widget library and drag-to-reorder
Drop a 2x PNG export here
Outcome
The dashboard moved from a single static layout to a modular system users could reorder and prioritise themselves, so the first screen after login reflected each user's role and usage rather than one generic arrangement. New layouts could be explored and shipped without a full design-to-handoff cycle for every variation.
Learnings
- Letting users set their own widget priority solved the generic-dashboard problem more directly than any single smarter default would have.
- Designing each widget as a self-contained module meant new layout variations could be tested without rebuilding screens each time, which is what made the shift away from a fixed design-to-handoff cycle possible.
What's next
Using per-widget engagement data to inform smarter default arrangements for new users, so people start from a role-appropriate layout rather than the same blank template before they have usage history to personalise against.