콘셉트·정보구조·상호작용

1. 조사에서 찾은 문제를 어떤 구조로 바꿀까

도서관 강좌 서비스 UR-LIB에서 “검토 화면을 신청 완료로 믿을 수 있다”는 가상 문제가 나왔다. 큰 초록 버튼과 축하 그림을 추가하면 해결될까? 검토 단계에서 “신청 완료”를 보여 준다면 화면은 더 명확하게 잘못된 사실을 전달한다. 메뉴를 바꿔 모든 화면에 쉽게 도달하게 만들어도 이 오류는 남는다.

이 절은 앞의 조사·계획을 정보의 분류와 이름, 과업의 경로, 행동에 대한 상태·응답으로 구체화한다. UR 사례의 사람·기록·화면과 수치는 모두 학습용이다. 실제 이용자가 어느 설계를 더 좋아하거나 더 잘 사용했다는 측정 결과가 아니다.

앞 절의 문제와 계획이 설계의 입력이다

사용자 조사·문제정의·UX 계획의 UX 계획은 사용자·목적·맥락의 근거와 미확인을 조사·설계·검증의 결정에 연결했다. UR-P1은 검토와 확정의 구분이며 UR-M1은 올바른 신청과 확정 여부의 정확한 이해를 성공 조건으로 삼았다.

이번에는 앞 절에서 세운 UX 계획을 바탕으로 구체적 콘셉트·정보·상호작용을 설계하되, 가상 관찰을 실제 연구로 바꾸지 않는다.

응답이 없다는 뜻을 화면에서도 유지한다

시간초과·재시도·멱등성과 부분실패에서 시간초과는 기다림의 한도이며 재시도는 같은 목적의 요청을 다시 보내는 조치라고 배웠다. 응답이 없다는 사실만으로 서버가 일을 하지 않았다고 확정할 수 없었다.

UR에서도 제출 뒤 시간초과를 결과 미확인으로 남기며 버튼의 비활성화와 서버의 중복 효과 방지는 다른 책임임을 유지한다.

정확한 정의와 이 절의 책임

UI/UX 콘셉트 구체화는 사용자 문제와 경험 목표를 실현할 설계 방향을 정하고, 필요한 정보의 조직·명칭·탐색과 과업의 행동·상태·응답을 일관된 대안으로 만드는 활동이다.

사용자 조사·문제정의·UX 계획에서 정한 문제와 목표를 이어 쓴다. 여러 화면과 구성요소를 유지하는 방법은 UX 아키텍처·디자인시스템·접근성에서, 프로토타입의 상세 사용성 평가·개선은 프로토타입·사용성 평가·개선에서 다룬다. 여기서는 그 사이에서 무엇을 어떤 흐름과 상태로 제공할지 구체화하며 화면 구현이나 사용자 검증 완료를 뜻하지 않는다.

근거에서 화면까지 중간 결정을 빠뜨리지 않는다

선은 구현 호출이 아니라 설계 판단의 연결이다. 메뉴를 바꾸면 과업의 진입 경로를 다시 보고, 확정의 뜻을 바꾸면 결과 문구와 조회·지원 경로를 함께 검토한다.

콘셉트 문장은 장식보다 작동 원리를 담는다

UR-C1을 처음 신청하는 이용자가 강좌 조건을 비교하고, 제출 전 검토와 제출 후 결과를 구별하며, 결과가 불명확하면 다시 확인할 수 있는 흐름이라고 적자. 대상·목표·해결 원리와 예외가 드러난다. 친근하고 혁신적인 서비스만으로는 어떤 설계를 선택할지 판단하기 어렵다.

화면에 사용할 색·그림·문체도 이 방향을 지원해야 하지만 콘셉트 그 자체와 같지는 않다. 별도의 사용자 근거가 없으므로 C1은 검증할 방향이다. 자격·정원·지원 절차 등 미정 정책을 디자이너가 임의로 확정하지 않는다.

2. 필요한 정보를 조직하고 찾게 한다

정보구조는 사용자가 필요한 내용을 이해하고 찾도록 정보 항목의 분류·관계·명칭과 탐색 구조를 조직한 것이다. UR에서 강좌·신청조건·신청내역·도움말의 관계를 정하는 일이며 소프트웨어 모듈의 계층과 다르다.

이 정의는 이 절의 UI/UX 문맥이다. 데이터베이스 스키마나 정보시스템 전체의 아키텍처를 새로 정의하는 것이 아니다. 먼저 무엇을 찾고 어떤 판단을 해야 하는지 정한 뒤 분류와 경로를 만든다.

콘텐츠 목록과 페이지 목록은 일치하지 않는다

