B2B SaaS platform for Construction site management
Bringing workforce, attendance and inventory operations into one connected system.
A B2B SaaS platform designed to digitise construction site operations. It helps organisations manage employees, track attendance, handle payroll information and monitor inventory across multiple construction sites.
Project overview
Project: Construction Site Management Platform
Industry: Construction Technology / Enterprise SaaS
Platform: Web and Mobile
My role: UX/UI Design
Project phase: Phase 1
Primary users: Headquarters administrators and on-site operations teams
1. The challenge
Construction companies manage several operations across multiple sites. These include employee management, attendance, payroll, material procurement and inventory.
A large part of this work is handled through manual registers, spreadsheets and physical documents.
Employee attendance is recorded in registers. Salary information is maintained in payroll sheets. Purchase orders and material movements are documented through physical records and challans.
This creates fragmented information and makes it difficult to maintain a consolidated view of operations across sites.
We wanted to bring these activities into one digital platform.
The challenge was not just to digitise existing processes. We also needed to account for different users, responsibilities and working environments.
Headquarters needed a system to manage employees, payroll and overall operations. On-site teams needed simple interfaces to manage attendance and inventory using their mobile phones.
2. Understanding the existing processes
Designing without direct access to users
We did not have direct access to end users for interviews or contextual research.
Instead of making assumptions about how the business operated, we started with the documents already being used to manage daily operations.
We had access to three types of documents:
Employee attendance registers
Salary and payroll sheets
Purchase orders and challans
These documents helped us understand what information was being recorded and which operational activities the product needed to support.
We examined the existing records and translated their information requirements into digital workflows.
For employee onboarding, we did not have an equivalent internal document to work from. We referred to competitor products to understand established employee onboarding patterns and create a standard digital flow.
This gave us two sources of design inputs:
Existing operational documents to understand business requirements.
Competitor products to understand established digital interaction patterns.
The takeaway: We used the available business records as our starting point rather than designing workflows based on assumptions.
3. Designing for two operating environments
One platform, different responsibilities
The application needed to serve people working in very different environments.
Headquarters handled administrative and management activities. Construction site teams were responsible for day-to-day operations.
We decided to design separate experiences for these environments while keeping them connected through a common system.
Headquarters: Centralised management
The desktop application was designed for administrative tasks and organisation-wide oversight.
It included:
Employee onboarding and management
Employee history and records
Salary and payroll management
Attendance monitoring
Inventory management
Site and sub-site management
Operational dashboards and reporting
The interface used tables, filters, forms and dashboards to support information-heavy workflows.
Construction sites: On-site operations
On-site teams needed to perform operational tasks using mobile phones.
We designed separate mobile experiences for:
Employee attendance
Inventory management
The focus was on making these tasks accessible within the environment where the work actually happened.
Role-based access
Not every user needed access to every part of the application.
We designed the system around different user roles and access levels. This allowed users to access the information and functions relevant to their responsibilities.
The objective was to maintain centralised management without making every user navigate through the same set of features.
4. Design Decisions
Design Decision 1 :
When users weren't accessible, we started with the documents they used.
The decision: Use existing operational records to understand business requirements and translate them into digital workflows.
Direct access to users was limited. We still needed to understand how attendance, payroll and inventory were managed.
We had three important sources of information:
Attendance registers
These helped us understand how employee attendance was recorded.
Salary and payroll sheets
These provided inputs for understanding employee compensation and payroll information.
Purchase orders and challans
These helped us understand how material procurement and movement were documented.
We used these records to identify the information that needed to be captured and represented in the application.
For employee onboarding, we referred to competitor products to establish a standard digital workflow.
This approach helped us move forward despite limited access to end users.
It also had limitations. Document analysis could tell us what information was being recorded, but it could not fully explain user behaviour, workarounds or problems experienced during daily operations.
Direct user interviews and usability testing would be important next steps.
Design Decision 2 :
Designing for multiple construction sites without fragmenting the system.
The decision: Separate access and interfaces based on user responsibilities while maintaining one connected operational platform.
Construction companies operate across multiple sites. Each site has its own operational activities, but headquarters needs visibility across the organisation.
We needed to accommodate both requirements.
We approached this through three design considerations.
A centralised management interface
Headquarters needed access to employee history, payroll and information across construction sites.
The desktop dashboard brought important operational information into one place.
Site-level operations
On-site teams needed access to attendance and inventory functions without navigating through administrative features that were not relevant to their work.
We designed separate mobile experiences for these operations.
Role-based access
Users were given different access levels depending on their roles and responsibilities.
This allowed us to separate administrative functions from on-site operational activities.
The result was a product architecture that supported both centralised management and decentralised execution.
The key design consideration: Different users needed different experiences, but their work still belonged to the same operational system.
Design Decision 3 :
Prioritising digitisation before advanced automation.
The decision: Focus the first phase on digitising existing manual operations, supporting both desktop and mobile users, and establishing a centralised cloud database.
The product had several potential capabilities. Trying to build everything at once would have increased the scope considerably.
We needed to establish what the first phase should achieve.
We identified three priorities.
1. Digitise existing manual operations
The first priority was to bring existing operational activities into the digital system.
This included employee management, attendance, payroll information, inventory and material records.
2. Support both headquarters and on-site teams
Digitisation needed to happen across both operating environments.
We designed desktop experiences for headquarters and mobile experiences for on-site attendance and inventory management.
3. Establish a centralised cloud database
The product needed a common place to store operational information.
We prioritised creating a cloud-based database to bring employee, attendance, inventory and site-related records into one system.
This would provide the foundation for future reporting, automation and integrations.
What we chose to build later
We deliberately kept advanced capabilities outside the initial phase.
Some opportunities for future development included:
Workflow automation
Automated attendance calculations
Payroll processing
Approval workflows
Inventory alerts
Advanced analytics
Site-wise operational costs
Workforce cost analysis
Material consumption trends
Budget variance reporting
Third-party integrations
Accounting software
Banking and salary payment systems
Biometric attendance devices
ERP integrations
Intelligent operations
Workforce allocation recommendations
Shift optimisation
Predictive material requirements
Material wastage analysis
These features could build upon the operational data collected through the initial platform.
We wanted to establish reliable digital records first. Advanced automation and intelligence would make more sense once the underlying processes were structured and connected.
5. The solution
A connected system for construction operations
The first phase brought together several operational functions within one application.
Home dashboard
The dashboard provides an overview of important operational information, including attendance, workforce distribution, expenses and inventory.
It gives headquarters a consolidated starting point for monitoring operations.
Employee management
The employee module allows administrators to maintain employee records and manage onboarding.
The onboarding process is divided into three stages:
Basic details
Employment details
Facial recognition registration
This separates personal information, employment information and biometric registration into manageable steps.
Attendance management
The attendance module provides an overview of employee attendance.
Users can examine attendance records through filters such as date, site, employee category and shift.
The system also accounts for site-level attendance requirements.
Inventory management
The inventory module provides a structured way to manage materials and their movement.
It includes material categories, manufacturers, units, vendors and purchase-related information.
Users can view material records, track quantities and examine incoming and outgoing transactions.
Material loading and challans
The material loading workflow captures information about incoming materials.
It includes details such as material, quantity, unit, rate, value and relevant purchase documentation.
The inventory views also provide transaction history to help track material movement.
Site management
The site management module allows headquarters to maintain site information.
It includes site details, geographical coordinates, geofencing configuration, sub-sites and shift information.
This helps organise operational information around the organisation's construction sites.
6. The Design system
The application uses a consistent interface across its desktop modules.
The design focuses on clarity and information accessibility.
Tables and filters help users navigate large amounts of operational information. Forms organise data entry into manageable sections. Consistent components help maintain familiarity across different modules.
The desktop experience is designed around information-heavy administrative workflows.
The mobile experience is designed around specific operational tasks performed at construction sites.
7. Reflection and learnings
This project involved designing for an operational environment with multiple users, workflows and responsibilities.
A few important learnings came out of the process.
1. Existing documents can be useful design inputs.
When direct access to users is limited, operational records can help uncover information requirements and existing business processes. However, they cannot replace direct user research.
2. Enterprise products need to account for different working environments.
A headquarters administrator and an on-site operator have very different responsibilities. Designing one interface for everyone would have introduced unnecessary complexity.
3. Product foundations matter.
Digitising existing operations and centralising data created a foundation for more advanced capabilities. It was important to establish this before introducing automation and predictive features.
4. Designing a connected system requires thinking beyond individual screens.
Attendance, employee records, payroll and inventory are separate modules, but they belong to a larger operational ecosystem. Their relationships need to be considered while designing the product.
8. What comes next
The first phase focused on bringing manual operations into a connected digital environment.
The next opportunity is to make these operations more efficient through automation, integrations and better use of operational data.
The next phase would also include an interface for data entry of past records for efficient storage and retrieval.
With a structured database and digitised workflows in place, the product can gradually evolve from an operational management system into a more intelligent construction management platform.