Product designer & builder · user research to working product · part-time, employed or freelance

Courtney Brown

I find out what people actually need, then design and build it. I work across both halves of the double diamond. My research case studies show the first, most fully my student housing study: discovering and defining the right problem, from brief to recommendations. My own venture, a music marketplace in private development, shows the second: developing and delivering the solution. I designed the user experience and interface for every side of it, then specified, built and tested the platform behind it, from payments and third-party integrations to release management and security.

It comes from my move from fashion creator markets into music creator markets. I followed the outcry over how little artists earn from streaming, then ran my own unfunded investigation into what makes music careers hard to sustain, for artists and the professionals around them. Since learning formal user research in 2025, I'm putting the venture through the structured discovery it didn't get at the start, using the method behind my studio, Fruityard.

cspacebrown@outlook.comCardiff · remote
Case studies · newest first

A trail of work, 2014 to now

From engineering, through retail and the music industry, to formal user research. Numbered in the order I did them.

Product
Theme

2025 – 2026

Case study 09 · 2024 – 2026 · venture design · Define to Deliver

Fruityard: a venture studio that tests before it builds

New founders rarely get proper discovery before they build. The overview: why a studio and an academy, what's built, and what I changed. The two services each have their own case below.

Read the case study → · 5-minute read

Case study 09a · 2024 – 2026 · service design · Define and Develop

Fruityard Studio: selling the test before the build

Five services as small cases: Discovery, ad prototypes, free planning tools, the Room Fit Review and the later stages. Includes a working demo of the new break-even calculator.

Read the case study → · 5-minute read · Try the calculator →

Case study 09b · Oct – Nov 2026 · learning design · Develop

Fruityard Academy: from seven course ideas to two pilots

How the courses were ideated from the roles in a real client project, which five I held back, and why two became pilots.

Read the case study → · 4-minute read

Case study 09c · Oct – Nov 2026 · learning and service design · Deliver

Creative Director course: an ad competition that asks for evidence

A student ad competition for a real client, redesigned so teams prototype with AI, test on 10+ real people and pitch what they learned. Testing carries as many marks as the idea.

Read the case study → · 5-minute read

Case study 09d · Nov 2026 · learning and service design · Develop

UX Researcher course: paid research on a problem I'd already found

My student housing study becomes a course: postgraduates learn the method on it, then run paid, supervised reviews of student housing. Demand is being tested with seven audiences first.

Read the case study → · 5-minute read

Case study 09e · Oct – Nov 2026 · service design · Develop

The studio's first sector: music businesses

Labels, promoters, record shops and new founders, each with a free tool, a self-serve plan and a full Discovery. Housing and games are the next sector cases.

Read the case study → · 4-minute read

Case study 09f · Nov 2026 · service design · Define

The studio's next sector: small games studios

Test a game's world, characters and adverts with players before paying for production. Built from my Skate. research, starting in Bristol.

Read the case study → · 4-minute read

Case study 08 · 2025 – 2026 · innovation research · Discover and Define

Skate.: when fans built what was promised

EA rebuilt a cult skate series as a free-to-play live service. A year in, players praise the skating and reject what's built around it, and a fan mod passed 350,000 downloads in days. A scorecard of how EA manages innovation, and five changes I'd make.

Read the case study → · 5-minute read

Case study 07b · 2026 · prototyping and testing · solo · Develop

Nature on campus, a year on: running the redesigned test

Each change answers a finding from the team test: one bike ride, foraging and dyeing the same day, real samples and a field guide for Cardiff.

Read the case study → · 3-minute read

Case study 07a · Nov 2025 · prototyping and testing · Develop and Deliver

Nature on campus: prototype and test

My idea, upcycling clothes with foraged dyes, was prototyped and tested with students. Then delivery broke down.

Read the case study → · 5-minute read

Case study 06 · Oct–Nov 2025 · ideation · Develop

Women in sport: ideating from a handover

An agency team takes over a client's research on why girls drop out of sport. The vote and the evidence picked different ideas, the research had a gap, and the honest answer to the client was "not ready to build".

Read the case study → · 5-minute read

Case study 05b · Nov 2026 · service review · solo · Define

