Windows 앱 UX 설계 - 이용 환경별 우선순위

Windows 앱의 UX를 생각할 때, 처음에 “모던하게 보이는가”, “여백이 깔끔한가”부터 들어가면 순서를 잘못 잡기 쉽습니다.

Windows 데스크톱에서 UX는 외관만으로 정해지지 않습니다.

• 키보드로 어디까지 완결할 수 있는가
• 마우스 전제인가, 터치 전제인가
• 장시간 사용하는가, 가끔 몇 분만 사용하는가
• 감시인가, 입력인가, 현장 단말인가
• 오조작했을 때 어떤 영향이나 손실이 생기는가
• 문자 확대, 대비 테마, 스크린 리더 등 지원 기술을 써도 문제 없이 조작할 수 있는가

이 요소들이 모두 합쳐진 것이 UX입니다.

flowchart TB
    accTitle: 외관만으로 정해지지 않는 UX
    accDescr: 키보드로 완결할 수 있는지, 마우스인지 터치인지, 이용 시간과 용도, 오조작했을 때의 영향이나 손실, 스크린 리더 등 지원 기술을 써도 문제 없이 조작할 수 있는지까지 모두 합쳐 UX임을 나타내는 그림.
    a1["입력 방식과 조작의 완결도"] --> a4["모두 합쳐 UX"]
    a2["이용 시간과 용도"] --> a4
    a3["실수 비용과 지원 기술"] --> a4
    a4 -.-> a5["'모던하게 보이는가'부터 들어가면 순서를 잘못 잡는다"]

그림 1: Windows 데스크톱의 UX는 외관보다 먼저 이용 맥락의 묶음으로 정해집니다.

더 까다로운 점은 BtoC와 BtoB에서 무게 중심이 다르다는 것입니다. 다만 여기서 “BtoB이니 정보를 채워 넣으면 된다”, “BtoC이니 부드럽게 가볍게 만들면 된다”고 생각하면, 대체로 어딘가에서 사고가 납니다.

예를 들어 같은 BtoB라도,

• 경리 입력이나 수발주 관리 같은 사무 앱
• 공장, 창고, 접수, 검사 장치 같은 현장 단말
• 24시간 감시나 보수 대응의 운영 화면

에서는 좋은 UX의 조건이 꽤 다릅니다.

반대로 BtoC라도,

• 개인용 작은 유틸리티
• 이미지 편집, 음악 제작, 투자 분석 같은 상급자 쪽 도구

에서는 UI 밀도도 바로 가기에 대한 요구도 전혀 다릅니다.

flowchart TB
    accTitle: 같은 라벨이라도 조건이 다르다
    accDescr: 같은 BtoB라도 사무 앱·현장 단말·운영 화면에서 좋은 UX의 조건이 꽤 다르고, BtoC라도 작은 유틸리티와 상급자 쪽 도구에서는 밀도와 바로 가기 요구가 전혀 다름을 나타내는 그림.
    b0["BtoB라는 같은 라벨"] --> b1["사무·현장 단말·운영 화면"]
    b1 --> b2["좋은 UX의 조건이 꽤 다르다"]
    c0["BtoC라는 같은 라벨"] --> c1["유틸리티·상급자 도구"]
    c1 --> c2["밀도도 바로 가기 요구도 다르다"]

그림 2: BtoC / BtoB라는 같은 라벨 안에서도 좋은 UX의 조건은 갈립니다.

Microsoft의 Windows용 설계 지침도, Windows 앱 설계는 직관적이고 접근하기 쉬우며, 입력 방식이나 폼 팩터를 가로질러 일관되게 동작할 것을 중시합니다.¹²

이 글에서는 Windows 앱 UX를 용도별 판단표로 정리합니다. 설계 리뷰나 화면 설계 초기 단계에서 “이 앱은 무엇을 우선해야 하는가”를 가르기 쉽게 하는 것이 목적입니다.

이 글의 대상 독자와 전제

이 글에서 쓰는 용어

1. 먼저 결론

먼저 거칠게 말하면 이렇습니다.

• BtoC에서는 먼저 첫 이해의 쉬움, 안심감, 설정의 적음, 동선의 곧음을 우선합니다
• BtoB에서는 먼저 지속 효율, 오조작 방지, 키보드 지원, 안정된 배치를 우선합니다
• 다만 BtoB의 현장 단말은 밀도보다 명확함, 큰 조작 대상, 짧은 동선이 우선입니다
• 다만 BtoC의 상급자용 도구는 쉬움보다 정보 밀도, 바로 가기, 사용자 지정이 우선입니다
• Windows 앱에서는 키보드 / 마우스 / 터치 / 텍스트 확대 / 대비 테마 / 지원 기술까지 넣어 UX를 생각하는 편이, 나중에 설계가 깨지기 어렵습니다¹³⁴⁵⁶⁷

처음에 정말로 정해야 할 것은 BtoC인지 BtoB인지만이 아닙니다. 먼저 언어화하고 싶은 것은 다음 다섯 가지입니다.

1. 누가 쓰는가 (초보자, 숙련자, 혼재)
2. 어디서 쓰는가 (책상, 회의실, 현장, 공장, 접수, 옥외)
3. 무엇으로 조작하는가 (키보드, 마우스, 터치, 펜, 바코드, 지원 기술)
4. 얼마나 쓰는가 (첫 사용 중심, 가끔, 매일, 하루 종일)
5. 실수했을 때 비용은 무엇인가 (가벼움, 무거움, 위험, 감사 대상)

이 다섯 가지가 보이면 UI 밀도, 내비게이션, 바로 가기, 확인 대화 상자, 사용자 지정의 우선순위가 훨씬 정해지기 쉽습니다.

flowchart TB
    accTitle: 먼저 언어화하는 다섯 가지 질문
    accDescr: 누가 쓰는가, 어디서 쓰는가, 무엇으로 조작하는가, 얼마나 쓰는가, 실수했을 때 비용은 무엇인가의 다섯 가지가 보이면 UI 밀도나 내비게이션, 확인 대화 상자 등의 우선순위가 정해지기 쉬움을 나타내는 그림.
    q1["1. 누가 쓰는가"] --> q2["2. 어디서 쓰는가"]
    q2 --> q3["3. 무엇으로 조작하는가"]
    q3 --> q4["4. 얼마나 쓰는가"]
    q4 --> q5["5. 실수 비용은 무엇인가"]
    q5 --> q6["밀도·내비·대화 상자의 우선순위가 정해진다"]

그림 3: BtoC인지 BtoB인지보다 먼저, 다섯 가지 질문을 언어화하면 우선순위가 정해집니다.

이 글의 지식 맵

이 기사는 Windows 앱의 UX 설계를 BtoC/BtoB라는 분류만이 아니라, 누가·어디서·무엇으로 조작하는가·얼마나 사용하는가·실수의 비용은 무엇인가라는 이용 맥락으로 판단해야 한다고 정리합니다. BtoC용 유틸리티에는 상부 내비와 처음 접했을 때의 이해 용이성이 어울리고, 사무계 BtoB에는 리스트/상세와 키보드 조작성이, 감시·운용에는 좌측 내비와 색에만 의존하지 않는 상태 표시, 복수 경로의 커맨드, 불가역 조작에 대한 확인 다이얼로그가, 현장 단말에는 충분히 큰 터치 타겟과 hover에 의존하지 않는 설계가, 전문가용 도구에는 탭과 충실한 키보드 지원이 어울린다고 봅니다. 아울러 터치 타겟 7.5mm 사방이나 대비비 4.5:1 같은 수치 기준과, 글자 확대나 대비 테마를 따라가는 레이아웃의 중요성도 다룹니다.