UR에는 강좌명·주제·장소·대상·시각·신청 조건·현재 처리 상태·다음 행동이 필요하다. 각 항목의 원천, 의미, 갱신 책임과 필요한 시점을 목록에 적는다. 같은 강좌 조건이 목록 화면과 상세 화면에 보이면 정보는 하나지만 표시 위치는 둘이다.

페이지 수를 채운 뒤 빠진 내용을 끼워 넣지 않는다. 오래된 조건이 한 화면에만 남거나 필요한 정보를 이미지에만 넣으면 같은 주제를 보여 주어도 사용자에게 다른 판단 근거가 된다. 현장 안내와 웹 설명이 어디에서 같은 기준을 참조할지도 확인한다.

부서 기준과 과업 기준의 대안을 비교한다

B가 모든 기관과 사용자에게 우수하다는 결론은 아니다. 특정 부서를 이미 아는 사람에게 A가 편할 수 있다. 두 대안의 정보·과업 범위와 비교 조건을 맞추고, 기관 조직도를 그대로 사용자의 이해 구조로 가정하지 않는다.

레이블은 사용자가 내릴 판단의 단서다

레이블링은 정보와 행동의 의미를 사용자가 구별할 수 있도록 명칭·문구를 정하고 일관되게 적용하는 설계다. UR의 신청 내용 확인과 신청 확정 결과는 서로 다른 시점과 뜻을 갖는다. 같은 확인 버튼을 제출·조회·단순 닫기에 모두 쓰면 행동의 결과를 예측하기 어렵다.

이름이 짧다는 이유만으로 좋다고 하지 않는다. 사람들이 실제로 쓰는 표현과 관련 내용을 확인하고, 같은 단어를 다른 의미로 쓰거나 같은 대상을 화면마다 다르게 부르지 않는다. 의미를 바꾸는 경우 해당 과업과 상태를 함께 다시 검토한다.

카드 소팅은 분류 방식의 단서를 모은다

카드 소팅은 내용 항목을 나타낸 카드를 참가자가 의미 있다고 보는 기준에 따라 묶게 하여 분류 기대를 조사하는 방법이다. 열린 방식은 미리 정한 범주 없이 묶고 이름을 붙이게 하며, 닫힌 방식은 제시한 범주에 항목을 배치하게 한다.

UR에서 강좌 일정, 내 신청 결과, 장소 안내, 신청 조건을 어떻게 묶는지 탐색할 수 있다. 모르는 카드를 억지로 아무 그룹에 넣게 하지 않고 혼동한 이유도 듣는다. 여기서는 실제 카드 소팅을 수행하지 않았다.

분류를 잘했다고 실제로 찾는다는 보장은 없다

카드 소팅은 분류를 만드는 입력이지만 여러 단계의 실제 탐색과 화면 문맥 전체를 재현하지 않는다. 참가자가 붙인 그룹명을 최종 메뉴 이름으로 그대로 승인할 필요도 없다. 서로 다른 사용자 유형의 분류를 하나의 평균으로 합치면 누구에게도 명확하지 않을 수 있다.

따라서 묶음의 공통점·차이와 이유를 정리하여 계층과 레이블 후보를 만들고 찾기 과업으로 이어 확인한다. 자료가 가상이면 그 지위를 유지한다. 카드 개수나 참가자 수를 채웠다고 전체 구조의 사용성이 보증되는 것은 아니다.

트리 테스팅은 구조에서 목적지를 찾게 한다

트리 테스팅은 시각적 화면 장식을 분리한 범주 계층에서 주어진 과업의 정보 위치를 찾게 하여 탐색 구조를 평가하는 방법이다. UR에서는 원하는 강좌 조건이나 이미 신청한 결과의 위치를 찾게 할 수 있다. 과업 문장에 정답 메뉴의 이름을 그대로 써서 길을 알려 주지 않는다.

목적지와 허용 경로, 직접 도착·되돌아간 뒤 도착·실패의 기록 규칙을 먼저 정한다. 이는 메뉴 구조의 확인이며 입력 양식·서버 처리·실제 기기의 전체 사용성 평가와 같지 않다.

TT-M1의 경로 결과를 성공률 하나로 덮지 않는다

도착 성공은 6/8=75%, 직접 성공은 4/8=50%, 되돌아간 뒤 성공은 2/8=25%다. 성공 6건 안에서만 직접 비율을 구하면 4/6≈66.67%로 다른 질문이다. 실패를 빼서 전체 직접 성공률이라고 쓰지 않는다.

