( By Munawar Khel / Teamfront / Lead UI/UX Designer / 2024–PRESENT / 9 min read )
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.
The result and the decision behind it
( What it did )
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.
( The decision behind it )
Design the portal as a layer above the branches, not a bigger version of one
Corporate administrators do a different job from branch staff. They are not running jobs; they are watching performance, closing periods, and deciding who has access. A filtered version of the branch product would still have made them go looking for the enterprise picture instead of opening on it, which is the exact behavior the manual branch-by-branch aggregation had forced on them.
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
- 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.
The full record / 4 decisions
- My role
- Lead UI/UX Designer
- Timeline
- January 2024 – Present
- Platform
- Web (Enterprise SaaS, multi-branch corporate administration)
- Category
- Enterprise SaaS Product Design
- Status
- New design, delivered
Tools Figma, Figma Prototyping, Align UI Design System
Team Cross-functional, working with design, product management, engineering, and business stakeholders
Decisions
Design the portal as a layer above the branches, not a bigger version of one
- What
- Structured the portal around what a corporate administrator is responsible for, an enterprise KPI dashboard with a Requires Attention section, analytics, a branch directory that launches into any instance, accounting period closure, and role and permission administration, rather than mirroring the branch product's module structure at a larger scale.
- Alternatives
- Extending the existing branch-level interface with multi-branch filters and aggregate views, keeping one product shape for both audiences.
- Why
- Corporate administrators do a different job from branch staff. They are not running jobs; they are watching performance, closing periods, and deciding who has access. A filtered version of the branch product would still have made them go looking for the enterprise picture instead of opening on it, which is the exact behavior the manual branch-by-branch aggregation had forced on them.
Make the branch directory an operational tool rather than a reference list
- What
- Built the directory as a searchable, filterable table carrying each branch's status, region, staff count, active jobs, and revenue, with expandable rows exposing site URL, primary contact, and phone, and a Launch button that opens that branch's Arborgold instance directly.
- Alternatives
- A simple directory listing of branches with contact details, leaving administrators to reach individual instances the way they always had.
- Why
- The legacy workflow was log in somewhere else, look, come back, repeat. Putting the operational numbers in the row and the launch action next to them collapsed that loop into one place, so the directory answers which branch needs attention and gets the administrator into it without a detour.
Define access once per role through a permissions matrix
- What
- Designed role configuration as a matrix mapping each role against module access across dashboard, analytics, branches, accounting, user administration, and developer portal, with system roles protected from modification and custom roles fully configurable, paired with per-user branch access assignments shown as tags in the user list.
- Alternatives
- Per-user permission toggles set individually at the point of inviting or editing someone.
- Why
- The legacy system's problem was that access was all or nothing, and per-user toggles solve that in a way that stops scaling the moment an organization has dozens of administrators across many branches. A matrix makes the whole access model visible on one screen, which is what an administrator needs to answer who can see the accounting module, and protecting system roles keeps the model from being accidentally dismantled.
Treat period closure as a guarded workflow, not a status field
- What
- Designed accounting around a Branch Financial Status and Period Closure table with explicit open, pending, and overdue states per branch, month selection, close and unlock actions, confirmation dialogs, and a full audit trail.
- Alternatives
- Presenting consolidated financial summaries for visibility only and leaving period closure itself in the accounting tools finance teams were already using.
- Why
- Month-end close is the workflow multi-branch finance teams were running on spreadsheets, and the risk in it is not calculation, it is a period changing state without anyone knowing who did it or when. Confirmation dialogs and an audit trail make the action deliberate and reviewable, which is what lets a CFO trust the portal enough to close in it.
( Tags )
- Information Architecture
- Interaction Design
- Visual Design
- Design Systems
- Web
- Enterprise SaaS
- B2B SaaS
- Dashboard
- Field Service Management
- Legacy Modernization
- Data Visualisation