Demo 06 · Design thinking

Redesigning a show page for accessibility

The engineering demos prove I ship. This proves how I decide what to ship. A clear design process, from persona to journey map to information architecture to a measured result. Every artifact is built as code. No Figma needed.

The problem

A listener hears a track on air and wants to find the show, play it, and save it for later. On the current page that takes too many taps, fails keyboard users, and leaves nothing to come back to. I scoped a redesign of the show and listen flow around one person and her scenario.

1 · Persona

Priya, 34. Commuter and member.

Listens on her phone, often one handed on transit.

Goal: capture a song or show the moment she hears it.
Goal: get to play in the fewest taps.
Context: uses VoiceOver some mornings, with bright sun on the screen.
Frustration: I lose the thing I wanted before I can save it.

2 · Context scenario

Priya is on the bus when a track catches her ear. She pulls out her phone in bright sun with one hand on the rail. She wants to know the show, start it from the top, and follow it so tonight she can pick up where she left off. No squinting, no digging through a menu, and VoiceOver reading everything right. The design has to make that whole arc feel like three easy taps.

The method: write the story first, then pull the requirements from it. The story above leads straight to the opportunities in the experience map.

3 · Experience map

Reading down each phase shows the pain points in red and the design opportunities highlighted. Those are what the redesign has to answer.

Experience map · **Priya. Find, play, save a show.**
Phase →	Hears a track	Searches the site	Plays the show	Saves and returns
Doing	Catches a song on air and wants to know what it was.	Opens the site on her phone to find the show.	Starts the live stream or the on demand episode.	Wants to follow the show and come back later.
Thinking	What was that? I need to find it before I forget.	Which show is on at 9am again?	Just let me press play.	Will I be able to find this again?
Feeling
Pain points	Now playing is buried three taps deep.	The schedule is a dense table with no clear focus order.	The play button is an unlabeled icon. A screen reader says button.	No saved state. Nothing personal to return to.
Opportunities	A persistent now playing bar with one tap to save.	A card based schedule with clear focus states.	A labeled, keyboard ready player (Demo 02).	A My Station dashboard (Demo 05).

4 · Information architecture and flow

Diagrams as code with Mermaid. They live in the repo as text, not as exported images. Left is the site structure. Right is the redesigned task flow.

Information architecture. Site structure.

View diagram source

graph TD
  Home["Home"] --> Listen["Listen Live"]
  Home --> Shows["Shows"]
  Home --> Schedule["Schedule"]
  Home --> My["My Station"]
  Home --> Support["Support / Join"]
  Shows --> ShowDetail["Show detail"]
  ShowDetail --> Episode["Episode + player"]
  My --> Saved["Saved shows"]
  My --> Recent["Recently played"]
  Support --> Join["Membership funnel"]

Task flow. Hear, find, play, save.

View diagram source

flowchart LR
  A([Hears a track]) --> B{Knows the show?}
  B -- No --> C[Open Schedule]
  C --> D[Pick show card]
  B -- Yes --> D
  D --> E[Show detail]
  E --> F[(Play: labeled,\nkeyboard ready)]
  F --> G{Wants it later?}
  G -- Yes --> H[Save to My Station]
  G -- No --> I([Keep listening])
  H --> I

5 · Wireframes, before and after

Before cluttered and inaccessible

Icon only controls, no labels
3.1 to 1 text contrast on cream
Schedule is a non semantic table
Focus order jumps around
No skip link, nav not reachable by keyboard

After clear and accessible

Every control labeled and in tab order
All text 4.5 to 1 or better (AA)
Card schedule with real headings
Logical order with a visible focus ring
Skip link and landmark regions

6 · The result, measured

Accessibility is testable, so the redesign is measured, not claimed. Scores are from axe-core and Lighthouse on the prototype.

Metric	Before	After
axe violations	23	0
Lighthouse a11y	61	100
Keyboard operable	Partial	Full
Contrast failures	9	0
Labeled controls	54%	100%

These numbers are from the prototype I built for this case study, not a live KCRW page. The accessible player in Demo 02 and the dashboard in Demo 05 are the after of this story, built for real.