Windows 앱에서의 UX 설계의 사고방식 - ToC / ToB / 감시 / 현장 단말 / 상주 도구에서 무엇을 우선할지의 판단표

Windows 앱의 UX를 생각할 때, 처음에 「모던하게 보이는가」 「여백이 깔끔한가」부터 들어가면 조금 순서를 틀리기 쉽습니다.

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

• 키보드로 어디까지 완결할 수 있는가
• 마우스 전제인가, 터치 전제인가
• 장시간 사용하는가, 가끔 몇 분만 사용하는가
• 감시인가, 입력인가, 현장 단말인가
• 실수했을 때 무엇이 망가지는가
• 문자 확대, 대비 테마, 지원 기술에 견디는가

이 부근이 전부 통합되어 UX입니다.

게다가 까다로운 것이 ToC와 ToB로 중심이 다르다는 것입니다. 다만 여기서 「ToB니까 정보를 채우면 된다」 「ToC니까 부드럽게 가볍게 만들면 된다」고 생각하면, 대체로 어딘가에서 사고가 납니다.

예를 들어 같은 ToB라도,

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

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

반대로 ToC에서도,

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

에서는 UI의 밀도도 단축키 요구도 전혀 다릅니다.

Microsoft의 Windows용 설계 가이던스도, Windows 앱의 설계는 직감적이고 접근하기 쉽고, 입력 방식이나 폼 팩터를 걸쳐서 일관되게 동작할 것을 중시하고 있습니다.¹²

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

1. 먼저 결론

꽤 실무에 가깝게 먼저 거칠게 말하면 이렇습니다.

• ToC에서는 먼저 초회 이해의 쉬움, 안심감, 설정의 적음, 도선의 자연스러움을 우선합니다
• ToB에서는 먼저 지속 효율, 오조작 방지, 키보드 대응, 안정된 배치를 우선합니다
• 다만 ToB의 현장 단말은 밀도보다 명쾌함, 큰 조작 대상, 짧은 도선이 우선입니다
• 다만 ToC의 상급자용 도구는 간단함보다 정보 밀도, 단축키, 커스터마이즈성이 우선입니다
• Windows 앱에서는 키보드 / 마우스 / 터치 / 텍스트 확대 / 대비 테마 / 지원 기술까지 포함해서 UX를 생각하는 편이, 나중에 설계가 망가지기 어렵습니다¹³⁴⁵⁶⁷

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

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

이 5가지가 보이면 UI의 밀도, 내비게이션, 단축키, 확인 다이얼로그, 커스터마이즈성의 우선 순위가 꽤 정하기 쉬워집니다.

2. ToC / ToB는 입구이지만 답이 아니다

ToC / ToB라는 구분 방식은 최초의 입구로서는 편리합니다. 다만 UX의 정답을 정하는 힘이 강한 것은 구매자의 종류보다 사용 방식의 종류입니다.

예를 들어 대략 2축으로 보면 이런 느낌입니다.

즉,

• ToC = 언제나 가벼운 UI
• ToB = 언제나 고밀도 UI

가 아닙니다.

Windows 앱의 설계 가이던스에서도 디바이스, 입력의 종류, 폼 팩터를 걸쳐서 일관되게 사용할 수 있을 것이 중시되고 있으며, 접근성의 관점에서도 장애의 유무뿐만 아니라 밝은 옥외, 공유 공간, 조용한 장소, 시끄러운 장소와 같은 환경 제약까지 포함해 생각하는 것이 중요하다고 되어 있습니다.¹²

그래서 ToC / ToB를 본 후에 추가로 다음 축으로 자르는 것이 추천입니다.

여기를 먼저 잘라 두면 회의 중의 「뭔가 모던」 「뭔가 업무 같은」 의론이 꽤 줄어듭니다.

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

먼저 가장 실무에서 사용하기 쉬운 표를 둡니다.

이 표만으로도 꽤 방향이 보입니다. 특히 중요한 것은 ToB라도 현장 단말은 고밀도 UI가 정답이 아니다는 것과, ToC라도 상급자 도구는 가벼움보다 효율이 정의가 된다는 것입니다.

4. 용도별의 설계 방침

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

ToC의 작은 Windows 앱에서는 먼저 「기동해서 즉시 사용할 수 있다」가 꽤 강합니다.

특히 중시하고 싶은 것은 다음과 같은 점입니다.

