[목 차]
CHAPTER 1 정보 설계와 UI 디자인 1
1.1 소프트웨어와 UI 3
__소프트웨어 디자인하기 / 소프트웨어 디자인이란? 3
__사람이 소프트웨어를 조작하기 위해서는 UI가 필요하다 5
__UI란 무엇일까? 5
__소프트웨어와 사용자를 고려하고, 소프트웨어적인 사고로 UI를 구성한다 6
__사용자에게는 UI가 전부 7
1.2 정보 설계 시점에서의 UI 디자인 사고방식 9
__정보는 무엇일까? 9
__정보의 전달 방식과 맥락에 포함된 데이터와 지식의 관계 10
__UI를 허브로 사용해 정보 전달 방식 설계하기 11
__정보 설계는 사물에 뼈대를 제공하는 것이다 12
__정보 아키텍처 12
__정보 설계는 형태가 쉽게 변하는 소프트웨어에 꼭 필요하다 14
__설계를 쌓아서 논리를 연결한다 14
__확장성과 유연성 의식하기 15
__페이스 레이어링 16
__변경 가능성에 대비한다 18
__사용자 환경의 계층 구조 19
__소프트웨어로서의 UI 20
__디자인 공통 언어, 디자인 언어 21
__적극적인 패턴화와 재사용 22
1.3 UI의 구성 요소 24
__UI를 구성하는 기본 요소 24
__콘텐츠 25
__비주얼 요소 26
__뷰와 레이아웃 27
__메뉴와 컨트롤 28
__입력 장치 30
__입력 방법 31
__출력 장치 32
1.4 모델 기반 UI 디자인 33
__모델 아이디어 33
__모델 / 인터랙션 기술 / 룩앤필 35
__디자인 프로세스의 개요 36
__디자인 프로세스의 각 공정 37
CHAPTER 2 유스 케이스 정의 41
2.1 유스 케이스 중심 설계 43
__기능 대신 유스 케이스 고려하기 43
__모든 것은 유스 케이스에 기반한다 45
2.2 유스 케이스 표현 방법 47
__유스 케이스 정의 방침 47
__'누가', '무엇을', '할 수 있다' 구문 48
__행동 시나리오, 페르소나 모델 49
__명사와 동사 / 객체와 태스크 50
__'누가' 하는지 생각하기 51
__'하다'가 아닌 '할 수 있다'를 사용하기 52
__유스 케이스 이름 54
__유스 케이스 분류 54
__유스 케이스 번호 55
__유스 케이스 정의를 위한 도구 57
CHAPTER 3 태스크 정리 59
3.1 태스크 정리 방침 61
__'태스크', '액션', '기능' 61
__특징과 작동에 의한 기능 구분 61
__유스 케이스, 특징, 작동 63
__태스크 리스트 63
__태스크 리스트 확장, CRUD 열 추가 64
__태스크 리스트 보완하기 65
3.2 태스크 찾아내기 66
__태스크 도출 66
__태스크 분기 조건 명시 67
3.3 CRUD 태스크 분류 68
__CRUD 68
__개념 객체와 CRUD 대응 70
__Read는 기본적으로 존재하므로 CUD로 먼저 태스크 정리 71
__CRUD를 사용해 구체적인 태스크 검토하기 71
__유스 케이스 기반 태스크 평가 76
CHAPTER 4 개념 설계 79
4.1 UI의 개념 모델 81
__개념 설계의 목적 81
__개념 설계의 의의 82
__관련 용어 83
__개념 객체 84
__콘텐츠 구조 84
__프레임 구조 85
__내비게이션 구조 85
4.2 콘텐츠 구조 설계 86
__개념 객체의 단서 86
__개념 객체의 요건 88
__개념 객체에 이름 붙이기 88
__이름 살펴보기 89
__용어의 정의(시소러스 정의) 90
__핵심 객체 파악하기 91
__개념 객체의 시점에서 연관성 파악하기 92
__단방향으로 연관성을 나타내는 예시 93
__다중도 나타내기 94
__다중도에서 패턴을 파악하는 방법 96
__개념 객체의 확장, 프로퍼티 작성 98
4.3 프레임 구조의 설계 관점 100
__와이어프레임에 대해 생각해보기 100
__프레임 구조를 설계하는 방침 101
__단위 뷰 102
__콘텐츠 구조와 개념 객체에서 뷰 표현 검토하기 103
__유스 케이스와 콘셉트로 뷰 표현 검토하기 104
__글로벌 내비게이션을 결정하는 방침 107
__앱 단위 또는 모드 단위로 내비게이션 구조를 하나로 사용하기 107
__레이아웃의 기본 방침 결정하기 108
__프레임 표현 방법 109
__콘텐츠 구조와 프레임 구조 대응시키기 112
__마지막으로 레이아웃 정리하기 115
4.4 콘셉트 정의 116
__제공하고자 하는 사용자 경험 나타내기 116
__디자인 철학 나타내기 117
__기능 나타내기 117
__콘셉트 이미지 그리기 118
__콘셉트로 돌아가기 119
4.5 멘탈 모델 정리 120
__멘탈 모델이란? 120
__개념 객체, 태스크, 콘셉트 120
__개념 객체 리스트 작성하기 121
__태스크 리스트 작성하기 122
__콘셉트 리스트 작성하기 122
__부모-자식 관계 나타내기 122
__의존 관계 나타내기 124
__우선순위 나타내기 124
4.6 리버스 모델링 127
__리버스 모델링의 목표와 의의 127
__1단계 UI 이미지에서 개념 객체 후보 추출 128
__2단계 개념 객체 후보가 반복적으로 나타나는 성질인지 판단하기 129
__3단계 프레임 구조에서 유사 표현 찾기 130
__4단계 개념 객체와 콘텐츠 구조 정의하기 131
__5단계 뷰와 개념 객체 대응시키기 131
__6단계 모델 분석 132
CHAPTER 5 내비게이션 구조 설계 135
5.1 내비게이션 설계 방침 137
__내비게이션 설계에 착수해야 할 시기 137
__화면 단위로 구분하는 방식 피하기 138
__뷰 단위로 파악하기 140
5.2 내비게이션의 기본 구조 142
__개요 리스트 상세 표시 142
__개요 리스트와 상세 표시의 기본 세트와 응용 143
__동일 계층 간의 내비게이션 144
5.3 내비게이션의 표현 패턴 146
__드릴다운 146
__스텝형 147
__플랫형 148
__피라미드형(빌딩형) 149
__허브앤스포크 구조 151
__오버레이: 강한 모달 뷰 152
__오버레이: 약한 모달 뷰 154
__오버레이: 모드리스 플로팅 뷰 155
__상태 변화·전환형 156
__콘텐츠 중심의 비선형 내비게이션 157
__내비게이션 컨트롤 내비게이션 바 159
5.4 내비게이션을 보조하는 메커니즘 159
__커맨드와 제스처 160
__브레드크럼 리스트 160
__활성화와 하이라이트 161
5.5 내비게이션 설계의 기본 방침 162
__목표 지점을 1개 또는 2개로 설정한다 162
__다중도 기반 내비게이션 패턴 검토하기 163
__개념 객체를 고구마 줄기와 같은 이미지로 생각하기 164
5.6 양방향 내비게이션 설계와 교차 연결 전략 167
__보텀업과 톱다운 방식 167
__보텀업 방식: 유스 케이스를 참고하여 상세 표시부터 거슬러 올라가기 168
__톱다운 방식: 글로벌 내비게이션 패턴 검토하기 169
__톱다운 방식: 유스 케이스를 참고하여 2단계 이후의 구조 검토하기 172
__유스 케이스의 우선순위 검토 173
__두 설계도를 겹쳐보고 차이를 비교하기 174
5.7 기타 내비게이션 설계 기술 176
__사용자의 능동성과 수동성 176
__노출 기회를 고려하여 배치한다 177
__탭 내비게이션을 간단하게 유지 178
__중간 행동은 기본 원칙에 따른다 179
__컴포지트(복합) 표현: 탭 내비게이션 180
__컴포지트 표현 모드 기반 내비게이션 181
__칸막이식 구조에 주의한다 183
__탭 점프를 억제한다 185
__탭 바 내비게이션 바를 불필요하게 숨기지 않는다 185
__상세 표시의 모달화를 가능한 한 피한다 186
CHAPTER 6 플랫폼에 맞는 인터랙션 설계 187
6.1 폼 팩터와 플랫폼 189
__폼 팩터란? 189
__폼 팩터의 유형 190
__플랫폼의 종류 193
__소프트웨어 개발에서 폼 팩터와 플랫폼의 결정 방식 194
__네이티브 기술의 장단점 196
__크로스 플랫폼 기술의 장단점 197
__웹 플랫폼 브라우저 기반 앱의 장단점 198
6.2 정보 설계와 레이아웃 200
__레이아웃의 기본 원칙 200
__인터페이스의 지향성 201
__우→좌(RTL) 레이아웃 202
__세로쓰기 레이아웃 203
__적응형 레이아웃과 반응형 레이아웃 203
__개념 모델을 기반으로 하는 정보의 계층화와 패턴 검토 205
6.3 데스크톱을 위한 인터랙션 패턴 208
__윈도 시스템과 멀티 윈도 환경 208
__멀티태스크 UI 앱 간 연동 209
__마우스와 키보드 210
__파일 매니저 파일 시스템 210
__멀티 패널 레이아웃 211
__멀티 패널의 패턴 214
__최소 인터페이스 앱 218
__웹 기반 앱 네이티브가 아닌 앱 219
__메뉴와 커맨드 219
__플로팅 툴바 220
__키보드의 바로 가기 바로 가기 키 221
__수식 키 모디파이어 키 222
__키보드의 바로 가기 설계 224
__키보드 내비게이션 226
__작업 취소(Undo) & 다시 실행(Redo) 227
__더블 클릭 229
__보조 클릭(콘텍스트 메뉴) 230
__드래그 앤 드롭 230
__마우스 버튼 길게 누르기(메인 버튼) 231
__클릭하고 잠시 기다리기 232
__마우스 보조 버튼으로 드래그(우클릭 드래그) 232
6.4 모바일을 위한 인터랙션 패턴 233
__터치 제스처 종류 233
__싱글 윈도 환경과 싱글 패널 레이아웃 237
__레이아웃의 3단 구성 237
__시트 표현 239
__모바일 환경에서 고려해야 하는 사항 240
6.5 패턴과 관용 표현 243
__패턴과 관용 표현 활용하기 243
__한 번에 기억할 수 있는 관용 표현 244
6.6 용도별 관용 표현과 예시 247
__에디터/크리에이티브 도구(데스크톱) 247
__오서링 도구 250
__콘텐츠 브라우저(데스크톱/모바일) 253
CHAPTER 7 구조 설계와 인터랙션 설계 257
7.1 정보 구조 패턴 259
__계층 구조 259
__중첩 구조 260
__트리 구조 261
__준격자 구조 263
7.2 모드 267
__모드란 무엇일까? 267
__모드리스 방식의 인터페이스 268
__모달 방식의 인터페이스 271
__1회성 모드 273
__일시 모드 273
__처음부터 모드를 완전히 없앨 수 있을까? 274
7.3 모드리스를 위한 기술 276
__조작 대상 객체가 먼저 눈에 들어오도록 한다 276
__개념 객체에 기반한 이름 짓기 278
__인터페이스를 차단하지 않는다 280
__다중 모달 피하기 284
7.4 모드를 간단하게 만들기 위한 기술 286
__현재 모드를 명확히 보여주기 286
__커맨드명에 '...'을 사용해 모드 발생 암시하기 287
__모달 대화상자는 닫기(x) 버튼을 제거한다 288
__모드가 느껴지지 않도록 만든다 289
__모드의 탈출구 마련하기 291
마치며: 생성형 AI와 UI 디자인 294
참고 문헌 297
찾아보기 300
[본 문]
소프트웨어 디자인은 다양한 정보를 어떤 방식으로든 ‘형태’로 표현한다. 예를 들어 UI 디자인에서는 메타포를 활용하여 사람이 이해하기 쉽도록 표현한다. 그러나 본질적으로는 어떤 표현 방식을 택하더라도 ‘전기 신호의 데이터화를 어떻게 처리할 것인가’라는 공통 과제가 존재한다. 사진을 예로 들면 소프트웨어상의 사진은 기본적으로 비트맵 데이터다. 하지만 ‘사진’이라고 부르면서 현실을 떠올리게 하고, 단순한 데이터의 나열이나 비트맵 이상의 어떤 가치를 지닌 것으로 표현하는 것이 UI 디자인에서는 중요한 주제다. (7쪽)
무언가를 모델로 검토하는 것은 합리적이다. 거대한 건축물을 짓는 데 있어서 실제 크기로 지어본 뒤 세부적인 설계를 검토한다면 너무 비효율적일 뿐만 아니라 건축물을 다시 짓게 될 수도 있고 돈과 시간도 너무 많이 소비된다. 만족할 때까지 짓고 부수는 일을 반복하는 것은 건물을 짓는 목적을 잊게 만든다. 짧은 시간 안에 만들 수 있는 도면이나 축소 모형 등의 모델을 통해 설계를 검토하면 실물 크기의 건축물을 세우거나 실제로 물건을 만들지 않아도 세부적인 설계를 수행할 수 있다. 이렇게 모델을 활용하는 것은 구조물을 만드는 비용을 크게 줄여준다. (34쪽)
CRUD에서 Read에 해당하는 것은 데이터 표시와 관련된 태스크가 대부분이다. UI 관점에서는 개념 객체가 UI에 나타나는 것은 매우 당연하므로 굳이 데이터를 불러오는 태스크를 명시적으로 정의할 필요성은 크지 않다. 따라서 특정 버튼을 눌러 데이터를 표시하는 방식의 명시적인 Read 구조를 검토하는 것이 아니라면 처음부터 Read는 기본적인 태스크로 두고 CUD 세 가지 타입의 태스크를 우선 정리하는 것이 현실적이다. (71쪽)
설계의 기본 방침으로 먼저 내비게이션 구조를 단순하게 설계하고 각 개별 레이아웃을 나중에 연결하고 추가하는 방식으로 UI를 설계해보자. 이 방식은 내비게이션의 전체 구조를 미리 완성할 수 있으므로 이후 내비게이션 수정 시 레이아웃을 다시 만들어야 하는 재작업의 필요성을 줄이고 작업 비용을 최소화할 수 있다. 모델 기반 UI 디자인에서는 개념 설계와 콘셉트 정의의 결과물을 적극 활용한 설계 방식을 권장한다. (85쪽)
왼쪽에서 오른쪽(LTR)으로 읽는 레이아웃은 인터페이스가 기본적으로 왼쪽 정렬을 중심으로 구성되므로 왼쪽에 있는 요소일수록 노출 빈도가 높아진다. 반대로 오른쪽으로 갈수록 스크롤 뷰에 가려지거나 생략될 가능성이 높다. 따라서 탭 바의 왼쪽에는 가장 중요한 정보나 내비게이션을 배치하고 오른쪽에는 상대적으로 중요도가 낮은 항목을 배치하는 것이 좋다. / 예를 들어 Bluesky 앱에서 사용 빈도가 낮은 계정 탭을 왼쪽 끝에 두게 되면 이는 우선순위 측면에서 명백히 잘못된 설계이며, 홈 탭을 가장 왼쪽에 두는 것이 논리적으로 적절하다. (177쪽)
메뉴 바를 설계할 때는 현재의 콘텍스트나 선택된 객체에 대해 실행할 수 없는 명령이라도 비활성화된 상태로 표시하고 커맨드의 존재 자체를 숨기지 않는다. 이렇게 하면 현재 콘텍스트에서는 사용할 수 없는 커맨드라는 것을 인지할 수 있으면서도 앱을 직접 다루는 과정에서 해당 커맨드가 유효해지는 조건을 쉽게 발견할 수 있고, 이를 통해 사용자의 학습을 강력하게 지원할 수 있다. (293쪽)
AD광고
AD광고
