ux-design-for-architects
아키텍트가 UI 외의 사용자 접점(API / 설정 / 확장 기능)의 UX를 설계 및 검토하기 위한 지침입니다. UI 화면 디자인(색상, 레이아웃 등)은 대상이 아닙니다.
UX는 UI뿐만 아니라 시스템과 사용자의 모든 접점에 영향을 미칩니다. 접점의 UX가 나쁘면 (사용자가 의존하기 때문에) 나중에 변경하기 어려워지고, 시스템 전체의 성공 확률이 낮아집니다. 따라서 구현보다 먼저 결정해야 합니다.
진행 방법
- 접점 식별: 대상은 API / 설정 / 확장 기능 중 하나(또는 여러 개)입니다.
- 사용자 식별(원칙 1): 누가, 어떤 목적으로, 어떤 기술 수준으로 사용하는지 파악합니다.
- 해당 접점의 상세 가이드 읽기:
- 설정 →
references/configuration.md - API →
references/api.md - 확장 기능 →
references/extensions.md
- 설정 →
- 6가지 원칙으로 검토(아래 참조). 설계안을 제시하는 경우, 원칙에 따른 근거를 한 줄씩 첨부합니다.
- 검토인 경우,
references/review-checklist.md형식으로 지적합니다. - 판단이 엇갈리는 점은 사용자에게 가설과 함께 확인합니다(AskUserQuestion).
UX의 6대 원칙
| # | 원칙 | 요점 | 이유 |
|---|---|---|---|
| 1 | 사용자 이해 | 목표, 기술 수준, 멘탈 모델, 일반적인 워크플로를 파악하여 예상대로 작동하게 함 (최소 놀람의 원칙) | 사용자는 자신의 예상과 다른 행동을 합니다. 듣는 것보다 관찰과 측정이 효과적입니다 |
| 2 | 필요 최소한의 일만 하기 | 필요한 기능만 제공합니다. 널리 사용되는 표준(OAuth, OpenID 등)이 있다면 채택합니다 | 제공한 것은 부채가 됩니다. 한 번 내놓으면 사용자가 익숙해져서 고치기 어렵습니다 |
| 3 | 매뉴얼 불필요 | 사용 방법을 자명하게 만들고, 추천이나 단서를 통해 안내합니다 | 사용자는 매뉴얼을 읽지 않습니다. 해결할 수 없으면 제품이 나쁘다고 판단합니다 |
| 4 | 정보 교환 관점에서 생각하기 | 묻지 않고 해결하기 > 적게 묻기 > 답변하기 쉬운 형태로 묻기. 같은 것을 두 번 묻지 않습니다 | 입력은 부담입니다. 추측, 기억, 유도를 통해 줄일 수 있습니다 |
| 5 | 단순한 것은 단순하게 | 처음 몇 번의 조작 장벽을 제거합니다. 사전 설정된 클라이언트나 샘플을 준비합니다 | 초보자일수록 이탈하기 쉽습니다. 첫 경험이 정착을 결정합니다 |
| 6 | 구현보다 먼저 UX 설계 | 아키텍처보다 UX를 먼저 설계하고, 피드백을 주고받으며 구체화합니다 | 구현 후 UX 변경은 비용이 높습니다. 구현은 늦추고 설계는 깊게 합니다 |
정보를 묻는 상황의 판단(원칙 4 구체화)
우선 순위로 생각합니다:
- 묻지 않음: 합리적인 기본값, 환경에서 자동 감지, 과거 입력 기억, 알려진 정보에서 유도
- 적게 묻기: 정말 필요한 것만
- 답변하기 쉽게 묻기: 내부 구현 용어가 아니라 사용자가 머리로 계산하지 않고 답할 수 있는 형태로 묻습니다 (예: "최대 캐시 항목 수" 대신 "캐시에 사용할 메모리 상한", 나아가 "서버인가 클라이언트인가"와 같은 모드 선택에서 세부 사항 유도)
출력/응답 반환 상황(원칙 4)
성능상 문제가 없다면, 사용자가 이해할 수 있는 형태로 충분한 정보를 반환하고 다음 행동을 예측할 수 있도록 합니다. 어떤 호출의 결과를 다음 호출에 전달하는 경우, 가공을 최소화하여 전달할 수 있도록 합니다.
접점별 요약
- 설정: 설정은 "도입하지 않는 것"이 최선입니다. 다음으로 자동 결정, 마지막으로 합리적인 기본값과 함께 도입합니다. 질문은 "사용자가 우리보다 더 나은 맥락을 가지고 있는가?"입니다. — Yes인 경우에만 설정으로 만듭니다. 알 수 없는 키, 적용 실패는 묵살하지 않고 오류 처리합니다. 유효한 설정 값은 시작 시 등에 확인할 수 있도록 합니다.
- API: 사용자는 개발자입니다. 배우기 쉽고, 오용하기 어렵고, 다음 단계가 항상 명확해야 합니다. 한 가지 일을 잘 수행합니다. 상용구 코드를 작성하게 하지 않습니다. 표준을 따릅니다. 처음부터 버전 관리를 합니다. 공개는 필요할 때까지 늦추고, 먼저 내부에서 사용합니다.
- 확장 기능: 사용 사례를 깊이 이해할 때까지 추가를 기다립니다 (나중에 리팩토링으로 추가 가능). 한 가지 일을 잘 수행합니다. 입출력을 정의하고 내부 구조를 노출하지 않습니다. 한 번 공개하면 변경하기 어렵습니다.
자주 발생하는 실패 (설계/검토 시 의심)
- UX 전문 지식 부족 / 전문가 초청 지연
- UI만 보고 API, 설정, 확장 기능의 UX 간과
- 기술 리더가 UX를 결정하고 전문가에게 UI 미세 조정만 요청
- 전문가의 제안 무시
- 두 가지 안에서 고민하다 설정으로 도피 (문제를 사용자에게 전가)
전문가가 없는 경우, 그 사실을 명시하고 UX 전문가를 조기에 참여시킬 것을 권장합니다. 단, 조언을 거부하여 설계를 중단하지 말고, 본 가이드에 따른 임시 안을 제시합니다.
반복적 진행 방식과의 연결
- 사용자 여정에서 설계 도출 → 여정상의 각 접점에 본 가이드 적용
- 반복적으로 분할 → 첫 번째 분할에서 필요한 접점만 생성 (공개 API나 확장 기능은 MVP 이후인 경우가 많음)
- 변경이 어려운 것은 깊게 설계하고 천천히 구현 → UX가 대표적인 예. 실제 사용 관찰을 통해 학습
출력 형식
설계 제안: "대상 접점 → 사용자 이미지 → 제안 → 해당 원칙 및 이유 → 미결 사항" 순서로 간결하게.
검토: references/review-checklist.md 형식.