TT-M1은 앞 절의 UR-M1과 별개의 합성 자료다. 숫자가 같다고 같은 참가자나 같은 시험이 아니며 대안 A/B의 실측 비교 결과도 아니다. 어떤 지점에서 잘못 들어갔는지와 레이블을 해석한 이유를 후속 질문으로 남긴다.

도달 가능한 구조도 틀린 경험을 만들 수 있다

UR-I1의 필요한 내용 집합은 C01 강좌 찾기, C02 신청 조건, C03 제출 전 검토, C04 제출 결과, C05 도움이다. 아래 가상 연결에서는 다섯 항목 모두에 도달할 수 있다.

화살표의 방향과 조건을 따라 연결을 읽습니다.

이것은 UR-I1의 정보 항목 연결 예이며 실제 처리나 사용자의 시간순 여정이 아니다. C01~C05의 경로 존재 5/5=100%와 C03 제목의 ‘신청 완료’ 오류는 별도 검사다. 필수 항목·검사 입력 누락은 전체 통과로 처리하지 않는다.

도달 비율 5/5=100%는 경로 존재의 검사다. C03의 제목을 신청 완료로 잘못 붙여도 경로는 그대로다. 따라서 제목·내용·상태의 뜻과 실제 과업 성공을 따로 확인해야 한다. 연결 하나를 빠뜨리거나 검사 입력에 필요한 항목이 누락된 경우도 전체 통과로 처리하지 않는다.

3. 사용자의 행동과 시스템의 상태를 연결한다

과업 흐름은 특정 목표를 이루기 위한 사용자의 행동과 시스템 응답·분기·되돌아감을 순서와 조건으로 표현한 것이다. UR의 강좌 선택→조건 확인→입력→검토→제출→결과 확인이 한 예다.

사이트맵의 분류 계층과 달리 한 과업에서 여러 위치를 지날 수 있고, 앞 절의 여정 지도보다 구체적인 동작과 분기를 다룬다. 정상 완료만 그리지 말고 조건 불충족·수정·중단·미확인과 지원의 경로를 함께 적는다.

UR-S1: 검토·전송·확정은 서로 다른 상태 · 상태 따라가기

입력을 작성하고 같은 내용의 R1을 검토한다. 모든 단계에서 화면·R1·서버 결과의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

이 그림은 주요 전이 일부를 보여 준다. REVIEW는 최종 확정이 아니다. 제출 후 같은 요청 R1의 결과를 확인하여 CONFIRMED·REJECTED·UNKNOWN을 구분한다. UNKNOWN에서 조회한 R1이 거절이면 REJECTED, 아직 미확인이면 UNKNOWN을 유지한다. 다른 요청 R2의 성공은 R1의 확정 근거가 아니다. UI 상태 전이는 서버 중복 방지 계약을 대신하지 않는다.

이 예의 조건

• 이 그림은 주요 전이 일부를 보여 준다. REVIEW는 최종 확정이 아니다. 제출 후 같은 요청 R1의 결과를 확인하여 CONFIRMED·REJECTED·UNKNOWN을 구분한다. UNKNOWN에서 조회한 R1이 거절이면 REJECTED, 아직 미확인이면 UNKNOWN을 유지한다. 다른 요청 R2의 성공은 R1의 확정 근거가 아니다. UI 상태 전이는 서버 중복 방지 계약을 대신하지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상EDIT	원 설명입력·수정
대상REVIEW	원 설명내용 검토
대상SUBMITTING	원 설명같은 R1 결과 대기
대상REJECTED	원 설명업무상 거절
대상UNKNOWN	원 설명R1 결과 미확인
대상CONFIRMED	원 설명R1 확정 확인

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결EDIT → REVIEW	원 라벨·방향검토로 / 정방향 / 실선
연결REVIEW → EDIT	원 라벨·방향다시 수정 / 정방향 / 실선
연결REVIEW → SUBMITTING	원 라벨·방향확정 요청 / 정방향 / 실선
연결SUBMITTING → CONFIRMED	원 라벨·방향R1 확정 / 정방향 / 실선
연결SUBMITTING → UNKNOWN	원 라벨·방향미확인 / 정방향 / 실선
연결SUBMITTING → REJECTED	원 라벨·방향업무상 거절 / 정방향 / 실선
연결UNKNOWN → CONFIRMED	원 라벨·방향R1 조회 확정 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
EDIT에서 REVIEW 입력을 작성하고 같은 내용의 R1을 검토한다.	값·보충 정보 화면·R1: EDIT→REVIEW 서버 결과: 아직 확정 전	변화·이유 검토 화면을 서버 완료 화면으로 표시하지 않는다.
SUBMITTING 같은 R1을 보내며 화면은 제출 중이다.	값·보충 정보 화면·R1: SUBMITTING·R1 서버 결과: 결과 확인 전	변화·이유 전송만으로 업무 성공을 약속하지 않는다.
확정·거절·미확인 확인한 결과에 따라 서로 다른 상태를 표시한다.	값·보충 정보 화면·R1: CONFIRMED / REJECTED / UNKNOWN 서버 결과: 실제 결과 대조	변화·이유 응답 미확인을 확정 거절로 섞지 않는다.
같은 R1 조회 UNKNOWN에서는 기존 R1을 조회하여 확인한 결과로 화면을 바꾼다.	값·보충 정보 화면·R1: 같은 R1 유지 서버 결과: 기존 결과 조회	변화·이유 새 R1을 만들어 같은 업무를 다시 처리하지 않는다.