flowchart LR
    accTitle: Windows 앱 UX 설계 판단 축 지식 맵
    accDescr: 누가·어디서·무엇으로 조작하는가라는 이용 맥락이 내비게이션 패턴이나 터치 타겟, 키보드 조작성, 다이얼로그 사용법 같은 UX의 우선순위를 결정함을 보여주는 그림
    tob_field_device_ui["BtoB 현장 단말·장치 UI·키오스크"]
    tob_back_office_app["BtoB 사무 입력·백오피스 앱"]
    top_navigation["상단 내비게이션"]
    toc_utility_app["BtoC용 유틸리티/개인용 앱"]
    left_navigation["왼쪽 내비게이션"]
    tob_monitoring_app["BtoB 모니터링·운영 앱"]
    list_detail_navigation["목록/상세 내비게이션"]
    tab_navigation["탭 내비게이션"]
    expert_tool_ui["전문가용 편집·분석 도구"]
    touch_target_size_guideline["터치 대상 최소 크기 기준"]
    color_only_state_indication["색상만으로 상태 표시"]
    hover_only_interaction["호버 전용 조작"]
    multi_entry_commanding["명령의 다중 경로 제공"]
    inline_validation_error["인라인 유효성 검사 오류 표시"]
    confirmation_dialog_for_irreversible_action["되돌릴 수 없는 작업 확인 대화 상자"]
    keyboard_accessibility["키보드 접근성"]
    contrast_theme_support["고대비 테마 지원"]
    fixed_size_layout["고정 크기 레이아웃"]
    text_contrast_ratio_guideline["텍스트 명도 대비 기준"]
    content_spacing_guideline["콘텐츠 간격 기준(8/12/16epx)"]
    tray_resident_app["상주 도구·트레이 앱"]
    custom_control_overuse["커스텀 컨트롤 남용"]
    top_navigation -->|"권장되는 대응"| toc_utility_app
    left_navigation -->|"권장되는 대응"| tob_monitoring_app
    left_navigation -->|"권장되는 대응"| tob_back_office_app
    list_detail_navigation -->|"권장되는 대응"| tob_back_office_app
    tab_navigation -->|"권장되는 대응"| expert_tool_ui
    touch_target_size_guideline -->|"권장되는 대응"| tob_field_device_ui
    color_only_state_indication -->|"사용은 비권장"| tob_monitoring_app
    hover_only_interaction -->|"사용은 비권장"| tob_field_device_ui
    hover_only_interaction -->|"사용은 비권장"| tob_monitoring_app
    multi_entry_commanding -->|"권장되는 대응"| tob_monitoring_app
    multi_entry_commanding -->|"권장되는 대응"| expert_tool_ui
    inline_validation_error -->|"권장되는 대응"| tob_back_office_app
    confirmation_dialog_for_irreversible_action -->|"권장되는 대응"| tob_monitoring_app
    keyboard_accessibility -->|"권장되는 대응"| tob_back_office_app
    keyboard_accessibility -->|"권장되는 대응"| expert_tool_ui
    keyboard_accessibility -->|"권장되는 대응"| hover_only_interaction
    contrast_theme_support -->|"권장되는 대응"| fixed_size_layout
    contrast_theme_support -.->|"전제로 한다"| text_contrast_ratio_guideline
    content_spacing_guideline -->|"권장되는 대응"| fixed_size_layout
    confirmation_dialog_for_irreversible_action -->|"사용은 비권장"| tray_resident_app
    expert_tool_ui -.->|"양립하지 않는다"| toc_utility_app
    contrast_theme_support -->|"권장되는 대응"| custom_control_overuse
    keyboard_accessibility -->|"권장되는 대응"| custom_control_overuse

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 23건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. BtoC / BtoB는 입구이지, 답이 아닙니다

BtoC / BtoB라는 구분은 첫 입구로는 편리합니다. 다만 UX의 정답을 정하는 힘이 센 것은, 사는 사람 종류보다 쓰는 방식의 종류입니다.

예를 들어, 거칠게 두 축으로 보면 이런 식입니다.

즉,

• BtoC = 언제나 가벼운 UI
• BtoB = 언제나 고밀도 UI

가 아닙니다.

Windows 앱 설계 지침에서도 디바이스, 입력 종류, 폼 팩터를 가로질러 일관되게 쓸 수 있을 것이 중시되며, 접근성 관점에서도 장애 유무만이 아니라 밝은 옥외, 공유 공간, 조용한 장소, 시끄러운 장소 같은 환경 제약까지 넣어 생각하는 것이 중요하다고 합니다.¹²

flowchart TB
    accTitle: 사는 사람 종류보다 쓰는 방식의 종류
    accDescr: BtoC는 언제나 가벼운 UI, BtoB는 언제나 고밀도 UI라는 등식은 성립하지 않고, UX의 정답을 정하는 힘이 센 것은 사는 사람 종류보다 쓰는 방식의 종류임을 나타내는 그림.
    e1["BtoC = 언제나 가벼운 UI"] --> e3["이 등식은 성립하지 않는다"]
    e2["BtoB = 언제나 고밀도 UI"] --> e3
    e3 --> e4["정답을 정하는 것은 쓰는 방식의 종류"]
    e4 -.-> e5["환경 제약까지 넣어 생각한다"]

그림 4: UX의 정답을 정하는 것은, 사는 사람 종류보다 쓰는 방식의 종류가 됩니다.

그래서 BtoC / BtoB를 본 뒤에, 다음 축으로 한 번 더 가르는 것이 좋습니다.

여기를 먼저 갈라 두면, 회의 중의 “왠지 모던”, “왠지 업무 같다”는 논의가 꽤 줄어듭니다.

3. 한 장으로 보는 용도별 판단표

먼저, 실무에서 가장 쓰기 쉬운 표를 둡니다.

이 표만으로도 대체적인 방향은 보입니다. 특히 중요한 것은, BtoB라도 현장 단말은 고밀도 UI가 정답이 아니다는 점, 그리고 BtoC라도 상급자 도구는 가벼움보다 효율이 정답이 된다는 점입니다.

flowchart TB
    accTitle: 라벨과 정답이 뒤집히는 두 예
    accDescr: BtoB라도 현장 단말은 고밀도 UI가 정답이 아니고, BtoC라도 상급자 도구는 가벼움보다 효율이 정답이 된다는, 라벨에서 상상하는 정답이 뒤집히는 두 예를 나타내는 그림.
    f1["BtoB의 현장 단말"] --> f2["고밀도 UI가 정답이 아니다"]
    f3["BtoC의 상급자 도구"] --> f4["가벼움보다 효율이 정답"]
    f2 --> f5["라벨이 아니라 용도로 정한다"]
    f4 --> f5

그림 5: 판단표에서 특히 중요한, 라벨과 정답이 뒤집히는 두 행입니다.

급하면 이 장에서 멈춰도 됩니다. 다음 4장은 이 표의 각 행을 “왜 그렇게 되는가”, “구체적으로 무엇을 두는가”까지 펼친 것입니다. 표와 같은 결론은 반복하지 않고, 표에 다 못 적은 판단 재료만 읽는 식으로 쓸 수 있습니다.

4. 용도별 설계 방침

4.1 BtoC용 유틸리티 / 개인용 앱

BtoC의 작은 Windows 앱에서는 먼저 “실행해서 바로 쓸 수 있다”가 무엇보다 셉니다.

특히 중시하고 싶은 것은 이 부근입니다.

• 첫 한 화면에서 무엇을 하는 앱인지 안다
• 주요 조작이 하나 또는 둘로 줄어 있다
• 빈 상태가 불친절하지 않다
• 위험한 조작을 취소할 수 있다
• 설정 항목을 처음부터 전부 보여 주지 않는다

여기서 흔히 하는 실수는, 기술적으로 할 수 있는 일을 전부 늘어놓는 것입니다. 그러나 BtoC의 가벼운 도구에서는 다기능인 것보다 바로 쓸 수 있는 것이 가치가 되는 경우가 많습니다.

