Jun 23

The Bet: Build a Tool Instead of Reading 200 Tickets by Hand

By Erik Taylor AI, Claude, Claude Code, Journey Mapping, Product Owner, Uncategorized, UX Research, Vibe Coding

The Problem

A feature faced negative feedback, but diagnosing root causes meant manually synthesizing help docs, demo transcripts, and scattered customer complaints. I could have spent weeks reading through all of it by hand — instead I made the call to vibe-code a tool that automatically generates persona-based journey maps from help center content, then integrates Zendesk and Slack to map complaints directly to journey steps. The bet: if the tool was wrong, I’d lose a week building something useless. If it worked, I’d turn months of manual audit into days.

Why It Mattered

The feedback was clear but the root causes were opaque. You could read a support ticket saying “confusing,” but which specific steps were confusing? A demo transcript mentioned complexity, but where did users get lost? Without a way to systematically map complaints to journey stages, any fix was guesswork.

Worse: manually building journey maps from scattered docs and videos would take weeks. We needed to respond to negative feedback fast — shipping improvements, not studies.

My Role

I owned the full build solo: designed the tool, vibe-coded the generator, integrated it with Zendesk and Slack, ran the analysis, and authored the handoff report. My goal was to automate the synthesis problem — turn scattered docs and demos into actionable journey maps, then wire them to live customer data so friction wasn’t abstract, it was pinned to specific steps.

The Key Insights

The problem wasn’t just scattered feedback. It was that no one had a system to connect complaints to specific steps. Manually reading docs, watching videos, and reading tickets meant months of work. But those same sources contained everything needed to generate journey maps automatically — and once you had those maps, you could overlay customer complaints and surface exactly where the friction lived.So I built a tool that auto-generates journey maps from existing content, then integrates with live customer data.

Problem Statement:

“A feature faced heavy negative feedback, but diagnosing root causes meant manually synthesizing help docs, demo transcripts, support tickets, and Slack escalations — too much surface area to audit systematically. Friction evidence was scattered across formats and platforms with no way to connect complaints to specific steps in the user journey.”

Design Decisions

1. Auto-generate from existing content, not from scratch

What I did: Built the generator to ingest help center docs and demo video transcripts, automatically extracting personas and journey flows. No manual mapping; let the content speak.
Why it mattered: We already had authoritative docs and demos. Reusing them meant fast turnaround and high fidelity — the journey map was built from what the company actually shipped, not my interpretation.
Tradeoff: Generator quality depends on source content quality. Garbage docs = garbage maps. But the docs were good, so this was a win.

2. Export in multiple formats for different audiences

What I did: Journey maps rendered as interactive HTML (editable in browser), but also exportable as PNG (for Slack, quick sharing) and PDF (for formal reports). Same data, different surfaces.
Why it mattered: Engineers want to click and edit (HTML). PMs want to share in Slack quickly (PNG). Leadership wants a formal artifact (PDF). One tool, multiple use cases.
Tradeoff: Export logic overhead — repaid by adoption. A tool no one uses because the output format is wrong is worthless.

3. Integrate Zendesk and Slack to overlay live customer data

What I did: The tool pulls support tickets from Zendesk and escalations from Slack, then maps them to specific journey steps. Friction isn’t abstract — it’s pinned to where it actually occurs in the flow.
Why it mattered: A journey map is theoretical until you validate it against real complaints. Integration meant the tool surfaced the highest-signal friction automatically.
Tradeoff: Integration complexity — but the payoff was precision. A complaint about “configuration step 3” could now be mapped directly to the exact UI that caused it.

4. Separate writing-fixable friction from engineering blockers upfront

