Right Is Better Than Fast

Problem

I was running a project to redesign the login page at Box. Businesses use Box to store critical corporate data, and each customer could configure their unique, custom-branded login page. In addition to email and password text fields and a submit button, the login page included space for a custom welcome message for the end-users who were logging in to that organization's Box account.

The login page redesign aimed to make the experience more responsive and mobile-friendly. The new experience was sleeker and focused the user on a smaller, centered login form. The space for the custom welcome content was dramatically reduced from essentially unbounded to just a few lines subtly presented below the submit button.

As we prepared to roll out our gorgeous new login experience, the Customer Success team raised a major concern: our larger customers would be alarmed and unhappy with the new minimal design and deprioritization of the custom content.

Actions taken

I made the call to pause the rollout and investigate the CS team's concern. First, I looked at quantitative data: in this case, we could simply look at the total characters various customers entered in this field to understand the average and the maximum length of content. Since this was a login screen, we could even visit a few login pages to examine what the message said.

While we expected customers were using the space for a simple welcome message and guidance about how to use Box, many were in fact using the space to communicate legal disclaimers and usage restrictions. This custom message was being used for critical terms that these companies needed to share with their end users as they logged into Box.

 

The next step was to collect qualitative input. I partnered with CS to reach out to a couple of customers who we expected would have the strongest objections. Their sentiments echoed what we'd found in the data: this login custom content space was used for critical messaging to their end-users, and that message was often lengthy and needed to be prominent.

Ultimately, my product design partner and I revisited the design. Our changes weren't dramatic, but we did add more space to the message. We went back to our Customer Success partners and the customers we'd spoken to, both to explain the overall goal of the login page redesign as well as to ensure they felt heard and confident that we'd done our due diligence. While not everyone agreed with the final design decisions, they did understand the goal of helping end-users successfully and quickly log in by minimizing potential distractions on the page and ensuring it worked well on devices of all sizes. They also knew that we actively listened to their concerns and evaluated the trade-offs of our decision.

The feature launched later than we initially expected, but the reception by customers was better than it would have been if we hadn't paused to review and reiterate our goals and bring our customer success managers—who are on the frontlines communicating with customers on a daily basis—along on the journey to deliver a valuable product experience.

Lessons learned

• Partner with your customer-facing teams. It would have been easy to ignore the CS team's concerns, barrel forward, and launch the feature as soon as possible. But PMs can benefit tremendously from strong cross-functional collaboration. Customer Success has much better insights into what customers want and what their problems are through their direct interaction on a daily basis with customers of all segments. If we ignored their input, we would miss out on critical insights that led to a better solution in the end.
• Build trusted relationships. If different teams work together well, the entire business benefits. I would want my partners to feel confident that raising concerns directly to me was worthwhile. Pausing the rollout was the right thing to do not only from the customer experience perspective but also from the perspective of building trust with other teams. Thanks to my open-mindedness, CS would continue to feel empowered and interested in sharing feedback back to Product in the future.
• Right is better than fast. We shipped the feature later than expected but felt more confident that we were shipped the right experience and that we understood the trade-offs. While gathering this customer feedback much earlier in the product life cycle would have been the ideal process, it is rarely too late to improve a product before it's launched to customers.