UX case study · 2024 to 2026

Mobile Insights

Designing, researching and building an internal analytics platform for Bank of America’s mobile engineering teams.

User Journey screen in dark mode: a list of sessions on the left and a flow diagram of the screens one user moved through, with the services each step called — User Journey, from the back-end update: every screen one user selected, and the services each step called.

User Journey, from the back-end update: every screen one user selected, and the services each step called.

The product

An internal tool that gathers technical data from the bank’s consumer mobile apps. Features like Build Information, Code Commits and User Journeys put that data to use for developers, QA and leaders.

My role

The only UX designer for most of the original build, on a team of five to seven developers and a lead architect, with no product manager. One of two designers in the rebuild.

What I did

Designed most of the original platform and its design system, started the product’s first user research, and built two released screens in code with GitHub Copilot.

Outcomes

Usage was never formally measured. Feature leads shaped the product through frequent conversations with the lead architect and the manager who owned the project, and feature proposals came from them. My research was the first structured look across disciplines.

What Mobile Insights is

Developers and QA specialists work in separate tools, and each one holds a rich depth of information about the app. The code host holds the work being done in the app. The test system holds how the app is being tested. The build server holds what happened with each build. Each tool tells its own part of the story, and there are gaps between them.

Code host: the work in the appTest system: how it’s testedBuild server: each build

→

Mobile InsightsBrings their data together around each release, so the questions that fall between the tools can be asked.

Many of the questions that matter most sit in those gaps. If a crash happens in a build, under what conditions did it occur? Did the same crash occur in other builds, or around a particular release? Is it happening in a particular flow through the app, and is that a common flow? What about that flow, or about the environments the app is tested in, could explain it?

User Journey screen in dark mode showing a session’s details, its screens and services in order, and a crash in the session — User Journey with a crash in the session, from the back-end update.

User Journey with a crash in the session, from the back-end update.

Mobile Insights gathers the technical data from these tools so a person can see the work, the testing and the builds of a release together, and start answering questions like these. Its features apply that data. Build Information shows the builds and changes in a release. Code Commits shows code work across teams. User Journeys show every screen a user selected and the services each step called, for one user or combined across many to show the characteristics of a flow.

It serves engineers doing their own work, feature leads following their teams’ work, leaders watching the overall health of the apps, and the production certification testers who run the last round of testing before a release.

The team and the three phases

The team was five to seven people, all developers, with no product manager. Requirements came from the lead architect. Mobile Insights sat within a larger group of teams. The manager who headed that group tracked work across all of its teams and owned the project. The UI developer who started the project wasn’t a UX designer, and he left early.

Original release, from 2024

I designed most of the screens and the original design system in Figma.

Back-end update

A change in back-end technology brought a new search and user journeys, which I designed.

React rebuild, 2026

I ran the product’s first user research and built two released screens in code.

Screens I designed include Build Information, the original Code Commits, User Activity, Deals Dashboard, User Journey, User Journey Aggregates, Search Results, Release Summary, notifications, email reports and the admin screens. I added to the design of Services and Crashes.

Original release and back-end update

Designing the original release

How requirements were communicated

Most of the feature list came from the lead architect, working with the back-end lead. My job was to organize the features visually, design the modules, and decide how each piece of information is shown, inside a four-column card layout the original UI developer had already set. I wasn’t always told why a feature was needed, so I worked from what each screen had to let people do.

Doing the work

We worked at the whiteboard. With the lead architect and the back-end lead, I wrote down the requirements, asked whether another arrangement would show them better, and sometimes sketched the screen as we talked. Then I built a grayscale wireframe in Figma, fairly high fidelity, and we went through review rounds until the design settled. When I disagreed strongly, the lead architect had me make two versions, one with the team’s idea and one with mine, and we chose between them. My version was sometimes the one chosen.

Whiteboard sketch of the Code Commits screen: release and platform selection at the top, a column of teams with stats, a column of commits by repository and by developer, and a commits widget reused from Build Information — The Code Commits screen on the whiteboard. The notes say to reuse cards from existing screens and to let the second column filter the third. Selecting teams to filter the page carried through to the rebuild.

The Code Commits screen on the whiteboard. The notes say to reuse cards from existing screens and to let the second column filter the third. Selecting teams to filter the page carried through to the rebuild.

Whiteboard list of admin screen requirements grouped into navigation options and developer options

Whiteboard sketch of Deals Dashboard cards and charts

