Designing for teamwork


Teams that work together collaboratively build safer workplaces and better quality products and services.

At SafetyCulture, our mission is to help businesses continuously improve.

The best way to do this is by including frontline teams in the design of the work they do every day.

Frontline teams are the ones who see most clearly what the problems are, and how to improve.

Our goal is for iAuditor to be a platform that connects teams with each other: highlighting what matters, organising the best of their knowledge, and helping drive effective action.

Over the years, we have invested significantly to bring more collaborative experiences to iAuditor and many of our team goals focus directly on increasing the size of teams.


Our customers struggled to set up and manage their teams as they expanded their use of iAuditor.

When bringing their workforce into iAuditor, customers expected our system would create an environment that made it eas to work together.

Customers expected to —

  • control who had access to content and features
  • explore and manage the information they collected in a way that matched how they organise their business. 
  • be able to trust their team would see relevant information and notifications.
  • restrict what different team members could do and their responsibilities across the platform based on their roles.

These goals only became more essential to delivering a great user experience as we added more collaborative functionality to our product. They were critical to every feature in iAuditor.

Even though our features were loved by customers — they still couldn’t ‘scale up’ their use of the platform due to design issues in our current access management system.

The customer reality —

  • The overall design of sharing and access management was complicated, confusing, and inconsistently implemented.
  • Customers couldn’t measure and compare the information important to their business across their teams.
  • Even simple team structures required elaborate ‘sharing’ rules and expert help from Customer Success to set up, and it was very time-consuming to make changes.

As teams grew in size the product quickly became ‘noisy’ and full of irrelevant content and spammy notifications.

This poor user experience was actively discouraging growth.

iAuditor lacked the necessary foundation to support collaboration at scale.


Designing for scaling teams.

Over a 2 year journey, we went from early research insights to delivering a new product experience designed specifically to support growing organisations.

We conducted in-depth research to understand customer goals and how they thought about their organisation structure.

We uncovered common themes in how they expected their teams to work together.

We designed a new system to better represent those teams in iAuditor — and form the backbone for more relevant permissions, access, scheduling and notifications.

We focused on building the long term foundation for this new conceptual model — while also delivering value to customers as quickly as possible.

Along the way, we delivering in small steps — this meant we could release quickly to learn and adjust, making iterative improvements as a team.


We dramatically reduced the effort and complexity required to set up and maintain scaling teams.

Customers were able to significantly increase the size of their teams, leveraging the functionality we had built. We saw companies introduce inspection work for area managers and their site teams.

Over just 12 months, our work contributed to a 55% increase in teams with more than 10 users.

Access Management

We re-designed the way users managed access to inspection templates to make it easier to use, and to build the foundations for dynamic sharing rules in the future.

Team hierarchy

We helped organisations organise their teams and projects in a way that mirrored their business, so that dynamic rules could reference this structure.

Site Membership

We let organisations show us which team members were associated with which sites, so that we could then personalise their experience in the platform.

Dynamic rules

We tied all of this to dynamic ‘intersection’ and ‘site-based’ rules to reduce complexity of sharing and notification configuration across the platform, and to support how our users wanted their content to be shared.

We worked across all product teams to roll out these dynamic site-based rules to other areas of the platform such as inspection question alerts, incident management, and team communication.

At the same time, we worked to improve overall usability in these areas — aligning the overall experience to be more consistent.

Left: New experience for Issues feature / Right: Old experience for Issues feature