SYSTEM BLUEPRINT

보이지 않아도 조작되는 화면,
들리는 순서까지 그린 설계도

나레이터 앱 · 청취자 앱 · 디자인 핸드오프 3개 관점의 9개 핵심 화면 사전 기획서입니다. 각 화면에는 포커스 이동 순서와 스크린리더 낭독 문구가 함께 설계되어 있습니다.

청취자(시각장애인 관객) 시나리오

공연장에 앉아 앱을 켜는 순간부터
나레이션이 끝날 때까지

청취자 앱은 '찾는 앱'이 아니라 '기다려주는 앱'이어야 합니다. 탐색 단계를 최소화하고, 공연이 열리면 앱이 먼저 말을 겁니다.

앱 실행 · 공연 탐색

탭 바 없이 진행 중인 공연 목록이 곧 첫 화면. 실행 즉시 오늘 공연을 낭독합니다.

접근성 설정

글씨 크기 100·150·200%와 고대비 테마를 온보딩에서 한 번에 정합니다.

자동 대기 · 입장

공연이 없으면 대기 화면 유지, 시작되면 자동 안내 후 두 번 눌러 입장합니다.

실시간 음성 청취

화면의 41%가 단일 터치 영역. 보지 않고도 볼륨과 종료를 조작합니다.

종료 · 다음 공연 안내

종료 시 다음 공연 일정을 음성으로 안내하고 목록으로 되돌립니다.

청취자(시각장애인 관객) | 화면 01

진행 중인 공연 목록 (다크 고대비 기본)

Figma · Listener App / 01_Main_공연목록
9:41LTE  100%
진행 중인 공연 글씨 200%
🎭
● 나레이션 진행 중
햄릿
예술의전당 CJ토월극장
나레이터 김서연 · 함께 듣는 중 47명
입장하기
오늘 20:00 시작 예정
베르나르다 알바의 집
LG아트센터 서울 U+스테이지
새 공연이 시작되면 자동으로 음성 안내해 드립니다.
VOICE SPEC · 포커스 순서 & 낭독 문구
1
화면 제목
“진행 중인 공연, 제목”
2
진행 중 공연 카드
“햄릿, 예술의전당 CJ토월극장, 나레이션 진행 중, 함께 듣는 중 47명”
3
입장 버튼
“입장하기, 버튼. 두 번 누르면 실시간 나레이션을 듣습니다”
4
예정 공연 카드
“오늘 20시 시작 예정, 베르나르다 알바의 집, LG아트센터 서울”
5
자동 대기 안내
“새 공연이 시작되면 자동으로 음성 안내합니다”
라이브 리전: 공연 시작 시 목록 갱신 없이 “햄릿 나레이션이 시작되었습니다”를 즉시 낭독합니다.

[화면 개요 및 목적]

공연장은 어둡습니다. 저시력 사용자가 객석에서 화이트 배경 대형 UI를 켜면 눈부심이 오히려 방해가 됩니다. 그래서 청취자 앱은 다크 고대비를 기본 테마로 설계하고, 지금 들을 수 있는 공연 한 건을 화면 상단에 가장 크게 배치했습니다. 탭 바를 없애 화면 이동 자체를 제거했습니다.

[핵심 기능 로직]

제안서 역제안 ①(Voice Spec Layer)을 그대로 시각화한 화면입니다. 오른쪽 스펙 패널은 실제 납품물의 형식으로, 각 요소의 포커스 순번과 낭독 문구를 확정해 개발팀에 전달합니다. 공연이 시작되면 화면 갱신 없이 라이브 리전으로 즉시 알립니다.

  • Focus Order 1→5 / TalkBack · VoiceOver 동일 순서 보장
  • SemanticsService.announce() 기반 라이브 리전
청취자(시각장애인 관객) | 화면 02

자동 대기 & 청취 중 — 두 개의 상태

Figma · Listener App / 03_Listening_상태정의
9:41LTE  100%
지금은 진행 중인
공연이 없습니다
공연이 시작되면 자동으로 연결하고
음성으로 알려드립니다.
자동 대기 중 · 00:42
STATE A. 자동 대기
공연이 없을 때도 앱을 나가지 않는다.
대기 시간을 음성으로 계속 안내한다.
9:41LTE  100%
실시간 나레이션 청취 중
햄릿
나레이터 김서연 · 2막 1장
소리 크게 / 작게
화면 위쪽을 누르면 크게,
아래쪽을 누르면 작게
터치 영역 340×300 · 화면의 41%
청취 종료
STATE B. 청취 중
화면의 41%가 단일 터치 영역.
보지 않고도 볼륨 조작이 가능하다.

