Snow software
From on-prem to cloud self service
Snow Software specialises in software licences and machine compliance inside an organisation. It needs data collection agents to work. Snow package builder is the tool to build those agents.
Designer inside a product trio
1.5 years (50%) — 2021 to 2022

Problem space
As we are transitioning from an internal on-prem tool to a single web service for everyone, we are exposing complexity coming from each unique customisation. The experience quickly became overloaded with information, making decisions hard to make. How do we create a tool that contains all the features and customisation and remains simple to use?
Business strategy
For Snow software, agent creation represents a cost and point of stress for customers. Twice a year, a version would be released and all customers would show up all at once to get their new agents created. It would take weeks to clear the backlog and be prone to human errors. Offering a self service meant that customers could get exactly what they wanted without waiting time.

Learning from current users
Early on we saw a lot of complexity arise from the number of options possible when using the tool. I organised workshops with the people using the tool today and with the teams in charge of creating the custom agents to understand how they work together and what the thought process behind them was. These activities helped form categories and understand needs.
“In this project I pushed a lot for the concept of progressive disclosure of complexity and customisation. Once we validated that there was a standard relevant for 80% of use cases, it made sense to push in that direction. The challenge was then to convince engineers that not everything needed to be available on the first page, and that their feature was more an exception than a rule.”
Validating with customers
The risk was that we moved an action performed by in-house trained specialists and were going to place it in the hands of customers not accustomed to our lingo, process and know-how. I conducted several rounds of accessibility testing on this project to make sure the future audience would be able to use the tool. This was also a challenge as we had to increase the scope, producing documentation and help so that a new person would be able to feel safe when using the tool. We also added error validations and ways to revert if mistakes were introduced. Things we did not need to consider before.

Roadmap

Outcome
The project took more time than expected. By the end of phase one we had fully phased out our internal tool, our customer service agents used the cloud service and a selected list of more advanced customers started to have access to the self service. Since they were our most demanding customers we started to see the pressure reduce when we had our major releases. We had also identified the future areas of improvement needed to move it to the next phase.
Learnings
Things do not happen in a vacuum. What I learned in this project was that several teams had an impact on how this system worked. Changing how it worked meant asking several projects to operate differently; changing the availability of something meant changing how a specific work item would be valued against another. For the future planning of the project I understood that politics and global alignment would be needed in order to truly get to where we wanted to be.