What I did: The tool classifies each friction point by ownership: writing can fix (terminology, clarity, helper text) vs. engineering-only (routing, validation, state logic). Two lists, two different action plans.
Why it mattered: Prevents wasted effort. A writing pass can’t fix a broken API. An engineering sprint won’t clarify confusing copy. Separating them means both teams ship faster.
Tradeoff: Requires judgment calls about what’s fixable. But making those calls in the tool meant the report was already filtered by ownership, not just by severity.
What I killed: I considered building a confidence score per friction point, but cut it. A number that looked precise but wasn’t backed by real measurement would have been worse than no number — better to flag ambiguity honestly than fake certainty.

The Solution: Journey-Map Generator + Integrated Complaint Surfacing

The tool moved through three phases sequentially:

1. Generator Prototype (Week 1–2)

Built a simple version that ingested placeholder docs and video transcripts, auto-generating personas and journey flows in HTML. Proved the extraction and rendering logic worked before touching real content.

2. Live Generator with Export Options (Week 2–5)

Integrated real help center docs and demo video transcripts. Added export functionality: interactive HTML (browser-editable), PNG (quick sharing), PDF (formal reports). Single source, multiple outputs.

3. Zendesk + Slack Integration (Week 5–8)

Wired the tool to pull support tickets from Zendesk and escalations from Slack. The generator now maps each complaint to the specific journey step where friction occurs. Result: every customer complaint is pinned to a step, automatically classified by owner (writing vs. engineering), and ready for action.

Proof of concept: A customer journey map generated from help docs and customer feedback, showing how scattered friction data (support tickets, user confusion, product failures) gets systematically pinned to specific workflow steps. Orange friction boxes surface problems at each stage with priority, effort, and recommended fixes—demonstrating the tool’s ability to turn fragmentary complaints into actionable, scoped work for both writing and engineering teams.

Outcome

Within the eight-week window, the work went from validated prototype to shipped tool to engineering handoff.

Writing-Side Fixes: Complete

Across all four admin sections:

Jargon removed: confusing product terminology replaced with admin-centered language (6 terms total)
Toggle copy converted to declarative statements with both ON/OFF states explained
Helper text and progressive disclosure added for error prevention and conditional relevance
Visual progress indicator and step descriptions built with state clarity

Engineering-Owned Issues: Scoped

As of the final report, the following are explicitly owner-assigned and tracked separately:

Routing logic broken (notifications never reach designated recipients, multi-stage chains skip levels) — Owner: Engineering
Silent auto-submit when no valid recipient exists — Owner: Engineering
Irreversible state transitions (misclick requires full workflow reset) — Owner: Product + Engineering
Multi-recipient / any-of-group support not shipped — Owner: Product
Required-field validation not enforced at submit time — Owner: Engineering

Usability validation and baseline metrics: Defined in the report but not yet run. The report explicitly calls for moderated usability sessions and a post-launch support-ticket baseline to measure whether configuration-related inquiries drop.

A journey map table with persona swimlanes (Backend Admins and End Users) across the rows and six journey stages (Prerequisites, Setup, Configure, Deploy, Monitor, Complete) across columns. Red-bordered cells indicate friction points where customers complained about unclear workflows and missing context. Source tags show whether issues came from UX audits, Zendesk support tickets, or Slack escalations. Empty cells marked with dashes show where personas don't have actions in that stage.

The journey-map generator in action: A fully populated journey map showing two personas (Backend Administrator, End User) across six workflow stages (Prerequisites, Configure, Assign, Submit, Review, Complete). Orange friction-point boxes surface problems at step-level precision—each with a description, priority tag (UXA = UX audit, ZD = Zendesk ticket, Slack = internal signal), effort estimate, and green-highlighted suggested fix. Multiple tabs at the top show different workflow variants (Flow — Setup, Flow — Review and approval, Creating an approver role). The map is fully editable, with buttons to add persona rows, stage columns, step items, and friction points. Print/Export PDF and Save as HTML buttons enable sharing with engineering and product teams.

Reflections

What I’d validate next

Whether owner-tagging actually changed engineering’s prioritization — did scoped issues move faster than unscoped ones used to? This is the real test of whether the taxonomy added judgment or just organization.

What risk remained

