Wells Fargo

 In Standards and Processes -, UX Design -, Web and Application Design -


Wells Fargo

Wholesale Internet Division – User Experience


User Experience Standards Project Lead

Location / Dates

San Francisco, CA (Nov 2013 – May 2015)


Role Description

  • Project lead updating 60+ UX standards by

    • updating legacy standards to meet new requirements
    • drafting new standards
    • organizing and maintaining standards in their various stages
    • obtaining multiple levels of approvals prior to publication
    • creating a maintenance process for continual updates of the standards
  • Collaborated with multiple disciplines to ensure consistency and conformance across
    • continuously changing code base
    • new visual design branding
    • accessibility conformance
    • basic application architecture
      • emphasis on financial transactions and reports
    • updated content code
  • Prototyped the standards site architecture and layout using Balsamiq
  • Created standards user cases and stories
  • Worked closely with Front-end developers to design and integrate different templates and WordPress functions.

Work Samples

***The following work, performed at Wells Fargo, does not contain proprietary information and has been approved for presentation.***

Once CEO Central started to be populated with documentation, I was asked to create a “Gallery View” so that users who weren’t as familiar with the standards would be able to find what they needed quickly.  This view is also more conducive to an exploratory/investigative style of learning. Like a magazine, frequently used/popular standards are highlighted on this front page, and it leads users to randomly read other related articles. Definitions of “Design Article”, “Pattern”, and “Component” are provided via expanded text for new users or vendors, providing common language between users.


UX Standards Introduction

The following 3 standards are examples of work that I performed at Wells Fargo.  In order to be considered complete standards needed to be written to the latest Wells code base, be approved by all teams (UX, UI, Content, Visual Design, and Accessibility) and include example images with the latest visual design specifications.

There are three types of standards that I created while at Wells: Components, Patterns, and Articles.  Components described a discrete set of code, like a button or date picker.  Patterns described how to assemble Components in a higher level flows, like Reporting or Search functions.  Articles were high level discussion pieces that described why a designer would choose one Pattern or Component over another one.  The three examples below demonstrate the variety and detail to which every standard was held.

Component: Button

Button_1(3 main button styles)

Design Standard Overview

Buttons are components used to execute actions within an application.  This action will provide visual and system feedback.

  • There are 3 buttons types: Primary, Standard, and Chromeless.
    • Standard and Chromeless may be configured with an additional usage style, Image-only.
  • All buttons must have appropriate action text or an approved icon to convey the correct functionality.
    • Button labels can be a combination of text-only, text + image, and image-only.
  • Primary buttons typically trigger a system response.
  • Buttons are left aligned, by default.
    • Alignment exceptions exist.  See Alignment Exceptions.
    • When buttons are grouped, they are horizontally arranged: (starting left) primary, standard, and chromeless.
  • Buttons are used for actions or a combination of action and navigation; [LINK] Links are used only for navigation.

Use When

  1. System requires an action trigger that is not only navigational.
    1. Example: Trigger a search or a form submission
    2. If a control simply provides navigation, it must be a link.
  2. System requires an action trigger that also navigates the user to a new location
    1. Example: Close a dialog or cancel an action


Button Type Usage

Button_1(3 main button styles)

There are 3 buttons types available: Primary, Standard, and Chromeless.  Standard and Chromeless may be configured with an additional usage style, Image-only. These options help distinguish between task types.

Primary Buttons

Button_3 (Primary Buttons)

  • The primary button is recommended for the user’s main call to action.
    • It has more visual weight than other buttons to gain the user’s attention.
  • When a task is a main action, it is recommended that a single primary button is used.
    • When there are multiple controls that have equal likelihood of selection (no primary action on screen), standard buttons should be used.
    • Multiple primary buttons may be allowed on a single screen if each of these buttons are contained within their own group or component.
    • A single action on the screen does not necessitate the use of a primary button.
      • For example: Close

Standard Buttons