[화면 개요 및 목적]

공고의 '공연 없을 때 자동 대기'와 '실시간 음성 청취'는 사실 하나의 화면이 가진 두 가지 상태입니다. 별도 화면으로 만들면 전환 시 포커스가 튀어 사용자가 길을 잃습니다. 동일 컴포넌트의 상태 변형으로 설계해 포커스를 유지합니다.

[핵심 기능 로직]

청취 중 화면의 핵심은 '버튼을 크게'가 아니라 '영역을 넓게'입니다. 340×300px(화면의 41%)를 단일 볼륨 조작 영역으로 잡아, 화면을 보지 않고 손가락을 아무 데나 올려도 조작이 성립하게 만듭니다. 데모 Step 3에서 직접 확인하실 수 있습니다.

  • Single Component · State Variant (대기 / 청취 중)
  • MergeSemantics + onIncrease / onDecrease 볼륨 제어
청취자(시각장애인 관객) | 화면 03

공연 상세 — 포스터도 정보다

9:41LTE  100%
공연 상세
🎭
한 줄 음성 요약
햄릿, 예술의전당 CJ토월극장, 8월 21일 19시 30분, 러닝타임 150분, 나레이터 김서연
줄거리 3분 30초
캐스팅 1분 10초
무대 설명 2분 05초
처음부터 듣기
VOICE SPEC · 공연 상세 낭독 설계
1
뒤로 가기
“뒤로 가기, 버튼”
2
포스터 이미지
“햄릿 공연 포스터, 붉은 무대 막 위 배우 실루엣 (대체 텍스트 필수)”
3
한 줄 음성 요약
“햄릿, 예술의전당 CJ토월극장, 8월 21일 19시 30분, 150분, 나레이터 김서연”
4
섹션 목록
“줄거리, 3분 30초, 접힘. 두 번 누르면 펼칩니다”
5
처음부터 듣기
“처음부터 듣기, 버튼”
포스터는 장식이 아니라 정보입니다. 대체 텍스트 문구까지 디자인 산출물에 포함해 납품합니다.

[화면 개요 및 목적]

공고가 요구한 포스터·공연명·공연장·소개·줄거리·캐스팅·무대 설명을 한 화면에 담되, 맨 위에 '한 줄 음성 요약'을 둡니다. 전체를 다 듣지 않아도 이 공연이 무엇인지 5초 안에 파악하게 하는 장치입니다.

[핵심 기능 로직]

시각장애인 앱에서 이미지는 대체 텍스트가 없으면 존재하지 않는 것과 같습니다. 저희는 포스터 대체 텍스트 문구까지 디자인 산출물에 포함해 납품합니다. 각 섹션은 재생 시간이 표기된 접힘 목록으로, 듣고 싶은 부분만 선택할 수 있습니다.

  • Image alt-text 문구를 Figma 레이어 설명에 동봉
  • ExpansionTile + Semantics(expanded) 상태 낭독
나레이터(공연 해설자) 시나리오

공연 24분 전, 나레이터의 손에서
일어나는 일들

나레이터는 어두운 해설석에서 대본과 무대를 동시에 봅니다. 앱을 오래 볼 수 없으므로, 조작은 최소 단계로 끝나야 합니다.

할당 공연 확인

관리자가 배정한 공연만 노출. 시작까지 남은 시간을 상단에 고정합니다.

공연 메모 숙지

관리자 메모(읽기 전용)와 개인 노트(편집)를 시각·낭독 모두로 구분합니다.

마이크 · 음성 점검

입력 레벨을 파형으로 보여주고, 켜짐/꺼짐을 햅틱으로도 확인시킵니다.

실시간 음성 송출

경과 시간·청취자 수·마이크 상태 3가지만 남긴 단일 목적 화면입니다.

공연 종료 · 기록

종료 시 총 청취자 수와 진행 시간을 요약해 다음 공연 준비로 연결합니다.

나레이터(공연 해설자) | 화면 01

할당 공연 목록 & 승인 상태

