Does a grid or a linear feed better support a five-minute break?

The decision

The team was choosing between two layouts for a high-traffic content feed and had strong opinions on both sides. Preference data existed. What was missing was evidence about how each layout changed the way people actually used the feed.

How we designed it

Participants were Windows 11 users who already had the live grid experience. Each evaluated their own feed and then a linear prototype, so every comparison was within-subject. Because self-reported eligibility was unreliable, participants were required to share a screenshot of their own feed as proof they had the live experience before entering the study. I measured scan behavior, perceived content quality, decision ease and return intent on a 5-point scale, with open-ended prompts after each.

What we learned

Layout wasn't a visual preference. It changed the mindset people brought to the feed.

The grid invited fast scanning and quick exits; the linear layout pulled people into a slower, deeper reading mode. Neither was better in the abstract. The right answer depended on which job the surface was hired to do, and the team hadn't yet agreed on that.

What changed

The conversation moved from "which looks better" to "which mode are we designing for." The report gave the team a shared vocabulary (scan mode versus read mode) that showed up in later design reviews, and the recommendation tied each layout to a usage moment rather than declaring a winner.

When do people want quick utility, when do they want to browse, and what should open first?

The decision

A panel offered two entry points, one built for glanceable utility and one built for scrolling discovery. The team needed to know how users understood the difference, which felt more useful, whether either hurt focus, and which one should be the default when the panel opened.

How we designed it

Half the participants saw widgets first, half saw discover first, so first-impression effects couldn't drive the result. Everyone rated clarity, usefulness and focus impact for each board, then chose a default and explained why. Screenshot verification confirmed they were on the correct build.

What we learned

People sorted the two boards by intent, not by feature: “check something” versus “kill time.”

Widgets won on clarity and focus. Discover won on time spent but was the one more likely to feel like an interruption. The default question hinged on when the panel typically opens, not on which board people liked more.

What changed

The recommendation framed the default as a context decision, with evidence for each scenario, rather than a single verdict. That gave the team a defensible position in an executive review where the two boards had different sponsors.

What makes an AI summary feel useful enough to come back for?

The decision

The prototype offered AI-generated summaries in several formats and let users pick how deep to go. The team wanted to know which formats earned trust, whether depth controls were understood, and what would make someone return rather than treat it as a novelty.

How we designed it

Participants worked through the same stories in each mode, rated trust, usefulness and return intent per format, and talked through how they decided when a summary was "enough." I coded the open-ended responses against the ratings to see where perception and behavior diverged.

What we learned

Trust followed control, not format.

The summaries people rated highest weren't the shortest or the most polished. They were the ones where it was obvious how to reach the full story and how to adjust depth. When the path back to the source was unclear, trust dropped regardless of how good the summary read. Younger participants treated a visible source path as the signal that the AI wasn't hiding anything.

What changed

The recommendation prioritized source visibility and depth controls over adding formats. Several proposed modes were deprioritized in favor of getting the core reading experience right. The study also fed a set of principles about user agency in AI-assisted content that the team carried into later work.

Can a "catch up" module help people feel informed without feeling overwhelmed?

The decision

A digest at the top of the feed promised faster catch-up but risked adding noise and eroding trust if it felt like it was choosing for people. Three variants existed. The team needed evidence before committing engineering time.

How we designed it

Every participant saw all three variants in rotated order and rated scannability, engagement, perceived value and trust. I paired that with a short reflection on what they thought the digest was "for," which turned out to be the most useful question in the study.

What we learned

The focused digest won, and the reason was trust, not speed.

The broad version felt like the product was guessing; the focused version felt like it was helping. Most people described the surface as "inform first, entertain later," and the digest only worked when it respected that order.

What changed

The team moved forward with the focused variant and adopted "inform first" as a design principle for the top section. It's one of the clearest examples in my work of a study changing not just a feature but the team's mental model of the surface.

Where should editorial and content experiences live inside an AI assistant, and what would make them credible?

The decision

This one came before any feature existed. Leadership was deciding whether editorial and content experiences belonged inside the assistant at all, and if so, which of several candidate directions deserved roadmap space in the coming planning cycle. Everything downstream, including the four evaluative studies above, depended on getting this framing right. The risk of skipping it was obvious in hindsight: the team would have spent a quarter optimising a surface nobody had established a need for.

How we designed it

I ran in-depth interviews with 18 people across three usage profiles: heavy assistant users, people who used the assistant occasionally for search-like tasks, and people who consumed a lot of news and content but had not adopted an assistant. That third group mattered most, because they were the ones the product hoped to win and the only ones who could tell us what would make an assistant credible as a source. I kept the guide deliberately unstructured in the middle: rather than reacting to concepts, participants walked me through how they actually caught up on things they cared about, and where an assistant did or did not fit that.

I then mapped the candidate directions against two axes: how much value people expected from each, and how much trust each one demanded before they would use it. The second axis was the one the team had not been discussing, and it changed the shape of the conversation.

What we learned

People wanted the assistant to be a door to content, not a replacement for it.