UR-S1: 검토·전송·확정은 서로 다른 상태 · 상태 따라가기

입력을 작성하고 같은 내용의 R1을 검토한다. 모든 단계에서 화면·R1·서버 결과의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

이 그림은 주요 전이 일부를 보여 준다. REVIEW는 최종 확정이 아니다. 제출 후 같은 요청 R1의 결과를 확인하여 CONFIRMED·REJECTED·UNKNOWN을 구분한다. UNKNOWN에서 조회한 R1이 거절이면 REJECTED, 아직 미확인이면 UNKNOWN을 유지한다. 다른 요청 R2의 성공은 R1의 확정 근거가 아니다. UI 상태 전이는 서버 중복 방지 계약을 대신하지 않는다.

이 예의 조건

• 이 그림은 주요 전이 일부를 보여 준다. REVIEW는 최종 확정이 아니다. 제출 후 같은 요청 R1의 결과를 확인하여 CONFIRMED·REJECTED·UNKNOWN을 구분한다. UNKNOWN에서 조회한 R1이 거절이면 REJECTED, 아직 미확인이면 UNKNOWN을 유지한다. 다른 요청 R2의 성공은 R1의 확정 근거가 아니다. UI 상태 전이는 서버 중복 방지 계약을 대신하지 않는다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

관계도의 보충 설명

원그림의 모든 대상과 설명

대상	원 설명
대상EDIT	원 설명입력·수정
대상REVIEW	원 설명내용 검토
대상SUBMITTING	원 설명같은 R1 결과 대기
대상REJECTED	원 설명업무상 거절
대상UNKNOWN	원 설명R1 결과 미확인
대상CONFIRMED	원 설명R1 확정 확인

원그림의 모든 관계와 조건

연결	원 라벨·방향
연결EDIT → REVIEW	원 라벨·방향검토로 / 정방향 / 실선
연결REVIEW → EDIT	원 라벨·방향다시 수정 / 정방향 / 실선
연결REVIEW → SUBMITTING	원 라벨·방향확정 요청 / 정방향 / 실선
연결SUBMITTING → CONFIRMED	원 라벨·방향R1 확정 / 정방향 / 실선
연결SUBMITTING → UNKNOWN	원 라벨·방향미확인 / 정방향 / 실선
연결SUBMITTING → REJECTED	원 라벨·방향업무상 거절 / 정방향 / 실선
연결UNKNOWN → CONFIRMED	원 라벨·방향R1 조회 확정 / 정방향 / 실선

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
EDIT에서 REVIEW 입력을 작성하고 같은 내용의 R1을 검토한다.	값·보충 정보 화면·R1: EDIT→REVIEW 서버 결과: 아직 확정 전	변화·이유 검토 화면을 서버 완료 화면으로 표시하지 않는다.
SUBMITTING 같은 R1을 보내며 화면은 제출 중이다.	값·보충 정보 화면·R1: SUBMITTING·R1 서버 결과: 결과 확인 전	변화·이유 전송만으로 업무 성공을 약속하지 않는다.
확정·거절·미확인 확인한 결과에 따라 서로 다른 상태를 표시한다.	값·보충 정보 화면·R1: CONFIRMED / REJECTED / UNKNOWN 서버 결과: 실제 결과 대조	변화·이유 응답 미확인을 확정 거절로 섞지 않는다.
같은 R1 조회 UNKNOWN에서는 기존 R1을 조회하여 확인한 결과로 화면을 바꾼다.	값·보충 정보 화면·R1: 같은 R1 유지 서버 결과: 기존 결과 조회	변화·이유 새 R1을 만들어 같은 업무를 다시 처리하지 않는다.

상태는 현재 무엇을 알고 할 수 있는지를 구분한다