Button_4(Standard Button)

  • A standard button is used to execute tasks supplemental to the main/primary screen task.
    • When there is no single primary action, standard buttons become the de facto primary call to actions on the screen.
  • Standard buttons may perform a variety of actions. For example:
    • Trigger a menu, overlay, or screen.
    • Trigger additional user actions or input.
    • Update the current view.
  • Due to limited real estate in a few components, standard buttons may have a skinny treatment.
    • Skinny Buttons are limited to:
      • List View
      • Section
      • Data Tables
    • Multiple skinny buttons can be used in a group.

Button_5(Skinny Standard Buttons)

Chromeless Buttons

Button_1(Chromeless Buttons)

  • Chromeless buttons are used for additional actions, but not the main task.
  • Chromeless buttons are not meant to be as visually prominent as the other button types.
    • These may be associated with specific fields or portions of the screen.
  • Chromeless button perform a variety of functions, such as:
    • Modification of content (e.g. Edit, Change)
    • Abandoning an action (e.g. Close, Cancel, Reset, Clear)
    • Retrieving a value from a data set (e.g. Lookup, Find)
    • Annotating content (e.g. Notes, Comments)

Image-Only Button

  • Image-Only buttons are specially stylized Standard and Chromeless buttons that does not include text.
    • Icon used must follow Iconography Standards.
  • Image-Only buttons perform a variety of functions, such as:
    • Help
    • Settings
    • Status
    • Edit
    • Close
    • Refresh
    • Expand/Collapse

Button_6(Image Viewer Print Control)

Button Labels

  • Button label is the content (text-only and text with icon) displayed on the button component.
    • By default, labels are text-only.
    • Image-only buttons do not have labels.
  • Button labels should be simple and clearly communicate function.
    • Button labels must comply with Content Standards [Link to Content CEO Landing screen] to keep consistency across applications.
  • All buttons must have an accessible name.
    • If the button has a visually displayed text label, no additional screen reader text is required.
    • If the button has no visibly displayed text label, content team will provide a visually hidden label to communicate to screen readers.
  • Button labels have character limits.
    • Button label text does not wrap, but exceptions may be made for smartphones, where space is limited.

Below are frequently used button labels.

Table 1: Frequently Used Button Labels


Example Labels Use When Note
Submit Submits form information. Primary Button
Next Proceeds to the next step in the task workflow. Primary Button
Cancel Abandons a task. Chromeless Button
Search Executes a data query based on search criteria. Primary or Standard Button
Save Saves form inputs or state. Primary or Standard Button
Update Applies changes to form inputs or state. Primary or Standard Button
Clear Clears all inputs currently displayed in the form. Chromeless Button
Reset Resets the form’s input values to the initial state. Chromeless Button
View Access information, typically in read-only mode. Chromeless Button


Button Placement

  • As a general rule, buttons are left-aligned and presented in the order (starting left): primary, standard (standard), then chromeless (chromeless).
    • For complex forms with visually separated sub-areas, the primary button that submits the form should be placed below a separator and left-aligned with the form’s primary container.
    • For single or separately grouped sets of fields, the buttons should be left-aligned to the form fields.
    • See [LINK] Form Construction for more information.

Placement Exception Cases

Placement exceptions are allowed. For example:

  • Utility controls (e.g. Print, Export)
  • List View
  • Inline actions associated with a specific form field
  • Small Screen Devices
  • Close buttons
Utility functions
  • Utility functions examples include Print, Export, etc.
    • Buttons will be right-aligned to the parent container.
List View
  • List View action buttons may be right-aligned to facilitate task flow and/or information scanning.
    • Although aligned on the right, the button order presentation (left to right: primary, standard, chromeless) still holds.
  • When a panel is opened from List View, button alignment and order is maintained in the panel.
    • This maintains visual consistency when the task view changes to the panel.

Button_8(List View Action Controls)

Inline Action Buttons
  • Inline action buttons are placed on the right of the associated element.


Button_4(Standard Button)

Placement of buttons in Small Screen Devices
  • Screen real-estate may require that a horizontal string of buttons be vertically stacked.
  • When vertically stacked, place primary button(s) first with additional buttons (Standard or Chromeless) following after.
