Connect Product Redesign

UX / UI / Product Strategy / UX writing

With scant usage data, fuzzy use cases, and a multitude of stakeholder perspectives, I gave a scrappy MVP a full-scale design overhaul – avoiding customer backlash and setting the stage for B2B SaaS product growth.

My role

I was solely responsible for redesigning the console product, selling the changes to product and engineering leadership, presenting a rollout strategy, and supporting the rollout. As a part of the process, I also created a new design system and style guide and led the creation and writing of a product help center.

The challenge

The Hiya Connect product was born as a proof of concept. Engineers and PMs collaborated to build a tool that let users register phone numbers, apply their branding to the calls they make, and measure the various performance points of those calls.

But the piecemeal growth of the product resulted in a UI that was cramped, inefficient, and confusing. This led to constant reliance on help from the Customer Success and Sales teams. The unforgiving structure of the tool’s UI also kept the product team from being able to add new features. Furthermore, making any significant changes to the UI required a huge overhead of engineering time.

We needed a new product design that:

• Resolves frustrating users experiences and usability issues

• Avoids disrupting existing customers

• Increases engagement by making core features easier to find and use

• Accommodates new features

• Reduces manual support work for Customer Success and Sales teams

• Increases perceived value through improved design quality

The solution

change everything… over time

No one likes a design overhaul. Users don’t like showing up to find everything moved around. Engineers don’t like the huge amount of work required to completely rethink how their product is built. And product teams don’t like thinking about the answer to “what if it doesn’t work?”

The solution was to define a “north star” version of the product and iterate toward it.

The first step is a “glow up”: keep as much intact from the existing version of the site as possible but make it prettier. Don’t try to replace existing features with something new – just improve what’s there. Users can still easily find their way around. Engineers can keep existing systems intact while mostly making front-end improvements. The product team can feel comfortable that users will continue getting the same value out of the product.

From there, make iterative changes to the UI until you’ve reached the north star version – or something close to it.

selections from the pitch deck for the project:

How we did it

› Data Gathering (from scratch)

When I joined the team, very little was being measured. We had Google Analytics but nothing else – and I am certainly no GA whiz. We also had no personas, no use cases, no prior research, no user flows… nothing. So I got to work.

I dug into GA and discovered that roughly 50% of our customers had not visited the console in the last 30 days. I also learned that nearly every user had very wide displays and almost no one attempted to view the site on a mobile device.

Interviews with stakeholders, sales, and support reps helped me learn what customers were saying about the product. It turns out that no one visited the site because it was difficult to use and they could simply have a member of our team manage their account for them.

I combed through customer interview recordings, company presentations, and miscellaneous slide decks to understand user goals and pain points. Our team was small and scrappy, so proper in-depth research methods were out of reach for now.

› Design iteration

Armed with as much information as I could find, I started designing. This was a B2B SaaS product – it didn’t need to be revolutionary, it just needed to help customers do their work. (We could be revolutionary once the foundation was in place.)

I broke the structure of the site into something more conventional. A simple header offered a search bar for quickly finding their registered numbers. A left nav bar gave us the opportunity to organize, adjust, and flex our features now and in the future.

The new structure also provided the flexibility to make the content more accessible to users. Users came to the console to manage their list of phone numbers – often hundreds or thousands of them – but the access points for those management actions were stuffed into a teensy scrolling box on the bottom left corner. With the new design, we could move those numbers to their own full content page, provide more details for pinpointing numbers that needed attention, and let them see and do more in every pageview.

Incorporating styles from the company’s approved-branding marketing site made the users’ transition from the sales cycle to product usage as smooth as possible. As I worked through various iterations, I got feedback from stakeholders on what was working and what wasn’t and adjusted as necessary.

› Sell the vision

Once the design was largely in place, I needed to sell the project to leadership, engineering, and others in the organization. I put together a pitch deck, identified the major pain points, described the step-by-step rollout process, and provided a now/soon/later visual that demonstrated how we would get from A to B to C. We agreed that this was the right way forward for the product and slotted it into the engineering calendar.

With buy-in from stakeholders, I continued fleshing out the design details and creating updated versions of every page and state across the console.

› Support the team

As the project reached the build stage, I regularly checked in with the engineering team to make sure that the designs were clear, complete, and free of any “hair-brained design ideas.” Throughout the build process, I created additional mockups as needed, provided QA and feedback, and even included detailed HTML and CSS suggestions for addressing front-end issues.

› While I’m at it: A design system and a Help Center

Because the design was a complete rethinking and overhaul, I took the opportunity to define a design system for the product. The system created consistency in the product for users and consistency in the development process for engineers. From text to buttons to modals and date pickers, I created components and usage rules for common elements across the site. I handed off the components and style guide to the engineers as a reference to create their own front-end components.

The existing self-serve help documentation was a single outdated FAQ page. If a user had questions or wanted to troubleshoot a problem, it was a frustrating experience that almost always resulted in a series of emails with the Customer Success team over the course of a few days. A member of the Customer Success team had expressed an interest in UX writing and had taken a couple of bootcamp courses, so I invited her to help me create a new self-serve Help Center. Together we wrote dozens of support articles guiding users through the existing features and providing troubleshooting guidance for each one. I acted as an editor and mentor as she got real-world experience writing for users.