A few findings sat in genuine ambiguity between a writing fix and an infrastructure issue. I flagged the ambiguity rather than resolving it — honest but leaves a gap that requires stakeholder conversation to close.

What I’d improve with more time

Build the usability-testing and baseline-metrics step into the tool itself, so the loop from hypothesis to measured outcome doesn’t depend on a separate, currently-unscheduled effort. The report is only as good as the measurement plan that follows it.

May 02

Love0

The Pantheon Project: Original Graphic Novel

By Erik Taylor Uncategorized

The Pantheon Project: Complete Volume collects the full comic book mini-series about four teenagers who must face an amazing and dangerous reality when they are mysteriously granted the super powers they made up as children.

Writer / Co-Creator: Erik Taylor
Artist / Co-Creator: Leila Del Duca
Co-Creator: Kevin Caron
Letters, Graphic Designer: Rus Wooton
Colors: Kit Seaton
Colors: Lucas Schneider

Pages: 108
Rated: T+
ISBN-10: 0692431020
ISBN-13: 978-0692431023

Gallery

Individual Comic Covers

Characters

The Trade Paperback

Pinups & Artwork

Dec 06

Love0

WFG Home Sandbox

By Erik Taylor Uncategorized

Solution / Overview

The solution centered on reimagining the WFG agent portal to create a tailored, impactful digital experience that empowered users to navigate their workflows more efficiently. By integrating user-centered design principles, the project addressed key pain points and offered a solution that was intuitive, personalized, and productivity-focused.

Key Features of the Solution:

Interactive Dashboard: A redesigned homepage with a focus on accessibility, task prioritization, and role-based customization.
Personalized Content: Sections that adapt to the user’s role—licensed agents gained quick access to sales tools, while senior agents could efficiently oversee team metrics.
Streamlined Navigation: Improved layouts and tool placements made essential resources easy to find, reducing time spent searching and increasing productivity.
Customized Design System: A unique design system tailored to WFG’s branding and functionality requirements ensured consistency and usability across the platform.

This comprehensive redesign reflected the unique needs of WFG’s agents while fostering productivity, user satisfaction, and engagement. By listening to users and iterating on feedback, the solution transformed frustration into empowerment, helping agents achieve their goals with ease and confidence.

Collaborating on a Research-Driven Approach

While the project’s direction was set before I joined, our team identified opportunities to conduct key research, including user interviews and usability tests, to refine the design. Working together, we ensured the final solution aligned with user needs, demonstrating my ability to contribute to impactful, user-centered design in a collaborative environment.

Based on insights gathered during research and testing, the following metrics were established as key indicators of the redesign’s potential success. These targets represent the outcomes expected to address the challenges identified during the project:

Task Completion Rate:
- Aiming for a 95% task completion rate to ensure users can easily navigate the portal and complete key tasks with minimal friction.
User Engagement:
- Setting a goal for a 20% increase in weekly logins, reflecting improved usability and user motivation to interact with the portal regularly.
User Satisfaction:
- Targeting a 75% satisfaction rate, indicating a significant positive response to the tailored, intuitive design.
Net Promoter Score (NPS):
- Aspiring to achieve an NPS of 40+, signifying users’ likelihood to recommend the portal to colleagues due to its effectiveness and personalization.

These metrics were not measured yet but were defined as aspirational goals, informed by user research, competitive analysis, and usability testing. They serve as benchmarks for the ongoing project and guide the iterative improvements to ensure the final solution delivers maximum value to users.

Problem

The WFG agent portal was unintuitive and inefficient, with essential tools hard to find and no personalization, leading to frustration, reduced productivity, and low engagement.

3 Key Decisions

Conduct In-Depth Research: Focused on user interviews and usability tests to identify pain points.
Develop a Tailored Design System: Created a consistent, scalable system aligned with WFG’s needs.
Prioritize Personalization: Designed role-based dashboards for better task prioritization and ease of access.

Process