상호작용 상태는 사용자의 행동과 시스템 처리 과정에서 현재 확정된 사실·진행 상황·가능한 행동을 구분한 상태다. UR-S1은 편집 EDIT, 검토 REVIEW, 제출 중 SUBMITTING, 확정 CONFIRMED, 업무상 거절 REJECTED, 결과 미확인 UNKNOWN을 구별한다.

이 이름은 학습용 설계 계약이다. 서버의 데이터 구조나 법적 신청 효력을 자동 결정하지 않는다. UNKNOWN은 아무 처리도 안 됐다는 뜻이 아니며 REVIEW는 제출된 상태가 아니다. 화면의 제목·설명·버튼·다음 행동은 같은 상태의 의미를 보여 주어야 한다.

UR-S1의 전이 조건을 표로 쓴다

그림의 UNKNOWN→CONFIRMED는 조회로 확정 결과를 확인한 경우만 보여 준다. 조회는 성공을 보장하는 행동이 아니므로 같은 R1의 거절을 확인하면 REJECTED로, 여전히 불명이면 UNKNOWN으로 남긴다. 다른 요청 R2의 결과가 도착하거나 예상한 신청 내용과 다르면 R1을 확정 상태로 바꾸지 않는다. 원인 확인과 결과 조회가 필요하다. 서버 응답이 늦다는 이유로 새 의도의 식별자를 계속 만들어 제출하지 않는다.

제출 전 검토는 되돌아갈 수 있어야 한다

REVIEW에는 지금 제출할 강좌·조건·입력 내용을 요약하고 아직 제출 전이라는 뜻을 명확히 표현한다. 사용자가 틀린 값을 발견하면 그 항목을 수정하고 다른 값은 불필요하게 다시 입력하지 않도록 한다. 확인을 눌렀다는 사실과 업무가 확정됐다는 사실을 같은 이벤트로 묶지 않는다.

필요한 자격·정원 검사는 정책과 서비스 계약을 따른다. 화면 입력 형식 검사에 통과했다는 사실만으로 자격과 잔여 정원이 승인되었다고 표시할 수 없다. 최종 문구는 실제 업무 결과와 일치해야 한다.

피드백은 성공뿐 아니라 기다림과 복구를 설명한다

SUBMITTING에서 영원히 회전 그림만 보여 주면 사용자는 무엇을 해야 할지 모른다. 처리 중인지 결과를 확인할 수 없는지, 같은 신청을 다시 조회할 방법과 지원 경로를 상태에 맞게 안내한다. 아직 모르는 사실을 안심시키려고 성공으로 표시하지 않는다.

필드 오류는 해당 항목과 고칠 방법을 알려 주고, 업무상 거절은 실제 이유와 허용한 다음 행동을 설명한다. 중요 의미를 색 하나에만 맡기지 않고 텍스트·조작 순서·입력 보존도 살핀다. 상세 접근성 적합성 검사는 UX 아키텍처·디자인시스템·접근성의 기준과 실제 보조기술 확인이 필요하며 이 문장만으로 통과하지 않는다.

뒤로 가기와 버튼 비활성화는 서버 취소가 아니다

사용자가 SUBMITTING에서 뒤로 가거나 창을 닫아도 이미 보낸 R1이 서버에서 확정될 수 있다. 화면을 EDIT로 보이게 바꾸었다는 이유로 R1을 존재하지 않는 신청으로 취급하면 다시 신청할 때 중복 효과를 만들 수 있다. 결과 식별과 조회의 책임을 유지한다.

반복 클릭을 줄이려고 버튼을 비활성화하는 것은 UI 수준의 보조 수단이다. 재연결·다른 창·재시도에서도 중복 효과를 막으려면 앞서 배운 식별자와 처리 계약이 필요하다. 화면 스크립트의 상태 전이 검사와 실제 서버 멱등성 검사를 혼동하지 않는다.

같은 색의 세 화면을 의미로 구별한다

V2는 문구의 한 가지 모순을 고친 안이다. 사용자가 반드시 이해한다고 검증한 결과는 아니며 제출 버튼·설명·접근 경로와 함께 확인한다. V3도 제목만 맞고 실제 신청 ID가 다른 경우에는 올바른 결과가 아니다. 예쁜 외형의 평가와 상태·내용의 정확성 검토를 나눈다.

프로토타입은 모르는 것을 배우기 위한 표현이다

UR의 종이 흐름이나 클릭 가능한 화면으로 분류·이름·검토와 결과의 구분을 먼저 확인할 수 있다. 검토할 질문에 맞게 표현의 상세도를 정하고, 실제 제출이나 개인정보 수집이 일어나지 않는 학습용 상태를 명시한다.

