Gavin Colwill — Product Designer
Product designer with 15+ years’ experience turning complex problems into research-backed, user-centred solutions. Case study detail below.
Sedex SMETA 7
Smeta 7 — Audit Launch
SMETA (Sedex Members Ethical Trade Audit) is the world's most widely used social audit methodology. Sedex's platform supports over 100,000 organisation members and 120,000+ registered supply chain worksites, with more than 450,000 SMETA audits completed historically across all versions.
SMETA is Sedex's largest revenue-generating product – the standard the business is built on. I was given ownership of the design for its biggest update – launching SMETA 7 on platform.
Background
SMETA 7 introduced more data points and categories than any previous version — new areas including Management Systems and Workplace Requirements, restructured sections, and more complex sequencing than the platform had supported previously.
More structure meant more room for a user to lose track of where they were, or make an error that wasn't visible until much later in the process. The risk was the completion rate and completion speed would drop as complexity went up.
My role was to design the platform experience, protecting the two KPIs that mattered most, while giving auditors a clearer picture of a more complex process than they'd worked with before.
Discovery
I mapped the current flow across all variants and user types — auditors supported by admins, buying teams booking audits, suppliers responding to corrective actions — alongside the legacy audits still running through the new methodology. I spoke with subject matter experts on what SMETA 7 actually changed, and with practicing auditors on where the existing platform caused friction. I watched Hotjar recordings to see where users dropped off, rather than relying on assumption.
The added complexity made one thing clear early: the platform needed clearer signposting. Users weren't going to fail because the new categories were hard — they were going to fail because they'd lose track of where they were in a much bigger process.
That insight led to the progress tracker, tested with stakeholders and customers through a wireframe prototype.
The approach
Users needed to always know what was complete and what wasn't. Research showed auditors filled in forms non-linearly, from scraps of information that arrived over time. Auto-save let them add as information came in; progress bars showed where that left the audit as a whole.
Autofill pulled in data we already held — company details, numbers, staff counts — rather than asking for it again, directly serving the completion-speed KPI.
Design
Redesigning the landing screen.
I built the progress tracker into the existing landing screen, keeping what auditors relied on. A card-sort session established what earned its place — and surfaced a fix: auditors search by company number but had no way to copy it. I reprioritised the screen around actual use, then designed in the tracker.
Category pages showed complete / in progress / not started at a glance, feeding back into the overall tracker.
Order, confirmation, guidance.
Sections were enforced in sequence, with copy explaining why. Toasts confirmed every save — silent failure isn't acceptable in a compliance tool. Gainsight triggered a guided walkthrough on first visit, and a toggle gave users control over sensitive data.
Cross-referencing, built for real use.
Two new areas needed side-by-side comparison. With 90% of users on large desktop monitors, "open in new tab" was the right low-cost V1, with a comparison view scoped for V2.
Redesigning the CAPR report
Auditors used the CAPR report as much as the platform, for numerous reasons, including a lack of confidence in discoverability — yet the existing reports were also failing. Running to 80+ pages with no real structure, users got lost and struggled to share what they needed downstream.
I stripped the content back and reordered it based on sessions run in small groups to keep feedback focused. I added a navigation menu and embedded hyperlinks so users could jump straight to what they needed — a deliberate bridge to rebuild trust while confidence in the new flow was still growing.
Iteration
Simplifying the category panel.
The initial version listed SMETA categories individually to the point of cognitive overload. I restructured so company details sat embedded under the progress bar rather than competing with it — one clear path to completion, not a flat list to interpret.
Rebuilding the logic around a late scope change.
Comments on Management Systems were originally optional and had no effect on the progress tracker. Late in the project, SMEs ruled they were required for the full SMETA report but not the CAPR — so a section already marked "complete" for CAPR could no longer be marked complete overall. I reworked the tracker logic so those sections reverted to "in progress" with a note explaining why, so the change never read as a bug.
A deliberate trade-off
Not every legacy pattern was replaced. The platform's stepper component was already being misused — too many categories forced scrolling — and was deeply embedded across the legacy forms build, well beyond this launch's scope.
Rather than patch a component that needed a proper rebuild, I left it as-is for this release and scoped its replacement into the upcoming AXIS design system, where it could be solved properly rather than papered over under deadline pressure.
Principles in practice
A few core UX principles ran through every decision:
Familiar patterns (Jakob's Law).
The landing screen, CAPR structure, and navigation stayed close to what users already knew. Trust in a compliance tool comes from consistency, not novelty.
Progress motivates completion (the Zeigarnik effect).
Watching a section move from "in progress" to "complete" gave users a reason to keep going rather than abandon a long process partway through.
Progressive disclosure.
From the 80-page CAPR to the landing screen, the principle held: show the minimum necessary at each point, not everything at once.
Accessibility, scoped honestly.
The legacy build limited what could be rebuilt from scratch, so I had the interface tested with a screen reader to catch the most critical issues, and designed the dashboard with a deliberate eye on its future move to fully responsive. Deeper accessibility work was scoped into the AXIS rebuild that followed, where it could be done properly rather than half-done within the old constraints.
Testing
Testing ran in two groups, set up by our research team.
Unfamiliar users first.
People with no prior exposure to the product or industry were given simple, guided tasks, with a focus on CAPR completion, downloads, and whether the instructional messaging made sense without prior context.
Then the real users.
The same core tasks were tested with practicing auditors, admins, and in-house subject matter experts, to validate the flow against real domain expectations.
Sessions were kept small — around 5 people — because larger groups became a liability: quieter participants got talked over, and sessions risked being hijacked by unrelated frustrations.
The clearest finding across both groups: progress bars motivated completion, and testing directly shaped decisions — including the category panel simplification and the Management Systems comment logic.
Stakeholder alignment
Design decisions on a project this size weren't made in isolation.
The PM and I had to push for the progress tracker itself — engineering was initially against the length of build it required. Including the tech lead in usability testing, and letting them see the friction firsthand, moved the decision forward.
The one real sticking point was the late change to Management Systems comment behaviour. The PM and I pushed back against the SMEs on the timing, but it was non-negotiable. I redesigned that part of the flow so users understood the change, and the SMEs were confident it communicated clearly.
Outcome
Robust analytics was still being built out at this point, so I can't point to precise before/after figures. What I can point to is direct, unprompted feedback: our research and sales teams received positive reactions to the new dashboard, and the redesigned CAPR report landed well — users could now navigate and trust it in a way the old 80-page document never allowed.
One honest distinction: SMETA 7 genuinely takes longer on-site — auditing internal management systems in depth rather than a point-in-time check — and that rigour was never something the platform could design around. What the platform did do was speed up everything downstream of the site visit, because auditors were working from a structured, guided flow rather than long-form narrative text.
Given the stakes — the business's largest revenue product, on its biggest update in years — auditors actively preferring the new experience was the clearest signal the launch had done its job.
Reflection
The strongest signal came from how consistently this landed across every type of user, not just one. Auditors, buyers, and suppliers all used variants of the same interface, and our research team's follow-up interviews were consistent: positive reactions to the clarity and structure, not just from the group I'd designed most directly for.
That reach turned the audit dashboard into a guiding principle for the Buyer Proposition work that followed, where the same core idea had to adapt across user types rather than being redesigned from scratch. The approach held: simplify data down to what's actually needed (Hick's Law), and lean on familiar patterns over novelty, so trust carried across variants.
My one real disappointment was never getting to shadow a live audit — everything I learned about that side of the job came second-hand, like the fact that auditors can't use laptops or mobiles in factories, only tablets without camera access. Valuable, but not the same as seeing it myself.
AXIS
Axis Design System
I was brought in to lead a ground-up transformation of Sedex's design system – realigning it with the new brand and supporting the launch of the Buyer Proposition initiative. This case study covers the vision, process, and outcomes of that work.
Background
Sedex had a problem. Customers were driven across two separate platforms to access their information, and the legacy platform's running costs had become unsustainable. The existing design system had failed on almost every dimension — poor accessibility, no responsive behaviour, and typefaces unsuited to a data-heavy product.
Customer feedback was clear: competitors were rated as simpler and easier to use, despite offering a fraction of Sedex's data depth. The platform was getting in the way of its own product.
The business was approaching a significant acquisition, and investors had directly raised questions about the platform's future. The relaunch needed to demonstrate not just usability, but a credible, investable vision for where the product was going.
My role was to develop the vision for the new platform and design system, and deliver it within the project timeframe — running alongside the Buyer Proposition strategy relaunch.
The Existing Platform
The two platforms meant a fragmented experience, built on an ageing design system with no responsive foundation: complex tables didn't adapt to smaller screens, and there was no keyboard control or accessibility support. Typography was poorly suited to data-dense screens, colour usage failed accessibility standards, and navigation offered little clear hierarchy or tailoring by user type.
For customers managing complex global supply chain data, the platforms were hindering the work rather than enabling it.
North star
Before a single component was built, we created a north star vision to align stakeholders and build momentum — calibrated for an executive audience: clear vision, light on detail, heavy on direction, supported by a conceptual prototype.
The timing was contested. The legacy platform's decommission had a fixed deadline, and there was real resistance to replacing the design system at the same time. But the counter-argument was simple: if we didn't do it now, we never would. A hard deadline was the only forcing function we'd get. We made the case, got the buy-in, and moved forward.
AXIS Design System
The pillars I set for the new design system and platform refresh:
Visual and system
Brand alignment without compromise
— adopting the new Sedex brand while protecting semantic colour logic.
Responsive by default,
with a phased rollout bringing legacy screens in line as initiatives allowed.
Integrated data visualisation
— replacing Thoughtspot with our own Highcharts-built layer, with usage guidelines for colour rules and chart selection.
WCAG 2.1 / EAA compliance
across colour contrast, keyboard control, and beyond.
AXIS Design System — Strategic
Surface what matters
— prioritising key information on the dashboard, reducing time spent hunting for what users needed most.
Clear, human language.
The platform was dense with acronyms and jargon, so we introduced a clear language principle across every touchpoint — authoritative yet approachable.
Faster data access,
replacing a process that meant hopping between screens and long wait times.
Smarter global navigation
— a sidebar tailored to individual user types without compromising screen real estate.
Guided onboarding and intuitive patterns
— Gainsight-powered onboarding and clear signposting, leaning on recognisable conventions (Hick's Law) to lower cognitive load.
Component Architecture
The next challenge was scoping what needed to be built. Working with the pods, I sketched out the early buyer proposition flows and identified which components were needed and what could be reused — the foundation of the component inventory.
We chose headless components, giving flexibility across multiple libraries and reducing dependency on any single framework. I then T-shirt sized the full component list with our front-end leads, stress-testing scope against deadline and resource.
Selling the Vision
While the new flows were in development, sales needed something tangible to show customers. The removal of Thoughtspot and consolidation of platforms was causing anxiety among long-standing users — and these weren't small accounts. Sedex's customer base included some of the largest organisations in the world, so managing confidence during the transition mattered enormously.
I built a Figma prototype of the new journey that sales could use as a tap-through demo or export as a video walkthrough — shifting the conversation from what was being taken away to what was coming.
Building the System
With the architecture scoped and sized, we moved into the build. The core library covered the full range of interaction patterns the first iteration required — selectors, tabs, tables, filters, buttons, form elements. Particular care went into risk profile communication and the interactive scrollable tables and filters, which needed to perform across a wide range of screen sizes and data densities without sacrificing clarity.
Data Visualisation
Replacing Thoughtspot meant owning data visualisation entirely. After researching available libraries we landed on Highcharts, for the flexibility and performance the platform needed. Alongside the integration, we built comprehensive usage guidelines — colour rules, chart selection logic, and governance for how visualisation should be applied consistently across the business.
Roll out and testing
The rollout was phased. Colour palettes and typography switched across legacy screens first, bringing visual alignment quickly while full component replacements followed as initiatives allowed — keeping the deadline achievable without compromising the build's integrity.
Testing was embedded throughout with small customer groups, and as launch approached we ran a large-scale usability workshop. Participants from both the Sedex customer base and internal staff completed defined tasks across the platform, surfacing friction across global navigation, core buyer proposition journeys, and the broader design. We were deliberate about including people with accessibility needs — testing keyboard control and screen reader behaviour in real conditions.
Findings fed directly into a round of iteration and bug fixing before launch.
Outcome
The legacy platform was decommissioned on schedule, consolidating two platforms into one and eliminating the annual running costs. The new platform launched fully accessible to WCAG 2.1 and EAA standards.
Mobile and tablet usage increased measurably as users could finally access the platform effectively across devices. Feedback from some of the world's largest organisations was overwhelmingly positive, with particular praise for usability, simplicity, and data visualisation.
The relaunch laid the groundwork for continued improvement — resolving edge cases, introducing card format for mobile tables, dark mode, and a drawer slide-in pattern for filters that had been overloading page layouts.
Shortly after the relaunch, the acquisition completed successfully — with the platform's transformation playing no small part in demonstrating the product's value to investors.
Amazon
Ask Alexa — eLearning Platform
Amazon wanted to reach individual retail staff selling on shop floors worldwide, equipping them to recommend Amazon over competitors. An existing platform was little used and light on product information. We were commissioned to design and build a new responsive learning platform for Amazon's Alexa product family, Ask Alexa — Amazon's first time outsourcing a build of this kind.
I led UX and product design from concept through launch, working across three companies: Iris as creative and product lead, Synergy Learning building the underlying Totara platform, and Amazon's own sales, brand, and product stakeholders. The platform launched across five EU markets, then expanded into the US, Canada, Mexico, Australia, New Zealand, and Brazil — built to support 300,000 users with multilingual capability across device types.
The problem
Interviews with sales associates and managers, surveys, and observational studies of real sales-floor interactions converged on a specific, costly problem: associates often couldn't articulate Alexa's technical features clearly enough to customers, and that gap was translating directly into lost sales. This wasn't a training-satisfaction problem — it was a revenue problem, and that shaped everything that followed.
Learning is king
Retail staff didn't know Alexa well enough to sell it. Everything the product did had to close that gap — if a decision didn't help someone start or finish a course, it was noise, whatever else it offered Amazon.
That held under pressure. When Amazon's product stakeholders wanted the homepage to carry company updates and brand content, we pushed back and kept it built around one job: getting someone into a course. The lead module — telling a user at a glance whether to start or resume — existed for the same reason: across hundreds of product families, orientation was the difference between a personal learning path and a catalogue nobody finished.
What the research actually changed
Courses were grouped into product families (e.g. Echo) rather than one long list, to stop users being overwhelmed by the full catalogue at once — a decision made after research into how people wanted to navigate the content. Gamification — badges, progress tracking, a badge wall showing certifications still to earn — was included because research showed real demand for a way to track progress, not as a default engagement gimmick.
Giving the Amazon team a way to build their own content
Part of the brief was building the platform so Amazon's own team could manage large areas of it — creating and updating learning content — without depending on the agency for every change. That meant handover and training on the system as part of delivery.
Design system: built lean, scoped to grow
Rather than build a full design system for an MVP launch, I created a foundational style guide, colour palette, responsive type scale, and WCAG-compliant contrast standards — structured on Totara's framework so it could scale into a proper atomic design system once the product had proven itself.
Art direction
Colour palette and typography stayed aligned with Amazon's core brand, but the illustration style was built in-house with an illustrator and a learning content designer, creating characters and scenarios that reflected Amazon's inclusive principles rather than generic stock-style graphics. I also designed the Ask Alexa marque, signed off across the business before launch.
We chose illustration over photography deliberately: Amazon's hardware updates on a cycle photography can't keep pace with, and a new Echo or Fire variant can date a product page within months. Illustration let the visual language represent the product category rather than a specific device generation, holding up as the hardware line moved on underneath it.
Content, tested before it was built at scale
I worked with a content designer to shape the learning content and its illustration, sketching storyboards early and testing them with a sample of users before committing to the full build-out. We tested two approaches head to head — product-spec courses (learning Alexa's features directly) against scenario-based courses (e.g. how to cook using Alexa). Scenario-based content consistently outperformed on completion and comprehension, so we shifted the course structure to lead with scenarios, using them as the vehicle for the product knowledge underneath.
Results
The platform launched across five EU markets as a pilot, then expanded to seven more based on performance. Registration data was designed to let Amazon trace engagement back to individual users, stores, and retail groups, so the business could eventually connect learning activity to sales impact — though that link was still unfolding by the time I left Iris. Ahead of my departure, my team and I continued refining the product and building out in-platform marketing and rewards features.
Guinness Storehouse
Guinness Storehouse — Platform Transformation
We were tasked with pitching for the digital transformation of the Guinness Storehouse website. The brief asked for three things: bring the "magic" of the physical Storehouse onto the site, boost engagement, and simplify a booking process that was losing customers along the way. Whatever we designed also had to work across the wider Diageo ecosystem and partner brand sites.
The pitch
Research going into the pitch was limited, but it pointed clearly at a set of problems: navigation was hard to follow, the booking system offered no way to personalise a visit, cross-selling and bundling didn't work (a personalised pint glass couldn't be added to a basket alongside a booking), ticket sales had no momentum before the visit date, the Storehouse's archives sat unused, and the site skewed toward traditional beer enthusiasts rather than the broader audience the brand actually wanted, including younger visitors, women, couples, and families.
We simplified the information architecture down to three sections: Plan Your Visit, Explore, and What's On. Without stakeholder input at this stage, the priority was making sure the most important information was easy to find, cutting the duplication and misplaced content that had built up over years.
Three booking routes
We treated the booking journey as three routes rather than one, a quiz-led path for people who wanted guidance, an express path for people who already knew what they wanted, and a standard path in between, all converging on the same confirmation screen with a personalised pint glass upsell built in.
Staying close to the brand
We also stayed close to the existing Guinness brand guidelines rather than inventing a new visual language. Without stakeholder input on how far those guidelines could stretch for the Storehouse specifically, the safer route was to keep the brand fonts and colour palette, strip back some of the more intricate patterning, and put the distinctiveness into the interactions instead. The existing site's imagery was part of the problem too. It leaned on empty, static shots of the space that didn't capture what actually makes a visit good, so we set content principles that prioritised people enjoying the space over the space itself.
Moments of magic
Within that, a few specific moments of magic. An AR filter for the Stoutie experience, so visitors could try poses before their visit. An interactive timeline for the archives. Hover states on desktop that turned static photography into short video, giving a glimpse of a space without giving it all away.
Result — Pitch Win
"We were incredibly impressed with everything you crafted, especially considering the limited data and research available. Your streamlined navigation aligns perfectly with our vision, offering a refreshing departure from years of patching and fixes. Most notably, the design captures the moments of magic flawlessly. Your work not only aligns closely with our brand guidelines but also demonstrates a keen understanding of reusable modules, making it a perfect fit for our objectives."
Post pitch: from concept to build
We moved into a longer phase working directly with the Storehouse team, Diageo's product team, and BA, aligning the initial concepts on two fronts at once, strategic direction and product feasibility.
That meant reconciling our designs with Diageo's existing component library: working within modules that already existed where they held up, and submitting new ones where the UX genuinely needed something the library didn't have. We defined art direction guidelines to keep that consistent as more people touched the work. This phase also tackled real UX problems the existing booking journey had, flexibility to amend a booking, bundling and upselling, a faster path for walk-up visitors, working within technical constraints on the payment integration. From there we locked final architecture and content, then moved into interaction design and QA.
Folio
Folio — AI-assisted stock research
I'm trying to build a portfolio on sound decisions in the middle of an AI gold rush, where every name is being re-rated on narrative as much as numbers. I research it the way most people do: too many tabs, no single view, and no way to tell signal from noise. News, charts, fundamentals, and a calendar all live separately, and nothing tells me when to look, only what happened after I already missed it.
I'm also the user, not a persona. Every decision in Folio is tested against my own behaviour: how I actually research a stock before buying, how much AI reasoning I trust versus want to verify myself, how much notification noise I'll tolerate before switching an app off.
Background
Financial tools tend to sit at two extremes. Retail apps are built for transaction speed, not research depth. Professional terminals offer real depth, priced and built for full-time traders. There's very little in between for someone who wants a considered AI-assisted second opinion, without either the interface being dumbed down or the subscription pricing them out.
Folio sits in that gap. It compresses the research I already do (news, fundamentals, technicals, sector context) into one place, and uses AI to flag when something in that mix has shifted enough to be worth my attention.
Approach
I started from the workflow, not the feature list. Before any screen was designed, I mapped my own actual pattern of checking stocks: a morning scan of movers, occasional deep dives when something's flagged in the news, an unreliable mental calendar of upcoming earnings, and a habit of typing out a stock's thesis to an AI chat window before deciding anything.
That last habit turned out to be one of the most important product decisions in the whole build.
Signal logic — trend and context
The most demanding part of Folio isn't the interface, it's the logic underneath it. Early versions used the obvious indicators (RSI, MACD, basic volume spikes), and the results were exactly as unreliable as you'd expect. Those indicators are common because they're simple, not because they're sufficient.
ADX gates confidence on every directional signal, trusting them in a real trend and downweighting them in a choppy one. Relative strength compares a stock's move against its own sector average rather than in isolation, so a 5% gain against a 6% sector move reads correctly as underperformance. Anchored VWAP and price structure add further confirmation, and every signal resolves to a confidence score with a plain-English rationale attached, never a bare number.
Signal logic — entries, exits, and a long-term lens
Folio is built for a Stocks and Shares ISA: long-term positions, no shorting, no stop-loss. Volatility is used to time entries, not to trigger exits.
Quiet volume accumulation flags sustained above-average volume without a matching price move, often the earliest tell before a stock moves. A tightening range (volatility contraction) times an entry window rather than an exit. For early setups, Folio suggests a staged entry: a small first tranche, with further tranches gated behind a confirmed trend, protecting limited liquidity from a full-size guess on an unconfirmed thesis.
Signal logic — reframing the sell signal
Because this sits inside an ISA with no shorting or margin tools, the exit side of the model was scoped deliberately. Rather than a traditional sell trigger, Folio runs a trim-on-strength and buy-the-dip logic built on the same inputs, aimed at growing a position over time rather than exiting it outright.
After-hours price and volume are weighted low by default, since thin liquidity makes them unreliable, but weighted up specifically in the window right after a scheduled catalyst like an earnings release, where they briefly become a genuinely useful early read.
Radar
Every signal above assumes a stock is already on a watchlist. Radar exists for the opposite case: stocks I haven't thought to look at yet, but which are showing the early shape of a move. It runs the same signal inputs across a wider universe than my own watchlists — a scheduled market data API sweep across the index, with the indicator layer computed from raw price and volume, then an LLM pass (Gemini) to summarise why each hit surfaced in plain English.
Radar is kept visually and structurally separate from curated watchlists, so an AI suggestion is never mistaken for something I've already decided to track. One tap moves a Radar stock into a proper watchlist if I want to follow it further.
Mechanically, Radar runs on a scheduled sweep rather than live streaming, which keeps API cost predictable and matches how I actually use it. A market data provider supplies raw OHLCV for the index universe; the indicator layer (ADX, ATR, relative strength against sector, anchored VWAP, volume versus its own 30-day average) is computed from that raw data rather than pulled from a paid indicator endpoint, so the logic stays auditable and provider-agnostic. Each candidate is scored against the same confidence model as a watchlist stock, then an LLM pass writes the plain-English reason it surfaced, from the computed values rather than from free interpretation of the chart.
Chat with Gemini
I already talk through stock decisions with an AI chat window in text before I act on them. Folio embeds that same chat surface, provider-agnostic in architecture but running on Gemini by default, with read access to my existing portfolio and watchlists as context.
The harder problem was turning conversation into action without it feeling like a form. Saying "add that one to my EV watchlist" requires the model to look back through the conversation, identify the correct ticker, and confirm before writing anything.
Earnings calendar
Knowing an earnings date exists and actually remembering it on the day are different problems, and the second one is the one that costs money. Folio pulls every held or watched stock's upcoming earnings date into a single diary view, with configurable alerts a week, a day, or an hour out.
Each entry also surfaces how the stock reacted on its last four earnings prints, so the alert comes with context, not just a date.
Privacy
I want to use this in coffee shops and in public, and a live tracker showing real holdings and real numbers is not something I want legible over my shoulder. Rather than treat that as an afterthought, I designed for it directly.
A blur treatment sits over specific values (holdings, position sizes, £ amounts), toggled at the user's discretion rather than applied as a screenshot hack, so the interface, hierarchy, and interaction design stay fully usable while the numbers stay private.
Desktop only
Folio's first version is scoped to desktop deliberately, not as an oversight. My own usage pattern for this kind of research is sat at a desk or in a coffee shop, cross-referencing charts, news, and calendar together, not glancing at a phone between meetings.
Building a considered desktop experience first, rather than a compressed mobile-first one, let the information density and premium feel of the interface come first. Mobile is a future scope decision, not a first-version requirement.
Look and feel
The visual direction is a restrained monochrome system, near-black to soft off-white rather than pure black and white, with Inter Light carrying the primary typographic voice. The monochrome base exists so semantic colour, buy, sell, watch, and notifications, reads instantly and clearly against it.
Colour is reserved almost entirely for those signal states. In a product built to cut through noise, the interface had to model that same discipline.
It is deliberately basic and unpolished at this stage. Until the signal logic and the API integrations are properly tested, visual refinement would be effort spent on something the underlying model might still change.
Trade-offs
Every additional signal input made the model slower to compute and harder to explain in one sentence. I chose trust over speed throughout: no signal ships without a plain-English rationale, even where that meant simplifying which inputs made the cut.
Building a provider-agnostic AI layer from day one, rather than hardcoding Gemini, added real overhead for a first version built for one user. I made that trade anyway, since locking a personal tool to one vendor's roadmap and pricing felt like a decision I'd regret later, not one I'd regret now.
Status and next steps
Folio is currently in build, moving from design into the signal-engine and data-integration phase. The remaining decisions are largely technical: choice of market data provider, since commercial licensing terms differ meaningfully between personal and multi-user access, and whether the indicator layer runs on a paid API or is calculated directly from raw price data.
Reflection
The most useful constraint on this project was being both the designer and the only user. It removed the temptation to design for a hypothetical audience's edge cases, and forced every feature to answer one question: would I actually trust this enough to act on it.
Radar exists because I kept missing early moves. The staged-entry logic exists because I have limited liquidity and one bad full-size entry is a real cost, not a hypothetical one. That's a harder bar than designing for a persona, and a more honest one.
