The Brief

The client made physical toys for children aged 3 to 12. Good retail presence in the US and UK, a recognisable character universe, but no digital product. Once a toy was bought, the brand disappeared from a family's life completely.

They came to us with one question: can AI storytelling keep families connected to our characters at home? The job was not just to design an app. It was to figure out if the idea was worth building, and what it needed to do to earn a place in a family's regular routine.

Understanding Users

Before anything else I ran two research tracks. A group interview session with 14 parents of children aged 4 to 9 in the US and UK. And a structured review of 200-plus App Store reviews across competitor kids content apps, sorted by complaint theme. No wireframes existed at this point. The goal was to understand how families actually used this kind of product and what got in the way.

What the Research Changed

Three things came out of research that shifted the entire direction before a single wireframe was drawn.

1. The product is for parents, not kids

The brief said "an AI app for kids." Research said the parent is the one who downloads it, sets it up, manages the content, and decides whether to pay. Children are the audience, not the user. This reframe changed the safety model, the onboarding, and when we ask for money. I brought this back to the client in the week 2 readout and we agreed to redesign the brief before going any further.

2. The business model had to be defined before design started

Once we knew parents were the real user, the monetisation approach became clearer. I pushed for this to be agreed with the client before wireframes, not after. Two streams made sense.

Distribution was tied to physical product from the start: QR codes inside toy packaging, retail store promotions, and parenting blog partnerships. Every toy sold in a store was a potential app download.

3. Creation time had to be a design constraint, not a nice-to-have

Parents said 11 minutes was ideal for the full session. That meant story creation could take at most 2 minutes, leaving the rest for listening together. We set 90 seconds as a hard target and tested against it through every prototype round. This became one of the main constraints that shaped the builder flow.

How Might We…

• 1How do we make story creation fast enough to fit inside a family story session without it feeling like a chore?
• 2How do we show parents that the content is safe before asking them to sign up?
• 3How do we surface the physical toy at the right moment so it feels like a recommendation, not an ad?
• 4How do we time the subscription ask so it lands when the parent is most satisfied with the product?
• 5How do we build a feedback loop so the AI output gets better the more a family uses it?

Scoping Phase 1

After research readout I ran two FigJam sessions with the product and client team. The first was a full open brainstorm: AR toy scanning, voice cloning, social sharing, peer-to-peer story gifting, AI chapter sequels, all ideas welcome. The second was a prioritisation using an effort-versus-impact grid.