A year on: what student housing booking websites show

I checked five providers' booking pages against the six things students said they needed. None covered all six, and room fit was weakest everywhere.

Read the case study → · 3-minute read

Case study 05a · 2025 · user research · Discover and Define

Finding student housing from abroad

How international postgraduates find a room before they arrive in Bristol. Stress peaks at 6.0 out of 10 when they sign for a room they haven't seen. Includes a possible critical finding our analysis lost, and how I'd fix the process.

Read the case study → · 5-minute read

2022 – 2023

Case study 04 · Dec 2022 – Mar 2023 · discovery research · Define and Develop

SoundCloud: charts that let niches be found

There was no grime chart. I proposed a small, testable change: let creators and fans propose and vote on new subgenre charts, so niche artists and their fans can find each other.

Read the case study → · 5-minute read

Case study 03 · 2022 – 2023 · discovery research · Discover and Define

Spotify: why a good band can't be found

I followed one psych-rock band through every route a new listener could use to find them. Every free route was a dead end, and the paid route wasn't what I first thought.

Read the case study → · 5-minute read

2018 – 2022

Case study 02c · 2020 – 2022 · venture design · Develop

A creator marketplace, part 3: a marketplace that makes only what sells

A crowdsourcing model where fans help design clothes before they're made, developed without funding in Lisbon. In 2022 it moved into music.

Read the case study → · 4-minute read

Case study 02b · 2019 – 2021 · venture design · Define and Develop

A creator marketplace, part 2: a demonstrator I built alone

My final-year demonstrator, run again when I repeated the year I spent away in Lisbon. Follow-first community building beat two paid promotions combined.

Read the case study → · 3-minute read

Case study 02a · 2018 – 2020 · discovery research · Discover

A creator marketplace, part 1: curators were already running marketplaces

A third-year group project that found Instagram curator accounts had a marketplace's audience but no way to sell.

Read the case study → · 3-minute read

2014 – 2020

Case study 01 · c. 2019 · marketing strategy · Discover and Define

Isla Bikes: a bike that grows with the child

A marketing plan for renting or part-exchanging kids' bikes as they grow: the competition, the cash-flow risk inside a made-to-order business, and where shops and concierge services fit.

Read the case study → · 5-minute read

Engineering · 2015 – 2020 · electrical and electronic engineering with innovation

Engineering: building hardware and software from the ground up

Before design and research, I trained as an electrical and electronic engineer. I learned to build both halves of a product: the circuit and the code that runs it.

Hardware

  • A wireless link, from theory to working kit. I designed and built a transducer and receiver system myself, the circuit plus the software to transmit and decode, proving a wireless communication design from first principles.
  • A smart mirror (2016 hackathon, team of three). Built on Arduino and Raspberry Pi, it showed live weather and morning schedule reminders.
  • Power electronics. A technical note on thyristor switching that placed our team second in the engineering lab (2018).
  • Digital hardware in VHDL. Designed and tested a serial data receiver as a state machine, simulated in ModelSim.
  • Circuit and digital-circuit labs throughout.

Software

  • Low level to high. Assembly, C on Linux, C++, C#, Java and Python, plus VHDL for hardware.
  • Human–computer interaction (2017/18). My first formal design unit, before the innovation work took over.
  • The Wireless Orchestra (first-year project). Real-time software in C: I wrote a simple master–slave protocol of ASCII commands, sent over a wireless serial link, to conduct instrument notes across devices.
  • Games as a way in. A sprite game to learn programming, then a game in Python.
  • From one wireless link to networks. The orchestra led into units in communication systems, mobile communications, advanced mobile radio, broadband wireless, networking protocols, networked systems and applications, and coding theory (error checking): the plumbing behind every app I build now.

Why it matters now: I still build both halves. Today it's my own marketplace platform and Fruityard's tools, specified, reviewed and tested by me. Write-ups of the individual engineering projects will follow as I recover the files.

Case study 00 · Sep 2014 – Apr 2015 · hardware design · the whole loop

Where it started: a portable amplifier speaker

A college brief: solve a real problem with a circuit on a £20 budget. I chose my own problem, a phone too quiet to play music out and about, and designed, built and tested a battery-powered amplifier speaker.

