SPYGLASS
Canal's Internal tool to help streamline processes for Go-To-Market, Customer Success, and Sales
Canal's Internal tool to help streamline processes for Go-To-Market, Customer Success, and Sales
Canal helps streamline brand partnerships with the all-in-one tool for brand partner proposals, commissions, and payments. Canal makes it easier for online retailers and product makers to connect with each other, integrate each other's products in their stores, set commission rates and payment schedules and arrange shipment to their customers. As a member of the design team, I am able to combine my passion for creative expression and user focused design while helping brands reach more consumers.
Today, customer data lives across a variety of tools (Metabase, Airtable, Retool, Slack, Django) and it takes Canal's Go-to-Market and Customer Success teams hours, if not days, to find answers to our users’ questions (if they can find them at all).
This delay is an extremely poor user experience and is only going to get worse as Canal continues to grow. This process also takes significant amount of time away from both our customer facing and engineering teams, lowering efficiency across the board.
How can we allow Canal employees to save time and energy, allowing them to do their jobs more efficiently - driving success through-out the company.
Create a tool for Canal employees that will allow them to ultimately increase their productivity in their day-to-day jobs.
I conducted a series of five interviews with members from Canal's Go-to-Market and customer success team. All of these members gather customer data multiple times a day and would be active users for Canal's internal tool.
Goal: Understand what the end user's pain-points were with the current system of gathering information and what would they benefit from the most out of this tool
Criteria: Member of the Go-To-Market, Customer Success or Sales Team.
Number of Participants: 5
Method: Remote interviews over zoom and in person
Key Insights: When it comes to retrieving customer data, the priorities between the three teams have a fair amount of overlap. However, it is important to distinguish the unique priorities and ensure that they don't get disregarded when designing the information hierarchy of the product.
After conducting the user interviews, I sat with my product manager and wrote out a list of User Stories. This allowed us to grasp a 360 understanding of what the user's were wanting, needing, and expecting out of this final product. As a designer, writing out user stories is an integral part of my process of getting out of my head and into the user's shoes.
After my interview process, I needed to make sense of all of the information I gathered. I met with my product manager, Josh, and Eng. Lead, Alex, to organize and make sense of everything in FigJam.
There were many asks, all varying in priority levels. Some of the requirements for this internal tool already had existing solutions as well as data already being pulled in from our backend. In this situation, it was important that I work smart, not hard. This meant that once I organized the information I was given, I could look around and see what existing solutions I could recycle into this new internal tool. Once the key metrics were organized, I met with a product manager and backend developer to gain a deeper understanding on what to prioritize.
Next, I organized the data into several different wireframe options, then presented the options to the end users, walking through the different information hierarchies. An Engineer lead was also attending the meeting, making sure that building this internal tool was practical to fit into the scope of the project. During this meeting it was decided to add an additional feature - Ghost Mode. This would allow our team to "spy" on our clients app to quickly gather information. Ghost mode would act as a bandaid while the team wait for Spyglass to be built in full.
During this meeting, we discussed whether the majority of this information was already in a Canal user's profile. What if there was just a way for our team to log into their profile without disrupting their experience or changing any of their settings?
Thus, Ghost Mode was birthed into the design process. Alex quickly figured out a way for our team to log-in to a user's Canal platform and I whipped up a simple design that notified our team that they were logged in as a "ghost". Ghost Mode granted Canal employees the ability to do what they were going to do in Spyglass while giving the design and eng. team to create Spyglass at an appropriate pace.
Based on my research, my educated assumption was that it would make sense to break the client data up with between five different pages within the internal tool. This would allow the users to quickly navigate to each section based off of the data they needed to gather. The pages would be broken up by Overview, Partnership Details, Analytics, Inventory, and Payment history, with the user first landing on a home page - 6 pages in total. These pages held information such as a client's payment details, where they were in their onboarding process, and who their partners were.
However, my assumptions on how to organize the client data wasn't completely accurate. After presenting my first iterations during a design crit, the team requested to have the information more condensed. Having the information sprawled over several pages would actually be more difficult to navigate and it was preferred by the Canal team to have the majority of the customer data on one page, with the exception of Analytics and Payment history on their own separate page.
I converted the five pages into three, combining Overview, Partnerships and Inventory and turning it into the "Dashboard" page. The Dashboard was the first page a user would see when inspecting a client, and would primarily be used by Go-To-Market and sales.
The Customer Success team felt strongly that they were going to be primarily working out of the Analytics page, so I left that separated.
I gave Payment Details its own separate page. The reason I did so was because it is an extremely data heavy piece of information that could potentially take up large sums of the page. It wouldn't not have made for a positive user experience if it lived on the same page as the other pieces of client information. I did, however, put high level Payment History details on the Dashboard page.
Finally, the user could access "Ghost Mode" from all three pages.
During week six of this design process, Go-To-Market requested the "Friending" feature. This feature would ultimately expedite the process for two brands to form a partnership.
I adjusted the scope of the project with product the lead product manager and engineer and designed this feature request.
Originally designed to be broken up into several pages, this page contains the following data pieces such as Account Overview, Partnerships, and Inventory. I added jump-links at the tops so that the user can navigate to the section they desired more easily. I organized the data based on the expressed priority from the team. This Information hierarchy was collected back when I presented the wireframes.
Analytics ended up living on its own page, per the request of the customer success team. Although the CX team does occasionally need information from the Dashboard, they primarily work out of the data that's presented from a customer's analytics - presenting solutions and action plans drawn from the KPI's of the Analytics page. I also worked closely with Canal's Data scientists to best understand what data sets needed to be presented and how we could best pull this data from the backend of our software.
Since a customer's payment details held a lot of information, it was decided by me and the rest of the team to also give this its own page. On the Dashboard page, there are high level details about a customer's payment details, however, if a user wishes to inspect the information, they will be directed to the Payment Details page.
Spyglass was a project with many moving parts. Each product feature required its own amount of research and iteration. While a traditional design process did help guid the initial direction of the project, I couldn't hold on too tightly to the assumed process I had at the beginning. Some features needed littler iteration, while others required several rounds of iteration and user feedback. Cross-functional communication, remaining focused, and releasing all preconceived ideas on how this project would come together is what ultimately got it to the finish line. I Throughout this project, I was in close communication with several engineers and product managers to ensure that the designs would fit to the scope of the project. I thrive when empowered to work with a design solution end to end, so the eventual successful launch of Spyglass was the cherry on top of a fulfilling opportunity for me. Ultimately, the teamwork and collaboration that encompassed this project is what made it so fulfilling and energizing throughout its entirety.