• 최초의 1화면에서 무엇을 하는 앱인지 알 수 있다
• 주요 조작이 1~2개로 좁혀져 있다
• 빈 상태가 불친절하지 않다
• 위험한 조작이 취소될 수 있다
• 설정 항목을 처음부터 전부 보여주지 않는다

여기서 하기 쉬운 것이 기술적으로는 할 수 있는 것을 전부 나열해 버리는 것입니다. 하지만 ToC의 가벼운 도구에서는 다기능일 것보다 즉시 사용할 수 있는 것 쪽이 가치가 되는 장면이 많습니다.

Windows의 내비게이션 설계에서도 모든 앱에 공통된 정답은 없으며, 먼저는 일관성, 심플함, 명쾌함이 중시되고 있습니다. 표준 컨트롤이나 표준적인 장소를 사용하면 예측하기 쉬워집니다.⁸

그래서 ToC용에서는,

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

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

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

4.2 ToB 사무 입력・백오피스

사무계 ToB 앱에서 중요한 것은 외관의 가벼움보다 작업이 멈추지 않는 것입니다.

매일 사용하는 사용자는 며칠이면 UI에 익숙해집니다. 그 후에 효과적인 것은 다음과 같습니다.

• 키보드만으로 어디까지 갈 수 있는가
• 일람과 명세를 왕복하기 쉬운가
• 중요한 열이나 상태가 한눈에 알 수 있는가
• 필터나 정렬을 유지할 수 있는가
• 에러가 그 자리에서 고쳐지는가

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

또한 액세스 키는 접근성뿐만 아니라 키보드를 선호하는 파워 유저의 효율 향상에도 유효합니다. 적절한 장소에서는 커스텀 컨트롤도 포함해 액세스 키를 서포트하는 것이 권장됩니다.⁹

사무 입력계에서는 내비게이션으로서 리스트/상세가 꽤 강합니다. Windows의 내비게이션 가이드에서도 리스트/상세는 항목을 빈번히 전환하면서 상세 표시나 갱신을 하는 용도에 어울리며, 메일 수신함, 연락처 리스트, 데이터 입력 같은 케이스에 적합하다고 되어 있습니다.⁸

즉, 이런 구성은 꽤 자연스럽습니다.

• 왼쪽에 기능 분류
• 중앙에 일람
• 오른쪽이나 아래에 명세 / 편집
• 위에 검색, 필터, 주요 커맨드
• 자주 사용하는 조작은 단축키 대응

반대로 피하고 싶은 것은 다음과 같습니다.

• 1 조작마다 다이얼로그
• 열이 너무 적어 일람성이 낮다
• 주요 조작이 우클릭의 안쪽에만 있다
• 아이콘만으로 의미를 표하려 한다
• 탭 순이 엉망이고 Enter도 Space도 효과가 없다

입력 에러에 대해서도, 필드에 연결된 검증 에러는 다이얼로그가 아닌 화면 내에서 내는 편이 자연스럽습니다. Windows의 다이얼로그 가이드에서도 비밀번호란 등의 문맥에 결합된 검증 에러에는 다이얼로그를 사용하지 않고 인라인 표시를 사용하는 것이 권장됩니다.¹⁰

4.3 ToB 감시・운용

감시・운용 화면의 UX는 「사용하기 쉽다」보다 먼저 놓치지 않는다, 실수하지 않는다, 멈추지 않는다가 중요합니다.

여기서 우선하고 싶은 것은 대체로 다음입니다.

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

이 종류의 화면에서는 상태 표현이 UX의 중심입니다. 상태는 가능한 한 색 + 문자 + 아이콘 + 시각의 복수 요소로 표하는 편이 안전합니다. 색만으로 상태를 표하면 놓침이나 식별 실수가 일어나기 쉬워지고, 접근성상도 약해집니다.¹¹

내비게이션은 감시 대상이 많다면 좌측 내비, 개별 대상의 파고들기는 드릴다운, 상세는 로그나 시계열로 내는, 이라는 정리가 다루기 쉽습니다. Windows의 내비게이션 가이드에서도 좌측 내비는 최상위 항목이 많은 경우나 페이지 전환이 빈번하지 않은 구성에 어울립니다.⁸