프로토타입에서 확정 화면을 눌러 볼 수 있다는 사실은 서버 저장·보안·성능·법적 신청이 작동한다는 증거가 아니다. 실제 운영에 쓸 품질과 검증을 갖추지 않은 코드를 그대로 배포하지 않는다. 프로토타입과 사용성 평가의 상세 방법은 프로토타입·사용성 평가·개선에서 이어 다룬다.

대안의 선택은 사용자·정보·상태를 함께 대조한다

UR-C1을 지지하려면 사용자가 강좌를 찾는 경로, 필요한 조건의 내용, 검토·제출·결과의 상태, 오류·조회·지원 경로가 서로 맞아야 한다. 한 층의 장점으로 다른 층의 필수 모순을 상쇄하지 않는다. 메뉴가 한 단계 짧아졌다고 거짓 확정 문구를 허용하지 않는다.

현재는 A/B의 실제 비교 자료가 없으므로 하나가 우수하다고 점수를 만들지 않는다. 어떤 조건에서 어떤 대안을 우선 검토하며 남은 질문을 어떻게 확인할지 기록한다. 접근 경로가 길다는 사실과 사용자가 길을 잃는다는 사실도 같은 척도가 아니다.

인계 묶음과 종료 기준을 만든다

UR-DESIGN-01에는 문제와 목표 UR-P1·UR-C1, 정보 목록·분류·명칭의 판본, 과업 흐름, UR-S1의 전이·문구·입력 보존 규칙, 검증할 과업과 미확인 정책을 함께 넣는다. 변경하면 관련 내용·버튼·오류·결과 조회를 동시에 추적한다.

종료는 모든 화면을 그렸다는 상태가 아니다. 필수 내용과 경로의 누락, 상태 의미의 모순을 확인하고 사용자 검증이 필요한 대안과 담당·기준을 다음 단계에 넘기는 것이다. 실제 이해·접근성·운영 품질이 미검증이면 그 지위를 그대로 남긴다.

한 번에 적게 보여 주기와 맥락을 잃지 않기

UR의 입력을 여러 단계로 나누면 지금 답할 항목을 줄일 수 있지만 앞에서 무엇을 골랐는지 잊거나 수정 경로가 길어질 수 있다. 반대로 모든 것을 한 화면에 넣으면 비교는 쉬워도 복잡한 조건을 구별하기 어려울 수 있다.

과업의 중요 정보, 수정 빈도, 사용 환경과 오류 피해를 보며 대안을 만든다. 언제나 세 번 안에 클릭해야 한다는 고정 법칙으로 결정하지 않는다. 사용자가 올바르게 판단하고 복구할 수 있는지 같은 성공 조건 아래 확인한다.

기획을 검증으로 둔갑시키는 표현을 피한다

가상 카드 소팅을 사용자 의견이라고 부르거나 TT-M1의 75%를 실측 만족도라고 쓰면 근거의 종류가 바뀐다. 연결 검사 100%를 사용성 통과로 바꾸거나 상태 전이 스크립트 통과를 서비스의 중복 방지 보장으로 쓰는 것도 같은 오류다.

산출물에서는 가정·설계 의도·계산·실제 관찰·미확인을 구별한다. 이 구분은 작업을 멈추라는 뜻이 아니라 다음에 어떤 증거가 필요한지 알려 준다. 다음 UX 아키텍처·디자인시스템·접근성은 이 결정을 여러 화면·구성요소·접근성 규칙에 일관되게 유지하는 구조로 확장한다.

UI/UX 콘셉트 기획의 답안을 완성한다

콘셉트 기획은 사용자 문제와 경험 목표를 구체적인 정보·탐색·행동·상태의 대안으로 만드는 활동이다. UR에서 대상·목표·해결 원리를 정하고, 정보 목록과 분류·레이블, 과업 흐름과 결과·복구 경로를 맞춘 뒤 카드 소팅·트리 테스팅·프로토타입으로 확인할 질문을 구분했다.

답안에는 자료와 설계의 한계, 필수 조건과 미확인, 다음 단계의 담당·검증 기준까지 포함한다. 콘셉트 문구·화면 수·경로 존재·합성 성공률만으로 실제 경험이 개선됐다고 결론 내리지 않는다.

독립 연습 — R2의 성공으로 R1을 확정해도 될까

다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.

사용자가 R1을 제출하여 SUBMITTING 상태가 되었다. 연결이 끊긴 뒤 다른 요청 R2의 성공 응답이 도착했다. 아직 R1의 결과와 신청 ID는 확인하지 않았다. 화면이 큰 축하 문구와 “신청 완료”를 표시하려 한다.

