To begin, we examined emerging competitors and interviewed more than 30 ISS clients across the Americas, Asia, and Europe, representing firms managing $100M to $1B+ in assets.

We explored how clients prepared for proxy season, reviewed research, and cast votes, alongside conversations with ISS employees about internal challenges. This helped us understand where clients struggled, what they needed, and where changes to the product or internal processes could improve their experience.

The research revealed different client needs around efficiency, transparency, customization, and support before, during, and after proxy season.

We mapped those needs alongside pain points in client and employee workflows, then identified opportunities across the core platform, new digital products, internal processes, and customer support. This helped ISS agree on its priorities and which ideas to explore first.

An early hypothesis was that redesigning ProxyExchange (PX), ISS’s research and voting platform, should be a priority, and client research supported that view. PX accommodated sophisticated workflows, but years of accumulated technology and design debt had made navigation and everyday tasks unnecessarily complicated.

Rebuilding the platform would require significant investment, yet interviews revealed that some clients were already evaluating competitors, making the consequences of leaving the experience unchanged more tangible. Improving the core platform became a clear priority for client retention.

During proxy season, clients could research and vote on more than 10 meetings a day. Each meeting involved multiple proposals to assess, research to review, and votes to coordinate across accounts that could follow different policies—all against overlapping deadlines. The redesign needed to make that workload easier to manage while preserving the flexibility clients depended on, and launch ahead of the next proxy season with enough time for training.

With little room for disruption during proxy season, we brought ISS clients to test prototypes before committing to detailed design. We tested whether the proposed navigation and information architecture simplified the experience while preserving access to the information and functionality clients depended on.

In parallel, we explored new product opportunities: tools for creating and adjusting voting policies, simulations of how policy changes would have affected past decisions, and AI-assisted policy creation and research review. Prototypes gave clients something concrete to evaluate and helped us assess which ideas warranted further investment.

During the project, I guided how the team translated client feedback into design decisions and structured ongoing client validation, working closely with product and engineering to resolve priorities and tradeoffs.

I also stepped into hands-on design on critical parts of the experience. One of those areas was ISS’s research experience. ISS clients reviewed hundreds of research reports during proxy season, making quick, easy access essential. Three principles guided my design:

• Consolidate the fragmented research experience: Accessing subscribed research and requesting additional research required separate pages. I combined them into one area, using “Subscribed” and “Not Subscribed” to clarify access and bringing viewing, downloading, and requests together.
• Align research with the voting workflow: Each meeting could have five or more reports, each repeating 10+ columns of meeting details. So I grouped reports by meeting to eliminate repetition. Although product favored publication-date order, reports arrived at different times. I aligned the team on meeting-date order to match clients’ voting workflow.
• Simplify the view while preserving flexibility: The cleaner layout still needed to support bulk downloads, detailed report information, and extensive customization. I moved report statuses and voting flags into compact indicators beside each report and kept additional attributes in optional columns, making the table easier to scan without removing functionality.

The redesigned platform is scheduled to launch in early 2027, so post-launch performance data is not yet available. Early client demos have provided encouraging feedback on the simplified experience and new product concepts.

“This filter functionality is so much better. Right now it’s such a pain.”

“This is looking good, it looks much cleaner and more intuitive.”

A key stakeholder believed that shortening the flow would improve completion. We examined that hypothesis as part of a broader assessment, comparing competitors’ application and onboarding flows alongside a heuristic review of Wells Fargo’s experience, customer research through dscout, and drop-off analysis.

All of this research surfaced a key insight:

Wells Fargo already had one of the shortest flows, but customers still felt uncertain about how to proceed.

In the research, customers described not knowing what to do at certain stages or why information was required. Their responses to competing experiences helped explain what was missing: they felt more guided and understood what they were being asked to provide.

For example, participants were comfortable answering additional security questions in Chase’s flow because they understood their purpose. The extra questions did not necessarily feel like unnecessary effort.

Together, the competitive assessment and user feedback showed why flow length alone was insufficient to explain abandonment. The research pointed to gaps in guidance that shortening the application would not resolve.

The findings gave us a clear question to design around:

How could we help customers understand what was being asked of them and feel confident taking the next step?

I translated the findings into four experience principles that gave product, design, and business stakeholders a shared basis for evaluating recommendations.

• Transparent: Explain why information is needed and what customers should expect next.
• Supportive: Anticipate moments of uncertainty and provide guidance that helps customers continue.
• Consistent: Use language, interactions, and feedback that reinforce a predictable experience.
• Easy: Remove unnecessary effort while preserving the explanations customers need.

These principles informed recommendations such as a progress tracker showing the customer’s current stage and what would follow, from personal information through identity verification. It addressed the need for transparency by making the journey easier to anticipate.

We also recommended clearer copy where customers were unsure why information was required or what to do next. This provided guidance at the moments customers had identified as confusing.