Windows의 내비게이션 설계에서도 모든 앱에 공통의 정답은 없고, 먼저 일관성, 단순함, 명확함이 중시됩니다. 표준 컨트롤이나 표준적인 자리를 쓰면 예측하기 쉬워집니다.⁸

그래서 BtoC용에서는,

• 작으면 단일 화면
• 섹션이 병렬이면 상단 내비
• 설정은 단계적으로 보여 준다
• 주요 동작은 밝게, 그 밖은 조용히

정도의 정리로 충분한 경우가 많습니다.

flowchart TB
    accTitle: BtoC용의 정리 방향
    accDescr: BtoC용에서는 실행해서 바로 쓸 수 있음을 축으로, 작으면 단일 화면, 섹션이 병렬이면 상단 내비, 설정은 단계적으로 보여 주고, 주요 동작은 밝게 그 밖은 조용히, 라는 정리로 충분한 경우가 많음을 나타내는 그림.
    g1["실행해서 바로 쓸 수 있다"] --> g2["작으면 단일 화면"]
    g1 --> g3["병렬이면 상단 내비"]
    g1 --> g4["설정은 단계적으로 보여 준다"]
    g4 -.-> g5["주요 동작은 밝게, 그 밖은 조용히"]

그림 6: BtoC의 가벼운 도구는 “다기능”보다 “바로 쓸 수 있음” 쪽으로 모아 정리합니다.

다만 BtoC라도 사진 편집, 동영상 편집, 작곡, 투자 분석, 개발 지원 같은 상급자용 앱이 되면 이야기가 달라집니다. 그 경우에는 BtoC라는 라벨보다 숙련도와 이용 시간을 보는 편이 정답에 가까워집니다.

4.2 BtoB 사무 입력·백오피스

사무 BtoB 앱에서 중요한 것은, 겉모습의 가벼움보다 작업이 멈추지 않는 것입니다.

매일 쓰는 사용자는 며칠이면 UI에 익숙해집니다. 그다음에 효과가 나는 것은 이런 부분입니다.

• 키보드만으로 어디까지 갈 수 있는가
• 목록과 명세를 오가기 쉬운가
• 중요한 열이나 상태가 한눈에 보이는가
• 필터나 정렬을 유지할 수 있는가
• 오류를 그 자리에서 고칠 수 있는가

Microsoft의 키보드 접근성 지침에서도 앱은 키보드로 모든 기능에 도달할 수 있을 것이 중요하다고 하며, Tab 순서, 포커스, Enter / Space에 의한 조작, 바로 가기 구현이 권장됩니다.³

또한 액세스 키는 접근성만이 아니라, 키보드를 선호하는 파워 사용자의 효율 향상에도 유효합니다. 적절한 자리에서는 사용자 지정 컨트롤까지 포함해 액세스 키를 지원하는 것이 권장됩니다.⁹

사무 입력에서는 내비게이션으로 목록/상세가 탄탄합니다. Windows 내비게이션 가이드에서도 목록/상세는 항목을 자주 바꾸며 상세를 보거나 갱신하는 용도에 맞으며, 메일 받은 편지함, 연락처 목록, 데이터 입력 같은 경우에 적합하다고 합니다.⁸

즉, 이런 구성이 곧습니다.

• 왼쪽에 기능 분류
• 가운데에 목록
• 오른쪽 또는 아래에 명세 / 편집
• 위에 검색, 필터, 주요 명령
• 자주 쓰는 조작은 바로 가기 지원

flowchart TB
    accTitle: 사무 입력의 곧은 구성
    accDescr: 위에 검색·필터·주요 명령, 왼쪽에 기능 분류, 가운데에 목록, 오른쪽 또는 아래에 명세와 편집을 두고, 자주 쓰는 조작은 바로 가기에 맞추는 사무 입력의 곧은 구성을 나타내는 그림.
    h1["위: 검색·필터·주요 명령"] --> h2["왼쪽: 기능 분류"]
    h2 --> h3["가운데: 목록"]
    h3 --> h4["오른쪽 또는 아래: 명세·편집"]
    h4 -.-> h5["자주 쓰는 조작은 바로 가기 지원"]

그림 7: 목록/상세를 축으로 한, 사무 입력의 곧은 화면 구성입니다.

반대로, 피하고 싶은 패턴도 적어 둡니다.

• 조작마다 대화 상자
• 열이 너무 적어 목록성이 낮다
• 주요 조작이 오른쪽 클릭 안에만 있다
• 아이콘만으로 의미를 나타내려고 한다
• Tab 순서가 엉망이고 Enter도 Space도 먹지 않는다

입력 오류에 대해서도, 필드에 묶인 검증 오류는 대화 상자가 아니라 화면 안에서 내는 편이 자연스럽습니다. Windows 대화 상자 가이드에서도 암호란 등 맥락에 묶인 검증 오류에는 대화 상자를 쓰지 않고 인라인 표시를 쓰는 것이 권장됩니다.¹⁰

4.3 BtoB 감시·운영

감시·운영 화면의 UX는 “쓰기 쉽다”보다 먼저 놓치지 않는다, 틀리지 않는다, 멈추지 않는다가 중요합니다.

여기의 우선순위는 대체로 이렇습니다.

• 이상 유무가 한눈에 보인다
• 이상의 중요도가 보인다
• 현재값만이 아니라 변화나 시계열을 따라갈 수 있다
• 위험 조작의 동선이 너무 가볍지 않다
• 로그, 이력, 원인 조사로 바로 갈 수 있다

이런 화면에서는 상태 표현이 UX의 중심입니다. 상태는 되도록 색 + 문자 + 아이콘 + 시각의 여러 요소로 나타내는 편이 안전합니다. 색만으로 상태를 나타내면 놓침이나 식별 실수가 나기 쉽고, 접근성에서도 약해집니다.¹¹

flowchart TB
    accTitle: 상태는 여러 요소로 나타낸다
    accDescr: 감시·운영 화면에서는 상태 표현이 UX의 중심이며, 색만으로 나타내면 놓침이나 식별 실수가 나기 쉬우므로 색·문자·아이콘·시각의 여러 요소로 나타내는 편이 안전함을 나타내는 그림.
    i1["색만으로 상태를 나타낸다"] --> i2["놓침·식별 실수가 나기 쉽다"]
    i2 -.->|"대신에"| i3["색+문자+아이콘+시각으로 나타낸다"]
    i3 --> i4["놓침도 오인도 줄어 안전하다"]

그림 8: 감시 화면의 상태는 색만이 아니라 여러 요소의 조합으로 나타냅니다.

내비게이션은, 감시 대상이 많으면 왼쪽 내비, 개별 대상의 파고들기는 드릴다운, 상세는 로그나 시계열로 내는 정리가 다루기 쉽습니다. Windows 내비게이션 가이드에서도 왼쪽 내비는 최상위 항목이 많은 경우나, 페이지 전환이 끊임없이 있지 않은 구성에 맞습니다.⁸

조작 면에서는 명령을 한곳에만 두는 것도 위험합니다. Windows 명령 설계 가이드에서는 명령을 단추, 컨텍스트 메뉴, 바로 가기, 제스처 등 여러 면에서 쓸 수 있게 하고, 관련 명령을 모두 컨텍스트 메뉴나 CommandBarFlyout에 넣을 것이 권장됩니다. hover로만 나오는 조작에 의존하면 터치 단말이나 지원 기술에서 쓸 수 없게 되기 때문입니다.¹²¹³

위험 조작의 확인 대화 상자도 여기서는 중요합니다. 다만 “일단 무엇이든 확인한다”는 역효과입니다. 정말로 확인하고 싶은 것은 중지한다, 삭제한다, 전환한다, 차단한다, 덮어쓴다처럼 되돌리기 어려운 쪽의 조작입니다. 대화 상자를 띄운다면,

