American Express card applications suite

Annotated wireframe for an applicant whose entered information failed verification. The form sits at left; a yellow notes column at right lists seven numbered behaviors and eight field verification groups with their justification rules. logos redacted.
A
project
Client
American Express
Industry
Expertise utilized
Lead Interaction Designer
A dense one-page sign-up became a three-step flow, standardized across nearly every American Express consumer card.
For American Express, I led interaction design across nearly all online card applications — simplifying the experience to three steps and specifying the conditional field logic behind it.
One template, 17 specification drawings, three workstreams — shipped to production
100
%
allocation
9
weeks
From
04/2011
To
06/2011
Webflow Template - Designed by Azwedo.com and Wedoflow.com
Shipped
My Role and Partners

Engaged through my studio, Tangible Places, LLC, under contract to the creative team at Digitas (New York), Digitas held the agency-of-record relationship with American Express; I was the interaction design lead brought in against it, and the sole IxD resource across all three application workstreams. Digitas's Art Director and UI designer owned visual design and production comps, working from my specification. American Express owner representatives set required fields, disclosures, and eligibility rules and held approval; an off-shore development team built. 100% allocation across 26 weeks.

Context & Constraints

  • Scale: three parallel workstreams — Member Applications, Partner Applications, and Web Collector — specified against one shared template
  • Legacy baseline: existing application designs from a prior Digitas team, to be extended and reconciled with new card input requirements rather than be replaced
  • Regulated content: required fields, disclosures, and eligibility language set by the client, not open to design
  • Complexity: partner cards varied eligibility and disclosure rules, so fields had to appear, validate, and hide conditionally
  • Distributed build: specification had to survive handoff to an off-shore team without a co-located design review

Approach

  • Conceptualized a single application template from client-specified field requirements and the prior team's designs
  • Sequenced the primary application into three steps, with the same skeleton reused across every card
  • Specified conditional field behavior — verification groups, auto-population, variable panel heights — directly on the wireframe
  • Reconciled partner-card eligibility variations as rules against the shared template, rather than as separate layouts
My activities on this project