Figma · Narrator App / 02_Main_할당공연
9:41LTE  100%
내 공연 승인 완료
오늘 19:30 · 시작 24분 전
햄릿
예술의전당 CJ토월극장 · 2막
공연 시작
8월 23일 15:00
베르나르다 알바의 집
LG아트센터 서울 U+스테이지
할당된 공연이 없을 때는 “배정된 공연이 없습니다” 빈 상태 화면이 노출됩니다.
ONBOARDING → 승인 상태 4분기 설계
1
승인 대기
“관리자 승인 대기 중입니다. 승인되면 알려드립니다”
2
승인 완료
“승인 완료. 배정된 공연 1건이 있습니다”
3
반려
“등록이 반려되었습니다. 사유: 포트폴리오 음성 파일 확인 불가”
4
배정 없음
“현재 배정된 공연이 없습니다”
5
공연 시작 버튼
“공연 시작, 버튼. 두 번 누르면 실시간 나레이션을 시작합니다”
온보딩 5단계(약관·이름·포트폴리오·승인 대기·반려)를 한 컴포넌트의 상태 변형으로 설계해 화면 수를 줄입니다.

[화면 개요 및 목적]

공고의 온보딩은 약관 동의·이름 입력·포트폴리오 등록(선택)·관리자 승인 대기·반려까지 5단계입니다. 이를 5개의 독립 화면으로 그리면 7일 일정에서 손해입니다. 하나의 상태 카드 컴포넌트가 4가지 변형을 갖도록 설계했습니다.

[핵심 기능 로직]

제안서 역제안 ③(One Foundation, Two Apps)의 실제 적용 예입니다. 이 상태 카드는 청취자 앱의 온보딩에서도 그대로 재사용되며, 문구만 교체됩니다. 기능 변경 요청이 오면 컴포넌트 하나만 수정하면 양쪽 앱에 동시 반영됩니다.

  • Figma Component Variant · status = pending / approved / rejected / empty
  • 두 앱 공용 Foundation 라이브러리 참조
나레이터(공연 해설자) | 화면 02

공연 중 브로드캐스트 & 라이브 리전

Figma · Narrator App / 05_Live_공연중
9:41LTE  100%
공연 중 · 00:24:18
햄릿 · 2막 1장
마이크 켜짐
두 번 누르면 마이크가 꺼집니다
47
청취자
공연 종료
LIVE REGION · 자동 낭독 로그
19:30:02
“공연이 시작되었습니다. 마이크가 켜졌습니다”
19:31:44
“청취자가 47명으로 늘었습니다”
19:42:10
“네트워크가 불안정합니다. 음성이 잠시 끊길 수 있습니다”
HAPTIC PATTERN
짧게 1회
마이크 ON
짧게 2회
마이크 OFF
길게 1회
공연 종료

[화면 개요 및 목적]

공연 중 화면에는 경과 시간, 마이크 상태, 청취자 수 외의 어떤 요소도 두지 않습니다. 어두운 해설석에서 잘못 누를 수 있는 요소를 제거하는 것이 이 화면의 유일한 목표입니다. 마이크 파형은 '소리가 실제로 나가고 있다'를 눈으로 확인시키는 장치입니다.

[핵심 기능 로직]

오른쪽 패널은 화면에는 보이지 않지만 반드시 설계되어야 하는 두 가지, 라이브 리전 낭독 로그와 햅틱 패턴을 명세한 것입니다. 마이크 ON은 짧게 1회, OFF는 짧게 2회, 종료는 길게 1회로 정의해 화면을 보지 않고도 상태를 확신하게 만듭니다.

  • Live Region · 상태 변화 시 자동 낭독 (청취자 수 / 네트워크)
  • HapticFeedback 패턴 3종 정의 (ON / OFF / END)
나레이터(공연 해설자) | 화면 03

공연 메모 — 읽기 전용과 편집 가능의 구분

Figma · Narrator App / 06_Memo_공연메모
9:41LTE  100%
공연 메모
관리자 메모 · 읽기 전용
2막 1장 암전 구간(약 40초)은 나레이션을 멈추지 말고 무대 전환을 설명해 주세요. 유령 등장 장면은 조명이 급격히 바뀝니다.
내 개인 노트 · 편집 가능
- 1막 3장: 오필리아 의상 ‘연회색 드레스’로 설명
- 무대 좌측 계단 3단, 우측 커튼
- 클로디어스 왕관은 금색
|
자동 저장됨 · 19:24
메모 음성으로 듣기
READ-ONLY vs EDITABLE 시각 구분 설계
1
관리자 메모
“관리자 메모, 읽기 전용. 2막 1장 암전 구간은 나레이션을 멈추지 말고...”
2
개인 노트
“내 개인 노트, 편집 가능. 두 번 누르면 편집을 시작합니다”
3
자동 저장 상태
“자동 저장됨, 19시 24분”
4
메모 듣기
“메모 음성으로 듣기, 버튼”
5
뒤로 가기
“뒤로 가기, 버튼. 저장하지 않은 내용은 없습니다”
읽기 전용/편집 가능은 색만으로 구분하면 색각 이상 사용자에게 사라집니다. 테두리 · 라벨 · 낭독 문구 3중으로 구분합니다.