Notebook sketch of a notification module with layout notes

Notebook sketch of a search bar placed inside the results timeline

Sketches from requirements sessions in the original release: grouped requirement lists, screen layouts and component notes.

Grayscale wireframe of the Authenticator session details screen — From grayscale wireframe to finished design: the Authenticator session details screen.

From grayscale wireframe to finished design: the Authenticator session details screen.

Designing beyond the feature list

Throughout the project I thought ahead to what would be most useful to the people using Mobile Insights, beyond what the feature list covered. I treated it as one product. Between assignments I designed a contact screen before one existed, designed reporting email templates before that work began, and designed a newsletter for product updates.

Search is one example. On the first Search Results screen, I designed a way to change the date, the identifying criteria and the time range right in the results panel, without running a new search. It went beyond the scope the lead architect had in mind for that release, and the back end was about to change, so it was held back. When the back-end update turned search into the User Journey screen, I proposed it again. It was built and still works.

Notebook sketch: a search bar with identifier, time range and environment fields placed inside the results timeline — Notebook sketch of the idea: the search fields sit inside the results bar, so they can be changed in place.

Notebook sketch of the idea: the search fields sit inside the results bar, so they can be changed in place.

User Journey screen in dark mode: identifier, time range and environment fields above the results timeline, with session details below — As built on User Journey: the identifier, time range and environment sit beside the results timeline and change the results without a new search.

As built on User Journey: the identifier, time range and environment sit beside the results timeline and change the results without a new search.

A product update newsletter I designed before the team needed one. It was never sent. Its first item describes the change to search.

The original design system

I chose the typography and the initial color palette and built the design system in Figma, with variables and a two-layer token structure: raw color values, mapped to tokens named by their purpose. It kept theming consistent and supported light and dark modes. I checked text contrast through several palette revisions with the original UI developer. Many new features built on existing patterns, and I extended the system when a new problem needed it.

Figma variables panel listing design tokens with dark mode and light mode values — Variables and tokens in the original design system.

Variables and tokens in the original design system.

Dashboards for each team

Feature leads could also have dashboards for their own teams. The Deals Dashboard was for the feature lead over the deals module: it tracked that team’s code work along with information specific to the modules they worked on. The idea grew into a dashboard builder, where a feature lead with admin access could create a dashboard for their team. A developer was already building it when I redesigned it, and parts of my design were used. It came shortly before the rebuild.

Deals Dashboard in dark mode with bar charts of widget impressions and deal performance, a line chart of sessions, and a table of recent sessions — Deals Dashboard: one team’s code work and module-specific data on one screen.

Deals Dashboard: one team’s code work and module-specific data on one screen.

Email reports

I designed the leadership email reports on release health, crashes and service errors, turned them into HTML with an AI Figma plugin, and worked around older Outlook’s limits. I also designed the screen in Mobile Insights where people configure, preview and send them. The emails went out in light mode, at the group’s manager’s direction, to limit accessibility concerns.

Service Errors Report email in light mode, with example data: total services, failed services and new service errors for Android and iOS, service errors by team as pie charts, top modules, and service errors by day as bar charts — A service errors report email, and the screen in Mobile Insights where people choose the environment, app, release and template, preview the email and send it. Example data and names.

A service errors report email, and the screen in Mobile Insights where people choose the environment, app, release and template, preview the email and send it. Example data and names.

Handoff and design review

I wrote specifications wherever the developers could read them: in the project wiki while we designed in Sketch, and in the Figma files themselves once we moved to Figma, since developers didn’t have Dev Mode. With each handoff I provided reusable components, annotated interaction details, the color and typography system, and variants for each data state, including loading, empty and error states. Once features reached staging, I reviewed spacing, alignment, grid structure, component behavior and visual fidelity, and contributed CSS refinements so the product matched the design.

Navigation specification sheet from the original release, with measurements and states — Navigation specifications from the original release.

Navigation specifications from the original release.

During the rebuild, 2026

The product’s first user research

Feature leads had real input into Mobile Insights. The lead architect and the group’s manager were in frequent contact with them, and feature proposals came from them. That input wasn’t gathered through a formal process that captured what more people thought, and it reached me as requirements. When the reason for a feature wasn’t apparent, I had to dig for it. I wanted the opportunity to do UX research and contribute to the product that way, and the rebuild was about to start from the ground up. I wrote a research proposal, the lead architect added questions about outdated code and technical debt, and the group’s manager approved it.

