Dashboard System

Pinpoint's LMS homepage had two problems, and the obvious one was hiding the bigger one.

The obvious problem was speed. The page rendered as a single large server response, so every panel had to finish computing in sequence before anything reached the browser. The slowest panel set the speed for the whole page and some client homepages spent over 15 seconds loading while users saw a blank screen.

The bigger problem was that the homepage was a dead end. It showed everyone the same static layout: a banner, training requirements, sometimes events, sometimes news. It did this regardless of who was logging in or what features their organization actually used. No two clients ran the same build, but every homepage looked the same. So features the platform was investing in, like video libraries and coaching, were easy to miss because the homepage had no way to promote what was relevant to a specific client or person.

We were running a multi-tenant product with different user types yet served all of them the same static page.

Three groups, each needing something different. Licensed financial advisors and reps needed their own training status and upcoming requirements at a glance. Managers needed downline visibility: who was overdue, who was compliant, who needed attention. Administrators needed to control what each group saw and configure the experience per organization, without filing an engineering ticket every time.

This was multi-tenant SaaS. Firms differed in branding, regulatory requirements, and which features they'd licensed. Whatever I built had to be configurable per client without custom engineering for each one. It had to stay extensible, since new features would keep getting added. And it couldn't alienate existing customers by making them relearn a product they already used every day.

The easy move forward was to optimize the render and make the slow page load faster. After all, this would make the obvious speed problem go away. However, if we were going to alter the homepage anyway, why not make the page more useful for our clients, whose needs had grown beyond the static layout we were serving them?

So I proposed one answer to both problems: a dashboard built from independent widgets, each aware of client and individual context. A single decision solved both issues at once. If a widget is self-contained enough to know who it's for and whether a client even has that feature, then it's also self-contained enough to load on its own. Fast widgets paint right away while slow ones fill in behind them, so nobody waits on the slowest panel anymore. Context and perceived speed weren't two separate fixes. They came from the same piece of architecture.

To validate the idea, I pitched the dashboard concept at our annual user conference. The selling points were context and discoverability. A client would only see widgets for features they had, but that also put those features front and center for users that were unaware of them. Individuals would see widgets that specifically pertained to their role and responsibilities. The homepage would try to anticipate what mattered to whoever logged in and put it in front of them so they could act on it.

This generated a lot of excitement and questions, pushing the project forward.

Context drives everything. Each widget knew who it was for. Client configuration controlled which widgets appeared, and from there, individual preferences and role permissions narrowed the view further. Everything else in the system depends on this decision, and it's the reason the thing lasted.

Optimize for perceived speed, not throughput. The shell rendered immediately, then each widget pulled its own data in parallel. Users could read and act on the visible parts of the page while the rest loaded. What people experience is time to useful content, not total load time.

Make the widget pattern repeatable. Each widget was a self-contained unit with its own view, behavior, and data source, sized so one developer could build it end to end. Adding a widget didn't require touching the core, and a broken widget failed in its own panel instead of taking down the page.

Let discoverability come for free. Because widgets surfaced the features a client actually had, the homepage became the place where users found out that the platform was more than a required-training checkpoint. The portal was trying to grow past that reputation, and the dashboard was the surface that made it possible.

Keep it familiar. This was an enterprise product with a real customer base. The new dashboard preserved the existing page regions and content categories, so it got faster and more flexible without forcing anyone to relearn the site.

The User Dashboards system: a configurable homepage where each client's dashboard reflected their own feature set, each user could tune their own view, and each role saw what it needed. I designed the widget experiences and built the CSS layer, which had to hold up as a responsive production interface across different widgets, user roles, loading states, and client configurations.

The widget set covered the real jobs of the homepage. Learners got training status and a resume-course shortcut. Managers got downline analytics and review queues. Engagement features like media, events, and badges had their own widgets. News covered communications, and administrator-authored panels handled anything custom.

Perceived load time dropped from over 15 seconds to a couple of seconds before useful content appeared. That was the win users felt right away.

To me though, the best part is how the system held up. Because it was built around per-client and per-user variation from day one, capabilities added afterward, like multilingual rendering, customer-specific widget options, manager tooling, and end-user customization, fit in as configuration rather than redesign. Widgets could be installed or swapped live with no maintenance window, so the team shipped more of them. The system is now deployed across tens of enterprise client installations and is still being actively developed four years on.