Defining Product Vision at SafetyCulture

In 2018 I joined the Team Management team at SafetyCulture as a Product Designer. This teams key responsibility was enabling iAuditor customers to rapidly expand and manage their users. I worked with researcher Dylan Mathiesen to understand the growing complexities that iAuditor administrators faced when managing their users.

During this process we:

Pulled the brakes on what was fast becoming a solutions led project.
Defined and delivered a vision for the future of Team Administration within iAuditor.
Established a repeatable process for presenting complex visions and proposals to stakeholders.

The Initial Problem

What had worked for small and medium-sized teams, wasn’t scaling to meet the needs of large organisations.

Within iAuditor, there are two key types of users:

Users who are responsible for conducting inspections, these users require inspection templates to be shared to them.
Users who require access to completed inspection reports, these users require completed inspection reports to be shared to them.

In an effort to streamline the sharing process, iAuditor offered the ability to group users and apply sharing rules at the group level.

However, as larger teams started to use iAuditor, this flat model of grouping users for sharing became cumbersome. Large organisations were creating multiple groups with complex naming structures to accommodate their business rules. As a result, organisations set up multiple sharing rules that became impossible to manage and keep track of.

A Preconceived Solution

The popular opinion among SafetyCulture staff was that sharing could be automated, simplified and more manageable if we supported nested groups, thus establishing a tree structure (mirroring a typical enterprise hierarchy). It was hypothesised that inspection templates would share down the tree, and completed inspections reports would share up.

For example, as illustrated in the below digram, if an inspection template was created at node A, everyone under node A would have access to that inspection template. If node E conducted an inspection, the completed inspection report would automatically share up to nodes B and A.

Research and Discovery

Observation #1: Interviews revealed that the preconceived solution of nested groups failed to satisfy all of our customers business needs.

To kick off this project we conducted extensive customer interviews with iAuditor administrators. These interviews revealed that, for small and medium teams, the mental model of templates sharing down and reports sharing up a tree structure worked. However, large organisations had complex sharing needs, which would require constant overriding of any automatic hierarchical sharing.

Example 1 - Cross Sharing

When a template is created at a certain node, but is required to be accessible by everyone on that node level and below. Eg, a template created at node B needs to be accessible to everyone under node B and C as B and C are on the same level.

Example 2 - Mystery Shopper

When an inspection is completed, but the node level directly above shouldn’t see the inspection report. Eg, an inspection is conducted at node D, but node B shouldn't see the inspection report but node A should see it.

Example 3 - Travelling Auditor

If a user is part of multiple groups, and they complete an inspection, how do we determine which route of sharing the completed inspection should take? Eg, a user is part of node D and G, should node B or C see the completed inspection report?

Observation #2: Our customer base had outgrown the rudimentary user administration and team management tools that iAuditor offered.

Internal interviews with staff who assist iAuditor administrators on a daily basis (the support and success teams), in combination with our customer interviews highlighted that administrators lacked basic visibility and management over their users.

We identified and recorded a large number of jobs to be done (JTBD) that administrators needed to do that were either too difficult or impossible. These included:

Resetting a users password
Editing a users account details (name, email, timezone, notification settings)
Viewing a list of all templates and inspections a user had access to
Viewing a list of all groups a user was part of
Viewing all devices a user is associated with
Viewing when a user last logged in

Observation #3 - The sharing pain was actually a symptom of a much larger problem.

There existed two main pain points surrounding the task of sharing. Initial setup; and validating that users had correct document access. Our initial plan of automating the sharing process via nested groups only addressed one part of the problem (initial setup). If we released a method to automatically share documents, without fixing the visibility issues, we would dramatically increase the manual complexity of identifying if users had access to the documents they should.

It was vital that we provided a method for administrators to confirm who had access to what, at the individual level, before we allowed any type of of automated sharing.

Defining the Vision

If team administration was a house: User management and access visibility would be the foundation.

While automating the sharing process was a worthy endeavour, there were other more pressing issues that needed to be addressed first. As such, Dylan and I put together the following recommendations for holistically improving Team Administration within iAuditor.

