Bespoke · First version of the app
A review of the first version of the Bespoke app: what we found, how it affects the member experience, and why a more consistent design approach was needed.
Read the findingsOriginal member app
Reviewed 23 September 2026
Based on the app’s screen structure and visual styles in source. The findings below concern that version of the app.
The first version brought together valuable capabilities, but the interface did not yet present them as one coherent product.
Personalised scanning, daily health guidance, family support, and a conversational companion were meaningful foundations. The main concern was how those capabilities were organised and presented: several competing priorities on the same screen, repeated routes to the same task, and different visual treatments across related features.
These were broader issues than a few colours or spacing adjustments. They affected the clarity of the product itself—where a member should begin, which action mattered most, and whether different screens belonged to the same experience.
Figures reported in the original review. *Up to seven tabs, depending on feature flags. Source counts describe the implementation and do not mean every element was visible at once.
Overall finding: the breadth of the product was ahead of the consistency of its interface. A clearer structure and a shared visual language were needed to make that breadth easier to use.
The original Home screen gave several features the prominence of a primary destination.
The review identified more than 17 content regions in the Home implementation, including daily guidance, tests, a journal, body information, biomarkers, scanning, and supplements. The Six Foundations board was added above existing content rather than becoming a single organising structure.
This made the intended daily experience difficult to read. Members were presented with a broad catalogue of capabilities before the interface had established one clear starting point.
Multiple prominent areas on Home weakened the distinction between the main task and supporting information.
Combined and mode-dependent names made destinations harder to interpret and recognise consistently.
Family, journal, wearables, and scanning appeared in several places without a clearly established primary home.
The colours below were found in the original app. They document the inconsistency identified in the review.
The source contained four palette definitions and 59 local colour objects. Related screens used different greens, golds, dark backgrounds, and status colours. In some cases, the same colour key referred to different values on different screens.
The issue was not simply the size of the palette. Colour did not have a dependable role throughout the app, so the visual identity and the meaning of interface elements changed from one area to another.
Distinct six-digit colour values found in the first version, across 159 screen and component files.
Existing colours under review—not a proposed palette.
Number of distinct six-digit colour values
of the distinct values appear fewer than five times in the source.
That is 274 values used fewer than five times. Together with the separate palette definitions, this points to fragmented styling. Low frequency alone does not make a colour unnecessary.
| Colour family | Distinct values | Source occurrences |
|---|---|---|
| Blue | 75 | 417 |
| Green | 56 | 885 |
| Red | 47 | 595 |
| Teal | 44 | 437 |
| Near white | 42 | 573 |
| Orange / ember | 36 | 430 |
| Neutral grey | 33 | 132 |
| Near black | 26 | 95 |
| Gold / amber | 15 | 78 |
| Violet | 14 | 192 |
| Pink | 12 | 26 |
| Total | 400 | 3,860 |
The count covers six-digit hex literals in app/**/*.tsx and components/**/*.tsx. Each distinct value counts once. Three-digit shorthand and 49 eight-digit values are outside this total. Occurrences measure declarations in source, not screen area, visibility, or importance.
The original implementation contained several overlapping treatments. This comparison shows why the experience lacked a consistent visual identity.
| Existing treatment | Surfaces | Accents |
|---|---|---|
| More Good Days | Cream & forest | Ember |
| UI tokens | Raised forest | Ember & sage |
| Food logging | Obsidian & cool dark cards | Gold |
| Six Foundations | Forest & bone | Brass & ember |
Specialist cards and membership screens introduced further variations. The concern was inconsistent application and meaning, rather than any particular hue being inherently unsuitable.
Several screens combined tasks with very different purposes, making simple journeys harder to follow.
This was visible in the structure of onboarding, scanning, health tracking, and account management. The interface frequently exposed the breadth of the feature set before clarifying the task at hand.
The flow combined personal details, health history, personality questions, and test offers. Clinical terminology appeared alongside conversational questions.
Why it matters The purpose of each step became less clear, and members were asked to consider several different commitments before reaching the core experience.
The Scan implementation included food logging, label and supplement scanning, family mode, questions, home detox, medications, and glasses settings.
Why it matters A direct camera task was surrounded by additional choices. The useful family-scanning capability was harder to distinguish within that broader collection.
Track combined sport reports, sleep, a journal, medical history, and extended fasting content. Profile combined account details, family information, membership, settings, and connected devices.
Why it matters Routine logging, specialist guidance, and account administration appeared at similar levels of importance, despite serving different needs.
Learn / Shop opened with Shop selected, while specialist topic cards used different visual identities. Membership presented five tiers in a dense comparison table with 11px cells.
Why it matters It was harder to separate educational content from commercial choices, or to compare membership options comfortably on a phone.
Inconsistent language, compact controls, and uncertain feedback made the interface less predictable.
The review found navigation labels at 9–10px, a 28 × 28px information control, and a type system in which 12px was the most common declared size. These are source measurements; their practical impact still needs to be checked on real devices.
These explanations describe the original labels. Members had to learn internal product terms before understanding familiar tasks.
Some Ask actions included an intentional 300ms delay before opening. Readiness updates could remain pending for up to 35 seconds in the source logic. Home could also snap to the readiness ring after a scroll.
These patterns risk making the interface feel unresponsive or moving it away from the member’s chosen position. Loading, error, and empty states varied by screen rather than following a shared pattern.
These are behaviours identified in the source review, not measured average response times.
Small text, frequent heavy weights, and varied corner radii made it harder to distinguish headings, controls, and supporting content.
Status colours also appeared as decoration. Where colour alone carried a status, its meaning was less accessible and less dependable.
Hardcoded insight fallbacks risked obscuring the difference between personalised information and content displayed when data was unavailable.
Emoji, text symbols, and icon components coexisted. Repeated cards and controls did not consistently share the same visual treatment.
The first version contained useful product ideas, but the interface did not give them a clear, consistent expression.
The findings explain the move towards a calmer look and feel: fewer competing visual signals, more readable typography, clearer grouping, and a palette with defined roles. Each addresses a specific inconsistency found in the original version.
Visual refinement alone would not resolve the full picture. Repeated journeys, changing labels, and unclear product boundaries also required attention. The review therefore established a need for both a more coherent interface and a clearer structure.
This report records that assessment of the first version. It is not a specification of the new prototype or a proposal to reuse the colours shown above.
For a closer look
This report draws on the structural and visual-system review dated 23 September 2026. The observations below preserve its full set of 55 findings, grouped into practical areas of work. Each entry records an observation from the first version, with its implication or corrective guidance. This was a source-based review, not a member usability study.
Scope and method. The underlying review examined member-app screen and component source, plus compiled web styling. It was not a signed-in TestFlight review. Reported source counts include 60 routes, 99 components, four palette definitions, and 59 local colour objects. The colour breakdown comes from the supplied inventory. Counts have not been independently rerun against the original member-app repository.
Reading the evidence. A code declaration may belong to a conditional or inactive view. File size and route count provide maintenance context; they do not establish runtime performance or what every member sees. The navigation diagram is a schematic of the original app, not a screenshot or proposed replacement.