Inncircles - Manjusha | Portfolio 2026

Redesigned enterprise construction setup, cutting completion time from a full day to around two hours

Overview

Every new customer relied on Inncircles’ onboarding team to configure their project structure. I redesigned the setup model so customers could create complex hierarchies themselves, reducing a full-day task to approximately two hours in usability testing.

TL;DR

WhatRedesigned the Construction Type Setup flow for Inncircles — a B2B construction-management platform, so clients could configure projects independently instead of relying on the onboarding team.

WhyManual configuration slowed onboarding, increased support effort, and limited the business's ability to scale.

My roleLed the setup experience from problem framing through prototyping and validation. I owned the hierarchy model, interaction flows and usability testing.

Team2 Product Designers (me + 1 senior) · 1 PM · 1 Business Analyst

DurationAug 2024 – May 2025

Validation results

Less onboarding-team setup work

Projected self-serve completion

Fewer setup errors reaching live projects

What success will mean after launch

Median setup completion time

Self-serve completion rate

Onboarding hours per new account

Estimates developed with Product and Customer Success using current onboarding hours, support records and prototype task performance.

Why this problem mattered ?

I compared the 12 audited workflows by customer reach, support frequency and impact on activation. Construction Setup ranked highest because every customer encountered it before reaching the product’s core workflows Reducing dependency here had the greatest potential to improve onboarding, reduce operational effort, and establish a scalable pattern for future platform redesigns.

Every new clientResidentialCommercialIndustrial

Manual setup, by handA person on our team — every single time

↓Slower onboarding↑Rising support cost

That human dependency in the middle was the business's real ceiling on scaling — and the thing this redesign had to remove.

Every project begins here. Teams define locations, work packages and activities before any work can happen. The redesign focused on translating domain complexity into a workflow people could confidently navigate.

Why the existing setup failed?

The existing experience fragmented related decisions across multiple screens. Users couldn't see the full project structure, predict the impact of changes, or confidently review their work before publishing.

The product mirrored the database, not how construction managers structure projects

The setup flow exposed internal system relationships instead of the sequence construction managers naturally follow. Users first had to define technical building blocks before they could model an actual project

Shadowing the onboarding team exposed a deeper modelling problem

01Heuristic audit12 core flows mapped for breakdowns

02Onboarding shadowingObserved support & BAs configuring projects for clients

03Stakeholder interviewsSpoke with support leads, BAs and PMs who lived the pain daily

The real findingCustomers weren't struggling because the workflow was long — they were struggling because the product exposed implementation logic instead of construction logic.

Access constraints meant early discovery relied on internal domain experts. I treated this as a limitation and validated the proposed workflow with real participants later.

Four recurring patterns explained most onboarding effort.

Hidden hierarchyComplex project hierarchies had to be mentally reconstructed because relationships were never visible in one place.

Poor orientation and recoveryUsers couldn't tell where they were, what they'd completed, or what remained, making long setup sessions difficult to recover from.

Low confidence in irreversible actionsWithout preview, undo or bulk editing, users became cautious about making structural changes

One workflow for different project typesThe same experience served residential, commercial and industrial projects despite each requiring different setup strategies

Together, these issues translated directly into onboarding time, repeat support requests and slower customer activation.

Explorations

Concept-1Guided hierarchy builder

Strength: Made parent–child relationships visible. Trade-off: Became cumbersome beyond four hierarchy levels.

Concept - 2Task-based setup dashboard

Reduced cognitive load by breaking setup into independent task. While it simplified navigation, uconstruction managers are not used to this setup

Concept - 3Import-first mapping

Importing their organisation level data first that maps to our level based hierarchy.

Concept - 4Configuration workspace

Aligned with existing platform patterns and required minimal engineering effort, but kept setup fragmented across multiple pages and would be cluttered when levels increases

I combined the strongest elements of the four directions — visible hierarchy, guided progression, bulk import, and a configuration model that could scale within the existing platform.

The final direction had to pass all five

Allows bulk setup

Scales beyond four levels

Supports new and migrating customers

Maintains visible relationships

Feasible within existing architecture

I assumed one guided flow could serve every customer

Reviews showed that teams migrating existing projects needed an import-first path, while teams starting from scratch needed guided creation. I retained one underlying hierarchy model but introduced two entry points based on customer experience and available data

What came up during reviews

The import-first concept worked well for customers migrating existing projects, but it excluded teams creating projects from scratch. The redesign shifted from one guided flow to two pathways that supported different levels of expertise.
The hierarchy-first concept made project relationships easy to understand, but editing became increasingly cumbersome as projects grew beyond three or four levels.

The import-first concept worked well for customers migrating existing projects, but it excluded teams creating projects from scratch. The redesign shifted from one guided flow to two pathways that supported different levels of expertise.
The hierarchy-first concept made project relationships easy to understand, but editing became increasingly cumbersome as projects grew beyond three or four levels.

Solution

The final experience combines progressive guidance with persistent context, allowing new users to learn the system while enabling experienced teams to move quickly.

FROM DATABASE STRUCTURE → TO A MENTAL MODEL

BEFOREBuilt like a database — three disconnected screens

Entity TypesSuper LocationLocation Types

No nesting. Users couldn't see the whole they were building.

AFTEROne nested hierarchy, visible at every level

Block

Floor

Room

Door

Parent–child nesting the manager sees and edits as they build.

The cost was not limited to usability. Every implementation consumed onboarding capacity, turning product complexity into an operational constraint.

Start from a proven template or from scratch

Most projects weren't unique. Starting from proven structures reduced unnecessary setup without introducing another workflow to learn.

Keep the hierarchy visible while editing

Hierarchy stays visible while supporting inline editing, bulk actions and duplication—making structural changes without losing context.

Assign work without losing location context

Configure work in context

Keeping activities attached to their location reduced context switching and made dependencies easier to verify before publishing.

Reuse work sequences across projects

Sequence templates let returning users skip rebuilding a hierarchy from scratch for similar projects. The workflow supported first-time guidance without limiting teams who configured projects repeatedly.

Validation focused on whether the redesign addressed operational pain

This is one piece of a larger, phased platform revamp, sequenced across quarters so the business keeps running while it ships.

I tested the prototype with X participants responsible for configuring or supporting construction projects. Each participant completed three tasks: creating a project structure, editing a nested level and reusing an existing sequence.

What changed in the experience?

BeforeAfterProduct reflected the underlying data model.Product follows how construction teams structure projects.Setup depended heavily on onboarding support.Workflow designed for independent customer setupConfiguration was spread across multiple disconnected screens.Related decisions happen within a single workflowRepeat setup required recreating common structures.Templates and reusable sequences reduce repeated effort.

What I'll watch once it ships

Setup completion time%of setups published without critical errorsAssistance requests per setupDrop-off by setup stageTemplate reuse rate

What I learned?

01I initially treated setup as a navigation problem. Shadowing the onboarding team showed it was a product-model problem.

02Designing within the existing architecture forced me to separate what users needed to understand from how the database stored it.

This project reinforced that good enterprise design isn't about removing complexity, it's about deciding where complexity belongs.

Next projectForm BuilderRedesigned Inncircles' form builder so teams could configure inspections and checklists without developer support.

Curious to know more?

This is one part of a larger platform revamp. Happy to walk through the Form Builder redesign or the research behind it if you're interested. See more of my work below.

NEXT PROJECT