From July 1 to August 3, 2026, I interviewed eight people: feature leads, developers, QA, production certification testers, the lead architect and the group’s manager. I recorded and transcribed each session. I organized what I heard in two ways: a web app I built in Figma Make that captures each person’s feedback, pain points and what their role found missing, and a gap analysis that set nine needs against the six tools people already used.

Where people struggled

Access and self-serviceRegression burdenCodebase complexityEnvironments going downFinding root causesSwitching between toolsUnclear ownershipMissing automation

The interviews gave me, as the designer, visibility into what people across those disciplines were doing day to day. Many people knew what Mobile Insights was without knowing what to use it for. The gap analysis recommended that Mobile Insights stop competing with existing tools in their own areas and connect what none of them connect: how the work, the testing and the builds behind a release relate to each other.

What happened next

I showed the findings app and the gap analysis to the group’s manager, who asked for design concepts answering each role’s needs and a way to learn how people use the tool. I meant to turn everything into a presentation for the team. It was my first time running research, with little guidance, and organizing that much information into something I could present was the hardest part. The rebuild then took my time, and the findings didn’t become design changes.

React rebuild, 2026

The rebuild in code

From 2024 the department wanted me to learn development. I held that UX was where I added value, until GitHub Copilot made development approachable. In the 2026 rebuild, a new lead UI developer set the visual style and a three-level structure for the components, and I built inside it.

Page levelReceives the data and arranges the cards

Shared card patternsThe base of every card the project uses

Single UI piecesButtons, labels, icons

I built the Build Information and Code Commits screens in React, TypeScript and MUI with Copilot. I learned by planning each piece of work with Copilot, keeping a running list of questions for developer meetings, and recording those meetings so Copilot could use the transcripts as reference. When the Code Commits cards came back empty after I connected them to the data, I traced the request in the browser and worked with the developer who wrote the query until we found the dates were in the wrong format.

Code Commits

The starting point was a design the lead UI developer generated with Copilot from a dashboard template. I chose what sits under each headline number by researching what different users, including leadership, would want from each card. I built the team selector in the new design language and designed it for phone width.

Code Commits as I built it, August 2026. Recreated with invented data.

Build Information, original and rebuilt

Build Information puts a release’s build activity and its change log in one place: the commits, pull requests and dependency changes for the release, every build with a graph of successes and failures, and the change log filtered by phase, after code freeze, after code lockdown and after release. I designed it for the original release. In the rebuild I translated that design into the new components. The information stayed the same and the layout changed. The release pickers moved to the page header, the overview collapses so the change log can take the screen, and the change log became a table with phase, approver and status.

Build Information in dark mode, recreated with invented data: four columns showing release numbers, builds, the change log and dependencies — Original release design, four tall columns. Recreated with invented data.

Original release design, four tall columns. Recreated with invented data.

Build Information in light mode, recreated with invented data: headline numbers across the top, the list of builds down the left, and overview cards above a change log table on the right — Rebuilt in code: builds down the left, the overview and change log on the right. Recreated with invented data.

Rebuilt in code: builds down the left, the overview and change log on the right. Recreated with invented data.

Designing beyond the feature list, in code

The habit from the original release carried into the rebuild. Now I could build a proposal in code and show it working.

One example: when the overview on Code Commits is minimized, its five cards disappear. I proposed that each card shrink to a one-line preview so people keep a sense of what it holds, and I built it in my local copy. For the engineers card, Copilot suggested a ranking of top engineers. I chose average change size, because it was already in the card’s data and flags changes too large to review well, and a ranking would encourage competition over engineers’ work. The team didn’t adopt the previews. They were a first step toward something I’d do more of: finding where insights fit on each screen.

Code Commits with the overview minimized to five one-line previews, so the change log sits on the first screen; recreated with invented data — The proposal, September 2026: five one-line previews keep the change log on the first screen. Recreated with invented data.

The proposal, September 2026: five one-line previews keep the change log on the first screen. Recreated with invented data.

What I’d do differently

Keep a record of what I heard

Nobody was keeping an inventory of the feedback in whiteboard sessions and other meetings. I was in those rooms, and I could have recorded it and added it to what we knew.

Carry the research further

Turn the findings into clearly organized design deliverables, check the screens I was building against the interview transcripts as I worked with Copilot, keep doing follow-up interviews, add usability testing, and get real data on how people use the product.

Look for insights in every screen

Inventory the features on Code Commits, Build Information and the other screens, and find where insights fit.