top of page

Home Page & Widget System — Building a Scalable Foundation

Context

Working as part of the product trio (Design, PM, Tech Lead), we aligned early that a static dashboard would lock us into assumptions too quickly. To reduce risk, we agreed to pursue a more flexible framework that could scale as our understanding of user needs matured.

​

Instead of shipping a static dashboard, I designed a modular, collapsible widget system that could flex to different roles (staff vs. managers) and scale as the product grew. By designing a flexible framework rather than a fixed dashboard, we gave ourselves room to adapt. Future widgets of different sizes and complexities could be added without breaking consistency.

​

Fig 1.png

 

 

Problem

Users lacked a personalized starting point.

​

  • Staff wanted answers like: “What work do I have to do?” and “How busy am I this week?”
     

  • Managers needed visibility into their team’s workload and bottlenecks.
     

Without a dashboard, both groups wasted time piecing together the day’s priorities across scattered modules. The lack of a central hub didn’t just waste time, it also risked locking us into piecemeal solutions if we didn’t address the problem systemically.

​

We also faced a delivery risk: a static dashboard would have been faster in the short term, but would have prematurely locked us into widget sizes, layouts, and assumptions before we had real usage insights. We needed a solution that met the Unlock deadline while preserving flexibility for the future.

​​

Fig 1.png
Fig 2.png

​

​

Solution

A constraint we faced was that we had to set up a system that would scale. This widget system solved immediate user needs and set up the platform for long-term extensibility. The framework intentionally balances short-term speed and long-term flexibility. With three axes of choice (expand/collapse, CTA/no CTA, header menu/no menu), any future widget inherits the same structure and can slot easily into the system.

​

Our guiding principle was to make the system additive, not prescriptive. The initial widgets were never intended to be the only widgets. Instead, we built a shared framework where future teams could plug in new widget types, dimensions, or interaction models without undoing past work.

Key design decisions:

​

  • Widget anatomy: Defined header, body, footer, menu, CTA placement.
     

  • States: Default, empty, and loading for both expanded and collapsed widgets.
     

  • Responsiveness: Grid layout that adapts between desktop and mobile.
     

  • Role-based defaults (roadmap): All users see the same core set of widgets, but the information inside each widget adapts to the user’s role. For example, both staff and managers see Action Items, but managers may see review or approval tasks while staff see individual task assignments. In the future, I anticipate adding role-specific widgets, modules designed exclusively for managers (like workload balancing) or staff (like timesheet shortcuts), in addition to the role-specific data already present within shared widgets.

​

By standardizing widget anatomy and states, we enabled other designers and engineers to build on this framework quickly. Any new widget inherits consistent loading, error, and empty states, reducing redundant work and ensuring consistency across the experience.

​

Fig 3.png
Fig 4.png

 

 

Collaboration

I drove design as part of our product trio, working closely with PM and Tech Lead to balance urgency, technical feasibility, and long-term flexibility. Together we:

​

  • Defined the widget framework and prioritized the first five widgets.
     

  • Partnered with engineering to ensure reusable components.
     

  • Shared early designs with sales so they could use polished screenshots in customer decks
     

Because priorities shifted quickly, we created transparent problem/solution documentation in Miro so everyone could see progress, give feedback, and share context. Engineers only had to build a single baseline component, which let us move quickly while still setting up a reusable system. This alignment turned speed into an advantage rather than a liability.

​

Fig 5.png

 

 

Iteration

The Home page launched with four core widgets, and two more in the works, each solving a distinct problem:

​

  • Action Items: “What work do I have to do?”
     

  • Workload Overview: “How busy am I (or my team) this week?”
     

  • Needs Attention: “What’s falling behind?”
     

  • Time Allocation: “Where has my time gone?”
     

  • Pooled Work Queue: “What unassigned work could I pick up?”
     

  • Time Tracking: “Is all of my time accounted for and submitted?”

 

All widgets share the same anatomy, making them consistent, scalable, and responsive. Because all widgets inherit the same anatomy and states, adding new widgets will be straightforward for future teams. Whether small utilities or more complex modules, each new piece builds seamlessly on the same foundation.

​

Fig 6.png
Fig 7.png

​

​

Final Design

The Home page launched with four core widgets, and two more in the works, each solving a distinct problem:

​

  • Action Items: “What work do I have to do?”
     

  • Workload Overview: “How busy am I (or my team) this week?”
     

  • Needs Attention: “What’s falling behind?”
     

  • Time Allocation: “Where has my time gone?”
     

  • Pooled Work Queue: “What unassigned work could I pick up?”
     

  • Time Tracking: “Is all of my time accounted for and submitted?”

 

All widgets share the same anatomy, making them consistent, scalable, and responsive. Because all widgets inherit the same anatomy and states, adding new widgets will be straightforward for future teams. Whether small utilities or more complex modules, each new piece builds seamlessly on the same foundation.

​

Fig 8.png

 

 

Impact

  • Established the Home page as the daily entry point for staff and managers.
     

  • Delivered a widget framework that other teams now use to ship features faster.
     

  • Created a role-based dashboard system, reducing friction for staff and increasing visibility for managers.
     

  • Strengthened the sales story: the Home page is now a central demo highlight.

​​​

 

“Yes. That. We need that.”​

 

– Customer feedback during prototype review

 

 

Reflection

Our team could have shipped a static dashboard faster, but it would have introduced long-term risk. Instead, we invested in a flexible widget system that delivered what we needed for Unlock while preserving optionality for the future. By reducing the risk of premature lock-in, we set up a platform that other teams can continue to extend without disruption.

​

This required tight alignment with engineering and sales under tight timelines, but it elevated the product from “lists everywhere” to a true hub for work.

​

Ultimately, this project wasn’t just about delivering a dashboard, it was about making a strategic product decision: prioritizing adaptability, enabling collaboration, and setting a strong foundation for future growth.

​

bottom of page