Research: Gathered insights from user interviews, surveys, and usability tests.
Prototyping: Created and tested wireframes and high-fidelity prototypes.
Iteration: Refined designs based on feedback to improve usability and functionality.
Customization: Built a unique design system to ensure consistency and scalability.

Lessons from the WFG Agent Portal Redesign

Redesigning the WFG agent portal reinforced the power of user-centered design. Direct user engagement uncovered critical pain points, while iterative testing ensured the final product met real needs. Developing a tailored design system demonstrated how customization enhances usability and aligns with business goals.

Collaboration was key, enabling us to balance user needs with objectives and create role-specific features that boosted engagement and productivity. This project was a reminder that impactful design stems from empathy, research, and teamwork—creating experiences that truly matter.

Final Thoughts

This project highlights my commitment to user-centered design, collaboration, and delivering impactful solutions tailored to user needs. If you’re looking for a designer who thrives on turning challenges into meaningful experiences, let’s connect and explore how I can bring value to your next project.

Nov 19

Love0

Why I Didn’t Solve Adoption with More Training

By Erik Taylor IBM, Product Owner, Seller Enablement

Solution Oveview

IBM’s Cognitive Sales Advisor platform was live, but sellers weren’t using it — they saw it as one more thing competing with time they needed for closing deals. The easy fix would have been more training sessions or a mandate from leadership. I made a different call: build a centralized guidebook on WordPress that met sellers and managers where they already worked, rather than asking them to adopt a new tool on top of a tool they were already resisting.

Success Metrics

Increased platform adoption: A noticeable uptick in Cognitive Sales Advisor usage among both managers and sellers.
Executive recognition: The guidebook was praised as IBM’s most comprehensive internal resource for sellers.
Sustained engagement: Content expansion supported new initiatives and adapted to evolving user needs.

The Problem

Sellers viewed the platform as overhead, not help. Managers had incentive to push adoption but no real way to demonstrate value in the time sellers had available. The actual constraint wasn’t awareness — it was that every existing solution added cognitive load instead of removing it. Any fix that asked sellers to learn something new, in a new place, was going to fail the same way the platform itself had.

Key Decisions

User-Centered Approach

What I did: Brought sellers and managers directly into the design process instead of designing from assumptions about their workflow.
Why it mattered: Stakeholder interviews surfaced the real blockers — high cognitive load and no time for training — that wouldn’t have shown up in a requirements doc.
Tradeoff: Slower start than building from existing specs, but it meant the guidebook solved the problem sellers actually had, not the one that looked obvious from outside.

Tool Familiarity

What I did: Built the guidebook on WordPress rather than a purpose-built platform.
Why it mattered: WordPress integrated cleanly with tools IBM sellers already used, so the guidebook didn’t ask anyone to learn new infrastructure.
Tradeoff: Less flexibility than a custom build, but adoption mattered more than capability — a more powerful tool nobody opened would have been worse than a simpler one people actually used.

Centralized Information

What I did: Designed one entry point with strong search and segmented content (general users, enterprise sellers, other roles), instead of separate resources per team or product line.
Why it mattered: Sellers had no time to figure out which of several resources applied to them. One searchable hub removed that decision entirely.
Tradeoff: Centralizing meant taking on more upfront content architecture work, so the navigation and segmentation had to be right before launch — there was no easy way to course-correct structure later without disrupting a resource people had started to rely on.

Process

Research and Analysis
To understand the barriers to platform adoption, I conducted stakeholder interviews with sellers and managers. These sessions revealed key pain points: high cognitive load, limited time for training, and a lack of clear, accessible resources. I also analyzed existing workflows and tools to identify opportunities for integration.
Content Strategy
Based on the research, I developed a content strategy that prioritized user needs. This included:
- Product Pages: Detailed overviews of features, benefits, and seller testimonials to quickly convey value.
- Knowledge Base: Segmented articles tailored to general users, enterprise sellers, and other specific roles.
- Video Library: Organized recordings of training sessions and meetings, searchable by user goals.
Prototyping and Testing
Using wireframes and interactive prototypes, I tested the guidebook’s usability with key user groups. Feedback from these sessions informed improvements in navigation, content layout, and search functionality.
Development and Launch
I collaborated with developers to build the guidebook on WordPress, ensuring seamless integration with existing IBM tools. After thorough QA testing, the guidebook was launched as a centralized resource for sellers and managers.
Iterative Updates
Post-launch, I continued to gather feedback and expand the guidebook’s content to support new initiatives and adapt to evolving user needs. This iterative process ensured the guidebook remained relevant and effective over time.