조작 면에서는 커맨드를 1곳에만 두는 것도 위험합니다. Windows의 커맨드 설계 가이드에서는 커맨드는 버튼, 컨텍스트 메뉴, 단축키, 제스처 등 복수의 면에서 이용할 수 있을 것을 권장하며, 모든 관련 커맨드를 컨텍스트 메뉴나 CommandBarFlyout에 포함할 것이 권장되고 있습니다. hover만으로 나오는 조작에 의존하면 터치 단말이나 지원 기술에서 사용할 수 없게 되기 때문입니다.¹²¹³

위험 조작의 확인 다이얼로그도 여기서는 중요합니다. 다만 「일단 뭐든 확인한다」는 역효과입니다. 정말로 확인하고 싶은 것은 멈춘다, 삭제한다, 전환한다, 차단한다, 덮어쓴다 같은 불가역 쪽의 조작입니다. 다이얼로그를 낸다면,

• 무엇이 일어나는지를 최초의 1행에 명확하게 쓴다
• 버튼 문언은 OK / Yes가 아니라 삭제 / 정지 / 차단처럼 구체적으로 한다
• 안전 측의 버튼을 반드시 둔다

의 3가지는 최저한 지키는 편이 좋습니다.¹⁰

4.4 ToB 현장 단말・장치 UI・키오스크

현장 단말은 Windows 앱 UX 중에서도 꽤 별종입니다.

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

라는 조건이 평범하게 있습니다.

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

또한 터치의 설계에서는,

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

라는 차이가 있습니다.⁴

그래서 현장 단말에서는 대체로 다음 방향이 강합니다.

• 버튼이나 리스트 항목은 충분히 크게
• 1 화면 1 목적에 가깝게 한다
• 조작 후의 반응을 분명히 보인다
• 플로우를 단계화한다
• 입력은 가능한 한 자유 입력보다 선택, 스캔, 정형에 기울인다
• 상태는 화면의 상부나 중앙에서 명쾌하게 낸다

반대로 피하고 싶은 것은,

• 작은 문자
• 작은 히트 영역
• hover 전제의 툴팁 의존
• 깊은 계층
• 1 화면에 대량의 정보
• 긴 자유 입력

입니다.

ToB니까 밀도가 높은 편이 좋다, 라는 거친 발상이 가장 빗나가기 쉬운 것은 이 영역입니다. 여기는 오히려 업무 앱 중에서도 꽤 명쾌함 우선입니다.

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

전문가용의 도구에서는 「알기 쉽게 해 달라」보다 「손을 멈추지 말아 달라」가 이기는 경우가 있습니다.

예를 들어,

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

와 같은 것입니다.

이 종류의 앱에서는 다음이 효과적입니다.

• 정보 밀도
• 복수 페인
• 탭
• 컨텍스트 메뉴
• 단축키
• 레이아웃 저장
• 열이나 표시 항목의 커스터마이즈
• Undo / Redo
• 작업 상태의 복원

Windows의 내비게이션 가이드에서도 탭은 복수의 페이지나 문서를 개폐・나열하고 싶은 케이스에 어울립니다.⁸ 또한 Windows의 커맨드 설계에서는 커맨드는 복수의 UI 면에서 공유하고, 입력 방식이 달라도 같은 조작에 도달할 수 있도록 하는 것이 권장됩니다.¹²

이 종류의 도구에서 하기 쉬운 것이 초보자에게 친절하려 해서 전부를 깊은 메뉴에 숨기는 것입니다. 하지만 숙련자는 매일 몇 백 번이나 같은 조작을 합니다. 그 사람들에게 중요한 것은 최초의 5분의 친절함보다 100시간 사용한 후에도 지치기 어려운 것입니다.

그래서 상급자용에서는

• 고빈도 조작은 가까이
• 보조 기능은 약간 안쪽
• 고도 기능은 지우지 않고 정리한다
• 표시 레이아웃을 저장한다
• 키보드 조작을 두텁게 한다

라는 설계가 효과적이기 쉽습니다.

4.6 상주 도구・트레이 앱

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

예를 들어,

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

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

우선하고 싶은 것은,

• 트레이나 작은 메뉴에서 즉시 만진다
• 지금의 상태를 알 수 있다
• 필요할 때만 알림한다
• 알림에서 직접 필요 조작으로 간다
• 메인 화면이 전면을 너무 빼앗지 않는다

입니다.

피하고 싶은 것은,

• 사소한 일로 다이얼로그를 낸다
• 기동할 때마다 메인 화면을 연다
• 배경 동작의 상태가 보이지 않는다
• 알림이 너무 많아서 전부 무시된다

