Created by the construction industry, Site Safe are a not-for-profit organisation, that provide Health and Safety training in Aotearoa, New Zealand. Site Safe purchased Zero Harm, a health and safety management SaaS product aimed at the farming industry. With this new acquisition, Site Safe looked to release this product for the wider construction industry under the new brand, SiteSmart (Not to be confused with SiteSafe). With a trusted position in the industry as health and safety leaders, and also with their non-profit status, Site Safe have a competitive edge in bringing health and safety to the construction workplace. They literally write the training guides.
About
Design challenge
The client had an app originally designed for legacy users but needed to adapt the platform for the construction market. While we were initially approached to conduct a UX audit, it quickly became clear that the real challenge lay in defining the product’s direction before meaningful design interventions could be made.
My role
Effect (my employer) was brought in by SiteSafe to assess the existing Zero Harm app and identify opportunities for improvement ahead of its launch into the construction industry. Following the audit, I embedded myself into the SiteSafe team as a UX designer, working alongside developers and project managers to continuously evolve the platform. My role included:
- Addressing key usability issues in the existing app.
- Helping define product strategy, including pricing models and target user segments.
- Lead the re-design of UI and overall UX.
- Designing new construction-specific features.
Understanding the problem
The initial scope was a UX audit of the Zero Harm Health and Safety platform to help transition it to the construction market. However, as we started asking questions about users, key product offerings, we didn’t have a clear picture of what the specific target market is. The product was intended for the construction market but still were looking at a wider range of customers.
The client had some existing personas, backed by their research and customer interviews. The users and potential users crossed a wide range from farmers, vineyard owners and managers, large property owners, industrial sites, property managers, construction foreman, and large construction companies.
If we were going to make design interventions as a result of the audit, which users should we prioritise? We agreed with the client that we really needed to nail down the product strategy and put the audit to the side for now.
The client had some existing personas, backed by their research and customer interviews. The users and potential users crossed a wide range from farmers, vineyard owners and managers, large property owners, industrial sites, property managers, construction foreman, and large construction companies.
If we were going to make design interventions as a result of the audit, which users should we prioritise? We agreed with the client that we really needed to nail down the product strategy and put the audit to the side for now.
Aligning on Strategy
We ran a series of workshops with SiteSafe to realign the team around a shared product vision. As an external partner, we could challenge assumptions and help them think beyond their current frame.
Workshop focus areas
- Defining what success looks like for SiteSafe as a product
- Narrow the products focus by identifying the core user groups and target markets. We needed a clear answer on if it is only the construction industry, and within the construction industry, what segments?
- Understand competitor pricing models and develop a pricing model for SiteSafe that aligns with its value proposition.
Workshop outcomes
1. Success for SiteSafe
Sustainably delivering Health and Safety outcomes for New Zealandders. We needed profit to grow the app, but couldn’t sacrifice health and safety outcomes. Our focus also was inside New Zealand.
2. Product focus
We narrowed the primary focus on small to medium enterprises in the construction industry. In contrast, larger constructions institutions already have more sophisticated Health & Safety requirements that are catered by other software or processes that are more demanding feature wise. SMEs lack the time and skills to implement H&S, have a large number of smaller physical sites to manage and their needs align with Site Smarts existing domain expertise.
We would deprioritise customers who have a single physical site such as farmers or offices, but the basic app plan would still serve their needs.
We would deprioritise customers who have a single physical site such as farmers or offices, but the basic app plan would still serve their needs.
3. Pricing Model & Product Proposition
Site based subscription: SiteSafe will base its subscription costs primarily around physical sites requiring Health and Safety. A "site" is any physical location with H&S requirements—construction zones, farms, or offices. A "site" refers to any worksite with Health & Safety (H&S) requirements—such as a construction site, a farm, or even an office. This model ensures that users pay based on the real-world work they are managing.
As a contractor's business scales with more physical sites, they can increase their subscription. This model also offers a role based simplicity, the person most responsible for H&S is the one that pays. This also aligns with the costing models for construction, with the main contractor able to bring this cost into their 'Preliminaries and General' pricing for contrsuction projects.
As a contractor's business scales with more physical sites, they can increase their subscription. This model also offers a role based simplicity, the person most responsible for H&S is the one that pays. This also aligns with the costing models for construction, with the main contractor able to bring this cost into their 'Preliminaries and General' pricing for contrsuction projects.
Free for workers: To align with Site Smart's ethos of making New Zealand a safer place, the product will be free for most workers. In addition to lowering barriers to H&S participation this will help increase adoption. Instead of charging workers, we focus on businesses as paying customers. Your average worker won't pay out of their own pocket for the app, but the main contractor or business owner will easily pay a small monthly cost to reduce their administration overheads.
Network effect: Due to their being many more workers and subcontractors in construciton than businesses themselves, they would form the backbone of our network effect. Subcontractor's are the connectors in the network. They regularly work across multiple sites and companies, and they need to view and submit H&S in many places. Once their H&S information is completed once on the platform they can easily share and request others to share. Invitations to sites play a key role in helping this. Subcontractors might request a site be setup from a main contractors, or a main contractor invites subcontractors.
Understanding the platform
Knowing that we had a clear focus on Small to Medium Enterprise construction contractors, we could focus our audit and future design work. The audit looked at various page types, interaction types (such as navigation patterns, wizard patterns etcc) and the components making up the site. Below are some high level issues we found:
Page types
I documented the full range of nested pages, labelling them A to E. Interaction patterns weren’t similar horizontally (all C type pages) and also changed as you move down nested layers.
As part of this process, I also documented each of the page types, this also included the many different interaction patterns and features.
There was a clear lack of standardised page templates. As I documented the pages, it was clear that new features were being added but weren’t following rules about what page or interaction patterns they should follow. This caused the user experience to be wildly varied between similar tasks.
Findings
- The navigation was confusing due to both the many different navigation patterns and templates and also the structuring of the wider IA. The mobile design was also particularly bad.
- The user interface itself also didn’t support a modern brand for a high quality product. Built on Bootstrap 5, the UI was forced into fitting this as opposed to supporting the growth of the app. The lack of clear design system was causing issues.
- The IA didn’t quite fit the updated ‘site model’ where users would have multiple different relationships to different sites.
- There was a new brand incoming, the site didn’t have a regular setup to enable this to be inserted easily. The initial app was built with bootstrap 5 and felt like it. This lack of clear design system or repeatable elements was causing issues.
Design principles
A key element to providing longer term value once we had done our design work was setting up some driving principles for making future decisions.
- Provide the right info at the right time. Prioritise actions for people.
- Clear ownership drives responsibility. Let people know what they need to do and also show what hasn’t been done.
- Health and Safety is more than ticking box, are we helping change behaviours?
- Building sites are made for hammers. Let's make it easy for busy users, who aren't H&S experts or might not have English as a first language.
- Be the experts. SiteSafe are industry leaders so can be opinionated. GIve people actionable information and give them the next steps.
Design: Structuring the app for construction sites
The original architecture of the app was built to support users with a single physical site such as farm owners. Users would often only have one role and one place of work. This structure poses a barrier to construction users however, who work across multiple sites with shifting responsibilit.es For example, a foreman might manage one site, contribute temporarily to another site, or hand over one site to a specialized team. All of these sites and roles could be activeat the same time.
.The app was split into a binary of “Site administration” and “My workplaces”. Furthermore, depending on whether you were on the Homepage, My Sites, Site Adminstration, Company Dashboard and the Company List of sites the user would be presented with different table views of the sites you were involved with. On top of this search was a seperate experinece.
As a result the user experience was fragmented and jarring
As a result the user experience was fragmented and jarring
Below, you can see all the different types of landing pages that a user could find sites from.
Our key goal was to simplify the relationship between users and sites, moving away from a choosing 'admin' or 'workplaces' we simplified everything into a single, streamlined 'Sites' page (Refer to sitemap below).
Opening 'Sites' essentially opens the search page. All sites a user has access to is available here, allowing for searching, browsing and filtering. To the right of the image below, is a proposed Dashboard, including items such as 'To do' items but also the same 'Sites' table to keep a consistent user experience.
Note that you will see on the Site search page that tabs still seperate 'Sites you manage', 'SItes you work on' and 'Public sites'. Backend limitations meant we still needed to seperate the data, but the user still had access to all these options from one place. A hypothesis that was not tested at the time was that people who managed sites would mainly use the first tab. If they didn't manage sites, they wouldn't have that tab display anyway.
To reinforce this experience, the remaining avenues to find sites would all push users to the same place. The Dashboard had a similar sites table and the Search feature would allow for either direct searches or push users to the 'Sites' page.
.png)
Feature Redesign: Hazards
Part of the scope was starting to design new and updated features. The Hazards example below illustrates how decisions made during feature design worked hand in hand to inform the wider structural changes being made.
Hazards
Managing hazards is a key part of Health and Safety. The existing Hazard creation process no longer matched New Zealand best practice. More information would be required from users.
Wa user added a hazard from a list, opened a modal, selected to add that hazard. Then the app opened the page for that created hazard, the user then had to open a ‘new assessment’ of the hazard from a button halfway down the page, then add the information, then return back to the hazard screen if they wanted to add another one. It was highly confusing and time consuming.
Wa user added a hazard from a list, opened a modal, selected to add that hazard. Then the app opened the page for that created hazard, the user then had to open a ‘new assessment’ of the hazard from a button halfway down the page, then add the information, then return back to the hazard screen if they wanted to add another one. It was highly confusing and time consuming.
At critical steps such as immediately after adding the hazard, the app would ask a user to 'customise' or 'add to register'. 'Add to register' then forced the user to open the page for the hazard and then find the correct button. 'Customise' opened up another modal that only allowed the changing of the generic hazard name and description, not manage the hazard itself. There was no clear next steps for the user.
Below you can see when a user then needs to add a 'new assessment' to complete the hazards process.
Key changes mapped out
Using Figjam, I quickly mapped out an updated user journey which would allow users to make logical next steps, and also cater to the new information requirements. The new user flow would allow users to select a hazard from the list and then either edit it immediately (replacing the whole 'new assessment process') or edit it later. Editing later allow the user to either keep adding hazards to the list or return to other tasks.
This design would also do away with confusing terms like customise that didnt relate to the immediate task at hand.
This design would also do away with confusing terms like customise that didnt relate to the immediate task at hand.
.png)
Designing to higher fidelity
The next iteration reduced further complexity, making users finish editing the hazard they had selected. Based on user research, it seemed that users would just add empty and generic hazards to the list. A list of empty Hazards didn't make anyone safer.
As a result, the user would now add a hazard, step through a wizard to add the hazard information and then return to adding more hazards to the list.
Despite this change, the new process took 6 steps to add a hazard and return back to the hazard list. The old process took 7 steps, despite requiring less information and also being a confusing journey that could easily be broken by the user.
As a result, the user would now add a hazard, step through a wizard to add the hazard information and then return to adding more hazards to the list.
Despite this change, the new process took 6 steps to add a hazard and return back to the hazard list. The old process took 7 steps, despite requiring less information and also being a confusing journey that could easily be broken by the user.
Managing hazards across the company
Good Health and Safety practice is about consistency. We needed to ensure that changes to hazards at the company level could be incorporated at the site level. Changes could be pushed out across the company and site managers be informed via notification about the changes. For example if their company plan for ’Dust and airborne particulates’ hazard management changed, an admin for the company could globabally update this, and all site managers would receive notification of this change. The site manager could then choose to review and update this information for their site, saving them the work of adding this information in. They could also choose to reject it due to unique site context. Below, you can see the notification panel in yellow (left UI design) with the updated information being displayed in the modal (right UI design).
Design: UI implementation
The brand design was incorporated into the new UI decisions, focusing on creating a more consistent and readable UI. In addition to the UI features identified below, the whole design system for the app was re-structured, giving the development team a kit of parts they could continue to use into the future.
Page types: One of the key findings from the audit was the number of different page formats used for similar page types, as per the below image. There wasn't a consistent reason for when a white, grey background was used, or whether a grey sidebar or a white sidebar
Navigation: The mobile and desktop navigation was overhauled, particularly the mobile design. Previously the mobile nav had far too many icons and two hamburger menus!
Sidebars: The sidebars needed to still be accessible from mobile, theis navigation pattern was overhauled to be a submenu below the nav. Some key changes also include chunking navigation items into logical sections to make it more digestable.
Outcomes
Impact and reflections
The most critical success of this project was the structure and focus given to the product and the team. The SiteSmart team could move forward knowing who the app was for, what would deliver that value and how it would all site together.