# BofA Mobile Dashboard — Testing Plan
**Decision Map: Define + Measure**
Prepared for: Bank of America mobile dashboard improvement
---
## DEFINE
Define establishes *what* we're testing and *who* we're testing with before a single study runs. It has three blocks: User Needs, Audience, and Collecting Data.
---
### Block 1 — User Needs
User Needs are organized into five categories, foundational to aspirational. Each category earns the right to the next — a beautiful product no one can find is still invisible; a trustworthy product that feels generic won't retain users. We diagnose where the dashboard first breaks down and fix that layer before moving up.
**Category: Basics — "Can I use it easily?"**
Need types: Usable, Useful, Findable, Accessible
Looking at the current dashboard, Basics is the first layer to examine. The six-tile grid presents accounts, credit card, Zelle, December spending, and FICO score at equal visual weight. There is no hierarchy. A user who opens the app to pay a bill must scan all six tiles to find the relevant action. The Zelle tile displays "3 Pending Requests" — urgency information — with the same visual treatment as the FICO score tile, which is informational. These are two different job types presented as if they are the same.
- **Findable failure signal:** Users may not locate the pending Zelle request without scanning all tiles. First-click success on urgent actions is the key metric to test.
- **Usable failure signal:** The spending tile shows "3 Categories Over Budget" but no immediate next step. Users must tap in to learn more, adding a step to an already urgent message.
- **Credible gap (Trust category):** The FICO score is dated 08/01/2019. In a banking context, a stale date on a financial indicator raises questions about whether other data on the screen is current.
**User Needs to prioritize for this project:**
1. **Findable** (Basics) — Can users locate urgent actions (Zelle, budget alerts) without scanning all tiles?
- Key metric: First-click success rate, Comprehension
2. **Usable** (Basics) — Can users act on what they find — specifically the spending alert — easily and confidently?
- Key metric: Task success rate, Time on task, Error rate
3. **Credible** (Trust) — Do users believe the data on screen is accurate and current?
- Key metric: Trust score, Satisfaction, Bounce/abandonment from dashboard
4. **Useful** (Basics) — Does the dashboard tile selection match what users actually open the app to do?
- Key metric: Usefulness rating, Session frequency, Feature engagement per tile
---
### Block 2 — Audience
Without a defined audience, analytics, stakeholder opinions, and participant feedback all receive equal weight and metrics lose meaning. We use the four-voice model: Project Team, Stakeholders, Customers, Participants.
**Customers (highest signal weight)**
Locate users within lifecycle segments. For the BofA dashboard, the highest-priority segments are:
- **Habitual users** — open the app regularly; most affected by tile layout efficiency and scan time
- **New Paying users** — recently onboarded; most affected by tile comprehension and credibility gaps (e.g., stale FICO date creates early distrust)
- **Power users** — use multiple products (checking + credit card + Zelle); most affected by the flat visual hierarchy that treats all tiles equally
**Participants (high weight during testing)**
For unmoderated tests (first-click, preference): 75–150 participants, mobile banking users.
For moderated sessions (task success, think-aloud): 8–12 participants per round, recruited from Habitual and New Paying segments.
**Stakeholders (medium weight)**
Relevant functions and their metrics of interest:
- **Product** — daily active users, tile engagement rate, session duration
- **Engineering** — reliability of real-time balance and data freshness
- **Finance/Legal** — accuracy standards for displayed financial data (relevant to the stale FICO date)
- **Support** — contact rate driven by dashboard confusion
**Audience attributes (3–5 per segment):**
- Behavioral: frequency of app opens per week
- Lifecycle: segment (New Paying / Habitual / Power)
- Contextual: device type (iOS vs. Android), primary use case (balance check / payment / monitoring)
- Motivational: financial confidence level, goal orientation (saving vs. spending awareness)
---
### Block 3 — Collecting Data
We use the Define → Capture → Connect cadence. Data collection pairs at least two feedback types so we get both *what* users do and *why*.
**Feedback type pairing:**
- **See what users do** (behavioral) + **Hear what users say** (attitudinal) = primary pair
- **View user data** (analytics) + **Sense what users like** (preference/appeal) = secondary pair
**Collection approach by need:**
| User Need | Approach | Technique | Instrument / Tool |
|---|---|---|---|
| Findable — tile navigation | Evaluative | First-click testing | Helio first-click test |
| Usable — spending alert flow | Evaluative | Task success + SEQ | Maze or Helio usability test |
| Credible — FICO trust | Evaluative | Attitudinal survey + SUS | Helio preference test + SUS |
| Useful — tile relevance | Exploratory | In-app microsurvey + diary | Sprig / Qualaroo (exit survey) |
| Behavioral baseline | Behavioral | Heatmaps + clickstream | Hotjar / FullStory + Pendo |
**Show Your Sources rule:** Every finding must cite technique used + audience tested + metric measured.
Example: "First-click success rate from a Helio unmoderated test with 100 mobile banking users (Habitual segment), measuring Findable (Comprehension + Success Rate)."
---
## MEASURE
Measure takes the user needs defined above and turns them into testable bets. It runs in four moves: **Concepts → Hunches → Questioning → Findings.**
---
### Move 1 — Concepts
A Concept passes the 5-minute test: user need + business goal + signal, written in under 5 minutes. If it can't be written that fast, the intent isn't clear enough yet.
**Concept A: Dashboard tile hierarchy**
- User need (from Define): Findable — users need to locate urgent actions without scanning all tiles
- Business goal: Increase Zelle engagement; reduce support contacts driven by dashboard confusion
- Signal: First-click success rate on the Zelle tile when an urgent state ("3 Pending Requests") is present
**Concept B: Spending alert clarity**
- User need (from Define): Usable — users need to act on "Categories Over Budget" without an extra tap
- Business goal: Increase spending tools engagement; reduce drop-off from budget-aware users
- Signal: Task success rate for "find which categories are over budget" and time on task
**Concept C: FICO data trust**
- User need (from Define): Credible — users need to believe the data on screen is accurate
- Business goal: Reduce trust-driven churn among New Paying users; reduce support contacts about data accuracy
- Signal: Trust score (attitudinal survey) comparing stale date vs. refreshed date variants
**Concept D: Tile relevance to intent**
- User need (from Define): Useful — the dashboard should match what users open the app to do
- Business goal: Increase tile engagement depth; reduce zero-interaction sessions
- Signal: Usefulness rating per tile + session frequency from analytics
---
### Move 2 — Hunches
Hunches are falsifiable — they could be wrong, and that's the point. Each is tied to a user friction, expressed as a testable hypothesis, and linked to a UX metric.
**Hunch A**
*"We believe that the Zelle tile's visual treatment for New Paying and Habitual users will produce a low first-click success rate when a pending request is present, because the tile reads as a navigation shortcut rather than an urgent notification — causing users to miss or delay acting on pending money requests."*
- Metric: First-click success rate (target benchmark: ≥75% correct first click)
- What would disprove it: First-click success ≥80% without any design change
**Hunch B**
*"We believe that the spending tile's current design — showing 'December Spending · 3 Categories Over Budget' without a visible breakdown — will require an additional tap for Habitual users to understand which categories are over budget, because the alert is stated but not explained, increasing time on task and reducing task success."*
- Metric: Task success rate + SEQ score + time on task
- What would disprove it: Users can correctly name the over-budget categories without tapping into the tile
**Hunch C**
*"We believe that displaying an FICO score dated 08/01/2019 will lower trust scores among New Paying users compared to Habitual users, because new users have not yet established confidence in the app's data reliability and a stale date creates an early credibility gap."*
- Metric: Trust score (Likert, 1–5) segmented by lifecycle stage
- What would disprove it: No significant trust score difference between New Paying and Habitual users when shown the stale date
**Hunch D**
*"We believe that the majority of dashboard sessions for Habitual users begin with a specific, single intent (check a balance or complete an action) rather than a general review — meaning the six-tile flat grid creates unnecessary scanning overhead for most sessions."*
- Metric: Session intent match rate (from exit microsurvey: "Did you find what you came for, and how long did it take?")
- What would disprove it: Exit survey shows >60% of users report reviewing multiple tiles as part of their normal session
---
### Move 3 — Questioning
Questions run in three modes. Mode is chosen by where in the design cycle each concept sits.
**Mode: Evaluative** (designs exist; does this work for users?)
Used for Concepts A, B, C — we have a screen to test against.
**Mode: Exploratory** (no firm hypothesis yet; what should we learn?)
Used for Concept D — we need to understand session intent before redesigning.
---
**Questions for Concept A — Tile navigation (Evaluative)**
*People question:* How do users typically scan the dashboard when they open the app?
*Process question:* What steps does a user take when they see "3 Pending Requests" on the Zelle tile?
*Product question:* Does the Zelle tile communicate that action is required, or does it read as status information?
*Problem question:* What prevents users from immediately acting on a pending Zelle request?
Testable form: "When a user sees the dashboard with '3 Pending Requests' shown on the Zelle tile, can they tap the correct tile as their first interaction?"
Technique: First-click test (Helio)
UX metric: First-click success rate (Behavioral), Comprehension (Performance)
---
**Questions for Concept B — Spending alert (Evaluative)**
*People question:* When users see a budget alert on the dashboard, what do they expect to happen next?
*Process question:* What steps do users take to find out which spending categories are over budget?
*Product question:* Is "3 Categories Over Budget" understood as a summary or as a complete message?
*Problem question:* What makes acting on a budget alert feel difficult or unclear?
Testable form: "Can users identify which spending categories are over budget in under 60 seconds, starting from the dashboard?"
Technique: Task success rate + think-aloud (Maze / Helio moderated)
UX metric: Task success rate (Behavioral), Time on task (Performance), SEQ score (Attitudinal)
---
**Questions for Concept C — FICO trust (Evaluative)**
*People question:* How do users interpret a date shown next to financial data on their banking dashboard?
*Process question:* What do users do when they notice the FICO score date is from 2019?
*Product question:* Does a stale date on one tile affect how users perceive the accuracy of other tiles?
*Problem question:* What causes users to distrust data displayed in a banking app?
Testable form: "After viewing the dashboard, how confident are users that the financial data shown is current and accurate?" (5-point Likert scale)
Technique: Attitudinal survey + SUS (Helio); A/B variant — stale date vs. refreshed date
UX metric: Trust score (Attitudinal), Satisfaction (Attitudinal)
---
**Questions for Concept D — Session intent (Exploratory)**
*People question:* What do users open the BofA mobile app to do?
*Process question:* How do users navigate from the dashboard to complete their primary intent?
*Product question:* Does the dashboard surface what users need most on a typical session?
*Problem question:* What information or action is missing or hard to find on the dashboard?
Testable form: "In the last 5 times you opened the BofA app, what did you open it to do?" (open-ended exit microsurvey)
Technique: In-app microsurvey (Sprig) + 5-day diary study (10–15 participants)
UX metric: Usefulness (Attitudinal), Session frequency (Behavioral)
---
### Move 4 — Findings
Findings become signals only when data ties to a design choice, a user need, AND a business goal. Raw data alone is noise. The translation chain: raw data → finding → tie to user value → tie to business result → act → share.
**Finding template (to be completed after each test):**
| Field | Content |
|---|---|
| Raw data | [Test result: e.g., "42% first-click success on Zelle tile"] |
| Finding | [Pattern: e.g., "Users tapped the checking account tile first when trying to act on a pending Zelle request"] |
| User value | [Need type met or unmet: e.g., "Findable need unmet — Zelle urgency not visually distinct"] |
| Business result | [Metric impact: e.g., "Delayed Zelle action increases pending request abandonment"] |
| Connected to | [Concept A — Hunch A] |
| Recommended action | [Design decision: e.g., "Add visual urgency treatment to Zelle tile when pending requests > 0"] |
---
## Signal stack — UX metrics by type
Each concept maps to a metric type so findings are comparable across tests and stakeholder-ready.
| Concept | Behavioral | Attitudinal | Performance |
|---|---|---|---|
| A — Tile navigation | First-click success rate, tap frequency per tile | — | Comprehension |
| B — Spending alert | Task success rate, drop-off rate | SEQ score | Time on task, error rate |
| C — FICO trust | — | Trust score, satisfaction, SUS score | — |
| D — Session intent | Session frequency, tile engagement depth | Usefulness, sentiment | — |
---
## Three-tier sharing model
**Project level:** Raw test results stored in Helio, Maze, and Sprig — shared within design team during each test cycle.
**Cross-team:** Findings grouped by concept and tied to UX metric — surfaced in product and engineering sprint reviews. Format: finding + user need + business metric impacted.
**Leadership rollup:** Chain of proof for roadmap reviews:
Trust score / Comprehension → Tile engagement rate → Support contact reduction + Zelle activation rate