Read the case study → · 5-minute read

How I work, end to end

From user research to a working product

One person can run the whole operation, from finding out what people need to keeping the live product safe. Each stage links to the work that proves it. When something goes wrong, I fix the process, not just the problem.

1 · Discover

Find out what people actually need

I plan research from the question, not the method, then pick the methods that each answer part of it.

Case study 05 · Finding student housing from abroad

Team project, University of Bristol, 2025

  • Question first. I broke the brief's "how might we" question into method, goal, issue, who and where, so every method had a job and every finding traced back to the question.
  • A plan that grows. A research matrix (the 10 questions) and an opportunity solution tree, built before fieldwork and deepened with desk research as each method took us further.
  • Methods in the field. Six autoethnographies, interviews including a Students' Union officer, and a focus group with 8 international postgraduates from 5 countries.
  • Methods I combined. A journey-map focus group with PESTLE and AEIOU prompts on each stage, alongside stress ratings.
  • What it found. Stress peaks at 6.0 out of 10 when students sign for a room they haven't seen.

Across the trail

  • Case study 00 · listed four everyday problems, then took apart a rival speaker
  • Case study 01 · mapped competitors and the shift to direct-to-consumer
  • Case study 02 · studied Instagram curator accounts turning into marketplaces
  • Case study 03 · walked one band through every route a listener could use to find them
  • Case study 08 · read five years of public evidence and player data on a live game
2 · Define

Turn findings into the right problem

I turn raw data into a short list of problems, ranked by how much they matter and how sure we can be.

Case study 05 · Finding student housing from abroad

Team project, University of Bristol, 2025

  • A coding framework from both sides. Desk research gave the PESTLE codes for the wider environment; I built the AEIOU half for what we observed in the field.
  • From codes to insights. Thematic coding, affinity mapping, a stage-by-stage journey map and a composite persona, giving six insights.
  • Prioritising. I re-analysed the team's data to rank problems by reach, stress and consequence, and added a confidence rating for how much evidence sits behind each one.
  • What it decided. Time leads on the data. Access has the worst consequence but the least evidence, which is what led to the rules below.
  • What it produced. Six design recommendations for universities and housing providers.

When it went wrong

A finding was lost between methods in my case study. These became standing rules for every study:

  • Each method's data is coded before the next method's guide is finalised.
  • Every guide is checked against the coding framework before fieldwork, and any gap is closed or written down as a deliberate choice.
  • Before synthesis, I search all raw data by hand for health, disability, money and safety.
  • A person checks every AI-coded source against the original.
  • Sensitive details become consented, anonymised codes instead of being deleted.

Across the trail

  • Case study 01 · named the two risks inside the business: cash flow and existing customers
  • Case study 03 · defined a discovery problem that hurts bands and listeners at once
  • Case study 04 · framed the symbiotic discovery problem: no grime chart
  • Case study 08 · scored innovation management and found two broken promises
3 · Develop

Design it and let people react before it's built

Walkthroughs, then clickable screens in the real styles, then rules that come out of testing them.

Case study 06 · Women in sport: ideating from a handover

Team project, role-play agency brief, University of Bristol, 2025

  • Checked the handover. The research we inherited had interviewed women still playing sport, not the girls who'd stopped.
  • Ideated and ranked. Brainwriting, reverse brainstorm and role storming, then a decision matrix that overturned the vote.
  • Told the client the truth. Not ready to build; the research needed more work first.
  • The redo. Ideate the discovery instead: prototype the research (internal) before the product (external).

Case study 07 · Nature on campus: prototype and test

Team project, role-play agency brief, University of Bristol, 2025

  • My idea. Upcycling clothes with foraged dyes, built from the best parts of ten ideas we were handed.
  • Prototyped. Three personas, three journey maps and the touchpoints worth testing.
  • Tested with students. Desirable, but change the format and show real samples.

Across the trail

  • Case study 00 · simulated the circuit and laid out the PCB before building
  • Case study 02 · designed a six-step service where fans shape garments before they're made
  • Case study 04 · proposed open-design charts as the smallest testable change
4 · Deliver

Spec it, build it, test it