Milestone 1: User Management
Improve onboarding; visibility; and management of users within an organisation.
Milestone 2: Group Management
Easier setup; visibility; and management of groups within an organisation.
Milestone 3: Sharing Workflows
Reusable sharing patterns that work.
Milestone 4: Delegated Privileges/Hierarchy
Privilege delegation; organisational control; automated sharing patterns; and simplified permissions.

Milestones 1 and 2 would see the introduction of user and group profiles into iAuditor. Solving the visibility and management issues, while providing a foundation for an improved sharing experience.

Pitching the Vision

The key to successfully pitching our vision hung on our ability to effectively communicate the pain experienced daily by our customers.

We had to pitch our recommendations to various stakeholders, including the:

Product Manager for the Team Management Team
Heads of Product, Design, Customer Support and Customer Success
Team Management Team

Our pitch detailed each of the four milestones, and for each milestone we:

Discussed the high-level problem that required addressing.
Provided compelling and memorable customer stories that represented significant portions of our user base.
Summarised what we aspired to accomplish.
Showcased early design mocks and prototypes to aid in outcome visualisations.

To ensure everyone walked away from our pitch understanding our customers' frustrations, we ran activities we called "Feel the customer pain". Participants would be assigned a series of tasks that our customers regularly do; tasks that are either impossible; too time-consuming; or confusing.

Outcomes

Our vision made it onto the product roadmap and a second team was assigned to assist in delivering the vision.

We successfully secured buy in for Team Management to undertake this project. By focusing initially on user management, Dylan and I afforded ourselves more time to spend exploring other options for simplifying sharing. During my time with the team I saw the delivery of Milestone 1 which you can read more about here.

I established a repeatable process that I now adopt in all my projects.

This was my first large scale project as a Product Designer. The process that I followed is one that I now employ and continue to tweak with each new project. The process can be broken down into several phases:

Stakeholder analysis: Conduct external customer and/or internal staff interviews.
Distil findings: Identify and document JTBD and/or customer stories.
Sketch: Begin rough mocks of deliverables and flows.
Roadmap breakdown: Roughy identify, scope and prioritise deliverables for each release.
Stakeholder buy in: Pitch the vision; roadmap; and rough mocks to stakeholders to secure project resources.
Design and implementation: A conventional cycle of designing; user testing; and refining.

Conclusion

I learnt a lot about user research and research methods as a result of this project.

Upon starting this project there was a strongly held preconceived solution to a very loosely defined problem. This was, in itself, the most challenging part of this project. It was imperative that we steered this project away from being solutions led and back to being problem focused.

While I think we did a great job redirecting the project back to being problem led, I do think that early on we spent to much time trying to make that preconceived solution of nested groups work.

This experience reinforced the importance of asking "why?"

During the research and discovery phase, I had staff and customers suggesting that the product should do X, Y and Z. Upon further questioning it was almost always revealed that X, Y and Z were simply bandaid solutions to a deeper problem. I was often reminded of the Henry Ford quote "If I had asked people what they wanted, they would have said faster horses".

I found my voice!

At the start of this project I was a reasonably new to Product Design, with little experience interviewing customers and pitching to stakeholders. This project saw my confidence and skills as a Product Designer grow exponentially. This experience helped me find my voice and become the voice for our customers.

Peer Feedback Relating to this Project

Jo researched, engaged, designed and in partnership developed a strategy for Team Administration that has changed the product direction and defined the primary work for the Team Management team over the next 12-18 months. Some of the highlights include:

Building the ground work and helping convince Brian and Tom that the project was heading in the wrong direction with real customer stories and customer research.
Conducting exceptional in-depth customer research that allowed the team to truly understand the pain and form a vision for the product.
Jo brought the entire team on the journey. Every single person on the team can clearly articulate the customer problem and understands the pain they experience.
Jo investigated and explored new methods for improving the customer experience at an incredible level of detail.
Jo was a major contributor to the Team Administration vision and has now set a standard for depth and clarity of project vision. All of the product teams have been requested by Brian to build the same style of vision now.
Jo went above and beyond assisting Tom and Dylan preparing all of the artefacts, mocks, research and info required before the project kickoff.
This project would have stalled without Jo's work to keep the momentum going.