입니다.

이 종류의 앱은 「기능을 많이 가질까」보다 방해하지 않을까 쪽이 UX를 좌우하기 쉽습니다.

5. 내비게이션의 판단표

Windows의 내비게이션 가이드에서는 모든 앱에 효과적인 1가지 내비게이션 디자인은 없다고 하면서 일관성, 심플함, 명쾌함을 원칙으로 하고 있습니다. 또한 사용자가 기대하는 장소에 표준 컨트롤을 두면 예측하기 쉬운 UI가 됩니다.⁸

실무에서는 대체로 다음 표로 자르면 정리하기 쉽습니다.

Windows의 내비게이션 가이드에서는 특히 다음과 같은 구분 사용이 나타나 있습니다.⁸

• 상부 내비: 모든 내비게이션 항목을 화면에 표시하고 싶을 때
• 좌측 내비: 최상위 항목이 많을 때, 빈번히 페이지 전환하지 않을 때
• 리스트/상세: 항목 전환이 많고, 상세 표시나 갱신이 필요할 때
• 탭: 복수의 문서나 페이지를 동적으로 개폐하고 싶을 때
• 브레드크럼: 깊은 계층에서 돌아갈 길을 알기 쉽게 하고 싶을 때

요컨대 내비게이션은 「외관의 취향」이 아니라 정보 구조와 작업 구조의 반영입니다.

6. 입력 디바이스와 커맨드 설계의 판단표

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

또한 Windows의 플랫폼 컨트롤은 복수의 입력 방식을 어느 정도 흡수해 주므로, 표준 컨트롤을 자연스럽게 사용하는 것이 먼저 강합니다.⁴⁸

실무에서 사용하기 쉬운 정리는 다음입니다.

키보드 주변에서는 특히 다음이 중요합니다.³⁹

• 키보드만으로 전 기능에 도달할 수 있을 것
• Tab 순이 시각 순과 크게 어긋나지 않을 것
• Enter / Space로 눌려야 할 요소가 눌릴 것
• 중요 기능에 단축키가 있을 것
• 고빈도 조작에는 액세스 키나 액셀러레이터를 준비할 것

터치 주변에서는 다음이 중요합니다.⁴

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

커맨드 설계에서는 Windows의 커맨드 가이드가 꽤 참고가 됩니다. 특히 중요한 것은 커맨드를 복수의 UI 면에서 사용할 수 있도록 하는 것입니다.¹²

• 버튼에서 누를 수 있다
• 컨텍스트 메뉴에도 있다
• 단축키로도 부를 수 있다
• 필요하면 스와이프나 제스처도 있다

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

7. Windows 앱에서 최저한 빼고 싶지 않은 UX 항목

여기서부터는 용도를 불문하고 최저한 짚고 싶은 것을 정리합니다.

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

Windows 데스크톱에서 키보드는 「있으면 편리」가 아니라 꽤 본줄기입니다.

Microsoft의 키보드 접근성 가이드에서도 키보드 대응은 시각이나 운동 능력에 제약이 있는 사용자를 위해서뿐만 아니라 효율 목적으로 키보드를 선택하는 사용자에게도 중요하다고 되어 있습니다.³

최저한 보고 싶은 것은 다음입니다.

• Tab 순은 자연스러운가
• 포커스 가시화는 있는가
• Enter / Space로 눌리는가
• 단축키는 있는가
• 우클릭 상당의 조작을 키보드로도 부를 수 있는가

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

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

Windows 앱에서는 문자 사이즈나 대비에 제대로 추종하는 것만으로 UX가 꽤 안정됩니다.

Microsoft의 가이드에서는 가시 텍스트의 대비비는 적어도 4.5:1이 권장되며, 문자가 확대되었을 때는 컨트롤이나 컨테이너도 함께 리사이즈・재배치되는 것이 요구됩니다.⁵⁶

더욱이 대비 테마에서는,

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

것이 권장됩니다.⁷

여기서 무너지기 쉬운 것은,

• 고정 폭 전제의 라벨
• 픽셀 고정의 버튼 높이
• 색만으로 의미를 전하는 설계
• 커스텀 묘화로 테마 추종하지 않는 UI

입니다.

이 부근은 「접근성 대응」이라기보다 길게 망가지지 않는 Windows UI를 만드는 기초 공사로 생각하는 편이 적합합니다.

7.3 다이얼로그를 남용하지 않는다

