welcome to my court
Josephine KimProduct designer · Cornell Information Science · graduating Dec 2026
A future-state exploration of a scalable marketplace layer beyond a Banking Hub-centered experience.
This is a future-state design exploration, not a launched redesign. The confidential interface work is not shown; everything below is described through sanitized diagrams and written process.
Opens the current public fintech experience, not the confidential future-state redesign.
The question: could AppMarket's fintech experience handle more than one Banking Hub purchase path?
AppMarket is Fiserv’s marketplace for financial-technology products, services, and integrations. During my UX Design internship I explored how its fintech experience could evolve as the catalog grows to include more platforms, products, plans, add-ons, and purchasing paths.
Banking Hub remained the most mature platform experience, so the design question was not “how do we redesign one flow” but how AppMarket could support discovery, evaluation, configuration, pricing visibility, and onboarding preparation across a broader ecosystem.
The work resulted in a future-state direction covering marketplace information architecture, product-family organization, plan comparison, guided configuration, dependency and ownership states, persistent selection visibility, checkout, agreement signing, and dashboard ownership views, delivered as a fully working interactive Figma prototype with three complete customer scenarios.
Public-facing product screenshots are shown for research and commentary. All trademarks and product imagery belong to their respective owners.
Everything was organized around Banking Hub, and the catalog was outgrowing that.
Today, discovery happens inside a Banking Hub-centered context: clients arrive already connected to one platform and browse products that connect back to it. That structure works for the current ecosystem, but it behaves less like a marketplace and more like a platform extension catalog. As additional platforms, product families, and plan-based offerings enter the catalog, there is no higher-level structure for them to live in.
The offerings themselves are also interdependent. Plans, products, services, integration keys, and add-ons rarely stand alone, they are included, required, optional, or tied to a platform. Pricing compounds that complexity: base plans, included features, optional additions, recurring costs, and service costs all change the total. Shown too late, pricing feels like a surprise. Shown all at once, it overwhelms.
How might AppMarket evolve from Banking Hub-centered discovery into a scalable marketplace that supports comparison, configuration, pricing visibility, and onboarding preparation?
Framing question for the project
The brief was genuinely ambiguous. It could have become a product-detail redesign, a plan-comparison feature, a pricing model, a checkout flow, or an IA project. Defining which problem was worth solving became a real part of the work.
I was a UX Design Intern on an established team, with a lot of design reviews every week.
I worked most closely with my design mentor, who had been AppMarket’s only designer before I joined. I reported to Klaus, my manager and the Head of Design. I collaborated with product managers throughout, and other designers, researchers, and cross-functional stakeholders reviewed the work and gave feedback during the project.
The work was shaped by a recurring review cadence rather than by solo production. I had daily design reviews with my mentor, design reviews with Klaus twice each week, and weekly design presentations, critique sessions, and feedback discussions with my product manager and my mentor. I used those recurring reviews to test assumptions, compare design directions, refine the information architecture, improve hierarchy, clarify pricing and dependencies, and strengthen the prototype.
At the end of the internship I presented the completed multi-scenario prototype to the full product team and separately to the UX team. That final presentation walked through the future-state structure, the key design decisions, the three prototype scenarios, the scalability direction, and the remaining future considerations.
I owned the exploration presented here, including the IA proposals, configuration models, pricing-visibility patterns, and the interactive prototype, but the direction was shaped collaboratively. I was not the sole designer on AppMarket.
I started with individual screens and ended up designing the whole structure, plus a working interactive prototype.
I studied the current AppMarket experience, the Banking Hub relationship, the fintech catalog, existing product materials, and comparable marketplace and configuration patterns inside and outside financial services.
Early concepts and flows in Figma and FigJam: product cards, plan comparison layouts, configuration steps, and a first pass at how a user would move from browsing into selection.
Daily and weekly reviews kept surfacing the same structural questions: what a product belongs to, what it depends on, what a plan includes. Individual screens could not answer them, so the work moved up a level into information architecture.
I used Figma Make as an AI-assisted rapid-prototyping and vibe-coding tool to translate selected low-fidelity ideas into more interactive concepts quickly, so structural ideas could be evaluated as an experience rather than as static frames.
I brought those concepts back into Figma and manually edited, reorganized, expanded, connected, and refined them. I improved hierarchy, navigation, pricing visibility, configuration behavior, dependencies, cross-selling, ownership states, checkout continuity, and dashboard flows, then aligned the refined work more closely with the design system.
Daily mentor reviews, twice-weekly reviews with Klaus, and weekly critique with my product manager drove several rounds of restructuring. The internship ended with final presentations of the working prototype to the full product team and to the UX team.
What I learned came from auditing the current product, looking at competitors, and talking a lot with the people who know AppMarket best.
Users were not only asking what they could buy. They were asking what a product depends on, whether it is tied to Banking Hub, whether it is already included, and what happens after they select it.
Pricing is a comprehension problem before it is a display problem. Totals only make sense when the base plan, inclusions, and optional additions are visible in relation to each other.
Browsing and configuring are two different modes. Forcing one structure onto both either slows down exploration or leaves configuration unguided.
Scalability was the real constraint. Any structure that solved today's Banking Hub catalog but could not absorb new platforms would need to be rebuilt again.
The biggest call I made was to stop designing screens and work on the layer they'd live in.
Instead of treating AppMarket as a Banking Hub-adjacent catalog, the future-state direction introduces a marketplace layer above the platforms. Banking Hub keeps its depth and importance, but it becomes one platform inside a structure that can absorb others without reorganizing the whole experience.
Structure holds. Banking Hub is the context.
Catalog duplicates. Products live in two places.
Navigation and ownership logic break down.
A tree with AppMarket at the root, Banking Hub as the organizing context, and products and services nested beneath it.
A tree with a marketplace layer above platforms, product families, plans, configuration, and onboarding preparation.
This reframing changed what the rest of the project could do. Product relationships, ownership states, and cross-sell opportunities became properties of the architecture rather than one-off treatments inside individual screens.
Three decisions shaped everything: how fast configuration moves, how pricing stays visible, and how dependencies get explained.
Progressive configuration kept exploration and decision-making in one continuous space, but it only works if the user can always see what they have chosen and what it costs. That led to a persistent selections summary holding the plan, selected products and services, dependencies, and a running cost breakdown.
Pricing visibility was designed as a progression rather than a single reveal: indicative pricing during discovery, structured comparison at the plan level, and itemized recurring and service costs during configuration. Dependencies use the same logic: required, included, and optional items are labeled where a decision is being made, not buried in detail pages.
Cross-selling was treated as a consequence of clear relationships. When the structure explains what pairs with what, relevant additions can be surfaced without turning the flow into a sales pitch.
Feedback from my mentor, PMs, designers, and researchers changed the direction more than once.
| Feedback theme | What changed | Why it mattered |
|---|---|---|
| The flow felt too linear for users still comparing options | Moved from a stepper to progressive configuration with comparison available throughout. | Fintech buyers evaluate and configure at the same time rather than in sequence. |
| Pricing appeared too late to inform decisions | Introduced staged pricing visibility and a persistent, itemized cost summary. | Total cost is the deciding factor, so it had to be legible while choices were being made. |
| Product and platform dependencies were unclear | Added explicit required, included, and optional states tied to platform relationships. | Users needed to know what a selection obligates before committing to it. |
| The structure had to survive future platforms | Reorganized the IA around a marketplace layer with platforms and product families beneath it. | A Banking Hub-only structure would need rebuilding as the catalog grew. |
| Concepts drifted from the design system | Rebuilt refined screens with existing components, spacing, and type styles. | The proposal had to look and behave like a real product, not a one-off exploration. |
The flow felt too linear for users still comparing options
Moved from a stepper to progressive configuration with comparison available throughout.
Fintech buyers evaluate and configure at the same time rather than in sequence.
Pricing appeared too late to inform decisions
Introduced staged pricing visibility and a persistent, itemized cost summary.
Total cost is the deciding factor, so it had to be legible while choices were being made.
Product and platform dependencies were unclear
Added explicit required, included, and optional states tied to platform relationships.
Users needed to know what a selection obligates before committing to it.
The structure had to survive future platforms
Reorganized the IA around a marketplace layer with platforms and product families beneath it.
A Banking Hub-only structure would need rebuilding as the catalog grew.
Concepts drifted from the design system
Rebuilt refined screens with existing components, spacing, and type styles.
The proposal had to look and behave like a real product, not a one-off exploration.
The hardest challenge was scope. With no single obvious answer, I had to define the problem, defend a structural direction, and repeatedly revise it as I learned more about product dependencies and platform constraints.
By the end I had a fully working Figma prototype with three connected customer scenarios.
The final deliverable was a fully working, interactive Figma prototype covering three complete customer scenarios end to end. Each scenario runs from entry through configuration, cart, checkout, billing information, agreement signing, order placement, and arrival on the dashboard. Together they demonstrate how AppMarket could support a customer from a first Banking Hub purchase, through returning-customer expansion, and into broader multi-platform growth.
A new fintech customer discovers Banking Hub, evaluates plans, configures the purchase, and completes checkout.
An existing customer returns, reviews what they already own, and expands their Banking Hub relationship.
A Banking Hub owner expands beyond one platform, encountering contextual cross-selling along the way.
The full journey: landing in the marketplace, checking out, signing the agreement, and managing it all from the dashboard.
Platform-agnostic entry point
Organized above individual platforms
Inclusions and indicative pricing side by side
Dependencies surfaced in context
Options revealed as they become relevant
Persistent summary panel
Itemized recurring and service costs
Billing information captured in the flow
Agreement review before commitment
Order confirmation and next steps
Ownership states and product management
Banking Hub onboarding preparation, with additional platforms as future work
The exploration concluded with a documented information architecture, a progressive configuration model, a pricing-visibility approach, dependency and ownership patterns, a continuous checkout and agreement path, dashboard ownership views, and design-system-aligned concepts handed to the AppMarket team for continued evaluation.
This work was not launched. It is a future-state direction, and no performance metrics or shipped outcomes are claimed.
The main happy paths were fully prototyped. Four things were still open when my internship ended.
This project taught me how to design through ambiguity. There was no defined brief, so the first real contribution was moving from individual screens to system-level information architecture and taking a position on what problem was worth solving.
Balancing user clarity against product strategy was the constant tension. I learned how much pricing, dependencies, ownership states, and platform relationships shape an experience, and how quickly a structure breaks when those relationships are not made explicit.
Figma Make accelerated my early exploration, but the work that mattered was manually transforming generated concepts into a cohesive, connected Figma prototype. Daily reviews with my mentor, twice-weekly reviews with Klaus, and weekly critique with my product manager taught me to defend a direction, absorb feedback quickly, and revise in public. Collaborating with my mentor, Klaus, product managers, designers, researchers, and other stakeholders shaped every version of the direction.
Most of all, presenting the final prototype to both the full product team and the UX team showed me how a working prototype can communicate a future-state product strategy far more convincingly than a deck of static screens.