• 무슨 일이 일어나는지를 첫 줄에 분명히 쓴다
• 단추 문구는 OK / Yes가 아니라 삭제 / 중지 / 차단처럼 구체적으로 한다
• 안전 쪽 단추를 반드시 둔다

세 가지는 최소한 지키는 편이 좋습니다.¹⁰

flowchart TB
    accTitle: 확인 대화 상자의 세 원칙
    accDescr: 정말로 확인하고 싶은 것은 중지·삭제·차단 등 되돌리기 어려운 쪽의 조작이며, 띄운다면 무슨 일이 일어나는지를 첫 줄에 쓰고, 단추 문구를 구체적으로 하며, 안전 쪽 단추를 반드시 둠을 나타내는 그림.
    j1["되돌리기 어려운 쪽 조작만 확인한다"] --> j2["무슨 일이 일어나는지를 첫 줄에"]
    j1 --> j3["단추 문구는 구체적으로"]
    j1 --> j4["안전 쪽 단추를 반드시 둔다"]
    j2 -.-> j5["'일단 무엇이든 확인'은 역효과"]

그림 9: 확인 대화 상자는 되돌리기 어려운 조작에 좁히고, 세 가지 최소한을 지켜 띄웁니다.

4.4 BtoB 현장 단말·장치 UI·키오스크

현장 단말은 Windows 앱 UX 안에서도 꽤 다른 종류입니다.

• 앉아 있지 않다
• 장갑을 끼고 있을 수 있다
• 한 손만 비어 있다
• 화면을 찬찬히 보지 않는다
• 시간 압박이 있다
• 밝은 현장이나 시끄러운 장소에서 쓴다

는 조건이 흔히 있습니다.

Microsoft의 접근성 지침에서도, 좋은 Windows 앱은 장애 유무만이 아니라 밝은 햇볕, 공유 공간, 소음, 정적, 조리 중 같은 상황을 포함한 환경 제약을 고려하는 것이 중요하다고 합니다.²

또한 터치 설계에서는,

• 터치에는 hover가 없다
• 손가락이나 손으로 UI가 가려진다(occlusion)
• 화면 일부는 손 자세상 누르기 어렵다
• 시각적 피드백이 중요하다

는 차이가 있습니다.⁴

flowchart TB
    accTitle: 터치 설계의 네 가지 차이
    accDescr: 터치에는 hover가 없고, 손가락이나 손으로 UI가 가려지며, 화면 일부는 손 자세상 누르기 어렵고, 시각적 피드백이 중요하다는 설계상의 차이를 나타내는 그림.
    k1["터치 조작"] --> k2["hover가 없다"]
    k1 --> k3["손가락이나 손으로 UI가 가려진다"]
    k1 --> k4["자세상 누르기 어려운 자리가 있다"]
    k4 -.-> k5["시각적 피드백이 중요해진다"]

그림 10: 터치는 hover와 가림의 전제가 다르고, 피드백을 어떻게 보여 주느냐가 핵심이 됩니다.

그래서 현장 단말에서는 대체로 이 방향으로 모읍니다.

• 단추나 목록 항목은 충분히 크게
• 한 화면 한 목적에 가깝게
• 조작 후 반응을 분명히 보여 준다
• 흐름을 단계화한다
• 입력은 되도록 자유 입력보다 선택, 스캔, 정형 쪽으로
• 상태는 화면 위쪽이나 가운데에서 명확히 낸다

반대로 피하고 싶은 것은,

• 작은 글자
• 작은 히트 영역
• hover 전제 도구 설명 의존
• 깊은 계층
• 한 화면에 대량의 정보
• 긴 자유 입력

입니다.

BtoB이니 밀도가 높은 편이 좋다, 는 거친 발상이 가장 빗나가기 쉬운 영역이 여기입니다. 여기는 오히려 업무 앱 안에서도 특히 명확함 우선의 세계입니다.

flowchart TB
    accTitle: 현장 단말은 명확함 우선
    accDescr: 현장 단말에서는 한 화면 한 목적에 가깝게 하고, 입력은 자유 입력보다 선택·스캔·정형으로 모으며, 조작 후 반응을 분명히 보여 준다는, 업무 앱 안에서도 특히 명확함 우선의 방향을 나타내는 그림.
    l1["현장 단말·장치 UI"] --> l2["한 화면 한 목적에 가깝게"]
    l1 --> l3["입력은 선택·스캔·정형으로 모은다"]
    l1 --> l4["조작 후 반응을 분명히 보여 준다"]
    l2 --> l5["업무 앱 안에서도 특히 명확함 우선"]
    l3 --> l5
    l4 --> l5

그림 11: 현장 단말은 밀도가 아니라 명확함·큰 조작 대상·짧은 동선으로 모읍니다.

4.5 전문가용 편집·분석 도구

전문가용 도구에서는 “알기 쉽게 해 달라”보다 “손을 멈추지 않게 해 달라”가 이기는 경우가 있습니다.

예를 들어,

• CAD
• 파형 해석
• 영상 편집
• 이미지 처리
• 음악 제작
• 개발 지원
• 데이터 분석
• 감사 / 진단 도구

같은 것입니다.

이런 앱에서는 이런 요소가 효과가 납니다.

• 정보 밀도
• 여러 페인
• 탭
• 컨텍스트 메뉴
• 바로 가기
• 레이아웃 저장
• 열이나 표시 항목의 사용자 지정
• Undo / Redo
• 작업 상태 복원

Windows 내비게이션 가이드에서도 탭은 여러 페이지나 문서를 열고 닫고 순서를 바꾸고 싶은 경우에 맞습니다.⁸ 또한 Windows 명령 설계에서는 명령을 여러 UI 면에서 공유하고, 입력 방식이 달라도 같은 조작에 도달할 수 있게 하는 것이 권장됩니다.¹²

이런 도구에서 흔히 하는 실수는, 초보자에게 친절하려고 전부를 깊은 메뉴에 숨기는 것입니다. 그러나 숙련자는 매일 수백 번 같은 조작을 합니다. 그 사람들에게 중요한 것은 처음 5분의 친절함보다, 100시간 쓴 뒤에도 덜 지치는 것입니다.

그래서 상급자용에서는

• 고빈도 조작은 가까이
• 보조 기능은 조금 안쪽
• 고급 기능은 지우지 않고 정리한다
• 표시 레이아웃을 저장한다
• 키보드 조작을 충실히 넣는다

는 설계가 효과가 나기 쉽습니다.

flowchart TB
    accTitle: 숙련자용의 배치 생각
    accDescr: 숙련자는 매일 수백 번 같은 조작을 하므로 처음 5분의 친절함보다 100시간 쓴 뒤에도 덜 지치는 것이 중요하고, 고빈도 조작은 가까이, 보조 기능은 조금 안쪽, 고급 기능은 지우지 않고 정리함을 나타내는 그림.
    n1["숙련자는 매일 수백 번 같은 조작"] --> n2["고빈도 조작은 가까이 둔다"]
    n1 --> n3["보조 기능은 조금 안쪽에"]
    n1 --> n4["고급 기능은 지우지 않고 정리"]
    n2 -.-> n5["처음 5분보다 100시간 뒤의 덜 지침"]

그림 12: 전문가용 도구는 조작 빈도에 맞춘 거리로 기능을 배치합니다.

4.6 상주 도구·트레이 앱

상주 계열은 앱의 존재감을 너무 내지 않는 것이, 오히려 UX입니다.

예를 들어,

• 동기화 상태
• 연결 상태
• 백업
• 음성 / 카메라 / 디바이스 전환
• VPN / 에이전트 / 런처
• 알림 허브

같은 앱에서는 메인 화면이 주인공이 아닌 경우가 많습니다.

우선하고 싶은 것은,