다이얼로그는 편리하지만 너무 사용하면 작업의 적이 됩니다.

Windows의 다이얼로그 가이드에서는 다이얼로그는 통지, 승인, 추가 정보의 입력이 필요할 때의 모달한 UI이며, 적어도 1개는 안전하고 비파괴적인 조작(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로 주요 요소의 이름, 역할, 패턴 확인
• 키보드만으로 주요 플로우를 통과
• 텍스트 확대와 대비 테마를 시험

정도는 해두면 후퇴가 줄어듭니다.

7.6 회복성을 넣는다

이것은 Microsoft의 1행 체크리스트라기보다 Windows 데스크톱의 실무에서 꽤 효과적인 이야기입니다.

UX는 「기분 좋게 누를 수 있는 버튼」뿐만 아니라 사고나도 돌아올 수 있는 것으로 결정됩니다.

예를 들어,

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

은 외관보다 훨씬 UX에 효과적입니다.

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

8. 자주 있는 설계 실수

8.1 ToB니까 고밀도로 하면 된다, 고 생각한다

이것은 절반만 옳습니다.

매일 사용하는 숙련자용이라면 고밀도가 효과적인 경우가 있습니다. 하지만 현장 단말, 접수 단말, 장치 UI에서는 오히려 밀도는 적입니다.

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

8.2 ToC니까 기능을 너무 숨긴다

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

뭐든 「간단하게 보이는」 방향으로 기울이면,

• 고빈도 조작이 멀다
• 매번 메뉴를 파낸다
• 화면을 계속 전환한다

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

8.3 hover 전제의 조작을 만든다

터치에는 hover가 없습니다. 게다가 포인터에서만 나오는 UI는 지원 기술과의 상성도 나빠지기 쉽습니다.⁴¹²

중요 조작은 상시 보이거나 적어도 복수의 경로를 가지는 편이 안전합니다.

8.4 색만으로 상태를 전한다

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

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

8.5 검증 에러를 전부 다이얼로그로 한다

사무 입력계에서 자주 있습니다. 입력할 때마다 다이얼로그가 나오면 작업 리듬이 완전히 망가집니다.

문맥에 닫힌 에러는 화면 내에서 그 자리에 내는 편이 자연스럽습니다.¹⁰

8.6 고정 사이즈의 레이아웃으로 만든다

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

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

에서 어처구니없이 무너집니다.⁶⁷

외관의 완성도를 올릴수록 고정 전제는 독이 되기 쉽습니다.

8.7 커스텀 컨트롤을 너무 만든다

Windows의 표준 컨트롤은 외관 이상으로 많은 거동을 가지고 있습니다.

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

까지 포함해 돌봐주므로, 이유 없이 전부 자작하면 UX와 접근성의 부채가 늘어납니다.⁸³

9. 착수 전에 정하는 8문

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

이 8문에 먼저 답해 두면,

• 내비게이션이 얕은 편이 좋은가
• 일람 + 명세가 좋은가
• 단축키를 두텁게 해야 하는가
• 다이얼로그를 어디서 사용해야 하는가
• 커스터마이즈를 어디까지 허용할지

가 꽤 자연스럽게 결정됩니다.

10. 정리

Windows 앱의 UX 설계에서 중요한 것은, 「깔끔한가」보다 먼저 「그 사람이, 그 장소에서, 그 입력 방식으로, 멈추지 않고 사용할 수 있는가」를 정하는 것입니다.

대략 정리하면 이렇습니다.

• ToC는 초회 이해와 안심감을 우선
• ToB 사무계는 지속 효율과 키보드 대응을 우선
• ToB 감시는 놓침 방지와 안전 조작을 우선
• ToB 현장 단말은 큰 조작 대상과 짧은 도선을 우선
• 전문가용 도구는 밀도, 단축키, 커스터마이즈를 우선
• 상주 도구는 방해하지 않는 것을 우선

그리고 용도를 불문하고 공통으로 효과적인 것은 다음입니다.

1. 표준 컨트롤을 자연스럽게 사용한다
2. 키보드로 주요 조작이 완결된다
3. 터치나 지원 기술에서 막히지 않는다
4. 문자 확대나 대비 테마에서 무너지지 않는다
5. 중요 커맨드에 복수의 경로를 준비한다
6. 사고나도 돌아올 수 있다

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

11. 참고 자료

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

저자 프로필

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

Go Komura

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

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