Close Button
  • Close buttons are located in the upper right corner of a panel or window.
  • Close buttons may be image-only (“x” glyph) or text (“Close”).


Do not overuse buttons on screen

Buttons should be closely related to task flows. Consider the comprehensive overall task flow when determining which action buttons should be used.  If you have a large number of actions that can be taken on an object, consider combining some or all of them into a [Link to ] Menu Button.

Place buttons consistently

Physical proximity between buttons and their targeted/associated area can make a design more predictable. Screens with consistent layouts help users predict where to expect controls.

Use Standard Language

Designers should use discretion when evaluating whether a specific application context or product requirement warrants a non-standard usage.

Use image-only buttons appropriately

Image-only buttons must comply with [Link to VisDe Landing screen] Visual Design Standards to keep consistency across applications and ensure they have a clearly established meaning.

Is it a button, or is it a link?

Buttons are used for actions or a combination of action and navigation; links are used only for navigation. Controls that take actions but do not navigate to a new screen are strong candidates for Chromeless buttons, to ensure accessibility.

Rules of thumb to determine whether to use a button or a link:

  • Is its primary purpose to take action or solely for navigation?
  • How would I describe it over the phone to someone else who is not looking at the screen.  Would I describe it doing something or going somewhere?

Examples of links that should be implemented as chromeless buttons:

  • Opening a dialog/panel
  • Cancel a flow

Related Standards

  • Application Screen Layout
  • Links
  • Panel
  • Form Construction
  • List View
  • Radio Button Group
  • Balloon (Balloon Button)
  • User Assistance (Help Button)
  • Menu Button and Simple Menu


Pattern: Search and Results


Design Pattern Overview

Search allows users to retrieve a new or refined data set, using the “Search” button, prior to any data management (such as filter, pagination, or sorting).  Results are presented in a Data Table or List View.

Use When

  • User needs to retrieve, view and potentially take action on a specific set of items as part of a task, for example:
    • User lookup
    • Search for a check
    • Search within Help
  • There is a large volume of items in a data set such that the list is too large to present by default.



Search Criteria

  • All search criteria should be placed in a designated search area.
  • Users are provided appropriate action controls for the search criteria.
    • These controls are determined by data types and categories as needed by the application.
  • Depending on application capabilities, intra-session searches can retain past criteria.
  • Based on application needs, search criteria may have default values.
  • See Form Types for information regarding single form field standards.
  • See the User Assistance for usage of micro-text and ghost text

Search Controls

  • The “Search” control will submit the search criteria to the application.
    • The control can include or consist of an icon.
      • See Iconography for icon standards.
    • Do not include the Search icon in both the control and Text Input Field.
  • A control may be provided to reset the search criteria.
    • The control label should be “Reset” and will be presented Chromeless, in-line to the right of Search and Cancel
    • This control will stay disabled until the user makes a modification to the default form
    • This control can be set to return the form to preset values, or to return all search criteria values to an un-selected/incomplete state.


Search Results

  • Search results will be presented via a Data Table or List View.
  • Search results may appear on the same or on a separate screen as the search criteria.
    • When search results appear on a separate screen:
      • Selected search criteria should be presented
      • Users should be provided the ability to modify/edit those criteria
  • When there are a high volume of results, provide the user controls to manage the returned data set, including:
    • Pagination
    • Sorting
    • Filter
  • The order of presented results returned is dependent on application needs.
  • Additional controls (Print, Save, Export) for search results may be provided based on application need.



Single screen Flow

  • The single screen scenario can be used when the form length and information retrieval needs allow the criteria and results to be presented in a single view.
  • If no results found, messaging should be provided to direct the user to refine search parameters
    • Message should be placed within empty Data Table or List View, near the top border of the component
    • Recommended message: “No results found. Refine search and try again.”