Learnings

The Importance of User Involvement
Engaging users early in the design process provided invaluable insights into their pain points and needs. By including sellers and managers in interviews and testing sessions, we were able to design a solution that genuinely resonated with them, driving adoption and satisfaction.
Cognitive Load Matters
Simplifying workflows and reducing the cognitive burden were critical to the guidebook’s success. Sellers and managers were more willing to adopt the platform when it felt intuitive and didn’t interrupt their primary focus: closing deals.
Iterative Design is Key
The iterative approach—building prototypes, gathering feedback, and making improvements—ensured the guidebook addressed real-world challenges. Continuous feedback loops enabled us to fine-tune features and keep the resource relevant post-launch.
Effective Content Strategy Drives Engagement
Providing tailored content, organized for different user roles and needs, significantly improved usability and engagement. A one-size-fits-all approach would not have worked in such a diverse user environment.
Collaboration Enhances Outcomes
Working closely with cross-functional teams, including developers and stakeholders, allowed for seamless implementation and alignment with business objectives. This collaboration ensured the guidebook met both user and organizational needs.

These learnings have strengthened my approach to user-centered design and reinforced my commitment to creating solutions that balance user needs with business goals.

Final Thoughts and Impact

The core decision underneath this project was resisting the instinct to add more training or more push from managers, and instead removing friction from the tool itself. That meant treating cognitive load as the real constraint, not adoption numbers. The guidebook worked because it asked less of sellers, not because it offered more content — and that’s the tradeoff I’d point to first if someone asked what actually moved the needle here.

DSGB Gallery

Firefox_Screenshot_2020-06-23T16-02-52.283Z 2

Firefox_Screenshot_2020-06-23T16-49-32.341Z

Firefox_Screenshot_2020-06-23T16-27-26.707Z

Firefox_Screenshot_2020-06-23T16-45-44.044Z

Firefox_Screenshot_2020-06-23T17-08-15.006Z

Firefox_Screenshot_2020-06-23T16-35-54.998Z

Firefox_Screenshot_2020-06-23T17-04-30.527Z

Firefox_Screenshot_2020-06-23T17-05-56.398Z

Firefox_Screenshot_2020-06-23T17-10-04.783Z

Firefox_Screenshot_2020-06-23T16-52-42.256Z

Firefox_Screenshot_2020-06-23T16-33-45.588Z

Nov 19

Love0

Structural Change vs. Familiarity: A Navigation Tradeoff

By Erik Taylor Prototyping, Transamerica, User Testing, UX Research

Solution Oveview

WFG agents were getting lost in their own portal — too many links, too many subcategories, no clear path to the tools they used every day. The obvious fix was trimming the menu. The harder call was deciding which version of “simpler” agents would actually trust, since the research surfaced two genuinely different concepts agents disagreed about.

Success Metrics

Although the project is still in progress and full metrics have not yet been realized, success is being guided by research-backed goals. From the outset, the team set measurable targets based on user needs and pain points identified through extensive research. These goals include:

A notable increase in task completion rates as a result of simplifying the navigation system.
Higher agent engagement driven by the reduced complexity and improved access to frequently-used tools.
Improved agent satisfaction, particularly regarding the reduction in clicks needed to access key resources.
Optimized mobile usage, with an emphasis on enhancing the experience for agents who rely on mobile devices for their daily tasks.

The Problem