• 트레이나 작은 메뉴에서 바로 만질 수 있다
• 지금 상태가 보인다
• 필요할 때만 알린다
• 알림에서 바로 필요 조작으로 간다
• 메인 화면이 앞면을 너무 빼앗지 않는다

입니다.

피하고 싶은 것은,

• 사소한 일로 대화 상자를 띄운다
• 실행할 때마다 메인 화면을 연다
• 배경 동작 상태가 보이지 않는다
• 알림이 너무 많아 전부 무시된다

입니다.

이런 앱은 “기능을 많이 가졌는가”보다 방해하지 않는가가 UX를 좌우하기 쉽습니다.

flowchart TB
    accTitle: 상주 도구는 방해하지 않는 것이 UX
    accDescr: 상주 계열은 트레이나 작은 메뉴에서 바로 만지고, 지금 상태가 보이며, 필요할 때만 알리는 것을 우선하고, 알림이 너무 많으면 전부 무시됨을 나타내는 그림.
    r1["트레이에서 바로 만진다"] --> r4["방해하지 않는 것이 UX"]
    r2["지금 상태가 보인다"] --> r4
    r3["필요할 때만 알린다"] --> r4
    r4 -.-> r5["알림이 너무 많으면 전부 무시된다"]

그림 13: 상주 도구는 존재감을 너무 내지 않는 것이 그대로 UX가 됩니다.

5. 내비게이션 판단표

Windows 내비게이션 가이드에서는 모든 앱에 통하는 하나의 내비게이션 디자인은 없다고 한 위에서 일관성, 단순함, 명확함을 원칙으로 합니다. 나아가 사용자가 기대하는 자리에 표준 컨트롤을 두면 예측하기 쉬운 UI가 됩니다.⁸

flowchart TB
    accTitle: 내비게이션 설계의 원칙
    accDescr: 모든 앱에 통하는 하나의 내비게이션 디자인은 없고, 일관성·단순함·명확함을 원칙으로, 사용자가 기대하는 자리에 표준 컨트롤을 두어 예측하기 쉬운 UI로 만듦을 나타내는 그림.
    s0["유일한 정답 패턴은 없다"] --> s1["일관성"]
    s0 --> s2["단순함"]
    s0 --> s3["명확함"]
    s3 -.-> s4["표준 컨트롤을 기대되는 자리에 둔다"]

그림 14: 내비게이션에 유일한 정답은 없고, 세 원칙과 표준 자리로 예측하기 쉽게 합니다.

실무에서는 대체로 이 표로 가르면 생각하기 쉬워집니다.

Windows 내비게이션 가이드에서는 특히 다음과 같은 쓰임이 나와 있습니다.⁸

• 상단 내비: 모든 내비게이션 항목을 화면에 보여 주고 싶을 때
• 왼쪽 내비: 최상위 항목이 많을 때, 페이지를 자주 바꾸지 않을 때
• 목록/상세: 항목 전환이 많고 상세 표시나 갱신이 필요할 때
• 탭: 여러 문서나 페이지를 동적으로 열고 닫고 싶을 때
• 이동 경로: 깊은 계층에서 돌아가는 길을 알기 쉽게 하고 싶을 때

5.1 골격만의 와이어프레임

말만으로는 그림이 잘 안 잡히므로, 대표적인 네 골격을 늘어놓습니다. 세부는 무시하고, 무엇이 어디에 놓이는가만 봐 주십시오.

[ 상단 내비게이션 ]  같은 수준 페이지를 전부 보여 주고 싶을 때
+-------------------------------------------------------------
| AppName        홈 | 변환 | 이력 | 설정
+-------------------------------------------------------------
|
|    주 콘텐츠
|    한 화면 한 목적에 가깝게
|
+-------------------------------------------------------------


[ 왼쪽 내비게이션 ]  최상위 항목이 많을 때
+-------------------------------------------------------------
| AppName                                 검색 [           ]
+-------------------------------------------------------------
| 대시보드        |
| 장치 목록       |    주 콘텐츠
| 알림            |
| 작업            |
| 보고서          |
| 설정            |
+-------------------------------------------------------------


[ 목록/상세 ]  항목을 바꾸며 상세를 본다·갱신한다
+-------------------------------------------------------------
| 검색 [          ]  필터: 미처리 / 모두      [신규] [삭제]
+-------------------------------------------------------------
| 목록             |  상세 / 편집
|  > 전표 1001     |    전표 번호   1001
|    전표 1002     |    거래처     ...
|    전표 1003     |    명세 행     ...
|    전표 1004     |
|                  |    [ 저장 ]   [ 취소 ]
+-------------------------------------------------------------


[ 대시보드 + 드릴다운 ]  이상을 찾아 판다
+-------------------------------------------------------------
| 전체   정상 22    주의 3    이상 1        갱신 0.5초 전
+-------------------------------------------------------------
| 이상 1건
|   ! 라인B 검사 장치    응답 없음    48초 전    [ 상세 ]
| 주의 3건
|   - 라인A 카메라      값이 오래됨    12초 전    [ 상세 ]
|   ...
+-------------------------------------------------------------
              |
              |  [ 상세 ]를 누른다
              v
+-------------------------------------------------------------
| < 목록으로 돌아가기       라인B 검사 장치 / 응답 없음
+-------------------------------------------------------------
| 현재값 | 시계열 그래프 | 이벤트 로그 | 조작
+-------------------------------------------------------------

넷을 늘어놓으면 고르는 축이 분명해집니다.

• 상단 내비와 왼쪽 내비의 갈림은 최상위 항목의 수입니다. 전부를 가로로 늘어놓을 수 있으면 상단, 늘어놓지 못하면 왼쪽입니다
• 목록/상세의 주인공은 오른쪽이 아니라 왼쪽 목록입니다. 목록 정보량이 부족하면 상세를 여러 번 다시 열게 됩니다
• 대시보드는 “이상이 몇 건인가”를 첫 줄에 내는 것이 요점입니다. 파고든 곳으로 가면 반드시 돌아가는 길을 마련합니다

결국 내비게이션은 “겉모습 취향”이 아니라 정보 구조와 작업 구조의 반영입니다.

flowchart TB
    accTitle: 상단 내비와 왼쪽 내비의 갈림
    accDescr: 상단 내비와 왼쪽 내비의 갈림은 최상위 항목의 수이며, 전부를 가로로 늘어놓을 수 있으면 상단, 늘어놓지 못하면 왼쪽이 되고, 내비게이션은 정보 구조와 작업 구조의 반영임을 나타내는 그림.
    t1{"최상위 항목을 가로로 늘어놓을 수 있는가"} -->|"늘어놓을 수 있다"| t2["상단 내비"]
    t1 -->|"늘어놓지 못한다"| t3["왼쪽 내비"]
    t2 -.-> t4["내비는 정보 구조와 작업 구조의 반영"]
    t3 -.-> t4

그림 15: 골격 선택은 겉모습 취향이 아니라 정보 구조에서 정해집니다.

6. 입력 디바이스와 명령 설계 판단표

Windows 앱은 되도록 많은 입력 방식에 대응하는 편이 유연하고 쓰기 쉬워집니다. Microsoft 가이드에서도 제스처, 음성, 터치, 터치패드, 마우스, 키보드 등 가능한 한 많은 입력을 고려하는 것이 권장됩니다.¹⁴

또한 Windows 플랫폼 컨트롤은 여러 입력 방식을 어느 정도 흡수해 주므로, 표준 컨트롤을 그대로 쓰는 것이 먼저 셉니다.⁴⁸

flowchart TB
    accTitle: 표준 컨트롤이 먼저 세다
    accDescr: 제스처·음성·터치·마우스·키보드 등 가능한 한 많은 입력을 고려하는 것이 권장되며, 플랫폼 표준 컨트롤은 여러 입력 방식을 어느 정도 흡수하므로 그대로 쓰는 것이 먼저 셈을 나타내는 그림.
    u1["다양한 입력 방식 지원"] --> u2["표준 컨트롤이 어느 정도 흡수한다"]
    u2 --> u3["표준 컨트롤을 그대로 쓰는 것이 먼저 세다"]

