During Q2 quarterly review, our COO identified unresponsive users as the primary cause of lost implementation project conversions.

That said, while it was helpful insight, "unresponsive" was a general diagnosis and could be caused by a variety of problems. Tasked with improving conversions, I wanted to determine why customers were becoming unresponsive.

In order to determine why customers were becoming unresponsive, I utilized ongoing research methods from which we had already collected data, such as Hot Jar heat mapping.

I found examples on Hot Jar of customer users and their agency engineers trying to connect to discuss details, but losing momentum due to asynchronous timing. I prepared my insights—as well as anecdotal feedback from account executives—to present to my team.

Having determined the main problem, I began to ideate around solutions and set goals to meet user needs. I concluded that our solution would have to serve three purposes: 1. Letting users know what to expect next, 2. Prompting users to return to the application when it was time, 3. Calling users to specific actions in app.

Next, I designed some high-fidelity wireframes in Figma using designs and components we had already developed. I knew that I wanted to add a side navigation to the product, and my favorite designs included notifications nested within it. However, the team decided to go with the cheap option for now: full-width notifications at the top of each project page.

These full-width notifications would ultimately appear overly prominent, push the rest of the information farther down the screen than desirable, and clunky; but in order to gain quick user feedback, we decided to move forward.

‍

As a team, we documented every in-project notification by user type in Notion. As often as possible, we wanted to include a link to the user's next action within the notification itself.

‍

Having charted all the notifications, we discovered we would need four variations: 1. a notification with no immediate action, 2. a notification with an optional action, 3. a notification with a necessary action, and 4. an empty state.

After designing the component variations, I lightly prototyped the interaction design to share with the Engineering team.

In turn, the engineers shared the planned backend logic and component mapping.

The engineering team added notifications to their upcoming two-week sprint. At the end of the sprint, we gathered as a team and split off in groups for a comprehensive QA session. The notifications build worked, but was not pixel perfect. Spacing was off and there was an extra container around the notifications. Additionally, there was no empty state. We added our issues to Linear and stood by for changes.

Eventually the feature shipped and went live.

My work for Scope taught me important lessons about working at a startup as the only Product Designer. First, I learned to design mobile first as much as possible to encourage the simplest possible architecture. Second, I learned to loop in engineers early in order to understand the design that would be the easiest to build. Finally, I learned to speak up for my vision and make fewer compromises on usability and quality control.