( Teamfront / January 2024 – Present )

Arborgold Corporate Portal

The redesign turned a fragmented, dated administrative interface into a cohesive enterprise command center for multi-branch service companies, built end to end on the Align UI design system.

My role: Lead UI/UX Designer
Timeline: January 2024 – Present
Category: Enterprise SaaS Product Design
Status: New design, delivered

Tools Figma, Figma Prototyping, Align UI Design System

Generated schematic standing in for imagery of Arborgold Corporate Portal. It depicts nothing. — Generated schematic, not a screenshot of Arborgold Corporate Portal.

Generated schematic, not a screenshot. Real imagery to follow.

( The account )

Context

Arborgold is a field service and business management platform for the green industry, used by tree care, landscaping, and lawn maintenance companies across the United States to run jobs, clients, scheduling, and invoicing. Its customers have historically been single-location operations, each working inside one branch instance.

Then they grew. Businesses running 10, 20, or more locations needed a view above the branches rather than inside one, and that is what the Corporate Portal is: a centralized command center where regional managers, CFOs, and system administrators monitor performance across every branch, manage financial periods, control who can see and do what, and launch straight into any individual branch instance.

A portal already existed, built during an earlier phase of the product, but it had not kept pace with what enterprise customers now expected of it. This project was an end-to-end redesign of that portal across 9 functional areas and more than 60 screens, with full state coverage for loading, empty, error, and success.

The problem

The legacy portal was a bottleneck at exactly the point where Arborgold's customers were growing fastest. Six problems defined the work.

Fragmented multi-branch oversight. Corporate administrators had no unified view of their own operation. To understand performance across branches they logged into each Arborgold instance one at a time and aggregated the numbers by hand, a slow and error-prone routine that made a real-time read on enterprise health effectively impossible. Branch counts, active job volume, quarterly revenue, and branches needing attention all sat behind disconnected systems.
An interface behind modern enterprise standards. The portal's visual design and interaction patterns predated any established design system. Hierarchy was weak, component patterns were inconsistent between sections, and daily users had to relearn behavior as they moved through the product. For enterprise buyers evaluating Arborgold, it was also the first thing they saw.
Inadequate financial controls. Accounting and period closure, a mission-critical monthly workflow for multi-branch businesses, was missing or poorly supported. Finance teams had no consolidated financial summary, no way to close periods across branches, no visibility into period status, and no audit trail, which pushed month-end close back into spreadsheets and manual reconciliation.
Primitive user and access management. There was no granular role-based access control. Administrators could not define custom roles, assign permissions per module, or scope which branches a user could reach, so people ended up with either too much access or too little and nothing in between. That is both a security exposure and a daily operational problem.
Fragile onboarding and authentication. The invitation and signup experience for new corporate and branch-level users was unreliable, with no polished invitation flow, no secure activation path with email verification, and an inconsistent password reset. Every team expansion created friction and raised questions about how accounts were being provisioned.
No developer integration surface. As the platform ecosystem grew, there was no developer portal reachable from the corporate level, which limited what technical teams could extend or integrate.

What I did

The redesign rebuilt the portal module by module on the Align UI design system, so visual consistency, accessible components, and scalable patterns came from the foundation rather than being renegotiated screen by screen. That mattered more here than on a smaller product: nine functional areas designed independently is precisely how the legacy portal became inconsistent in the first place.

On that foundation I organized the portal around what a corporate administrator is actually responsible for. The dashboard answers the daily question of enterprise health and surfaces the branches that need action. Analytics replaces manual aggregation with visual intelligence. The branch directory turns a list of locations into an operational tool that launches directly into any branch instance. Accounting gives finance teams consolidated summaries and a real period closure workflow with an audit trail. User management pairs a user list with a permissions matrix, so access is defined once per role rather than negotiated per person. Around those sit the flows that get people into the product safely: login, password reset, and two parallel onboarding paths for corporate and invited branch users, plus a developer portal entry point for technical teams.

Because the portal is an oversight tool rather than a production tool, every module was designed with its full range of states, loading, empty, error, and success, rather than the happy path alone. An administrator checking on a branch at month-end needs the interface to be honest about what it does and does not know.

Outcomes

Consolidated branch oversight, analytics, financial management, and user administration into a single portal, removing the manual branch-by-branch data aggregation that corporate administrators previously did by hand across disconnected systems.
Delivered the financial control layer the legacy portal lacked, with consolidated revenue, expense, profit, and margin summaries and a real period closure workflow carrying per-branch status, confirmation dialogs, and an audit trail, moving month-end close out of spreadsheets.
Introduced enterprise-grade role-based access control where none existed, replacing an all-or-nothing model with a permissions matrix mapping roles against module access and per-user branch assignments, with system roles protected from modification.
Made every branch reachable in one step through a searchable directory carrying operational and financial detail per branch with direct launch into that branch's instance.
Strengthened the platform's security posture and reduced friction during team expansion with polished invitation, activation, and password reset flows using time-limited links and six-digit email verification, plus handling for expired and invalid links.
Added a developer integration surface at the corporate level, including graceful handling for the case where the corporate backend cannot reach the Dev Portal API.
Established a modular architecture across 9 functional areas and more than 60 screens with complete loading, empty, error, and success state coverage, so the portal scales as customers add branches, users, and operational complexity.
Replaced an interface that undercut Arborgold's enterprise positioning with one that matches modern enterprise SaaS standards, which matters at the point where prospective enterprise customers evaluate the platform.

What I learned

The most useful reframing on this project was realizing the portal's users are not doing the same job as the branch product's users, only bigger. Corporate administrators are watching, closing, and granting, not producing. Once the information architecture followed that distinction, decisions that had felt like preferences became obvious: the dashboard opens on enterprise health, the directory carries the numbers that decide where to look next, and the launch action lives where the deciding happens.

Designing financial workflows taught me that trust is an interface problem as much as a data problem. Consolidated summaries make a finance team informed, but nothing about a summary makes anyone comfortable closing a period in a new tool. The confirmation dialogs, the explicit period states, and the audit trail are what carry that, and they are easy to treat as edge-case work when they are actually the feature.

Designing the full state range for every module changed how complete the product felt. Nine functional areas across more than 60 screens is a lot of surface to cover for loading, empty, and error alongside success, and the temptation is to design the happy path and handle the rest later. Doing it inline surfaced questions I would otherwise have missed, like what a branch directory should say when a search returns nothing, or what an administrator sees when the developer portal API cannot be reached.

Context

The problem

What I did

Outcomes

What I learned

( Tags )