그림 16: 다양한 입력 방식은 표준 컨트롤에 흡수시키는 것이 지름길이 됩니다.

실무에서 쓰기 쉬운 형태로 하면 이렇습니다.

키보드 쪽에서 특히 중요한 것은 다음입니다.³⁹

• 키보드만으로 모든 기능에 도달할 수 있을 것
• Tab 순서가 시각 순서와 크게 어긋나지 않을 것
• Enter / Space로 눌러야 할 요소가 눌러질 것
• 중요 기능에 바로 가기가 있을 것
• 고빈도 조작에는 액세스 키나 액셀러레이터를 마련할 것

터치 쪽에는 이런 특성이 있습니다.⁴

• hover가 없다
• 손가락이나 손으로 UI가 가려진다
• 누를 수 있는 자리는 겉보기보다 좁게 느껴진다
• 시각적 피드백이 필요하다
• 직접 조작에 맞는 UI와 간접 입력에 맞는 UI는 다르다

6.1 “충분히 크게”가 아니라 숫자로 정한다

설계 리뷰에서 다투기 쉬운 지점은 “충분히 크게”, “분명히”에서 멈추는 곳입니다. Microsoft 가이드가 숫자를 내놓은 항목은, 그 숫자를 그대로 합격 기준으로 삼는 편이 논의가 짧아집니다.

숫자가 정해지면 리뷰에서 말하는 방식도 바뀝니다. “이 단추 작지 않습니까”가 아니라 “이 단추는 32px이므로 7.5mm 기준에 못 미칩니다”라고 말할 수 있게 되면, 고칠지 말지의 판단이 그 자리에서 끝납니다.

flowchart TB
    accTitle: 숫자로 정하면 리뷰가 빠르다
    accDescr: '충분히 크게', '분명히'에서 멈추면 리뷰에서 다투므로, 가이드 숫자를 그대로 합격 기준으로 하면 기준에 미치는지로 이야기가 끝나고, 고칠지 말지의 판단이 그 자리에서 끝남을 나타내는 그림.
    v1["'충분히 크게'에서 멈춘다"] --> v2["리뷰에서 다툰다"]
    v2 -.->|"대신에"| v3["숫자를 그대로 합격 기준으로 한다"]
    v3 --> v4["기준에 미치는지로 말할 수 있다"]
    v4 --> v5["판단이 그 자리에서 끝난다"]

그림 17: 숫자를 합격 기준으로 하면 크기 논의가 그 자리에서 끝납니다.

참고로 WinUI 표준 컨트롤은 기본값으로 이 타깃 크기를 따르도록 만들어져 있습니다.¹⁵ 반대로 말하면, 직접 만든 컨트롤과 사용자 지정 그리기 자리만 위험하다는 것입니다.

명령 설계에서는 Windows 명령 가이드가 좋은 참고가 됩니다. 특히 중요한 것은 명령을 여러 UI 면에서 쓸 수 있게 하는 것입니다.¹²

• 단추에서 누를 수 있다
• 컨텍스트 메뉴에도 있다
• 바로 가기로도 부를 수 있다
• 필요하면 스와이프나 제스처도 있다

그리고 관련 명령을 모두 컨텍스트 메뉴나 CommandBarFlyout에 넣는 것이 권장됩니다. hover 중에만 보이는 조작에 의존하면 터치 전용 단말에서 막힙니다.¹²

flowchart TB
    accTitle: 명령은 여러 면에서
    accDescr: 명령은 단추에서 누를 수 있고 컨텍스트 메뉴에도 있으며 바로 가기로도 부를 수 있게 여러 UI 면에서 쓸 수 있게 하고, hover 중에만 보이는 조작에 의존하면 터치 전용 단말에서 막힘을 나타내는 그림.
    w1["같은 명령"] --> w2["단추"]
    w1 --> w3["컨텍스트 메뉴"]
    w1 --> w4["바로 가기"]
    w2 --> w5["어느 입력 방식으로도 도달할 수 있다"]
    w3 --> w5
    w4 --> w5
    w1 -.-> w6["hover 의존은 터치에서 막힌다"]

그림 18: 중요한 명령은 여러 UI 면에 두고, hover 의존을 피합니다.

7. Windows 앱에서 최소한 놓치고 싶지 않은 UX 항목

여기서부터는 용도를 가리지 않고 최소한 잡고 싶은 것을 정리합니다.

7.1 키보드로 완결할 수 있는가

Windows 데스크톱에서 키보드는 “있으면 편리”한 정도가 아니라, 핵심 입력 수단입니다.

Microsoft의 키보드 접근성 가이드에서도 키보드 지원은 시각이나 운동 능력에 제약이 있는 사용자만이 아니라, 효율을 위해 키보드를 고르는 사용자에게도 중요하다고 합니다.³

최소한 보고 싶은 것은 다음 다섯 가지입니다.

• Tab 순서는 자연스러운가
• 포커스 시각화가 있는가
• Enter / Space로 누를 수 있는가
• 바로 가기가 있는가
• 오른쪽 클릭에 해당하는 조작을 키보드로도 부를 수 있는가

수수하지만, 여기가 무너지면 BtoB UX는 꽤 아픕니다.

7.2 문자 확대, 대비 테마, 접근성

Windows 앱에서는 글자 크기나 대비를 제대로 따라가기만 해도 UX가 꽤 안정됩니다.

Microsoft 가이드에서는 보이는 텍스트의 대비 비는 적어도 4.5:1이 권장되고, 글자가 확대되었을 때는 컨트롤이나 컨테이너도 함께 크기 조정·재배치될 것이 요구됩니다.⁵⁶

나아가 대비 테마에서는,

• 색을 하드코드하지 않는다
• SystemColor / Brush 리소스를 쓴다
• 4종류의 대비 테마로 시험한다

것이 권장됩니다.⁷

여기서 깨지기 쉬운 것은,

• 고정 너비 전제 레이블
• 픽셀 고정 단추 높이
• 색만으로 의미를 전하는 설계
• 사용자 지정 그리기로 테마를 따라가지 않는 UI

입니다.

이 부근은 “접근성 대응”이라기보다, 오래 깨지지 않는 Windows UI를 만드는 기초 공사로 생각하는 편이 맞습니다.

flowchart TB
    accTitle: 확대와 테마를 견디는 기초 공사
    accDescr: 고정 너비 전제 레이블이나 픽셀 고정 높이, 색만의 의미 부여, 테마를 따라가지 않는 사용자 지정 그리기는 깨지기 쉽고, 색을 하드코드하지 않고 리소스를 쓰며 대비 테마로 시험하는 것이 오래 깨지지 않는 Windows UI의 기초 공사임을 나타내는 그림.
    y1["고정 너비 레이블·픽셀 고정 높이"] --> y3["확대나 테마 전환에서 깨진다"]
    y2["색만의 의미 부여·독자 그리기"] --> y3
    y3 --> y4["색을 하드코드하지 않고 리소스를 쓴다"]
    y4 --> y5["4종류의 대비 테마로 시험한다"]
    y5 -.-> y6["오래 깨지지 않는 UI의 기초 공사"]

그림 19: 문자 확대와 대비 테마를 따라가는 일은 UI의 기초 공사에 해당합니다.

7.3 대화 상자를 남용하지 않는다

대화 상자는 편리하지만, 너무 쓰면 작업의 적이 됩니다.

Windows 대화 상자 가이드에서는 대화 상자를 알림, 승인, 추가 정보 입력이 필요할 때의 모달 UI로 보고, 적어도 하나는 안전하고 비파괴적인 조작(Close, Cancel 등)을 두는 것이 권장됩니다. 나아가 단추 문구는 구체적인 응답으로 하는 편이 좋다고 합니다.¹⁰