[화면 개요 및 목적]

공고의 '관리자 메모'와 '나레이터 개인 참고용 노트'는 권한이 다른 두 종류의 텍스트입니다. 이 차이를 색으로만 구분하면 색각 이상 사용자와 스크린리더 사용자 모두에게 사라집니다. 테두리·라벨·낭독 문구 3중으로 구분했습니다.

[핵심 기능 로직]

'메모 음성으로 듣기' 버튼은 공고에 없지만 반드시 필요합니다. 공연 직전 어두운 해설석에서 긴 메모를 눈으로 읽기 어렵기 때문입니다. 기존 화면 구조를 바꾸지 않고 버튼 하나를 더하는 최소 변경으로 해결합니다.

  • Data Aggregation & Visualization
  • TTS 재생 · 자동 저장 상태 낭독
디자인 산출물(핸드오프) 시나리오

Figma를 넘기고 끝이 아니라,
개발팀이 그대로 붙일 수 있게

개발 적용은 클라이언트 내부에서 진행됩니다. 그래서 산출물은 '그림'이 아니라 '명세'여야 합니다. 아래 3개 문서가 Figma 원본과 함께 납품됩니다.

토큰 · 대비 실측

컬러/타이포/간격을 변수화하고 모든 조합의 명도 대비를 수치로 측정합니다.

무의미 낭독 제거

'버튼', '이미지'로만 읽히는 요소를 전수 조사해 낭독 문구를 확정합니다.

Flutter 매핑 시트

각 요소를 Semantics·TextScaler 속성에 1:1로 연결한 대조표를 만듭니다.

스크린리더 검수

TalkBack·VoiceOver 실기기로 전체 화면 낭독 순서를 통과 검증합니다.

스토어 에셋 등록

아이콘·스크린샷·피처드를 규격별로 내보내 등록까지 바로 연결합니다.

디자인 산출물(핸드오프) | 화면 01

Voice Spec Sheet — 무엇을 읽힐지 확정한 표

Deliverable · voice_spec_sheet_v1.0
Voice Spec Sheet v1.0
청취자 앱 / 나레이터 앱 · 전체 16개 화면군 · 낭독 요소 214건
검증 완료 214 미정의 0
화면 요소 포커스 낭독 문구 (label) Flutter 매핑
청취자 / 메인화면 제목1“진행 중인 공연, 제목”Semantics(header: true)
청취자 / 메인공연 카드2“햄릿, 예술의전당 CJ토월극장, 청취자 47명”Semantics(label:…, button:true)
청취자 / 메인입장 버튼3“입장하기, 버튼. 두 번 누르면 청취를 시작합니다”Semantics(hint:'두 번 누르면…')
청취자 / 청취 중볼륨 영역2“소리 조절 영역. 위쪽은 크게, 아래쪽은 작게”MergeSemantics + onIncrease
청취자 / 청취 중상태 알림-“청취자가 47명으로 늘었습니다”SemanticsService.announce()
나레이터 / 공연 중마이크 토글2“마이크 켜짐. 두 번 누르면 끕니다”Semantics(toggled: true)
나레이터 / 공연 메모관리자 메모1“관리자 메모, 읽기 전용”Semantics(readOnly: true)
공통 / 온보딩약관 체크박스3“이용약관 동의, 체크 안 됨, 필수”Semantics(checked: false)
개발 적용은 클라이언트 내부에서 진행하십니다. 그래서 저희는 ‘무엇을 읽힐지’를 표로 확정해 드립니다. 개발팀은 이 표를 그대로 코드에 옮기면 됩니다.

[화면 개요 및 목적]

이 표가 이번 제안의 핵심 차별점입니다. 시안만 받은 개발팀은 각 위젯에 어떤 문장을 넣어야 할지 스스로 정해야 하고, 그 순간 접근성 품질은 운에 맡겨집니다. 저희는 16개 화면군 214개 낭독 요소를 모두 확정해 표로 납품합니다.