• R1의 현재 표시 상태와 허용할 다음 행동을 쓰라.
• 다른 요청의 성공, 버튼 비활성화, 검토 화면 도달이 각각 보장하지 못하는 것을 설명하라.

풀이와 오답 교정 보기

R1은 결과 미확인 UNKNOWN으로 남긴다. 같은 R1의 결과를 조회하거나 정한 지원 경로로 확인하며 R2의 성공으로 R1을 CONFIRMED로 바꾸지 않는다. 버튼 비활성화는 화면의 반복 조작을 줄일 수 있지만 서버 중복 효과 방지의 증거가 아니다. REVIEW는 제출 전이고 실제 신청 완료가 아니다. 확정 제목은 같은 요청의 확정 근거와 신청 ID를 확인했을 때에만 맞다.

축하 문구를 확정 근거로 썼다면 상태별 근거, 시간초과를 거절로 썼다면 응답 없는 상황을 다시 연결한다.

4. 자체 10점 문제

UI/UX 콘셉트 기획에서 정보구조와 과업 흐름·상호작용 상태의 관계를 설명하고, 카드 소팅과 트리 테스팅의 용도를 구분하시오.

실제 기출이 아닌 자체 연습문제다. 용어의 뜻뿐 아니라 조사 근거를 어느 설계 판단과 확인 방법에 연결하는지 설명한다.

10점 풀이와 답안 구성 보기

10점 답안 목차

1. 목표에서 콘셉트로
2. 정보와 행동의 연결
3. 분류 탐색과 구조 평가
4. 근거와 다음 단계

10점 답안 도식

문제·경험 목표에서 콘셉트 원리를 정하고 정보의 분류·레이블·탐색과 과업·상태·피드백을 함께 맞춘다. 정보 연결 그림과 UR-S1 상태 그림을 구분해 읽고, 확인할 질문·근거·미확인을 다음 설계·평가로 넘긴다.

10점 모범답안

1. 목표에서 콘셉트로

사용자 문제·경험 목표·미확인을 입력으로 대상·해결 원리·범위를 정한다. 화면의 장식이 아니라 어떤 어려움을 어떤 흐름으로 줄일지 설명하며 가상 근거를 실제 검증 결과로 표시하지 않는다.

2. 정보와 행동의 연결

정보구조는 내용의 분류·관계·명칭과 탐색을 조직한다. 과업 흐름은 목표를 이루는 행동·응답·분기이며 상호작용 상태는 확정 사실과 가능한 행동을 구별한다. 메뉴와 화면 제목이 검토·확정 등 상태의 뜻과 일치해야 한다.

3. 분류 탐색과 구조 평가

카드 소팅은 내용 항목의 그룹화에서 분류 기대를 배우는 방법이고 트리 테스팅은 정한 계층에서 과업의 정보 위치를 찾게 하는 방법이다. 그룹 결과를 최종 메뉴로 자동 승인하지 않고 목적지·경로·실패와 혼동 이유를 확인한다.

4. 근거와 다음 단계

필수 내용·경로·상태·복구의 일관성을 확인하고 대안의 미확인과 검증할 과업을 인계한다. 구조 검사나 프로토타입을 실제 사용 성과·서버 처리·운영 승인으로 확대하지 않는다.

5. 자체 25점 문제

도서관 강좌 신청에서 제출 전 검토 화면의 제목이 신청 완료이고 제출 시간초과를 실패로 안내한다. 다섯 정보 항목의 연결 검사는 100%이며, 별도의 합성 트리 과업 8건은 직접 성공 4·되돌아간 뒤 성공 2·실패 2이다. 콘셉트·정보구조·상호작용 개선과 지표 해석, 확인 및 인계 방안을 제시하시오.

실제 기출이 아닌 자체 연습문제다. 서로 다른 검사의 분모와 대상을 유지하고 실제 확정 근거가 없는 성공·실패 표시를 교정한다.

25점 풀이와 답안 구성 보기

25점 답안 목차

1. 문제와 설계 방향
2. 정보구조와 확인 방법
3. 수치와 근거의 분리
4. 검토·제출·결과의 계약
5. 복구·중복 효과 경계
6. 평가·인계·한계

25점 답안 도식

UR-P1→UR-C1에서 정보·레이블과 과업·상태를 구체화하되 경로 검사 ≠ 의미 검사 ≠ 실제 사용자 평가를 유지한다. UR-S1의 REVIEW는 제출 전이고 SUBMITTING 뒤에는 같은 R1의 CONFIRMED·REJECTED·UNKNOWN 근거를 구별한다. 미확인은 같은 요청 결과 조회·지원으로 확인하고 근거·담당을 인계한다.