Licensed WFG agents faced significant challenges with the existing portal’s global navigation. The navigation was cluttered, with too many links and subcategories, making it difficult for agents to quickly access the essential tools they needed. Mobile users, in particular, found the portal difficult to navigate, which hindered their productivity while on the go.

Problem Statement:

“Licensed WFG agents face difficulty accessing key tools quickly due to a cluttered and inefficient global navigation system, leading to reduced productivity and frustration, particularly on mobile devices.”

Key Decisions

Simplified Navigation

What I did: Cut links and reorganized the remaining tools by frequency of use rather than by org chart or product category.
Why it mattered: Agents weren’t asking for fewer features — they were asking for fewer steps to the ones they used constantly, like Commissions and Client Management.
Tradeoff: Frequency-based ordering meant deprioritizing some tools entirely from the main nav. That’s a bet that the agents who need those buried tools are rare enough to accept the extra click, and it’s a bet that won’t be provable until full rollout data comes in.

Mobile Optimization

What I did: Treated mobile as a primary surface, not a scaled-down version of desktop.
Why it mattered: A large share of agents do their daily work on mobile, so a navigation fix that only worked on desktop would have solved the wrong problem for a meaningful chunk of users.
Tradeoff: Designing mobile-first meant some desktop conventions (denser menus, more visible categories) had to be sacrificed even for agents working at a desk — a deliberate choice to optimize for the harder context rather than split the difference.

User-Centered Design

What I did: Tested multiple concepts with agents instead of picking one internally and validating it after the fact.
Why it mattered: The two concepts split opinion in a way that wouldn’t have shown up without direct feedback. One agent said a concept felt “more aligned to how people see the business,” while another pushed back simply because it was different from what they already knew — “people will have negative reaction to change.”
The actual decision: Between a structurally better concept that some agents resisted purely on familiarity grounds, and a more conservative option that would have under-delivered on the original problem. I went with the structural change, betting that resistance from familiarity would fade once agents adapted — which the early post-launch feedback has started to support, though it’s not yet fully validated.

Process

The project began with user research, where we conducted interviews and surveys with WFG agents to identify their pain points and gather insights on how the current navigation was impacting their workflow. Based on these insights, we set research-backed goals and proceeded with design and prototyping, developing several design concepts focused on simplifying navigation and improving mobile accessibility.

Next, we conducted usability testing with agents to evaluate the prototypes. This iterative process allowed us to refine the designs based on real-world feedback, making adjustments to enhance both desktop and mobile usability. After finalizing the design, we moved into implementation, closely monitoring user feedback to refine the system further before full rollout.

Quotes from the Research

“I feel this is friendlier. This one would be easier to teach my recruits.”

“This one is better than Concept A...better because it's more aligned to how people see the business. I just want to see how to manage / grow my business. It's more conducive to what I'm trying to do.”

"I like the other one better. People will have negative reaction to change."

Learning Valuable Insights

The clearest signal wasn’t “simplify navigation” — that part was expected. It was that a genuinely better design and a well-liked design aren’t always the same thing at first contact, and resistance to change has to be managed as part of the rollout, not treated as evidence the design was wrong. Mobile-first paid off as a hypothesis, but that’s still being confirmed against real usage data rather than proven.

Final Thoughts and Impact

This one’s still open. Full MVP testing and rollout data will tell us whether the bet on structural change over familiarity was the right one. If agent sentiment keeps trending positive as adoption grows, that’s the strongest evidence the harder call was correct — and if it doesn’t, that’s the next decision point.

Nov 18

Love0

One Dashboard or Two: The Personalization Bet

By Erik Taylor Prototyping, Transamerica, User Testing, UX Research

Solution / Overview

The WFG agent portal was the kind of tool everyone tolerated but nobody liked — cluttered, generic, and built without much regard for who was actually using it. The direction was already set before I joined, but the open question on the table was personalization: build one dashboard everyone uses the same way, or build role-based views that diverge for licensed agents versus senior agents managing teams. I argued for the latter, which meant more design and system complexity in exchange for relevance per role.

