Ownership
Targeted discovery and native mobile flows under design lead Tarun Bhandari.
The dashboard fitin a pocket.The work did not.
The brief asked for a desktop port. Research found a different job: check, ask, filter, and act in the thin minutes between meetings.
60-second brief · The reframe
From a desktop viewer to a mobile decision tool
The brief was to shrink desktop analytics. Discovery showed mobile had a different job: check a number, ask a follow-up, filter it, and act, all between meetings.
The inherited answer was a smaller dashboard. Research replaced completeness with four time-sensitive jobs: check, ask, filter, and act.
EvidenceWatchlists, voice states, filters, alerts, and sharing shipped as one native mobile system.
Constraint
Four months to preserve enterprise depth without copying desktop.
Design call
Spend complexity only where a mobile decision moment justified it.
Evidence
23 public responses, seven customer interviews, and release reporting.
Discovery evidence
Check, ask, filter, act.
Twenty-three public responses and seven customer interviews broke the desktop-port assumption into four moments worth carrying: check, ask, filter, act.
How the research sample was built
I gathered 23 substantive responses to an anonymous public prompt about an ideal data-intelligence app, then interviewed seven ThoughtSpot customers: chief executives, chief financial officers, other C-suite leaders, business analysts, and people who reported insights to them. Follow-up sessions with customers and internal stakeholders tested the resulting flows.
- Check
Mobile was used between meetings, not as a smaller desktop.
Design response: Open on a watchlist of KPIs with trend, so a status check costs seconds.
- Ask
Natural-language answers needed visible, trustworthy feedback before anyone would rely on them.
Design response: Name every voice state out loud instead of hiding progress behind one spinner.
- Filter
Enterprise questions were multi-facet, and a full-screen filter swap lost the result being questioned.
Design response: Keep advanced filters reachable with their results still on screen.
- Act
The app let people view a metric, but meaningful changes waited for desktop.
Design response: Make watchlists editable on the phone, with a guard and a way back on delete.
Chapter 01 · Watchlist
Make the number actionable before the meeting ends.
A view-only watchlist exiled every edit to desktop. The check and the action had to live in one reachable flow: trends on open, then add, edit, and guarded delete without changing devices.
- Open on pipeline, SEO traffic, and conversion, each with its trend
- Keep add, edit, and delete in one thumb-reachable flow
- Guard the destructive action with confirmation and recovery
Decision cost
Thumb reach also puts delete within easy reach.
Proof
Shipped as the default Watchlist screen with trend-aware KPI rows.
Open the interaction rationaleThumb reach, destructive action, and the recovery decision
AcceptedTwo-way door
One-handed reach put delete inside the thumb
Decision
I placed add, edit, and delete in one reachable action surface, then designed confirmation and recovery around the destructive action.
Outcome
The complete watchlist flow shipped as part of the mobile redesign.
Tradeoff
The same reachability that helped frequent actions also made delete easier to hit. Recovery became a product requirement, not a polish task.
Inspect the full decision recordContext, drivers, consequences, alternatives
Context and problem statement
The watchlist was view-only. Adding, editing, and removing a KPI needed to work during short mobile sessions without sending people back to desktop.
Decision drivers
- Keep primary actions in the reachable thumb zone
- Support the complete watchlist lifecycle
- Make destructive actions recoverable
Positive consequences
The mobile app became useful for acting on a KPI, not only viewing it.
Negative consequences
The same reachability that helped frequent actions also made delete easier to hit. Recovery became a product requirement, not a polish task.
Kill criterion
If accidental-delete or restore usage exceeded the agreed guardrail, delete would move behind a second deliberate action.
Considered options
- Keep editing on desktop
- Place all actions in one reachable mobile surface
- Separate destructive actions into a deeper menu
Road not taken
Moving delete into an overflow menu would reduce accidental access but split one compact management model across two places.
Chapter 02 · Voice states
If the system is thinking, say so.
Asking out loud was faster than typing between meetings. Trust depended on making every state visible before an answer arrived.
- Five states: idle, listening, thinking, success, error
- More than thirty rounds across progress and recovery
- No spinner standing in for every state
Decision cost
Voice received more iteration than its likely daily use justified.
Proof
Shipped as five distinct progress and recovery states.
Enter the state roomFive named states, the iteration record, and the budget trade-off
1
Idle
Before a query starts; the microphone is available but not yet listening.
2
Listening
Actively capturing speech, with visible feedback that input is being heard.
3
Thinking
Processing toward an answer, distinct from listening so it's never mistaken for a stall.
4
Success
An answer returned with a way to act on it, not just a static result.
5
Error
The system says so plainly, with a path to recover, never a silent failure or an infinite spinner.
SupersededTwo-way door
Thirty iterations on voice for a minority of sessions
Decision
I designed the full voice-input state system and iterated it more than thirty times.
Outcome
The state specification shipped. The project did not isolate whether the additional iteration increased voice adoption.
Tradeoff
That attention came from the same delivery budget as flows people touched every day. I still think the states were worth resolving; I would not defend the ratio.
Inspect the full decision recordContext, drivers, consequences, alternatives
Context and problem statement
Speaking can be faster than typing an analytical question on a phone, but voice input serves fewer sessions and demos better than it gets used.
Decision drivers
- Make every system state unambiguous
- Cover permission, listening, processing, error, and recovery
- Reduce question-to-answer effort
Positive consequences
Engineering received explicit behavior for the states most likely to fail, and the interaction remained understandable beyond the happy path.
Negative consequences
That attention came from the same delivery budget as flows people touched every day. I still think the states were worth resolving; I would not defend the ratio.
Kill criterion
If observed voice use stayed below the agreed threshold after launch, iteration would stop and the pattern would fall back to the native control.
Considered options
- Ship the basic platform microphone pattern
- Design and specify the complete state machine
- Defer voice and spend the time on higher-frequency flows
Road not taken
A native microphone control would have shipped faster, but permission denial, timeouts, and low-confidence results would have remained underspecified.
Decision evolutionBrief
Input
Port the desktop query experience to mobile.
What changed
Voice appeared to be a faster input shortcut.
Ready
Start a query or choose a failure state to inspect the recovery behavior.
Faithful state-model reconstruction, not the production ThoughtSpot app. No audio is recorded.
Chapter 03 · Filters
Narrow the question. Never lose the answer.
Page, modal, and hybrid filters were put under pressure. The winning frame kept the affected result visible while the question changed.
- Preserve multi-facet depth
- Compare page, modal, and hybrid models
- Keep results and filters visible together
Decision cost
Filters and results each get less room.
Proof
The hybrid layout shipped without a full-screen context swap.
Inspect the discarded pathsEarly flow structure and the recovery state
Evidence
The mobile habit appeared in the numbers.
Team-reported product indicators from the release window, shown with their attribution limits.
3×
Team-reported monthly use
A product-level release indicator, not a controlled attribution to the redesign.
4.9
App Store rating
Reached 4.9 across 28 ratings after displaying 2.9 before release; the earlier rating count is not published.
9.7k
Team-reported installs
New installs reported during the release window; the exact dates and baseline are not published.
6
Core task coverage
Watchlists, voice queries, headers, filters, alerts, and sharing covered the main mobile analytics jobs.
Evidence boundaries
These are product-level release indicators reported by the team, not a controlled attribution study. I left as the redesign completed, and the store-rating samples were small: 28 on the App Store and 39 on Play. Read the full retrospective
Inspect the raw store evidence and product recognitionRating samples, download context, and the Cloud Award
Ownership
What was mine, and what it cost
The discovery and the native system were mine to run. One trade-off sat underneath every decision above.
Work nobody asked for
I expanded the assignment in two places: discovery changed the brief, and launch design carried the product into the store.
I ran the research that changed the brief
Why it matteredInterviews and analyst communities showed when mobile analytics was actually useful, ahead of any design brief.
Evidence boundaryThe evidence base combined 23 public responses, seven customer interviews, and follow-up evaluative sessions.
I designed the store listing and launch material
Why it matteredIt is the first screen a potential user sees, and it sat outside the brief. I took ownership of it.
Evidence boundaryLaunch performance was tracked at product level across the full release.
I led targeted discovery and native flow design under design lead Tarun Bhandari. Engineering led production delivery, while product owned the ongoing roadmap.
The hardest trade-off
Watchlists gave up a safety margin around delete, filters gave up screen density, and voice gave up part of the budget for daily-use flows. Matching enterprise depth on a phone always costs something. The job was choosing which cost to accept, not avoiding it.
In hindsight
What I would do differently
The shipped system answered mobile interaction. The next measurement layer is retention and chart legibility.
I treated adoption growth as proof without a veto metric
When the Metric Becomes the TargetWhat I shippedThe outcomes lead with a 3× rise in monthly active use and a rating jump from 2.9 to 4.9. Both are useful signals, but neither had a pre-registered guardrail that could have told me the redesign failed.
What I would do nowDefine the goal, signal, success metric, and one guardrail before release. Write down the result that would make me call the launch unsuccessful instead of interpreting every headline number after the fact.
My sub-three-second target was too soft
Latency Is a FeelingWhat I shippedI set a perceived sub-three-second target for time to first interaction at launch. That target could pass while the app still felt slow, especially to a repeat user checking one number between meetings.
What I would do nowBudget 100 ms for feedback and 400 ms for flow, then measure interaction to next paint at the 75th percentile on real devices. Motion should resolve around the response, never delay it.
I named accessibility as a goal but shipped no method
Solve for One, Help EveryoneWhat I shippedThe voice states and compact headers relied on color and audio cues. The work did not document a contrast rule, focus order, screen-reader path, or a second channel for every piece of meaning.
What I would do nowSet contrast and naming rules at the token and component level, run the complete voice flow through a screen reader, and test with people who use assistive technology instead of treating accessibility as an interface quality.