중요한 것은 무엇이든 대화 상자로 만들지 않는 것입니다.

특히,

• 필드 단위 입력 오류
• 그 자리에서 고칠 수 있는 형식 오류
• 일시적인 주의

는 되도록 인라인 표시로 모으는 편이 자연스럽습니다.¹⁰

7.4 중요한 명령은 여러 경로를 가진다

Windows 명령 설계에서는 중요 명령을 여러 입력 방식이나 UI 면에서 부를 수 있을 것이 중시됩니다.¹²¹³

이것은 실무에서도 잘 먹힙니다.

예를 들어 “삭제”라면,

• 도구 모음
• 컨텍스트 메뉴
• Delete 키
• 필요하면 스와이프

처럼 여러 경로가 있으면 사용감이 안정됩니다.

반대로,

• hover했을 때만 오른쪽 끝에 나온다
• 오른쪽 클릭으로만 나온다
• 키보드로는 평생 닿지 못한다

같은 설계는 입력 방식이 바뀌면 갑자기 약해집니다.

7.5 테스트 도구로 확인한다

접근성은 머릿속에서 “아마 괜찮다”고 생각하기보다, 도구로 보는 편이 빠릅니다.

Microsoft의 접근성 테스트 가이드에서는 Accessibility Insights for Windows를 쓴 Live Inspect, FastPass, Troubleshooting이 소개되며, 나아가 SDK의 Inspect로 UI Automation 특성과 내비게이션 구조를 확인할 수 있습니다.¹⁷

최소한으로도,

• Accessibility Insights로 대강 검사
• Inspect로 주요 요소의 이름, 역할, 패턴 확인
• 키보드만으로 주요 흐름을 통과시킨다
• 텍스트 확대와 대비 테마를 시험한다

정도는 해 두면 되돌아가는 일이 줄어듭니다.

flowchart TB
    accTitle: 접근성 확인 절차
    accDescr: Accessibility Insights로 대강 검사하고, Inspect로 주요 요소의 이름·역할·패턴을 확인하며, 키보드만으로 주요 흐름을 통과시키고, 텍스트 확대와 대비 테마를 시험하는 확인 흐름을 나타내는 그림.
    z1["Accessibility Insights로 검사"] --> z2["Inspect로 이름·역할·패턴 확인"]
    z2 --> z3["키보드만으로 주요 흐름을 통과시킨다"]
    z3 --> z4["확대와 대비 테마를 시험한다"]
    z4 -.-> z5["머릿속의 '아마 괜찮다'보다 빠르다"]

그림 20: 접근성은 도구로 검사한 뒤, 손으로 주요 흐름을 확인합니다.

7.6 회복성을 넣는다

이것은 Microsoft의 한 줄 점검표라기보다, Windows 데스크톱 실무에서 꽤 효과가 나는 이야기입니다.

UX는 “기분 좋게 누를 수 있는 단추”만이 아니라, 사고가 나도 돌아올 수 있음으로 정해집니다.

예를 들어,

• Undo / Redo
• 자동 저장
• 편집 중 상태 유지
• 필터 / 정렬 / 열 너비 복원
• 중단과 재개
• 긴 처리의 진행과 취소

는 겉모습보다 UX에 훨씬 효과가 납니다.

특히 BtoB나 전문가용에서는 다시 조작하는 스트레스가 그대로 UX의 나쁨이 됩니다.

flowchart TB
    accTitle: 회복성이 UX를 정한다
    accDescr: UX는 기분 좋게 누를 수 있는 단추만이 아니라 사고가 나도 돌아올 수 있음으로 정해지며, Undo나 Redo, 자동 저장, 상태 복원, 긴 처리의 진행과 취소가 다시 조작하는 스트레스를 줄임을 나타내는 그림.
    ba1["Undo / Redo·자동 저장"] --> ba4["사고가 나도 돌아올 수 있다"]
    ba2["편집 중 상태·표시 복원"] --> ba4
    ba3["진행 표시와 취소"] --> ba4
    ba4 -.-> ba5["다시 조작하는 스트레스가 그대로 UX의 나쁨이 된다"]

그림 21: UX는 누르기 쉬움만이 아니라, 사고가 나도 돌아올 수 있는 회복성으로 정해집니다.

8. 흔한 설계 실수

8.1 BtoB이니 고밀도로 하면 된다, 고 착각한다

이것은 절반만 맞습니다.

매일 쓰는 숙련자용이면 고밀도가 효과가 나는 경우가 있습니다. 그러나 현장 단말, 접수 단말, 장치 UI에서는 오히려 밀도가 방해입니다.

BtoB라는 라벨이 아니라 숙련도, 입력 방식, 이용 환경을 보는 편이 빗나가기 어렵습니다.

8.2 BtoC이니 기능을 너무 숨긴다

개인용이라도 숙련자용 도구라면 효율이 최우선입니다.

무엇이든 “쉽게 보여 주기”로 기울면,

• 고빈도 조작이 멀다
• 매번 메뉴를 판다
• 화면을 계속 바꾼다

는 조용한 지옥이 시작됩니다.

flowchart TB
    accTitle: 라벨 착각의 두 함정
    accDescr: BtoB이니 고밀도로 하면 된다는 착각은 현장 단말에서 빗나가고, BtoC이니 기능을 너무 숨기면 숙련자의 고빈도 조작이 멀어진다는 두 함정을 나타내는 그림.
    ca1["BtoB이니 고밀도"] --> ca2["현장 단말에서는 밀도가 방해"]
    ca3["BtoC이니 숨긴다"] --> ca4["숙련자는 고빈도 조작이 멀어진다"]
    ca2 --> ca5["숙련도·입력 방식·이용 환경으로 본다"]
    ca4 --> ca5

그림 22: “BtoB는 고밀도”, “BtoC는 쉽게”라는 착각이, 반대 방향으로 빗나갑니다.

8.3 hover 전제 조작을 만든다

터치에는 hover가 없습니다. 나아가 포인터로만 나오는 UI는 지원 기술과의 궁합도 나빠지기 쉽습니다.⁴¹²

중요 조작은 항상 보이거나, 적어도 여러 경로를 갖게 하는 편이 안전합니다.

Before: hover한 행만, 오른쪽 끝에 조작이 나타난다
  전표 1001   2026-03-18   미처리                        <- 아무것도 보이지 않는다
  전표 1002   2026-03-18   미처리        [ 편집 ][ 삭제 ] <- 마우스를 올린 행만

After: 항상 보임 + 경로를 늘린다
  전표 1001   2026-03-18   미처리        [ 편집 ][ 삭제 ]
  전표 1002   2026-03-18   미처리        [ 편집 ][ 삭제 ]
     오른쪽 클릭  -> 편집 / 삭제
     키보드  -> Enter로 편집, Delete로 삭제

8.4 색만으로 상태를 전한다

감시 화면에서 특히 많지만, 빨강 / 노랑 / 초록만으로 의미를 전하는 것은 위험합니다.

문자, 아이콘, 시각, 건수, 설명을 맞추는 편이 놓침도 오인도 줄어듭니다.¹¹

8.5 검증 오류를 전부 대화 상자로 만든다

사무 입력에서 흔합니다. 입력할 때마다 대화 상자가 뜨면 작업 리듬이 완전히 깨집니다.

맥락에 묶인 오류는 화면 안에서 그 자리에 내는 편이 자연스럽습니다.¹⁰

Before: 필드마다 모달
  우편번호  [ 1234        ]        +------------------------------+
  주소      [             ]        | 우편번호 형식이 올바르지 않습니다
                                   |                       [ OK ]
                                   +------------------------------

After: 그 자리에 인라인
  우편번호  [ 1234        ]
            ! 7자리 숫자로 입력해 주십시오. 예 1234567
  주소      [             ]

