Overview

Juniper and HPE have a lot of products and services, and finding the right one was harder than it should have been. A customer either dug through a dense website or reached out to sales and waited. Both are slow. This project was about replacing that with a chat assistant, something closer to a sales assistant, where someone could describe what they needed, add context, and land on the right product or service quickly.

The idea was a GPT-inspired chat interface that could handle dense information about Juniper and HPE's offerings, and let the user narrow in through conversation instead of navigation. I led the design end to end, and it was built and approved by the stakeholders involved

The user

This was not a consumer tool, and that shaped almost every decision. The users were long-standing enterprise partners and customers, vendors, enterprise operators, and CMOs, the kind of people who engage with Juniper repeatedly and consistently over time. They come back. They have ongoing relationships and recurring needs.

That detail matters because a repeat enterprise user benefits from things a one-time visitor doesn't, saved history, persistent context, preferences that carry across sessions. Keeping the user clear on who this was for is what justified the biggest architectural decision later on.
‍

Research and discovery

I'll be straight about the constraints. I didn't have a research team or direct access to user data on this project. I pushed for deeper user research throughout, and worked resourcefully with what was available, which is a normal reality of a lot of design work. So the discovery came from three places.

The first was competitive and comparative research. I studied how the leaders in AI chat actually structured their experiences, OpenAI's site among many others, to understand the established UX patterns for this kind of product and where they led. This turned out to drive the most important decision in the project.

The second was stakeholder alignment. I ran a working session with the CMO and the head of brand to get clear on the goals, the intent behind the experience, and what success looked like. Defining the problem with the people who owned the outcome kept the design pointed at the actual objective instead of my assumptions about it.

The third was the existing understanding of Juniper's customers. Even without a formal research pipeline, the team knew who these enterprise partners were and how they engaged, and I designed from that real understanding of the user rather than a generic persona.

The core decision: killing the hybrid

My first instinct was a hybrid, chat living inside the existing website and application experience, so a user could start a conversation right where they already were. I wireframed toward that.

The competitive research is what changed my mind. Looking at how the leaders handle it, even OpenAI, whose homepage has a chat input, sends you to the separate ChatGPT application the moment the chat actually executes. That was the tell. A real chat product isn't a feature you bolt onto a marketing page. It's a stateful application. It needs login, history, bookmarks, settings, and preferences, and all of that needs its own data and infrastructure.

Trying to make one page be both a stateless marketing site and a stateful chat application meant the two systems would fight, on navigation, on data, on state. And the chat experience needed its own navigation to handle settings, history, and preferences properly.

There's a fair counterargument, since this wasn't B2C, you could say persistent history and settings aren't strictly required. But when the established UX patterns for a product type call for those elements and you strip them out to force a fit, you introduce friction into the whole product. And at that point you have to ask an honest question: if it can't be done well as a hybrid, is the hybrid even worth building? I decided it wasn't. I deprecated the hybrid idea entirely and designed it as an independent experience that users would be directed to from the main website.

The user type backed this up. Repeat enterprise partners genuinely benefit from persistence and their own navigation across sessions, so the standalone application wasn't just cleaner architecture, it served the people who'd actually use it.

Design and exploration

I worked through multiple directions and layouts before settling, wireframing and prototyping across several ideas for how the interface should be structured and how a user would add context to narrow toward what they needed. The through-line was speed: someone should be able to describe a need, layer in context, and reach the right product or service without navigating a site or waiting on a person.

I also gave the AI experience its own visual language while keeping it aligned with Juniper's broader design system, so it felt distinct as an AI-native product but still unmistakably on-brand. That let it stand on its own without feeling like a foreign object bolted onto the company's identity.

The whole thing came together over about three weeks, alongside other projects I was carrying at the time.
‍

Outcome

The design became a high-fidelity prototype, it was built, and it was approved across the stakeholders involved, including the CMO and brand lead I'd aligned with early. It took a slow, frustrating task, finding the right product across a dense catalog, and turned it into a fast, conversational one, with an architecture chosen deliberately for the enterprise users it was actually for.

What I took from it

The decision I'm most proud of is the one I almost got wrong. The hybrid was the obvious, convenient idea, and the research is what saved it. Studying how the category leaders actually solved the problem showed me that a chat assistant is an application, not a page feature, and that recognizing when a convenient approach quietly degrades the product is worth more than forcing it to work. Sometimes the most useful design decision is deciding what not to build.