Tabbed Search

  • A tabbed scenario should be used when the application has multiple search flows to be surfaced on a single screen.
  • Searches presented within Tabs are mutually exclusive.
  • Search criteria input on one tab, will not affect the results on another.
  • For more information, see [LINK TO] 
  • When technically feasible, it is recommended to retain states across tabs.
    • For example, if a user performs an action within a tab (searches and receives results), moves to another tab and then returns, the desired behavior is for the original tab search results to remain present.


Multiple screen flow

  • A multi-screen flow should be used when search criteria and results can not or should not fit on a single screen.
  • Results screen should include:
    • A display of the submitted criteria
    • A way to return to edit/modify the search criteria.
  • If no results found, messaging should be provided to direct the user to refine search parameters
    • Message should be placed within Message Bar on search criteria input screen
    • Recommended message: “No results found. Refine search and try again.”




Related Standards

  • Forms
  • Reporting
  • Data Table
    • Smartphone Provisional Standard
  • List View
  • User Assistance
  • Filter
  • Paginator
  • Managing Your View of Data
  • Tabs


Article: Selecting Stuff


Design Standards Overview

This article provides information regarding users’ selection of items in order to take an action or to create a set for future use.

If the selection is straight forward, the appropriate simple selection control should be used – Radio Buttons, Radio Button Group, Checkboxes, Select, Auto Complete or MultiSelect.

Choosing the Right Selection Component


Selection Options

Radio Button and Radio Button Group

  • Radio Buttons are used provide a single selection from a record set or simple form list
    • Within a Data Table or List View, Radio Buttons are used as row selection options when provided actions are exclusive in nature
  • Use Radio Buttons for a small group (usually between 2 and 5 choices) of recognizable items
  •  Use Radio Button Group for selecting a single action item within small recognizable group.
  • For more information, see Radio Button and Radio Button Group.

SS_2 (Binary Radio Button Selections)

SS_3(Radio Button Group Example)


  • Checkboxes are used to provide multiple selections from a record set or simple form list.
    • Within a Data Table or List View, checkboxes are used as row selection when provided actions are inclusive in nature
  •  Use Checkboxes for small groups (usually between 1 and 10) of recognizable items
  • Checkbox can be used for a binary selection items
    • For more information on Progressive Enablement, see Dealing with Input Data
  • For more information see Checkboxes.

SS_4(Binary Checkbox and Radio Selections)


  • Select provides a single selection from a list or menu.
  • Use Select for a medium sized group of recognizable items, between 2 and 20 items.
  • For more information, see Select.

SS_5(Select Example)


  • MultiSelect provides the ability for users to select 1 or more options from a defined list.
  • MultiSelect allows for sort and filtering of selections options
  • MultiSelect should be used for a medium sized group (between 2 and 200 items) of recognizable items
  • See MultiSelect for more information


SS_6(MultiSelect Example)


  • Auto Complete is used to allow the user to enter a string to match for selection
  • Use Auto Complete for a large group of unfamiliar, complex, or disparate items
  • See AutoComplete for more information


SS_7(Currency AutoComplete)

Complexity Considerations

Predictable Lists and User/customer defined items


  • Predictable Lists should use Select to fulfill the need of providing familiar options to the user.
    • State names
      • Even though State names are a list that contains 50+ items, they are recognizable and exist outside the task context.


  • Auto Complete can be used when the user would benefit from a wild-card search.
    • Phone Number Country Code
      • See Phone Number for more information
    • Currency
      • It is recommended to use Auto Complete for Currency Codes, because while users may know which currency they need, they may not know the Code.
      • See Currency for more information
  • Auto Complete can also be used when users are be able to define the names of items (lists, account nicknames, reports).
    • These items are typically in the user’s language, not bank language
      • Example: Account Nickname (savings, checking, Claudia’s account) versus Account Number 12345

Related Standards

  • Radio Button
  • Checkbox
  • Radio Button Group
  • AutoComplete
  • Select
  • MultiSelect
  • Form Types
  • Reporting
  • Search and Results
  • Required Fields
  • Dealing with Input Data
Recommended Posts

Leave a Comment

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text. captcha txt