25점 모범답안

1. 문제와 설계 방향

강좌 조건을 비교하고 검토와 확정을 구별하며 불명확한 결과를 조회할 수 있다는 UR-C1을 제안한다. 보기 좋은 완료 화면이 아니라 정확한 신청 이해가 목표다. 정책과 실제 사용자 근거가 미확인이면 설계 가정으로 남긴다.

2. 정보구조와 확인 방법

내용 목록·분류·레이블과 부서 우선/과업 우선 대안을 같은 범위에서 비교한다. 카드 소팅으로 분류 기대를 탐색하고 트리 과업으로 목적지와 경로를 확인한다. 문제 문장에 정답 메뉴 이름을 넣어 성공을 유도하지 않는다.

3. 수치와 근거의 분리

트리 도착 성공은 6/8=75%, 직접 성공은 4/8=50%, 되돌아간 뒤 성공은 2/8=25%다. 성공 6건만 분모로 바꾸어 전체 직접 성공을 높이지 않는다. 정보 도달 5/5=100%도 잘못된 완료 제목을 검출하지 못하므로 상태 의미·과업 성공과 따로 판단한다.

4. 검토·제출·결과의 계약

REVIEW는 제출 전이며 수정 경로와 기존 값을 유지한다. R1 제출 뒤에는 SUBMITTING, 같은 요청의 확정 근거와 신청 ID를 확인한 때만 CONFIRMED로 표시한다. 실제 거절과 결과 미확인 UNKNOWN을 구별하고 제목·내용·행동의 뜻을 맞춘다.

5. 복구·중복 효과 경계

시간초과나 창 닫기를 서버 취소로 해석하지 않고 같은 요청의 결과를 확인한다. R2의 결과로 R1을 확정하지 않으며 버튼 비활성화만으로 서버 중복 방지를 보장하지 않는다. 오류와 조회·지원 경로를 정상 흐름과 함께 검토한다.

6. 평가·인계·한계

가상 트리 자료와 계산을 실제 사용자 선호나 사용성 개선 결과로 부풀리지 않는다. 정보·흐름·전이·문구의 판본과 근거·미확인·담당·검증 과업을 인계하고 프로토타입의 질문과 운영 품질 검사를 구분한다. 핵심 의미가 검증되지 않으면 사용 승인을 보류한다.

출처와 사례의 경계

• SRC-UX-NNG-TREE — Nielsen Norman Group / Page Laubheimer, Tree Testing: Fast, Iterative Evaluation of Menu Labels and Categories. 위치: What Is Tree Testing?; The Tree-Testing Process; Tree-Testing Tasks; Tree Testing vs. Card Sorting: Different Purposes; Limitations of Tree Testing. 발행: 2023-08-06. 확인: 2026-09-06.
• SRC-UX-NNG-CARDS — Nielsen Norman Group / Samhita Tankala and Katie Sherwin, Card Sorting: Uncover Users’ Mental Models for Better Information Architecture. 위치: Definition of Card Sorting; Card-Sorting Process; Conduct a Card Sort; Analyze Card-Sorting Data; Limitations to Card Sorting. 발행: 2024-02-02. 확인: 2026-09-06.
• SRC-UX-GOV-CHECK — GOV.UK Design System, Check answers. 위치: When to use this pattern; How it works; Make the page easy to understand. 발행: 원문 발행일 미확정. 확인: 2026-09-06.
• SRC-UX-GOV-PROTOTYPE — UK Government Digital Service, Making prototypes. 위치: When to use prototypes; Types of prototype; Using code prototypes; Sharing code prototypes; Testing your prototypes. 발행: 2016-10-18. 확인: 2026-09-06.

정의·방법의 제한된 사실만 위 원문에서 대조하고 사례·수치·표·도식·문제는 독립적으로 작성했다. 영국 지침을 한국의 법적 의무로 옮기지 않는다. 실제 사용자 조사나 운영 시스템의 개선 효과를 측정한 기록이 아니다. 출처 보존과 공개 이용권한, 사람 독립검토와 독자 검증은 별도이며 미완료다.

한 번에 되찾기

콘셉트는 사용자 문제를 정보·탐색·행동·상태의 구체적 대안으로 연결한다. 카드 소팅과 트리 테스팅의 질문을 구별하고, 도달 가능성과 올바른 의미·실제 과업 성공을 따로 검토한다. 검토·제출·확정·거절·미확인의 문구와 행동을 맞추며 근거·예외·검증할 질문을 다음 설계 단계에 넘긴다.