Impact

  • One interaction model carried three workstreams and both co-brand and supplemental card products, specified by a single designer in 26 weeks
  • One dense form reduced to a three-step flow, reused as the template across the suite
  • Conditional field rules documented in-wireframe as the single build reference for an off-shore team
  • Artifacts summary

    No items found.
  • User-flow diagram

    Design: 17 specification drawings across three workstreams — user flows for pre-approved, non-pre-approved, direct mail, and email entry paths; the primary application template; instant dialog and verification states at maximum condition; co-brand, airline partner, and supplemental card variants. Production screens for the shipped applications.

  • Case Study

    User flow for a cardmember who is not pre-approved: dual login by user ID or by card number and CID, two decision points, account selector and confirmation loops, then the application.
    No items found.

    Overview

    American Express needed its online card applications rebuilt across nearly the entire consumer line: every card carried its own eligibility rules, disclosures, and partner requirements, and each had accumulated its own form. The commercial stake is direct— an application abandoned mid-form is a customer not acquired— and the sign-up form is the only part of a card product every applicant must complete.

    I was engaged through Tangible Places under contract to Digitas's creative team as the sole interaction design resource across three concurrent workstreams: Member Applications for existing cardmembers, Partner Applications for co-branded products, and Web Collector for applicants arriving from direct mail and email campaigns. I owned the application template, the step structure, and the conditional logic, and presented that specification directly to American Express owner representatives rather than through an account layer. I did not own visual design or front-end build. Scope ran December 2010 through March 2011 at full allocation.

    Evidence of Need

    • Each card had drifted into its own form, so a returning applicant met a different experience per product— the case for one template with a short, consistent path.
    • Partner cards introduced eligibility and disclosure variations that a static layout couldn't absorb, which is what made conditional field specification a requirement rather than a refinement.
    • The off-shore build model and the compliance review both depended on unambiguous artifacts: anything left implicit in a wireframe would surface as a defect, not a question.

    Strategy

    North Star & principles.

    1. Short, scannable path to completion (3 steps).
    2. One template, many cards — variations captured via rules, not new layouts.
    3. Spec the logic — annotate when/why fields appear, validate, or hide.
    4. Tight design-build handshake — wireframes that AD/UI can lift directly.  

    Prioritization.

    • First: the primary application template and must-have field set.
    • Next: conditional/dynamic behaviors for partner cards.
    • Then: states, errors, and microcopy handoff for UI build.

    Design and Solution

    The application resolved into three steps, each a coherent disclosure of one kind of information: personal details, then employment and financial information, then review and submit. The same skeleton carried every card in the line; product differences were handled as rules against that skeleton rather than as new layouts.

    The conditional layer is where the specification did the most work, because the three workstreams shared one template but almost nothing else. Field verification groups were annotated individually, each with its own justification behavior and validation treatment. Home city and state auto-populate once an applicant enters a ZIP code; physical address appears only when a P.O. Box is present in the home address. Panels were specified as variable in height, expanding according to how many fields required verification for a given applicant and card, meaning the layout could not be drawn once and frozen, but had to be described as a set of states. Each behavior was numbered against a functional specification reference, so the off-shore team read the rule and its rationale in the same artifact.

    The template's reach is legible in the drawing set. Seven co-brand cards run on a single pre-selected model; two supplemental card products run on another; the Web Collector flows resolve pre-selected and non-pre-approved applicants into the same two-step path regardless of whether they arrived by letter or by email. Where a product genuinely differed, an airline partner's loyalty enrollment, a card art selector, a twelve-digit membership number ahead of the name fields, the difference was specified as a rule against the template rather than as a new layout. Seventeen drawings covered the set.

    Concepts
    No items found.
    Process

    The six pages below are not six screens. Each documents the same application template under a different applicant condition — a cardmember who isn't pre-approved, an applicant whose entered information failed verification, and so on — because what varied across the card line was the template's behavior, not its layout.

    Each page reads in three parts. The form state occupies the page; a numbered red marker sits on every element whose behavior isn't self-evident; and the right-hand column carries the matching notes — field verification groups and their justification behavior, ZIP-driven auto-population, and the conditions under which a panel expands or a field hides. An "About this user" strip heads that column and names the scenario the page documents, so a reviewer knows which applicant they are reading before they read a single rule. The footer carries the document number and version.

    That structure was the point. One artifact had to satisfy a client owner representative checking required fields and disclosures, and an off-shore developer building the rule — neither of whom could walk over to ask.

    No items found.

    Delivery

    Every wireframe went through joint review with client owner representatives and the off-shore development team before any application moved into visual design, checking requirements compliance and technical feasibility in the same session. That combination mattered: with the build team off-shore and the field requirements set by a regulated client, a rule that was ambiguous in the wireframe would surface weeks later as a defect rather than as a question. The contract structure sharpened this: as an outside specialist under contract to Digitas rather than a staff designer, I had no informal channel to the client or the build team, so anything ambiguous in a drawing was ambiguous permanently. Numbering each behavior against a functional specification reference gave reviewers on both sides (client, agency, and developer) a shared address for every rule.

    Step 1 — personal information.
    Step 2 — employment and financial information.
    Step 3 — review and submit.

    No items found.

    Outcomes

    The applications shipped.

    Production screens carried the three-step structure through to the live americanexpress.com experience, step indicator visible to the applicant, across partner cards including Blue Sky and JetBlue. The template held across all three workstreams: seven co-brand cards on one model, two supplemental products on another, and the direct-mail and email paths sharing a single application flow — which is what allowed one contract designer to specify the set inside 9 weeks.

    Fifteen years on, the step-and-indicator pattern these applications used is still the default for regulated online forms— the structure was durable, whatever the toolset.

    The shipped JetBlue application, step indicator visible at upper right — the three-step structure as an applicant encountered it.
    Learn more at the external product page
    Portfolio Webflow Template - Carolina - Designed by Azwedo.com and Wedoflow.com
    My activities
    Contact
    Portfolio Webflow Template - Carolina - Designed by Azwedo.com and Wedoflow.com
    Submitted! We’ll take it from here! 🪄
    Oops! Something went wrong while submitting the form.