Understanding the challenge and opportunity of teams.
INITIAL DISCOVERY: INCIDENTS
In 2019, my colleague and I were working on a project to design a new incident reporting and issue management feature for iAuditor.
As part of our research into the overall experience, we identified significant UX issues in our current access management system that were actively restricting the growth of teams.
Without a better access system, our new product feature would fail to be adopted more broadly.
However, this was already an existing challenge across the whole platform, and if we kept ignoring it, the problem would only get worse.
We were able to create a basic access solution for the initial release of the new Incidents feature — but we knew this was an issue that desperately needed to be resolved at a platform level.
Access had always been ignored due to the complexity of the problem, and it did not sit with a specific feature team.
Our research showed us broader patterns in customer expectations, goals and frustrations.
We spoke with both customers at length about their experience setting up their team in our platform overall.
We were able to highlight important customer goals we weren’t meeting, as well as significant pain points that hampered teams trying to work together day to day.
Customers expected their workforce would have easy access to the information that was relevant to them.
Open by default
New customers generally expect to start with all information available, restricting only what is necessary – rather than manually and explicitly ‘sharing’ everything.
Mature organisations needed to be able to support multiple functions, franchises, brands, etc working within the same team – keeping their experience separate where necessary.
As they progressed with our system, customers became motivated to reduce the noise of ‘too much information’, to make it easier for the team to notice, and find information relevant to them.
As they brought more locations onto iAuditor they wanted to reduce centralised administration load by allowing delegation of team management and privileges within organisational hierarchies.
When information was sensitive, customers wanted to have the ability to restrict access to only those people who needed to know, primarily based on team reporting lines.
Expansion without consolidation
For teams that wanted to expand, we had the opportunity to avoid ‘company-level’ blockers / gatekeepers by allowing teams to share data without having to create a single iAuditor account.
PAINS AND Frustrations
Our current design did not set customers up for success — resulting in a poor setup that was time-consuming to maintain or change.
A ‘simplified’ design led new customers to set up sharing early on that they didn’t understand, hiding complexity. They would then have to completely re-do their sharing setup later on when expanding.
Flat vs Hierarchy
We used a flat user groups model to facilitate sharing – this was at odds with even fairly simple org structures, which were hierarchical, and so required elaborate group setups.
Mandatory double handling
Any expansion attempt required changing both groups themselves, and then also the sharing rules. This meant that admins were effectively forced to do their setup twice.
Change requires lots of work
Even if customers understood how to design a new sharing system, they would then need additional help to properly implement it (from internal support scripts to roll out changes).
Privileges: a blunt instrument
Delegating admin responsibility down to teams is very risky in our system today, because all product permissions adopted an all-or-nothing approach.
Intertwined with Analytics
The interconnectedness of team management and analytics meant customers had to compromise both on how they shared, and on the analytics they could achieve.
The old interface had both ‘basic’ and ‘advanced’ sharing modes. Customers understood neither.
Poor team and access management negatively impacted day-to-day engagement, adoption of different product features, and deeper investment in the product.
It was possible to map improvements directly to business benefit…
- Simpler sharing → more self-serve → more organic expansion
- Flexible sharing → broader feature adoption → engagement & retention
- Confidence in scalability → investment → retention & engagement
- Reliable access restrictions → more team members added → engagement
- Give back time and energy to sales team → more large seat deals, faster
This helped us to build support internally for what would be a large, multifaceted change, and put together product teams to work on this area of the product.
Common mental models.
We researched how customers structured their teams, and how they wanted information to be shared across them.
We covered a wide range of different industries and created diagrams to make sense of them.
What initially appeared to be ‘unique’ and ‘complex’ structures actually resolved into a few common access patterns.
A mental model of the organisational hierarchy was the central thread consistent across these patterns.
Customers referenced these hierarchies consistently across their work — they used it to analyse data, but also to talk about responsibility and relevance.
Hierarchy = responsibility
Businesses tended to organize the people, places and things that mattered to them into a hierarchical structure, with people responsible for each level.
Admins wanted ‘managers’ further up the hierarchy to have oversight of the content from the areas they supervised, but not the entire organisation.
The entities that were managed were themselves relatively fixed, but organisations often restructured.
Representing their existing hierarchy mental model in iAuditor would help customers to…
- Collect and compare information in a way that reflected their business.
- Organise their teams based on who was working together.
- Delegate work more effectively to managers and teams responsible for different parts of the organisation.
- Separately manage the work of different teams under the same business structure.
- Make the platform experience more personalised for everyone, especially when dealing with a lot of information.
A system based on sites
We felt we could make use of the existing ‘Sites’ functionality in iAuditor as a foundation for a more flexible ‘directory’ for teams.
Sites had originally been created as an experiment back in 2017 and, despite not being developed any further over the past few years, had been adopted by about 2,000 organisations, most of which were larger teams who were also feeling the pain of access and user management as they grew.
These customers were already associating site information with their individual inspections, actions, and incidents. This meant that most of their documents had site metadata. They were then using this metadata to analyse their content across the platform.
As more customers had adopted sites, it was clear that this early experiment would also benefit from work to improve the overall experience.
We hypothesised that if we also associated users as having membership of sites, we could reference this information when managing access, send more relevant notifications, and even set up workflows like schedules.
This would be much more flexible than our existing model, because access (for example) could be managed based on the properties or metadata of the documents concerned, not based on the person conducting the inspection.
Validating our conceptual model
Designing a new approach required many stages of exploration. We needed to confirm whether customers could understand this new concept for themselves, and understand how this would fit into the existing experience.
- First we explored the base idea in very basic prototypes as part of our incidents concept design. We used very basic text interfaces only; sufficient only to describe the functionality of site-based access, without investing any time in the interface.
- We sent out surveys asking customers how they organised their teams and information, to validate our approach at scale.
- Once the initial concept was validated with customers, we did serious amounts of sketching to figure out how to turn this into an interface, and fit it within the wider platform — both as a new site hierarchy, and a new access management interface for all parts of the platform.
- We built out a high level concept prototype to visualise the long term experience vision. We tested this in research sessions with individual customers, internally, and also via ‘customer advisory board’ workshop sessions.
- We shipped a two week ‘site membership’ pilot experience that personalised the sites users could see in iAuditor, but didn’t touch access. This let us get the signal that site membership could be used to bring relevance to the experience, without actually building the full access system for documents.
Communicating a long term vision.
Ultimately we arrived on two core interrelated design concepts that could deliver value to more than just sharing, but in fact the whole product.
We wrote press releases for these two key design elements to describe what the end experience would be like in the platform in the future.
We’ve extended sites to allow you to tag your inspections, actions and incidents by project, brand, division and more. This will give you more flexible ways to compare your data using the things that matter to your organisation.
Most importantly, you can also now associate your team members with these directory tags (for example, say who is working at a particular site, or is involved in a project), making it easier than ever before for your whole team to track and discover information that’s relevant to what they’re working on.
Organise your activity in iAuditor in a way that reflects how your company works.
As you set up your directory tags and associated team members, you can use this information to set up dynamic rules everywhere across the iAuditor platform.
Restrict template and category access: Restrict access to just the people who need to see the content, based on where they work, or what project involvement they have.
Smarter scheduling: Set up schedules for sites and projects, so you can track whether each location has been inspected on a regular basis, instead of just tracking the work of individuals or groups.
Dynamic notifications: Send out notifications to just the people who work at the site concerned, or just those involved in a particular project.
Team workshops to develop the personas.
Refined research-based personas.
A customer example: Swissport
Swissport is an aviation services company that manages more than 100 airports around the world.
When an inspection is conducted by the ‘Fuelling team’ at Dusseldorf airport, they want the Inspection results to be available to all the managers up that chain of hierarchy, and also to the same team that conducted it.
No one else should have access to the results.
To get this sharing structure to work across all 104 airports the ‘fuelling inspection’ template would need 832 rules.
Each time a new airport was added to the organisation, new groups would need to be created, and then rules added to the template.
This setup would need to be repeated for each inspection process the organisation needed to set up.
With the introduction of some basic dynamic rules we could reduce these 800 rules down to just THREE rules, for ALL airports.
Even more significant — because the rules were dynamic they would not need to be updated as the organisation grew.
New sites could just be added, and the existing rules would automatically apply to those new sites.
Small steps, ferociously.
This project began in the Incidents Team, and was a significant blocker to the growth of this new feature.
Given the size of the investment, and the number of legacy systems and technical and design debt that would need to be addressed, product teams were very reluctant to take on this challenge.
However — after much negotiation and many whiteboard sessions with the Head of Product, Product Managers from various teams, and with engineering leadership — this work kicked off across two teams formed specifically for the project.
Sites & Team Directory
The Platform Team worked to build out the team directory backend infrastructure to support the kinds of queries site based access would need. The Collaboration Team built the frontend and iterated on the interface from early opt-in beta through to full launch.
Read the Team Directory case study
The Collaboration Team worked to re-platform and completely redesign the sharing interface, as the foundation for Dynamic site-based access rules in the product. The Platform Team built the backend to support dynamic access based on site membership.
Read the Access Builder case study
Results & Impact
I led the design, and the product strategy for our new Team Directory and Access system from initial discovery and design through to progressive delivery.
I worked across 2 teams to build the infrastructure we needed, and then guided teams and several other designers responsible our broader platform to implement a site-based approach.
It was a long (almost 2 year) journey and a big investment from many teams — but the results were well and truly worth it to the business.
- Site membership grew from 14,000 to 62,000 sites with members over our first 6 months. (340% increase in sites. Number of orgs using site membership grew 168%.)
- Usage of the new hierarchy UI passed that of the legacy list view while still in beta. We grew overall traffic to the sites section overall by 94.2% over 12 months.
- Orgs adopting sites grew from 2100 to 5,027 (140% increase, we more than doubled the number of orgs using sites).
- Users associated with more than one site grew from 1000 to more than 4000 (300%). This was a strong signal that at this stage we’re seeing more multisite users, rather than single site users — this means there’s plenty of opportunity to grow down, but also that we got the right people to help us.
Our north star metric was to increase the number of sites with members from 17,103 to 50,000 by Dec 25, 2021. We reached 72,000.
We have seen several large organisations scaling up successfully using site-based access, helping Success to win some significant deals for the business.
The trees that are slow to grow bear the best fruit.
Even the bitterest fruit has sugar in it.
– Terry a O’Neal
Winding veils round their heads, the women walked on deck. They were now moving steadily down the river, passing the dark shapes of ships at anchor, and London was a swarm of lights with a pale yellow canopy drooping above it. There were the lights of the great theatres, the lights of the long streets, lights that indicated huge squares of domestic comfort, lights that hung high in air.
No darkness would ever settle upon those lamps, as no darkness had settled upon them for hundreds of years. It seemed dreadful that the town should blaze for ever in the same spot; dreadful at least to people going away to adventure upon the sea, and beholding it as a circumscribed mound, eternally burnt, eternally scarred. From the deck of the ship the great city appeared a crouched and cowardly figure, a sedentary miser.