Hiya Connect Redesign

Designing Hiya’s flagship B2B product

When I joined Hiya as a Senior Product Designer, the Connect product had real potential and real problems. There was no design system, no established research practice, no roadmap for what the product should become — and no designer guiding the work. This is the story of how I rebuilt the product from the ground up, and how doing it alone meant doing it like a leader from day one.

Context

A product built without design

Hiya Connect started as a proof of concept. Engineers and PMs built it quickly to validate an idea. The result was a product that had promise but was cramped, confusing, and expensive to maintain. Customers relied on the Customer Success team to manage their accounts because the product itself was too difficult to use independently. Engineers struggled to add new features because the UI's rigid structure made any change costly.

When I joined, there was no design manager setting direction, no established design process, and no research to build on. Leadership trusted me to figure out what the product needed — but that trust was implicit, not structured. I had real ownership and no playbook.

The challenge

What needed to change

The problems weren't just visual. The product's structure actively prevented growth — for users, for the team, and for the business. A redesign needed to accomplish several things at once:

• Resolve core usability and labeling problems that frustrated users daily

• Create a structure that could accommodate new features without engineering rework

• Reduce manual support burden on Customer Success and Sales

• Avoid disrupting existing customers — no big-bang overhaul

• Increase perceived value through improved design quality

• Establish a design foundation the team could build on as it grew

How I did it

1. Built a research foundation from nothing

There were no personas, no user flows, no prior research — just Google Analytics and a product with obvious problems. I dug into GA and found that roughly 50% of customers hadn't visited the console in the last 30 days. I interviewed stakeholders, sales reps, and support staff to understand what customers were actually saying. I combed through customer sales recordings, company presentations, and slide decks to map user goals and pain points. The team was small and scrappy and formal research methods weren't accessible yet, so I synthesized what I could find and built from there.

↳ No one asked me to build a research practice. I identified the gap and filled it because the work required it.

2. Defined a strategy before touching the UI

A full overhaul would have disrupted users, overwhelmed engineering, and created risk the business wasn't ready for. I developed a north star vision and an incremental rollout plan: first a "glow up" that improved the existing experience without restructuring it, then a series of iterative changes toward the north star. This approach let users find their way around, let engineers make mostly front-end changes initially, and gave the business confidence that customers would continue getting value throughout the transition.

↳ Defining a phased strategy — rather than just designing screens — was a leadership decision. It required understanding the business and engineering constraints as well as the user needs.

3. Sold the vision to leadership

Once the design direction was clear, I built a pitch deck and presented it to product and engineering leadership — identifying the major pain points, describing the rollout plan, and providing a now/soon/later visual that made the path from A to B to C concrete. I hadn't been asked to do this. I did it because I knew buy-in was required to get the project on the engineering calendar, and getting it there was my responsibility.

↳ This was the moment the project shifted from a design effort to an organizational commitment. Driving that shift was something I took on independently.

Some selections from the pitch deck:

4. Designed every page and state, then supported the build

With buy-in secured, I fleshed out the full design — every page, every state, every interaction. Throughout the build phase, I checked in regularly with the engineering team to make sure designs were clear and complete. I provided QA feedback, created additional mockups as needed, and even offered specific HTML and CSS guidance to resolve front-end issues. The goal was to be a useful partner to engineering, not a gatekeeper.

↳ Setting the standard for engineering collaboration — being specific, responsive, and hands-on — established a working model that carried through as the team grew.

Some mockups from v1 of the redesign:

5. Created a Help Center — and mentored someone along the way

The existing help documentation was a single outdated FAQ page. Users with questions almost always ended up in a multi-day email thread with Customer Success. I decided to build a proper self-serve Help Center from scratch — and when a Customer Success team member expressed interest in UX writing, I invited her to co-create it with me. Together we wrote dozens of support articles covering every feature and common troubleshooting scenario. I acted as editor and mentor, giving her real-world experience while getting the Help Center done.

↳ This was the first time I recognized an opportunity to develop someone outside my team. It's an instinct that has defined how I lead ever since.

Outcomes

What the redesign delivered

The redesign was a resounding success by every measure the team tracked — and it set the foundation for everything the product became afterward.

• Restructured the UI to accommodate new features without engineering rework

• Resolved core usability and labeling problems that had driven support requests

• Reduced manual support burden on Customer Success and Sales

• No negative customer feedback (and plenty of positive feedback)

• Design and UX cited regularly by the sales team as factors in successful deals

• Established the design system still in use by the team today

• Launched a self-serve Help Center that reduced email-based support

• Created an engagement tracking foundation (Pendo, Hotjar) for future iteration