Together, these recommendations focused on keeping the application and onboarding process concise while providing the context and guidance customers needed to move forward.

REF_01

Framework development, workshop synthesis

With a clearer understanding of why customers hesitated, I worked with the Wells Fargo team to develop approximately 25 recommendations spanning application, identity verification, funding, activation, and guidance after application.

Prioritization meant weighing how much each change could help customers against what it would take to deliver. I brought the research perspective—where uncertainty was most pronounced and which changes could address it—while the Wells Fargo team assessed feasibility and implementation effort.

Copy improvements emerged as an early priority because they addressed confusion directly, required relatively little effort, and had executive support. The roadmap paired these opportunities with more substantial changes, giving the team a sequence of improvements grounded in customer needs and delivery constraints.

Several recommendations were incorporated into Wells Fargo’s product roadmap, including the progress tracker. Following implementation, Wells Fargo measured a 2× increase in conversion and customer satisfaction.

The work helped the team move beyond flow length as the primary explanation for abandonment and prioritize the guidance users needed to complete their application and account setup with confidence.

Before defining the product, I needed to understand how risk managers actually reviewed contracts and where they spent their time. Working with Enbridge’s risk managers and subject matter experts, we mapped the existing contract review process to understand how people assessed risk, verified findings, and decided when further review was needed.

That work surfaced two findings that shaped both the experience and the scope of the MVP:

Risk managers needed to respond consistently and accurately across complex policies and business relationships.

Teams worked across different portfolios and contract types, but shared a central need: apply Enbridge’s risk policies consistently and accurately when responding to contracts. Those policies were detailed, and their application depended on context. A company’s financial standing and Enbridge’s previous experience with it could influence how much flexibility reviewers allowed on particular terms.

The product needed to help reviewers identify what required attention and understand the relevant policy and relationship context, so their responses were consistent with Enbridge’s risk appetite while accounting for legitimate differences between companies.

The scope could easily expand beyond contract review.

Stakeholders also wanted assignment, reassignment, and visibility into individual workloads. These needs were valid, but would have expanded the product into workflow management. Given the delivery window and the complexity of contract review itself, I advocated for an MVP focused on helping people review contracts well. That gave us a clear basis for deciding what belonged in the first release.

By the end of discovery, we had aligned on the customer journey, the core pain points, and a focused product scope that became the foundation for the platform.

With the scope focused on contract review, the next question was how to make the experience faster while preserving confidence in the result.

Discovery showed that risk managers weren’t giving every clause the same level of attention. They were triaging contracts: identifying issues that could prevent approval, assessing their severity, and deciding where closer review was needed.

That gave us a clear question to design around:

“Can I approve this, or do I need to investigate further?”

I designed the contract detail experience around that decision. Overall compliance, critical annotations, coverage requirements, and the details behind each finding were surfaced so users could quickly understand where their attention was needed.

My initial direction allowed reviewers to inspect annotations within the product. Engineering effort and vendor costs made that impractical for the first release, so product and engineering chose a downloadable Word document for detailed review. I adapted the experience to make findings and next steps clear before users moved into the document.

AI could support the initial review, but risk managers still needed to understand and verify its conclusions. At Enbridge’s risk manager’s request, we required users to acknowledge critical annotations before proceeding to the processed document. I explored whether prominent findings could serve the same purpose with fewer steps, but Enbridge’s risk manager required an explicit acknowledgment before reviewers could proceed.

In usability testing with enterprise pilot partners, the acknowledgment feature received positive feedback. It provided a deliberate checkpoint for critical findings while leaving the final decision with the reviewer.

To serve customers beyond Enbridge, the product needed to accommodate different risk policies and operating needs. I designed configurable clause rules and permissions so organizations could adapt the experience to their requirements.

Onboarding presented another challenge: customers needed to provide historical contracts to support the model, and gathering those documents required effort. The team worked to reduce the volume needed while preserving enough variety to cover relevant use cases. Those requirements shaped the onboarding experience and how we explained what customers needed to submit.

I also designed dashboards to help teams anticipate review effort across contracts, using findings to determine which companies’ contracts would need more attention and surfacing critical flags that their contracts presented in the past. These capabilities supported the wider review experience while keeping assignment and workload management outside the MVP.

Together, these capabilities helped risk managers identify the findings that needed closer review, and respond consistently and accurately. Historical findings also helped teams anticipate which companies’ contracts might require more attention.

Bringing ACRE to market also meant establishing how the venture would operate and how design would continue after our engagement. Within Enbridge’s larger organization, I helped shape the venture’s governance and design culture, established a reusable design system, and hired a full-time designer to take ownership of its continued development. I also supported implementation and contributed to sales and go-to-market materials as the team prepared for launch.

In four months, we took ACRE from proof of concept to a venture ready for market, with enterprise pilot customers signed, a team and operating structure in place, and a clear process for turning customer feedback into ongoing product improvements.