[핵심 기능 로직]

화면 / 요소 / 포커스 순번 / 낭독 문구 / Flutter 매핑 5열 구조입니다. 개발팀은 마지막 열을 그대로 코드에 옮기면 됩니다. '미정의 0건'이 될 때까지 검수하는 것이 납품 조건입니다.

  • Semantics(label · hint · header · toggled · readOnly) 전수 정의
  • Figma 레이어명 ↔ 위젯 매핑 규칙 동봉
디자인 산출물(핸드오프) | 화면 02

대비 · 타입 스케일 검증 리포트

Deliverable · accessibility_report_v1.0
글자 크기 100%
진행 중인 공연
햄릿
예술의전당 CJ토월극장
입장하기
기본. 카드 2장 + 자동 대기 안내가 한 화면에 들어온다.
글자 크기 150%
진행 중인 공연
햄릿
예술의전당 CJ토월극장
입장하기
카드 1.5장 노출. 버튼 높이는 96dp를 유지한다.
글자 크기 200%
진행 중인 공연
햄릿
예술의전당 CJ토월극장
입장하기
카드 1장 + 스크롤. 텍스트 잘림 없음(말줄임 금지).
요소전경 / 배경대비기준
본문 텍스트#F1F5F9 / #0F172A16.1:1AAA
입장 버튼#FFFFFF / #C2185B5.9:1AA
진행 상태 배지#FDE68A / #0B122013.4:1AAA
보조 설명 (수정 전)#94A3B8 / #1E293B4.2:1→ #CBD5E1 교체
TOUCH TARGET
수정 전
32dp
최소 기준
48dp
핵심 조작
96dp
Figma Variables
type/body = 20 → 30 → 40
touch/min = 48dp
touch/primary = 96dp
color/accent = #C2185B

[화면 개요 및 목적]

'큰 글씨, 높은 명도 대비'라는 요구를 감각이 아니라 수치로 증명합니다. 글자 크기 100·150·200% 세 단계에서 레이아웃이 무너지지 않는 상태를 각각 시안으로 만들고, 모든 텍스트 조합의 대비를 측정해 기준 미달 항목은 색을 교체합니다.

[핵심 기능 로직]

제안서 역제안 ②(Type & Contrast System)의 결과물입니다. 200% 확대에서 텍스트를 말줄임 처리하지 않는 것이 원칙입니다. 저시력 사용자에게 말줄임은 정보 삭제와 같기 때문입니다. 대신 카드가 세로로 늘어나고 스크롤이 생기도록 설계합니다.

  • WCAG 2.2 AA 4.5:1 / AAA 7:1 실측 · Figma Variables 토큰화
  • Touch Target 최소 48dp · 핵심 조작 96dp
디자인 산출물(핸드오프) | 화면 03

스토어 등록 에셋 키트

Deliverable · store_kit_aos_ios
앱 아이콘
AOS 512×512
iOS 1024×1024
피처드 이미지 · 1024×500
공연을 귀로 봅니다
시각장애인을 위한 실시간 음성 공연 해설
스토어 스크린샷 · 팟빵형 캡션 레이아웃
캡션 자체가 큰 글씨 · 고대비
지금 열리는 공연을
바로 듣기
화면을 보지 않아도
조작됩니다
글씨 크기
200%까지
나레이터도
쉽게 송출
AOS 1080×1920 / iOS 6.7″·5.5″ 규격으로 각각 4컷 제작하며, 캡션은 본문 대비 7:1 이상을 유지합니다.

[화면 개요 및 목적]

공고가 요구한 앱 아이콘(AOS 512·iOS 1024), 스크린샷, 피처드 이미지(1024×500)를 한 세트로 제작합니다. '팟빵 앱 형식 선호'는 취향이 아니라 오디오 서비스라는 카테고리 인식을 만들고 싶다는 요구로 해석했습니다.

[핵심 기능 로직]

스토어 스크린샷의 캡션 자체가 큰 글씨·고대비여야 합니다. 저시력 사용자는 앱을 설치하기 전 스토어 페이지에서 먼저 이탈하기 때문입니다. 캡션은 본문 대비 7:1 이상을 유지하며 4컷 서사(찾기→조작→확대→나레이터)로 구성합니다.

  • AOS 512·1024×500 / iOS 1024 · 6.7″·5.5″ 규격 일괄 내보내기
  • Issue Tracking & Status Management