8.6 고정 크기 레이아웃으로 만든다

100% 표시의 개발 환경에서는 깔끔해도,

• 문자 확대
• 고 DPI
• 대비 테마
• 로컬라이즈

에서 쉽게 깨집니다.⁶⁷

Before: 고정 너비 레이블 + 고정 높이 단추. 텍스트를 확대하면
  [ 출하 예정... ][ 2026-03-1  ]      <- 레이블이 잘리고, 값도 넘친다
  [ 등 ][ 취 ]                        <- 단추 글자가 위아래로 잘린다

After: 내용에 맞춰 늘어나는 레이아웃
  출하 예정일
  [ 2026-03-18              ]
  [ 등록 ]   [ 취소 ]                 <- 높이는 내용 + 여백으로 정한다

겉모습 완성도를 올릴수록, 고정 전제는 독이 되기 쉽습니다.

8.7 사용자 지정 컨트롤을 너무 많이 만든다

Windows 표준 컨트롤은 겉모습 이상으로 많은 동작을 가지고 있습니다.

• 포커스
• 키보드
• 테마 추종
• UI Automation
• 지원 기술과의 연결

까지 포함해 봐 주므로, 이유 없이 전부 직접 만들면 UX와 접근성 부채가 늘어납니다.⁸³

9. 착수 전에 정하는 8가지 질문

마지막으로, 설계 리뷰 처음에 두면 편리한 8가지 질문을 둡니다.

이 8가지 질문에 먼저 답해 두면,

• 내비게이션이 얕은 편이 좋은가
• 목록 + 명세가 좋은가
• 바로 가기를 충실히 넣어야 하는가
• 대화 상자를 어디서 써야 하는가
• 사용자 지정을 어디까지 허용하는가

가 자연스럽게 정해져 갑니다.

flowchart TB
    accTitle: 8가지 질문에서 정해져 가는 것
    accDescr: 착수 전 8가지 질문에 먼저 답해 두면 내비게이션의 깊이, 목록과 명세 구성, 바로 가기의 충실도, 대화 상자 쓰는 곳, 사용자 지정 범위가 자연스럽게 정해져 감을 나타내는 그림.
    da1["착수 전 8가지 질문에 답한다"] --> da2["내비의 깊이와 목록·명세 구성"]
    da1 --> da3["바로 가기의 충실도"]
    da1 --> da4["대화 상자와 사용자 지정 범위"]
    da2 --> da5["자연스럽게 정해져 간다"]
    da3 --> da5
    da4 --> da5

그림 23: 8가지 질문에 먼저 답하면, 설계상의 주요 선택이 자연스럽게 정해집니다.

10. 정리

Windows 앱 UX 설계에서 중요한 것은, “예쁜가”보다 먼저 “그 사람이, 그 장소에서, 그 입력 방식으로, 멈추지 않고 쓸 수 있는가”를 정하는 것입니다.

flowchart TB
    accTitle: 예쁨보다 먼저 정할 것
    accDescr: UX 설계에서 중요한 것은 예쁜가보다 먼저, 그 사람이, 그 장소에서, 그 입력 방식으로, 멈추지 않고 쓸 수 있는가를 정하는 것이며, UX는 장식이 아니라 조작의 계약임을 나타내는 그림.
    ea1["그 사람이"] --> ea2["그 장소에서"]
    ea2 --> ea3["그 입력 방식으로"]
    ea3 --> ea4["멈추지 않고 쓸 수 있는가"]
    ea4 -.-> ea5["UX는 장식이 아니라 조작의 계약"]

그림 24: “예쁜가”보다 먼저, 사람·장소·입력 방식으로 멈추지 않는지를 정합니다.

거칠게 정리하면 이렇습니다.

• BtoC는 첫 이해와 안심감을 우선
• BtoB 사무는 지속 효율과 키보드 지원을 우선
• BtoB 감시는 놓침 방지와 안전 조작을 우선
• BtoB 현장 단말은 큰 조작 대상과 짧은 동선을 우선
• 전문가용 도구는 밀도, 바로 가기, 사용자 지정을 우선
• 상주 도구는 방해하지 않음을 우선

그리고 용도를 가리지 않고 공통으로 효과가 나는 것은 다음 여섯 가지입니다.

1. 표준 컨트롤을 그대로 쓴다
2. 키보드로 주요 조작이 완결된다
3. 터치나 지원 기술에서 막히지 않는다
4. 문자 확대나 대비 테마에서 깨지지 않는다
5. 중요 명령에 여러 경로를 마련한다
6. 사고가 나도 돌아올 수 있다

UX는 장식이 아니라 조작의 계약입니다. 그 계약이 이용자, 환경, 입력 방식과 맞물릴수록 Windows 앱은 수수하지만 강하게 쓰기 쉬워집니다.

11. 참고 자료

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

BtoB 업무 앱은 정보를 빽빽하게 넣은 고밀도 UI여야 합니까?

절반만 맞습니다. 매일 쓰는 숙련자용 사무 입력에서는 고밀도 목록성과 키보드 완결이 지속 효율에 도움이 됩니다. 공장·창고·접수 같은 현장 단말이나 장치 UI에서는 밀도가 오히려 방해이며, 큰 조작 대상, 짧은 동선, 명확함을 우선해야 합니다. BtoB라는 라벨이 아니라 숙련도, 입력 방식, 이용 환경을 보는 편이 빗나가기 어렵습니다. 반대로 BtoC라도 이미지 편집이나 투자 분석 같은 상급자용 도구에서는 쉬움보다 정보 밀도·바로 가기·사용자 지정이 우선입니다.

Windows 앱 UX 설계에서 처음에 정해야 할 것은 무엇입니까?

BtoC인지 BtoB인지만으로는 부족하고, 다섯 가지 질문을 먼저 언어화합니다. 누가 쓰는가(초보자·숙련자·혼재), 어디서 쓰는가(책상·현장·옥외·접수), 무엇으로 조작하는가(키보드·마우스·터치·스캐너·지원 기술), 얼마나 쓰는가(첫 사용 중심·매일·하루 종일), 실수했을 때 비용은 무엇인가(가벼움·무거움·위험·감사 대상)입니다. 이 다섯 가지가 보이면 UI 밀도, 내비게이션, 바로 가기, 확인 대화 상자, 사용자 지정의 우선순위가 정해지기 쉽습니다.

내비게이션 패턴은 어떻게 고릅니까?

모든 앱에 통하는 하나의 내비게이션 디자인은 없고, 일관성·단순함·명확함이 원칙입니다. 구분의 기준으로는, 상단 내비는 항목을 화면에 모두 보여주고 싶을 때, 왼쪽 내비는 최상위 항목이 많을 때, 목록/상세는 항목을 자주 바꾸며 상세를 보거나 갱신하는 데이터 입력, 탭은 여러 문서를 동적으로 열고 닫고 싶을 때, 이동 경로는 깊은 계층에서 현재 위치를 잃기 쉬울 때 맞습니다. 내비게이션은 겉모습 취향이 아니라 정보 구조와 작업 구조의 반영입니다.

확인 대화 상자는 어디까지 띄워야 합니까?

무엇이든 대화 상자로 만들지 않는 것이 중요합니다. 필드 단위 입력 오류나 그 자리에서 고칠 수 있는 형식 오류는 대화 상자가 아니라 화면 안 인라인 표시가 자연스럽습니다. 정말로 확인할 것은 중지·삭제·차단·덮어쓰기처럼 되돌리기 어려운 쪽의 조작입니다. 대화 상자를 띄운다면, 무슨 일이 일어나는지를 첫 줄에 분명히 쓰고, 단추 문구는 OK/Yes가 아니라 삭제·중지처럼 구체적으로 하며, 안전하고 비파괴적인 단추를 반드시 두는 세 가지는 최소한 지켜야 합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.