Credibility rested on two things. Visible sourcing, so it was always clear where something came from, and a clear line between what the assistant had summarised and what a person had written. Directions that blurred that line, including the most technically impressive ones, were the least welcome: participants read them as the product deciding for them rather than helping them decide. The highest-value directions were not the highest-trust ones, which is why the map mattered: the cheapest wins sat where value was high and the trust burden was low.

What changed

The framing became part of the research landscape the team used for planning. Three directions were sequenced by trust burden rather than by build cost, with the source-visible ones first. It also set the vocabulary the later evaluative work was built on: the trust-versus-control finding in the AI summaries study and the "inform first" principle from the digest study are both direct descendants of this framing, which is the clearest evidence I have that upstream work paid for itself.

How do you make a bank account feel personal without a profile photo?

The decision

The bank was replacing an app people tolerated rather than used. For the new wallet the team prioritised two things in the first-run experience: an account-creation flow with fewer steps, and a way for people to make the account feel like their own. In most consumer apps that second part is a profile photo. In a financial app it could not be, because image uploads were restricted for security reasons. So the question became what to offer in its place, and whether it deserved a spot in onboarding at all.

How I designed it

I started with discovery interviews and an analysis of the old app's store reviews, which are the cheapest source of unfiltered complaints a team has. That gave me a map of the journey with candidate friction at each stage, which I then tested rather than assumed. On account creation I ran moderated sessions on the identity-verification steps to see where people slowed down and which steps could go.

For personalisation, with photos off the table, I proposed illustrated avatars and took several graphic styles into concept testing. It ran over more than one round: the first rounds chose the style, the later ones decided which characters to offer and how many. One requirement held through every round. The set had to be neutral enough that any user could find an option they were comfortable with, which is why the final lineup mixes stylised people with a few robots and creatures, for anyone who would rather not pick a face at all.

Once the picker existed, we ran an A/B test with new users. One group went through personalisation as a required step at the start of the first-run experience. The control group had no personalisation option. We compared how much each group used the app, measured in transactions, to check that the feature earned its place. Because I proposed the flows and interactions as well as running the research, findings went straight into design without a hand-off in between.

These screens come from the public Tuya app, where this flow is still live today.

What we learned

New users who personalised their account at the start made about 20% more transactions than users who never had the option.

The style rounds did their job: we went into build with one illustration style and a set of characters that users had already chosen between, not a designer's favourite. The A/B test answered the bigger question. The group that personalised at the start used the app about 20% more, counted in transactions, than the control group with no personalisation option. Because the step was part of onboarding for everyone in that group, this compares two whole groups of new users, not the people who chose to personalise against the people who did not. That made the case that a restricted, curated form of personalisation was worth offering even where a photo is impossible, and that it belonged in front of new users instead of waiting in a settings menu. On account creation, the sessions confirmed that sign-up friction was real, and that removing steps helped.

What changed

Onboarding steps were reduced. The avatar shipped as a curated set in the style that tested best, with colour as a second, lighter choice. Personalisation moved earlier in the first-run experience rather than sitting in settings. In the six months after launch the app's store rating rose 32%, satisfaction reached 89% against a baseline 15 points lower, and the product passed 200,000 monthly active users. Those are results for the whole launch, not for one feature; the avatar was one of the changes behind them.

Financial assistant: how much should an agent decide for you?

Open the assistant ↗

The research problem inside the product

Early versions understood a request only when phrased one way. The fix wasn't more prompting; it was treating every misunderstanding as data. I built an admin hub that logs each friction, and those logs became the examples for the next iteration, plus an eval set that runs after every change so regressions get caught. That is the same loop as a continuous research program, with a model as the participant.

What I learned about agency and trust

People forgive an agent that asks. They don't forgive one that guesses about their money.

Adding a clarifying question when intent was unclear did more for trust than any accuracy gain. It's the same pattern I saw in the AI-summary study at Microsoft, from the other side of the table.

A games hub for big groups: can fifty games share one set of rules for how they connect?

Open the games hub ↗

What it is for

The starting point was a specific social situation: a group of people together in a room, one phone, and nobody wanting to install anything. From there it grew a second mode for the same friends when they are not in the same place, where a game becomes a challenge you send and answer on your own time. The hub is the layer that lets both live together, so a group can move from passing a phone around to playing from three cities without changing app.

The research habit that shaped it

Every game had to be self-explanatory to a group at a party, which is a harsh usability bar: the phone is moving, someone is half-listening, and nobody reads instructions out loud. I play-tested each one with the beta group and kept a simple log of where people hesitated, what they asked, and whether the rules survived without me explaining them. Games that failed got rewritten rules and a visual tutorial overlay, not longer text.

What I learned

Difficulty is a trust signal.

When a "hard" mode wasn't actually hard, groups stopped believing the labels everywhere in the app. Calibrating difficulty honestly (a maze that really uses the farthest cell, a bot that really plays well) did more for retention than adding games.

Live screens from the beta. The product ships in Spanish, English and Portuguese.