Natalie Kyle
Product Experience Designer


First impressions are everything.

The Problem

The on-boarding process of Acme's* PSA tool has been a problem for new users for EIGHT years. Users are terminating before they are even able find the value in the product. 

User problems:

  • Time Consuming
  • Complicated
  • Confusing

Time consumingIt takes users 20 - 90 days to be up and running after purchasing the product. Users have to take weeks to months worth of training to know how to setup and use the product. All the while continuing to run and maintain their business.

The product and setup is not intuitive. Users are not sure how much of the on-boarding requirements they have finished or how much is remaining.

ConfusingBecause the product is not intuitive the users need documentation to further educate themselves. The methods in which documentation is provided is not pleasant. 

The product loses money on 70% of their client base due to poor process.

My Role

Facilitated Design Sprint

I facilitated a 5 day long design sprint. The Designers, Product Manager, Developers, Internal Experts and Users combine forces in a room for five days. First we make sure we are all understanding the problem correctly. Using research, various thought evoking tools, communication and understanding we have a prototyped concept at the end of day 4. Now we can better communicate with VPs to see if the concept will solve the business need.


I conceptualized the solution and built the prototype in order to tell the story. I also ran the concept through some initial user testing.

Presented the concept to get Executive buy in

This was a very large concept that has been talked about for years. The solution will impact and affect all 6 products in the product suite. It was import that we vetted this concept with as many colleagues as possible. I presented this concept 8 times throughout the company to make sure everybody was informed. 

The Goal

Help partners onboard themselves by building a foundation that allows them to start using the product faster 

The Approach

Five days of cross team collaboration.

Set a goal πŸ†

The team sets a goal in order to assure our solution stays on track. We hold a meeting with all stakeholders and product VPs to ensure we are all on the same page with the goal. Our goal was "Help users onboard themselves by building a foundation that allows them to start using the product faster"

Map it out πŸ—Ί

Current Map
The current journey map is massive. Mapping out the user journey allows us to quickly see where the user problems arise. I have detailed below more about the current map.

New Map. The ideal experience.
This is a brand new concept so there is no current experience to map out. The team starts by mapping out the ideal user experience. We take the map and run it past internal experts and users to see if we are close to hitting the mark.

Expert Sessions πŸ—£

We have already done some upfront User Research which has given us a good place to start. We bring in internal experts and/or current users to answer some questions that are still outstanding. We run them through the new journey map to validate if we are heading in the right direction.

How Might We πŸ€”

These are questions that we have about solving problems. Instead of stating the problem, turning the problem into a question can help facilitate ideation.We document these on the map so we make sure we solve them along the way.

Our CEO made a surprise appearance to join in the fun. :)

Lightning Demos ⚑️

The team researched other dashboard products and illustrate what they like or dislike about them. Each member of the team presents the product they picked. We capture these ideas to help generate individual ideas for the sketching rounds.

Sketching ✍🏼

3 Rounds of sketching. Each person presents their concept sketches and the team then votes on the features they like the best. The most voted on features help us shape our storyboard.

Storyboard πŸ“–

We create and evaluate the storyboard to make sure the team is comfortable with the story we are telling and the way we plan to solve the issues.

Build Prototype πŸ‘·πŸ»β€β™€οΈ

The last day calls for primarily only designers. We have PMs on standby to supply us with data and answer questions that might come up. We review the storyboard, make sure everything checks out and then we begin prototyping. Designers get assigned screens so we can build the prototype in tandem.

User Testing πŸ‘¨πŸ»β€πŸ’»

After the prototype was completed we hopped on the phone with a few users that had recently gone through the on-boarding process. 

Users were not able to poke any major holes in the concept, which was great. What was even better is they were very quickly able to provide us with more insights and ideas to incorporate. We heard about a few issues that had not came up in previous research. 


The Current Onboarding Journey Map

  • The process goes through 10 different internal resources
  • The user receives 14 emails and requires 4 phone calls
  • The user has to wait 2 weeks to get started because the process relies on internal resource availability. Human intervention is required. 


New On-boarding Journey Map

We were able to remove NINE internal resources from this process and enable the users to complete the process by themselves. 

Sprint Questions:

  • Can we reduce the complexity?
  • Can we allow them to spin up their Manage instance instantly rather than 1-3 days?
  • Can we make it easy for users to know who to contact for help, should they need it?
  • Can we integrate with Quickbooks to quickly/seamlessly import their data?
  • Can we reduce the number of Connectwise points of contacts and handoffs? 
  • Can we bring educational assets to the user in product rather than have them dig to find them?


The solution was to first automate the process of creating a Manage instance. This allows for users to create their environment on demand, rather than wait 2 weeks for a sales rep to do it for them. From there they would be walked through a guided setup that would allow them to establish their basic foundation of Manage.  When the set up is complete we talk them through the product and show them where to find and how to use the foundational pieces they just setup. We decided to make the guided set up a layer on top of the product, to create a barrier to entry. Users were getting in the product instantly, without anything being set up and it was causing more confusion.

In short:

  • Automated creation of their Acme* environment
  • Guided setup to establish the foundational pieces of Acme* and tailor it to their business. 
  • Quickbooks integration to quickly import their client data. 90% of our users use quickbooks. 
  • Brought educational pieces and ways to contact support into the product so they would not feel lost during the process.
  • Streamlining the process removed NINE internal resources from the process


After the Design Sprint we conducted 5 interviews with users to get feedback on our design. Each user validated our concept and was able to provide even more insight and things to consider in future iterations.

User Feedback

  • "This is 100% improvement"
  • "Can you delete my instance and give me this one NOW!?"
  • "This is way more intuitive than what is happening now"

Days faster for the user to access the product
Cost saved internally per year
Emails removed from the process
Phone calls removed from the process

What I learned

This project was a great experience. I had never worked through a problem that involved so many departments before. We thought we might have too many hands in the kitchen at first, but everyone played a vital role in the solution. 

Data is King

The best part of the project for me was the fact that we actually had data to work with. DATA - oh, what a lovely thing! It isn't typical for our projects to have data to support the current state of the problem. This data made it a lot easier for the team to make decisions and to be able to measure the success once implemented.

Affect of internal process on users

The most eye opening thing for me was realizing how much internal processes at our software company affect the user, even though the processes are not in the software itself. I am very  passionate about helping colleagues realize the importance of the decisions we make and who those decisions effect. This problem and solution were a great example of this problem.

* Product name has been changed to keep anonymity.