I write the spec, build with Claude Code, review every change and test on staging with real test purchases.

Case study 07 · Nature on campus: delivery

Team project, role-play agency brief, University of Bristol, 2025

  • Viability. Desirable and feasible, but weak as a programme for the University to invest in.
  • When delivery broke down. No shared record of who did what; what I changed because of it.
  • A year on. I'm running the redesigned demand test myself, in Cardiff then Bristol.

Across the trail

  • Case study 00 · built, tested and adapted a working amplifier speaker
  • Case study 02 · ran a demonstrator where organic growth beat paid ads
5 · Run and improve

Keep the live product safe

When it went wrong

Incident response. When our hosting provider reported a security incident, I rotated every secret (Stripe, email, Shopify and others), revoked the old ones, turned on two-factor everywhere, redeployed, and wrote a data-protection self-assessment.

Data and hosting. I moved the production backend to an EU region: backup first, row counts checked before and after, then a fresh deploy and real sign-in and form checks. Secrets live in a password manager.

What I've shipped

Four systems, built and running

01

Payments

Stripe Connect checkout

  • Direct charges on each seller's own Stripe account, with the platform's fee taken as an application fee. The platform never holds buyers' money.
  • Webhook handling with retries and de-duplication, plus support for slower payment methods, full and partial refunds, and stock and postage by zone.
  • Live keys are refused in code until a sign-off flag is set. Everything runs in test mode until then.
02

Shopify app

Custom app on a dev store

  • Creates discount codes in each seller's own Shopify store automatically.
  • Paid and refunded orders sync back in about five seconds, without sharing buyer details.
  • Tested with real test purchases on a development store; I found and fixed a price bug that way.
03

The platform

Node.js, SQLite, Railway

  • Sign-in, seller campaigns, discount codes, public profiles, a release feed, and per-campaign statements showing sales by channel.
  • Feature flags gate the site, forms and pages, so work can merge before it goes public.
  • Transactional email through Brevo, sent from the company domain.
04

Fruityard site and tools

Symfony backend, Vercel front end

  • The studio site with forms, double opt-in email and free planning tools, including a break-even calculator for promoters.
  • Six sister sites hosted on Railway, each with its own domain, DNS on Cloudflare, mailboxes and icons.
How I work with AI

Spec first, then review and test everything

I build with Claude Code rather than writing everything by hand. I'm the one who decides what gets built, reads each change, tests it end to end, and runs the deploy.

  1. Write the spec and the rules
  2. Claude Code builds on a branch
  3. One pull request per change on GitHub
  4. I review the diff
  5. Test on staging with real test purchases
  6. Merge and deploy
  7. Written handover
From my checkout build plan (4 Nov 2026), lightly trimmed Branch: checkout-v1 off staging-next. One PR per item. Staging only. Stripe test mode only. Live keys stay refused in code until sign-off. Never hold money: direct charges on the seller's own Stripe account. Never store buyer names or emails beyond what the seller's Stripe holds. Stage 0 first: for each item, report works / partly / missing. Build only what's missing.
Demo · from staging

A tool working

Each demo gets its own space: the experience it gives the user, why it was built, how I designed it, and how it's built.

Demos of my marketplace are available on request while it's in private development.

Demo · Fruityard

Break-even calculator for promoters

screen · live
Fruityard break-even calculator

The experience. A promoter planning a night enters what it costs and what they'll charge, and sees straight away how many people they need through the door to break even. No account, no email and no sign-up stand between them and the answer.

Why it was built

It's the first rung of a ladder for promoters: a free tool that's useful on its own, then a self-serve planning sprint, then a full discovery engagement. Value comes first, and the sales conversation only starts if the person wants more.

Design process

  • Free tools first in the studio's method: build what helps the customer before selling them anything.
  • The answer is never locked behind a sign-up. A fuller breakdown by email, with a separate, unticked opt-in for news, is designed as the next step.
  • A "Suggest a change" panel is designed so users can shape the tool, and hear back if their idea ships.

How it's built

  • Part of the Fruityard studio site: Symfony backend, Vercel front end.
  • Lives on the Services page, phone first.

Backs up: Fruityard site and tools (04).