**This project was completed in 2020–2021, before AI tools became common in enterprise design. All work was done manually.

Juniper's partner network handles a significant volume of service contract renewals — but the tools partners used to manage them were outdated, fragmented, and manual. Renewals that should have been self-service required partner intervention with Juniper's internal teams, creating SLA bottlenecks, slower in-quarter renewal rates, and friction that eroded partner confidence.
The Digital Experience and Automation team at Juniper set out to change that. The goal: build a renewals portal that gives partners full self-service capability — create, edit, view, and bulk download renewal quotations — across a single stable platform, accessible from anywhere in the world.
This wasn't a redesign of an existing product. It was a net-new platform, built from scratch, with a direct line to revenue.

I owned the design end to end — from requirement analysis through UAT and launch — working across Business Ops, Development, and Research to keep a globally distributed team aligned on a shared product vision.

1. Getting up to speed on a restarted project

This project had been started by a previous team, then put on hold. I joined it without context and had to build that understanding quickly — not just the requirements, but the history: what had been decided, what had been deferred, and why.
I worked through the Business Ops requirement document in detail and ran a series of structured discussions with my manager to reconstruct the project background. Rather than treating the existing work as a starting point to polish, I used it as a diagnostic — understanding where the previous design had stalled told me where the real design problems were.

2. Studying the previous design — without being constrained by it

The previous designer had produced preliminary screens based on an earlier set of requirements. I studied them carefully — tracing the flows, understanding the assumptions, identifying which decisions were still valid and which needed to be revisited given the updated brief.
The old designs weren't wrong — they reflected a different problem statement. What they gave me was a concrete starting point for understanding the domain: what a renewal quote contained, how partners navigated between quote states, and where the complexity lived in the workflow.

3. Sketching to think, not to present

Before opening Figma, I worked in sketches. The goal wasn't deliverables — it was exploring how different structural approaches would handle the core challenge of the portal: partners needed to manage quotes across multiple states (approved, draft, expired, unused) at a glance, while also being able to drill into individual quotes with full detail.
I explored dashboard-first layouts, list-first layouts, and hybrid approaches before converging on a direction to take into initial design.

5. Prototype testing — validating before committing

With initial designs ready, the researcher ran semi-structured prototype testing with 4–5 partners across different regions. I supported by taking notes and synthesizing findings.
Four clear directions emerged from testing:

1. Revise the data cuts — the dashboard's data groupings didn't reflect how partners actually thought about their renewal pipeline. We needed to coordinate with Business Ops to restructure the cuts around partner mental models.

2. KPI-focus the dashboard — partners wanted four specific signals at a glance: top quotes by net price, new quotes since last login, upcoming renewals by contract, and quotes approaching end-of-life or end-of-support. The original dashboard showed data; partners needed decisions.

3. Quote name editing — a seemingly small feature that came up consistently: partners needed to rename quotes to match their own internal naming conventions.

4. Quote flagging — the ability to flag a quote for follow-up was a high-value low-effort addition that partners asked for directly.

The testing confirmed the structural direction and gave me a concrete, prioritized list of changes before any high-fidelity work was locked.

6. User story mapping — keeping design and delivery in sync

As I revised designs based on prototype feedback, I cross-referenced the PM team's user stories to ensure every business requirement was accounted for in the updated screens. This wasn't a passive check — it was an active negotiation between what users had asked for in testing and what the business had scoped for delivery.
Where there were gaps, I flagged them. Where there were conflicts, I facilitated the decision.

7. Design approval — structured, traceable, fast

I used InVision to manage the approval process with a clear three-gate sequence: PM approval first, then Business Ops, then dev handoff. This structure wasn't bureaucratic — it was a risk management decision. Getting PM sign-off before involving Business Ops meant feedback arrived in the right order and didn't generate rework loops between stakeholders who had conflicting priorities.
Every design decision was visible, versioned, and traceable. When the development team had questions during build, the answer was always one screen away.

The final design was built in Sketch and prototyped in InVision. It covers ten core user flows:

1. Quote list views by state — Approved, Draft, Expired, Unused
2. Filter, search, and saved views
3. Quote detail view with alerts
4. Quote download (single and bulk)
5. Global search
6. Create quote — from scratch, from contract, or from an existing quote
7. Edit and copy quote
8. Unattached assets view
9. Contract list and details view
10. Business partner selection

The design is built on Salesforce Lightning components, customized throughout to meet the specific needs of Juniper's partner workflow. Every flow was reviewed, tested, and approved before handoff.

(Click on the individual pages to see them full screen)

8. Developer handoff — specification as a shared language

Handoff wasn't a one-time event — it was an ongoing collaboration. I provided full component specifications to the development team and gave them access to InVision's Inspect tool for CSS derivation.
In parallel, I began building an extensive component library: documenting each component's specs, behaviors, variations, and usage guidelines. The goal was to give the team a reference that answered the question before it was asked — reducing back-and-forth during development and laying the groundwork for a consistent component system on future releases.

9. UAT — closing the loop before launch

The researcher and I ran a final UAT session with five live users across EMEA, APAC, and AMER — testing the built product, not the prototype, against real partner workflows.
I took notes throughout, and where the built UI had drifted from the design intent or where users flagged usability gaps, I communicated changes directly to the development team. UAT wasn't a box to check — it was the last quality gate before launch, and I treated it that way.

10. Launch — and what happened next

The portal went live regionally in phases: EMEA in May 2021, followed by APAC, AMER, and CALA in June 2021. The team tracked post-launch metrics and fed the findings back into a prioritized JIRA backlog for subsequent incremental releases.

What shipped: The portal launched globally across four regions in May–June 2021. Within 30 days: 290 unique users, 983 quotes created, $4.88M in quote value. The project was highlighted at the departmental all-hands as a benchmark success. Incremental releases are ongoing.

The outcome I'm proud of: $4.88M in quote value in 30 days is the clearest evidence I've seen that design decisions translate directly to business outcomes. Every call we made to simplify the quote creation flow, surface the right KPIs on the dashboard, and reduce the steps between a partner logging in and getting a quote out — each of those decisions compounded into that number. It's the reason I design the way I do.

The leadership moment: This project ran for six months across three time zones, six stakeholders, and a platform constraint that limited what we could build. Keeping that moving required something beyond design skill — it required being the person who held the whole picture in their head when everyone else was focused on their piece of it. I learned on this project that the Lead Designer's job is as much about making decisions visible and traceable as it is about making good decisions in the first place.

What I'd do differently: Three things, with the benefit of hindsight and AI tools now available:
The prototype testing yielded strong insights, but the synthesis was manual — I'd now use AI to process interview notes across all sessions simultaneously, surface patterns faster, and reduce the risk of recency bias skewing which findings felt most prominent.
The KPI dashboard design went through multiple revision rounds before landing. AI-assisted proto-persona work upfront — synthesizing partner behavior signals from support tickets, renewal rate data, and previous research — would have given me sharper starting criteria for what the dashboard needed to prioritize, cutting those revision cycles significantly.
The component library I started during dev handoff was the right idea but came too late in the process. I'd now use AI to accelerate the initial component documentation — generating spec drafts from design files — so the library is ready before development starts, not after it ends.