The previous design (left) was cluttered and made it difficult for advisors to access their most-used tools and information efficiently. The redesigned version (right) streamlines the experience, providing critical resources with minimal friction.

Key Features of the Solution:

Interactive Dashboard: A redesigned homepage with a focus on accessibility, task prioritization, and role-based customization.
Personalized Content: Sections that adapt to the user’s role—licensed agents gained quick access to sales tools, while senior agents could efficiently oversee team metrics.
Streamlined Navigation: Improved layouts and tool placements made essential resources easy to find, reducing time spent searching and increasing productivity.
Customized Design System: A unique design system tailored to WFG’s branding and functionality requirements ensured consistency and usability across the platform.

Collaborating on a Research-Driven Approach

Task Completion Rate: Aiming for a 95% task completion rate to ensure users can easily navigate the portal and complete key tasks with minimal friction.
User Engagement: Setting a goal for a 20% increase in weekly logins, reflecting improved usability and user motivation to interact with the portal regularly.
User Satisfaction: Targeting a 75% satisfaction rate, indicating a significant positive response to the tailored, intuitive design.
Net Promoter Score (NPS): Aspiring to achieve an NPS of 40+, signifying users’ likelihood to recommend the portal to colleagues due to its effectiveness and personalization.

Problem

The WFG agent portal was unintuitive and inefficient, with essential tools hard to find and no personalization, leading to frustration, reduced productivity, and low engagement.

3 Key Decisions

1. What I did: Joined a project whose direction was already set, and pushed to add user interviews and usability testing rather than design against the existing brief alone.
2. Why it mattered: The original scope didn’t include direct user input — adding it meant the redesign was grounded in actual agent pain points instead of assumptions carried over from the prior portal.
3. Tradeoff: Adding research after direction was set cost time the team didn’t originally budget for, but skipping it risked shipping a redesign that solved the wrong friction.
Develop a Tailored Design System: Created a consistent, scalable system aligned with WFG’s needs.
1. What I did: Built a custom design system for WFG instead of reusing a generic or off-the-shelf component set.
2. Why it mattered: WFG’s branding and functional requirements didn’t map cleanly onto existing patterns, so a tailored system kept the experience consistent without forcing the design into a mismatched mold.
3. Tradeoff: A custom system takes longer to build and maintain than adopting an existing one — that cost was accepted because consistency across a high-friction tool mattered more than speed to ship.
Prioritize Personalization: Designed role-based dashboards for better task prioritization and ease of access.
1. What I did: Designed role-based dashboards so licensed agents and senior agents saw different priority content, rather than one dashboard for everyone.
2. Why it mattered: Licensed agents needed fast access to sales tools; senior agents needed team-metric visibility. A single shared view would have buried one group’s priorities to surface the other’s.
3. Tradeoff: Role-based design multiplies the surface area you have to build, test, and maintain. It’s a bet that relevance per role outweighs the simplicity of one unified experience — a bet that hasn’t been validated yet, since engagement and satisfaction metrics are aspirational targets, not measured results.

Process

Research: Gathered insights from user interviews, surveys, and usability tests.
Prototyping: Created and tested wireframes and high-fidelity prototypes.
Iteration: Refined designs based on feedback to improve usability and functionality.
Customization: Built an ad-hoc, unique design system to ensure consistency and scalability.

Learnings

The real tension on this project wasn’t whether to do user research — that part was straightforward once added. It was whether personalization was worth the system complexity it demanded. Committing to role-based dashboards before having usage data to back it up was the riskier call, and it’s still an open question whether it pays off against a simpler shared-view alternative.

Final Thoughts

The targets — task completion, login frequency, NPS — are goals the team set going in, not results yet realized. I’d treat that honestly here: the personalization bet is the thing worth watching once real usage data comes in, since that’s the call most likely to be wrong in either direction.