We cut AR scanning (high effort, value unproven), social sharing (moderation risk too early in the product's life), and parent-voice narration (moved to Phase 2 as a premium anchor feature). What stayed was the core ritual and we committed to doing it properly.

Flows and Early Structure

Once scope was agreed, I mapped all six flows as low-fidelity wireframes in Figma before any visual design started. The focus was on getting the logic right and aligning the team on what the product actually did. Walking through each flow with the client and product team early surfaced a few things that needed fixing: the builder had too many steps and was slowing the creation path, the subscription prompt felt too early, and the toy card needed a better home in the sequence.

Seven flows covered: Onboarding, Story end-to-end (home through to toy suggestions), Library, Shop, Profile and settings, Share and refer, and Feedback. Scroll horizontally inside each flow to see all screens.

Design Decisions and What We Learned

What this project shows

The most important work here happened before any screen was designed. Research changed the product framing, the business model clarity, and the creation-time constraint. All three of those shaped every design decision that followed. That is the part of this job that does not show up in screen mockups.

Background

In 2024, the client had already built a working image-generation demo. It was rough, but the output quality stood out. In internal comparisons against image-generation tools of that period, the model performed especially well on one capability that mattered for consumer adoption: preserving a user’s facial identity across stylised scene transformations.

That mattered because many image tools at the time could create flashy outputs, but they often changed the person too much. Faces drifted, features blurred, and the result looked like “someone inspired by you” instead of actually feeling like you. This model was much better at what the broader space often described as identity consistency or identity-preserving generation.

What made the technology different

The client’s internal team had benchmarked the demo against several image-generation patterns common in 2024: open prompt-based creation, generic avatar generation, and style-transfer-like transformations. While it was not the best model for broad artistic freedom, it was meaningfully stronger at maintaining identity cues such as face shape, eye placement, and recognisable likeness after transformation.

That gave us a sharper product angle. We were not designing a general image toy. We were designing around a specific strength: face-consistent scene generation for consumers who wanted to see themselves inside the result.

The product problem

The internal demo proved the model worked, but it was not yet a product. There was no clear browse layer, no onboarding, no strong expectation-setting around photo quality, and no thoughtful path from first success to paid value.

I reframed the challenge around three simple questions: how do we make first use feel easy, how do we make AI output feel trustworthy, and how do we turn one good result into repeat behaviour?

Research inputs

Because this was 0-to-1 product work, the research model was intentionally light but useful. I reviewed competing AI image apps, mapped their first-session journeys, and looked at where users were likely to hesitate: choosing a style, uploading a usable image, judging whether the output was “good enough,” and deciding if the app was worth paying for.

For the expected launch market, we designed around mobile-first users in urban European markets, with early adoption likely among younger adults, creators, and social-first users looking for quick self-expression. That made speed, clarity, and visual confidence more important than feature depth on day one.

Strategy

The most important call I made was to move away from prompt-first interaction and toward scene-led selection. On mobile, asking users to imagine and write the right prompt creates friction. Giving them strong visual scenes reduces blank-state anxiety and gets them to value faster.

From there, I built the journey around four clear stages: browse, choose, generate, and act. That gave the app a usable product loop instead of a one-time generation mechanic.

Key flows

Browse and scene discovery

I designed the home experience to explain the product visually. Categories like sports, fantasy, and historical moments made the model’s capabilities legible without forcing users to understand technical AI concepts.

Lightweight social proof like likes and saves also helped users feel that certain scenes were safer bets for a good first outcome.

Guided generation

Once a scene was selected, the app narrowed the task to a simple upload-and-generate flow. I kept the chosen scene visible throughout so people always knew what they were making and what kind of result to expect.

I also designed this flow to quietly educate users. Better source images create better AI outputs, so the UX had to guide people without making the process feel technical or demanding.

Result evaluation

The result screen was designed as a trust layer, not just a celebration state. Users could compare, save, share, regenerate, or discard the image, which helped the output feel reviewable rather than final.

This mattered because AI products earn trust when users feel they still have judgement and control after generation.

Premium flow

The premium flow was positioned after successful outcomes, not before them. I framed it around simple benefits users could understand: more generations, cleaner exports, faster processing, and higher-quality results.

That timing helped paid conversion settle at 4.8% in the first 90 days, which was healthy for a new AI image app in an early consumer market.

AI UX principles we followed

Suggested AI-specific copy and safeguards

• Upload hint: Use a clear front-facing photo for best results. Generated images may vary based on image quality and scene choice.
• Result disclaimer: This image was generated using AI and may contain visual inconsistencies.
• Share/export note: AI-generated image. not a real photograph.
• Privacy note: Ask permission before using another person’s face image and explain how uploaded photos are used.

What this project shows

This case matters because it shows how I work with emerging technology. I can look at a model demo, identify the real consumer value inside it, and design the product layer that makes that value understandable and monetisable.

It also shows that I think beyond the happy path. In AI products, trust, disclosure, and user control are not side details. They are part of the core UX.

The Starting Point

When I joined BeyondTheLoop, there was a partial Figma file functioning as a "design system" in the sense that it existed. Components had been created as needed. a button here, a modal there. with no naming convention, no token layer, and no documentation. Engineering had their own interpretations built sprint by sprint without a reference to check against.

The result was a product that looked almost right in most places, and slightly off in all of them. Inconsistent border radii on similar cards. Three different shades of the same "muted text" colour across screens. Buttons with the same visual intent but different sizes. None of it was broken. All of it added up to a product that felt unfinished.

The Problem in Numbers

The Brief I Set for Myself

This wasn't a client brief. it was a problem I identified in week one and proposed adding to scope. Three constraints shaped every decision:

• Buildable in parallel. Every new component I designed for a feature became a library component at the same time. No separate "system sprint."
• Useful without documentation. The founders were moving fast. The system had to be self-explanatory through naming and organisation alone.
• Token-first, not component-first. If the token layer was wrong, every component built on it would be wrong too. The sequence mattered.

How Might We

• 1How might we create a shared visual language that engineering can reference without needing a designer in the room?
• 2How might we build a system that scales from a team of one to a team of ten without a full redesign?
• 3How might we eliminate "which version is correct?" as a category of question entirely?

The Architecture. Tokens First

I started with the token layer before touching any component. Tokens are the vocabulary; components are the sentences. Getting the vocabulary wrong means rewriting every sentence later.

The Component Library. 24 Components in 8 Weeks

Built in parallel with feature design. Every component I designed for a feature screen was immediately standardised, named, and added to the library. 24 components across 6 categories, all interactive states documented.

Numbers, data, and UI shown are representative and do not reflect actual figures or proprietary information.

The Decisions That Made It Actually Get Used

What Changed

What I'd Do Differently

I built the library entirely in Figma. Engineering implemented it in code independently, using the Figma file as reference. The two stayed in sync only because I was active enough to maintain them manually. If I were doing this again, I'd push the token layer into a shared JSON file (via Tokens Studio) that both Figma and the codebase pull from. One source of truth, not two files that happen to agree.

What This Was Really About

Design systems are often presented as a gift from design to engineering. This one was built as an honest acknowledgement that the way we'd been working wasn't sustainable. BeyondTheLoop was a small team moving fast. The component library didn't slow them down to make things consistent. it sped them up by removing the decisions that didn't need to be made again.

The brief

Fearless Pharma had a hardware problem that was also a data problem. Their sanitiser dispensers were installed across hospitals and food industry facilities. but they were dumb. Staff refilled them on a fixed schedule, not based on actual usage. The result was predictable: dispensers running dry in high-traffic areas, or being refilled when they were still half-full. Neither outcome was acceptable in a healthcare environment.

The goal was to design a connected dispenser and an accompanying dashboard that gave facility managers real-time visibility. and gave them something to act on, not just look at.

Who we were designing for

Two users, one system, very different jobs to do.

The facility manager needed to see everything. usage patterns, refill alerts, dispenser status across multiple floors. without having to walk the building or chase staff. They wanted one screen that told them whether things were okay or needed attention right now.

The hospital staff and cleaning crew needed the dispenser itself to be frictionless. They weren't sitting at dashboards. They were moving fast, managing a lot, and the dispenser had to work the first time, every time. with no learning curve and clear feedback about when it was running low.

A third stakeholder shaped the constraints: hospital administrators who cared about compliance data, and procurement teams who needed usage reports for budgeting decisions.

What the research told us

We ran two tracks in parallel. ethnographic observation and stakeholder interviews.

For the observation work, we visited a hospital branch in Navi Mumbai, watching how current sanitisation processes actually played out: where dispensers sat, how often staff checked them, how refills got triggered. What we found was almost entirely reactive. There was no signal until something was already wrong.

The interviews covered hospital administrators, food industry managers, and cleaning staff. A few things came up consistently:

• Nobody had real-time visibility. Refill schedules were based on estimates, not data.
• Compliance reporting was manual and time-consuming. Staff were filling out paper logs that no one was acting on.
• In high-traffic zones. entrances, ICU corridors, canteens. usage spikes were predictable but completely unaccounted for.
• Trust in the data mattered as much as the data itself. If a reading seemed off, staff would default to visual checks anyway.

That last point shaped a lot of the dashboard design. The system needed to be accurate enough. and transparent enough about how it worked. that people would stop second-guessing it.

What we were actually solving

From the research, four design areas emerged clearly:

Three design decisions worth naming

01. Predictive refill over reactive alert

The first version of the alert logic was threshold-based. when level drops below 20%, send a notification. That's still reactive. We redesigned around usage rate: if a dispenser in ICU-B is depleting at 3× normal speed, the alert fires before it hits the threshold. The manager gets ahead of it, not behind it.

02. Floor-level view before unit-level view

Early explorations showed the whole dispenser inventory in a list. Facility managers don't think in unit IDs. They think in floors and zones. We restructured the dashboard hierarchy to match their mental model. start with the floor, drill into zones, then individual dispensers. Sorting by "needs attention" surfaced the right units first.

03. Export as a first-class feature, not an afterthought

Compliance reporting was an afterthought in the first dashboard wireframes. a small link tucked in the nav. After two rounds of stakeholder interviews, it moved to the primary toolbar. For administrators, that was the whole point of having the data. It needed to feel like a real workflow, not a data dump.

What the device needed to do

The dispenser interface had almost no real estate to work with. The key decisions:

• A full-ring LED indicator visible from a distance. green, amber, red. no text required
• A single press to dispense, no sensor calibration required from users after setup
• An audible low-level alert that triggered only during off-hours, so it didn't disrupt patient environments during the day
• All pairing and configuration handled by the admin app at setup. zero interaction required from staff after that

What I took from it

This was an earlier project in my portfolio, and it taught me something I've carried into every IoT or multi-touchpoint problem since: the hardware and software aren't separate design problems. The quality of the data the dispenser sends upstream determines what the dashboard can say. And what the dashboard can say determines whether anyone trusts it enough to act on it. They're one system, and they have to be designed that way.

The medical context also raised the stakes on every decision. In a sector where "it worked most of the time" isn't good enough, edge cases and failure states aren't nice-to-haves. They're the design.

The problem

Corporate had Slack, Teams, and Outlook. Retail had nothing.

Job News, HR updates, and CXO communications were being created but buried inside ServiceNow-fed resource sections that employees rarely navigated to. A survey across 12 stores found that 68% of retail employees had missed at least one critical work update in the past month. The content existed. A reliable surface to receive it did not. Connect was the only platform every retail employee opened every day, which made it the right place to fix this.

And then there was the search problem. Connect had two separate search modes with a dropdown to switch between them. The tool filter was the default. Almost nobody changed it. So when employees searched for an HR policy or a job opening, they got zero results and left. We dug into which keywords were failing and found 76% of them were resource queries. Employees were searching in the wrong mode and the platform was letting them walk away empty-handed every time, without any signal that something had gone wrong.

Research and discovery

Surveys, store visits, and competitor teardowns before any wireframe.

I ran two tracks before opening Figma. Employee research across 18 contextual interviews and a 400-person survey spanning 12 stores. And a competitor teardown of how Amazon, Walmart, Target, LinkedIn, Workplace from Meta, and Viva Engage handle feed architecture, posting, search, and engagement at scale.

Design decisions

The calls that defined Phase 1.

Information architecture

Before and after: how Connect's structure changed.

Stakeholder alignment

Three groups, three different definitions of success.

One of the harder parts of this project was that product, engineering, and internal comms each had a different idea of what the feed should do and what risks to avoid. I made it a point to use research outputs as alignment tools, not just design inputs. The survey data and content source map went into early stakeholder meetings before any wireframes, which moved conversations from "should we build this" to "how do we scope it right."

Craft and prototyping

Figma Make cut our feedback loops by roughly half.

I prototyped the feed consumption flow, the publishing flow, and the BlueLine search interaction in Figma Make using BRIX components. This let me put a realistic, clickable experience in front of internal comms teams within the same week as initial wireframes. Two of the four major design changes in Phase 1 came directly from those prototype sessions. Engineering confirmed scope and feasibility before high-fidelity was complete, which meant near-zero surprises at handoff.

For new patterns that Connect introduced, the post card, filter strip, publisher toolbar, and search answer display, I wrote component usage documentation for the BRIX team so these could be formalised into the system for Phase 2 and other teams.

What shipped and what is next

The situation

Push notifications are one of Best Buy's main levers for deals, offers, and service updates - directly tied to revenue and retention. By the end of 2024, opt-in rate was at 43%. The FY2025 target was 50%. Not a massive gap on paper, but 7 percentage points across a user base of that size is a lot of people.

The app already had nudges in 7 places. Only three of them - positions 1, 3, and 6 - were driving almost all of the opt-ins. Previous attempts to improve the other placements had consistently failed. The brief from Product: find new, high-intent, contextual moments to ask - especially for non-member users - without compromising privacy or user trust.

Why non-members

The baseline data revealed a clear segmentation gap. Members opted in at roughly 3x the rate of non-members. But this wasn't a user demand problem - it was a design and messaging problem. Members had already been primed through loyalty context and prior app engagement. Non-members were getting the same generic nudge with zero personal relevance.

Non-members were also the bigger opportunity by far: they represented around 70% of the eligible user base but only 13% of opt-ins. A focused 10-point lift in non-member opt-in rate - from 27% to 37% - would alone contribute 5 to 6 points toward the 50% target. That's where we focused.

An in-app survey of non-members added another layer. When asked what types of notifications they'd actually want:

• Saved Items Price Drop Notifications - 23%
• Flash Sale or Limited-Time Offer Alerts - 21%
• Gift Recommendations - 20.5%
• Customer Service Updates - 18%
• Personalised Shopping Suggestions - 7%
• New Product Launch Alerts - 5%

Price drops and sale alerts were clearly what non-members cared about. That shaped the copy strategy across every nudge we designed - lead with the specific value, not a generic "allow notifications" ask.

The Saved Items story

This is the one I want to spend the most time on - not because it worked, but because of what happened when it didn't.

The "Saved Items & Lists" page looked like a promising nudge location. Users had already shown intent by saving something. Our survey data backed it up - price drop alerts were the top thing non-members said they'd want. On the surface, the case seemed obvious.

Numbers, data, and UI shown are representative and do not reflect actual figures or proprietary information.

But when I looked at the actual conversion data, one number stood out: only 0.6% of users who added items to their cart from the Saved Items page went on to purchase. That's not a healthy funnel. Adding a nudge that encouraged users to hold off and wait for a price drop - which is what Product was proposing - risked making that number worse, not better.

My concern with the product team's proposal

The proposal was to show a nudge when users landed on the Saved Items page, prompting them to enable price drop alerts instead of removing items from their list. The logic made sense at a surface level. But I was worried we'd be actively interrupting users at a moment of purchase consideration and redirecting their attention toward a future event - which, given the existing 0.6% conversion rate, felt like pouring more water into a leaking bucket.

I pushed back. Not against nudging on this page entirely, but against nudging at the wrong moment within it.

What I proposed instead

Two more contextual triggers - both of which respond to something the user is actually doing rather than just landing on a page:

• Nudge when the user clicks "Edit" or tries to remove an item - that's the moment of highest relevance. "Don't remove this - we'll let you know if the price drops." The user is about to lose the item. The value of the notification is immediately obvious.
• Nudge when the user tries to exit the page - a soft exit-intent prompt, not an aggressive modal. "Your saved items will still be here. We'll notify you if anything changes in price." Low interruption, high relevance.

Numbers, data, and UI shown are representative and do not reflect actual figures or proprietary information.

Numbers, data, and UI shown are representative and do not reflect actual figures or proprietary information.

What actually shipped - and what happened

Despite the data and the pushback, Product moved forward with the on-load nudge on the Saved Items page. Their reasoning had more to do with roadmap momentum than user behaviour. The nudge went live.

By the end of Q1 2025, it had added roughly 5,000 new opt-ins - about 0.1%. And the 0.6% purchase conversion rate had dropped to 0.3%. Exactly what we were worried about. The business team pulled the nudge.

We're now pushing for the edit-intent and exit-intent patterns to be added back to the roadmap. They haven't shipped yet.

Numbers, data, and UI shown are representative and do not reflect actual figures or proprietary information.

PDP to GHP - what went live and worked

While exploring the Product Detail Page, we found a behaviour pattern worth acting on. After a user saves a product on the PDP and exits to the homepage, they're essentially done exploring for now - the homepage is their resting point. We confirmed this with CJA data: around 2 lakh clicks on the PDP-to-home path were ending the session, not continuing it.

That exit moment turned out to be a good place to ask. The user had just expressed clear intent - saved a product - and was pausing. A bottom drawer nudge offering deal alerts for that specific product felt timely, not intrusive. We A/B tested two variants: one with a "Not now" button, one with just a close icon in the corner. The close icon variant performed better - around 4% increase in overall opt-ins, adding roughly 3,000 new users in the first month. This one is live.

One thing we learned during testing: animated nudges, while visually interesting, added cognitive load at the wrong moment. A user who hasn't opted in yet is already evaluating whether to trust the ask - layering an animation on top of that made them hesitate, not engage. We kept the final design clean and static.

Sale event nudges - a glimpse

Seasonal sale events - Black Friday, Back to School, Christmas - see some of the highest app traffic of the year, with a significant portion of those users having push notifications disabled. We worked on a GHP-level nudge strategy for these events: a global opt-in for sale alerts plus a product-specific SKU carousel for users who wanted to track specific items. Both global and product-specific approaches were needed because a global nudge alone would miss users who didn't see anything they wanted, and a product-specific one would miss casual browsers. This is still in progress.

What I took away

The Saved Items story is the most useful thing in this case study - not because it's a win, but because it shows what happens when design intuition backed by data gets overruled by roadmap pressure. The nudge failed in exactly the way we said it would. That's not a satisfying outcome, but it's an honest one.

The bigger lesson: document everything when you have a clear, data-backed position. Not to say "I told you so" later - but because a documented hypothesis gives you the foundation to re-enter the conversation when things go wrong. That's how the edit-intent pattern is getting back on the roadmap now.

Note: All data and designs shown here are altered for NDA purposes. The process, decisions, and outcomes are real.

What BRIX is

BRIX is the design system built by Best Buy to bring consistency across products and reduce duplicated effort between designers and developers. It has four libraries: BRIX Enterprise (colours, typography, core components), BRIX Icons, BRIX Web, and BRIX Native. The team was set up as a direct investment from top management - hired specifically to build and maintain these systems at scale.

With that investment came accountability. Every quarter, the BRIX team needed to show the value it was adding to the business. For a while, the engineering manager had built a small internal tool that pulled from Excel sheets and generated downloadable reports. That worked - until the system started scaling fast enough that the business wanted something more visible and ongoing. That's what gave this project its start.

Where I came in

Suyash and Shivani had been leading the project for three weeks when I joined. By that point there was already an information architecture and a first draft of wireframes. My role was to come in, absorb the context quickly, and help push the design from a functional skeleton to something that actually communicated the system's value clearly - both visually and structurally.

Getting up to speed fast was its own challenge. I was new to the organisation, the BRIX team had their own terminology (much of it engineering-side), and there were tracking gaps on the design side - component reuse in Figma wasn't being measured the same way as code-side adoption. Getting everyone to agree on a shared language before designing anything was necessary and took time.

Numbers, data, and UI shown are representative and do not reflect actual figures or proprietary information.

What we were designing for

Two types of users, one dashboard. Top management needed a summary - adoption trends, ROI, system health at a glance. The BRIX Engineering and Design Managers needed something more detailed - which components had debt, where legacy usage was still high, where the team should focus next.

We aligned early on three design principles that shaped every decision:

• Content personalisation - surface the right level of detail to the right person
• Better data visualisation - replace static numbers with visuals that actually told a story
• Visual alignment with BRIX - the dashboard should look like the system it was measuring

Numbers, data, and UI shown are representative and do not reflect actual figures or proprietary information.

Ideation and early feedback

Time overlap between team members was limited - we were working across different schedules - so we ran structured feedback calls instead of in-person workshops. That constraint actually helped. Having to present direction on a call forced us to be specific about what we were proposing and why. The feedback we got early shaped a lot of the structure: unify the terminology around "BRIX Enterprise" rather than calling it "new" vs "old"; lead with positives for top management and keep the remediation detail for the operational layer; stop showing numbers that duplicated each other without adding insight.

Numbers, data, and UI shown are representative and do not reflect actual figures or proprietary information.

The design decisions that mattered

A few specific calls are worth naming because they changed the feel of the dashboard significantly:

• The circular volume visualisation for adoption rate was removed. It looked sophisticated but it didn't communicate change over time. A static donut chart tells you where you are - it doesn't show momentum. We replaced it with a trend-based view that made progress visible at a glance.
• The component table got richer. Not all components take the same time and effort to build - a complex data table is a very different investment than a button. We added a complexity and cost-to-build column so that leadership could see where the team was actually spending its time, not just count components as if they were equivalent units.
• Side sheets were restructured around browsing behaviour. The original layout put information in the order it was easiest to pull from the data, not the order a person would want to read it. We reorganised them so the most decision-relevant information came first, with supporting detail further down.
• Old repositories were removed from calculations. They were inflating certain metrics without reflecting current usage. Cleaning that out made the numbers more honest and the comparisons more useful.

Numbers, data, and UI shown are representative and do not reflect actual figures or proprietary information.

New screens

A few of the final screens - hover to pause the carousel.

What we heard back

This was an internal tool, so there were no hard metrics to measure against. But when we asked stakeholders after the handoff, the feedback was consistent: the dashboard made the system's value legible in a way the Excel reports never had. Top management could see adoption trends without asking the engineering manager to interpret the data for them. The BRIX leads could drill into component-level detail without switching between tools.

The broader win was less visible but more important: by designing the dashboard to align visually with BRIX itself, we made the case in the most direct way possible that the system was mature enough to be used - even for internal tooling.

What I took away

Dashboards are not summaries of everything - they're summaries of the right things. The earlier version of this dashboard tried to show all the data it could access. The version we shipped showed the data that helped specific people make specific decisions. That distinction sounds obvious but it's easy to lose when the data is complex and stakeholders have different needs.

The other thing: working in a team that started before you is a different skill than starting fresh. You have to absorb context fast, understand what's already been decided and why, and find the gaps worth filling rather than trying to redo everything. That's something I got better at on this project.

The Context

BeyondTheLoop was a European AI workspace built for teams who needed more than one model. Different tasks called for different tools. a long legal brief needed careful reasoning, a quick marketing draft needed speed, and anything touching EU customer data needed local German hosting. The product had the right answer for each situation. It just wasn't telling anyone.

When I joined in September 2024, the model selector was a plain dropdown. Five options. GPT-3.5, Mistral, Perplexity, ChatGPT-4o, and Claude 3.5 Sonnet. listed with no descriptions, no guidance, and no signal about which was right for what you were doing. The product was asking users to make a consequential technical decision with zero scaffolding.

The Problem in Numbers

These numbers came from PostHog session recordings and a scrape of in-product search logs. The business consequence was serious: the EU-hosted Mistral model. BeyondTheLoop's most defensible competitive advantage for GDPR-sensitive clients. had single-digit selection rates. Not because users didn't need it. Because they never understood it was there.

What I Needed to Understand

Before designing anything, I ran 6 short moderated sessions (30 min, remote) with existing users across different team roles to answer three questions.

Why weren't users exploring? Session recordings showed the pattern. users landed, saw the dropdown, glanced at it, and started typing. The dropdown wasn't a decision. It was a label. Nobody read it as a choice point.

What did users think the models were? The findings were consistent and humbling:

Three of six users worked in roles where data residency was a genuine compliance concern. None had selected the Frankfurt-hosted Mistral model.

What did users need to know. and what could we leave out? I tested a full technical comparison table. Five of six users found it overwhelming. One said: "Now I feel like I'm going to make the wrong choice." The goal wasn't to make users knowledgeable. It was to make them confident. Those are different problems with different solutions.

How Might We

• 1How might we help non-technical users make a meaningful model choice. without making them feel like the choice is something they could get wrong?
• 2How might we surface BeyondTheLoop's most differentiated offering (EU data hosting on Mistral) to the users who need it. without turning the interface into a compliance checklist?
• 3How might we give users who don't want to choose at all a path that feels considered. not like a default they got stuck with?

What I Explored

The Solution. LLM Choice Cards

Each model got a card. Each card had four elements, every one deliberate.

One Decision I'd Make Differently

I designed the cards for the selection screen. What I didn't redesign was the chat interface itself. Once a model was selected, it appeared only as a small label in the header. If you forgot which model you'd chosen mid-conversation, there was no ambient reminder. The cards solved the selection problem. The chat interface still treated the model as a setting, not a collaborator. That's the next problem to solve.

What Changed

What This Was Really About

Most AI product problems are framed as capability problems. how do we make the AI smarter, faster, more accurate? This one was a trust problem. And trust problems are always about the user's internal experience, not the system's external performance.

The five models were genuinely differentiated. The product was genuinely valuable. Users just didn't trust themselves to navigate the choice. so they didn't try. The design work was mostly subtraction: removing the intimidation, removing the wrong framing, removing the feeling that there was a correct answer they might miss. What was left was five cards, ten sentences, and a badge that said we thought about you before you arrived. That was enough. It moved the number.

Also From This Engagement

Three more things shipped in the same 8 weeks.

Numbers, data, and UI shown are representative and do not reflect actual figures or proprietary information.

The Problem

BeyondTheLoop's users could switch between five AI models. GPT-3.5, Mistral, Perplexity, ChatGPT-4o, and Claude 3.5 Sonnet. at any point in a conversation. The intent was flexibility. The reality was a silent failure: when a user switched models mid-chat, the new model started from nothing. No memory of the task. No memory of the context built over the last ten messages. The response was generic. The user had no idea why.

Session recordings in PostHog showed a consistent failure loop: user starts a complex task on ChatGPT-4o switches to Claude mid-way Claude responds without context user re-prompts in frustration session abandoned. The switch was invisible except for a small label change in the header. The consequences didn't appear until the next message. by which point the user had already decided something was broken.

The Problem in Numbers

Understanding the Failure

This was a state management problem wearing a UX problem's clothes. The technical constraint was real and fixed: cross-model context passing was not on the engineering roadmap for this sprint. The design couldn't fix the underlying limitation. It had to make that limitation honest and navigable.

I watched 14 session recordings of users who had switched models mid-conversation. Three patterns emerged every time.

How Might We

• 1How might we make context loss visible before it happens. not after the damage is done?
• 2How might we give users a way to carry context forward. even without full cross-model memory?
• 3How might we prevent accidental context loss without blocking users who genuinely want a fresh start?

What I Explored

The Solution. Three Components

The Detail That Changed Everything

The original spec had the summary auto-sending to the new model. no user review. Engineering preferred it. I pushed back.

Making the summary editable added one step and something much more valuable: the user's sense of authorship over the context transfer. In testing, every user who saw the editable summary felt more in control of the product than before the switch. That feeling. the system is helping me, not replacing my judgment, was the real goal.

One Decision I'd Make Differently

The modal triggers after message 3. In retrospect, that's too early. the context built by message 3 is rarely worth carrying. I'd move the trigger to message 6 or 7. The friction-to-value ratio improves significantly, and users who are genuinely mid-task are always past that point anyway.

What Changed

What This Was Really About

The technical limitation. no cross-model memory. was never going to change in this sprint. The question was whether the product would pretend it didn't exist or design around it honestly. The modal, the summary handoff, and the identity pill are all the same answer: be transparent about what the system can't do, and give users the tools to work with that limitation rather than around it.

Users who understand and control their context are more confident in the product than users who never had to think about it at all. That's not a consolation prize for a missing feature. It's better product design than the feature would have been.