
디자인 카타
오늘의 토픽 - Selector 어떤 것을 선택하시겠어요?
선택 B안
A안과 B안 사용 사례가 골고루 많은 편이지만 B안 같은 경우에는 사용자가 박스 버튼의 크기가 이쯤 되는 구나 하고 누를 수 있는 범위를 예측할 수 있으며 이게 버튼이구나를 알 수 있음
A안 같은 경우 강조하고 싶지 않은 버튼에서 박스버튼을 누를 수 있는 범위를 예측할 수 없고 버튼 조차 아니라고 생각할 수 있는 요소라고 생각하기 때문임
A-E-I-O-U 관찰법을 활용한 사용자 정의
자료 조사로는 최근 1년 간의 뉴스 기사, 포털 검색, 각종 보고서나 논문 등을
활용할 수 있음
다만, 나는 최근 1년이 아닌 폭 넓게 2년~3년을 찾았으며 공식적인 문서여야 함에 대한 압박이 있었음
논문 올라가는 데 걸리는 시간을 계산했을 때 뉴스 자료 위주로 찾아보는 등 유동성이 큰 분야에서는 3개월, 6개월로 찾아봐야 함을 느낌
배민의 방문 포장 수수료 증가로 인해 자영업자 입장에서 음식 가격을 올리지 않을 수 없는 상황, 고물가와 고금리로 인한 배달비의 증가 등의 부담요인으로 인한 시장
시장조사에서 조금 아쉬운 부분이 보임
객관화된 데이터를 수집할 것
친화도 분석 시
해야 할 목표를 정의하는 데
배달/포장 서비스를 이용하는 사용자에게 만족스러운 서비스 제공하기
데이터를 모은 후
사용자의 관점에서 말하는 것처럼 표현해도 좋으며, 여러 방법으로 데이터를 모음
정보의 유사성을 기준으로 그룹핑 및 라벨링
사용자 흐름 파악
수집하는 정보를 이쪽으로 옮겼다가, 저쪽으로 바꾸고 여러번 분류하는 과정을 반복함으로 스스로 생각하는 힘과 관점을 기름
문제 발견
친화도 분석으로 그룹핑된 내용들을 살펴보며
사용자가 갖고 있는 주요한 문제가 무엇인지를 보아야 함
다만 친화도 분석을 가져온 것이 아닌 개별적인 문제 발견으로 과제를 진행했다고 생각하여 아쉬운 마음이 있음
HMW의 경우 Point of View 사용자의 시선으로 바라보기, HMW (How Might We?) 어떻게 하면에 맞춰
드러나는 요구 Needs 1를 배열하는데 피드백을 받아봐야 알겠지만 많은 실습과 복습이 필요함을 느낌
HMW로 만든 질문에 답변을 찾아보면서 문제를 해결할 다양한 아이디어를 도출하는데 HMW의 사용자 시선으로 바라보기를 잘못 잡은 것 같아 아이디어 도출 또한 잘못된 결과를 가져온 듯 보이기도 함
심화 과제는 진행하지 못하였는데 피그마에 사용자, 문제, 문제 해결의 아이디어를 한편에 놓고 제작하면
괜차나...이제 시작이니까😭😭
웹과 앱의 특성
웹과 앱은 보기에 큰 차이가 없어 보이지만 많은 차이점 존재
웹과 앱의 특성 비교
대표적인 웹과 앱의 UI 차이
페이지 이동
앱은 임의로 주소를 입력해 이동이 가능하나, 웹은 주소창에 URL 입력 시 어디든 접근 가능
뒤로가기
앱의 경우, 일반적 화면 상단의 아이콘 등 버튼을 눌러 화면을 이동하나, 웹의 경우 브라우저 자체 기능을 통해
이전 화면으로 돌아가는 것이 자유로움
주요 메뉴 이동
모바일 웹에선 일반적으로 화면 상단에 주요 메뉴로 이동할 수 있는 UI를 배치함
앱에선 화면 하단에 고정된 탭을 배치 주요 메뉴로 이동할 수 있도록 함
두 UI는 동일 목적과 기능을 지니지만, 웹과 앱에서 다르게 나타나는 대표적 UI
최근에는 모바일 웹도 앱처럼 화면 하단 고정 메뉴로 변화하는 중
바텀 시트
화면 하단에 고정되어 현재 화면에 관련된 옵션이나 메뉴를 제공하는 UI
화면 하단에 고정이 되어있음
앱의 경우 바텀 시트를 다양한 용도로 활용, 모바일 웹에서는 사용하기 까다로움
앱에서는 바텀 시트를 드래그해서 닫을 수 있지만, 모바일 웹에서는 드래그해서 닫기 어려움
OS별 차이
아이폰의 경우, 애플 로그인이 다른 로그인 수단에 비해 덜 중요하게 보이지 않도록
소셜 로그인의 경우, 애플 로그인도 로그인 수단에 반드시 포함
아이폰의 앱 경우 로그인 순서가 맨 앞에 있는 것을 볼 수 있음
iOS 홈 인디케이터
홈 인디케이터란 아이폰에서 홈 화면으로 이동할 수 있는 UI
다른 UI와 다르게 화면 위에 있기 때문에 실제 화면과 겹치는 경우가 있음
홈 인디케이터가 있는 경우, 하단에 고정된 UI들을 신경 써야 함
안드로이드 네비게이션 바의 뒤로가기
안드로이드 사용자들이 뒤로가기로 눌렀을 때 어떻게 이동해야 하는지 정하기 위하선
같은 아이폰이라도, 홈 인디케이터 때문에 차이가 생길 수 있음
차이에 따른 Ui 디자인은 절대적인 기준이 아니기 때문에, 사용성을 고려해서 선택해야 함
분기점은 디스플레이의 해상도에 따라 각각 다른 화면을 보여주기 위한 기준점
분기점이 중요한 이유
노트북으로 접속 시 모바일 화면이 나온다거나, 모바일 접속 시 데스크탑 화면이 나오면 매우 불편함
즉, 우리는 사용자의 디바이스 화면 크기를 고려해 디자인을 나눌 수 있어야 함
그 나누는 기준점이 바로 분기점
분기점은 이렇게 읽을 수 있어요!
가로가 1024px 이상 시 데스크탑 화면
가로가 768px 이상 시, 1024px 미만 시 태블릿 화면
가로가 768px 미만 시 모바일 화면
분기점을 정할 때 생각하면 좋은 것
태블릿 해상도 대응
태블린 생략, 태블릿 해상도 전체를 모바일 분기점으로 통합하는 경우도 많음
태블릿 사용자가 데스크톱과 모바일에 비하면 매우 적으며, 디자인과 개발 시 화면 세트가 하나 증가하기 때문
태블릿 분기점을 고려해야 하는 경우도 있는데 온라인 강의나 교육의 경우 태블릿을 주로 이용하기 때문에, 이런 경우 태블릿 해상도 고려
일반적 해상도 말고 다른 해상도를 정하고 싶다면?
사람들이 사용하는 기기 해상도 통계를 참고 시 어디서부터 데스크톱으로 하면 좋은지 힌트를 얻을 수 있음
통계자료 웹사이트
그리드는 원래 격자라는 뜻인데, 화면에 디자인을 배치하는 가이드라인임
일반적으로는 세로 방향의 기둥들을 좌우로 세우는데, 가로 줄을 추가로 사용하는 경우도 있음
디자인 배치할 기준선이 되는 가상의 선을 긋고, 그 선에 맞춰 레이아웃을 짜게 됨
그리드를 사용하는 이유
원래 그리드는 편집 디자인에서 쓰는 용어인데, 종이에 글과 그림을 배치하는 기준점
글과 그림들을 균형감 있게 배치하기 위해 사용
또한 주목해서 읽어야 하는 부분 강조, 적당한 간격으로 더 잘 읽히게 하기도 하는 등 전체적 완성도를 올리기 위해서 임
웹에서 그리드 사용 이유 역시 균형감, 완성도, 일관성을 위해서 임
그리드를 만드는 방법
그리드는 일반적으로 세로 방향 기둥들을 몇 개 둘지 정하는 게 우선이며, 이 기둥을 칼럼이라고 부름
자주 사용하는 그리드 예시
해상도에 맞게 움직이는 유동적인 디자인
우리가 다루는 디자인은 데스크탑부터 모바일까지 화면 크기가 다양한데, 따라서 디자인도 화면 크기에 대응해 레이아웃이 달라야 함
반응형 디자인과 적응형 디자인
반응형 디자인은 말 그대로 반응하는 디자인임
해상도 변화에 따라 실시간 반응
적응형 디자인
적응형 디자인은 한번 적응하면 움직이지 않은 고정된 디자인
해상도 변화하더라도 반응을 하지 않거나 실시간으로 변하지 않음
반응형과 적응형의 차이 및 특징
반응형 디자인과 적응형 디자인의 움직임
디자인을 브라우저에 띄울 때의 차이
반응형 웹사이트 그리드 만들기
기획을 디자인으로 옮기는 방법
먼저 전체적 개요와 흐름을 정하며, 개발자-디자이너-기획자 간 이해도 동일 시 맞춰야 함
일반적으로 정보구조도와 화면흐름도를 만듦
반드시 해야하는 것은 아니며, 만드는 시점 형식 모두 회사마다 다를 수 있음
정보구조도와 플로우차트의 차이
제품을 하나의 건물로 비유 시, IA는 층별 안내도, 플로우차트는 오시는 길이라고 할 수 있음
정보구조도
정보구조도의 영문 앞글자를 따 IA라고 부르기도 함
화면과 정보들이 어떤 구조로 연결 있는지 나타내는 일종의 설계도라고 할 수 있음
정보구조도의 예시
화면흐름도
플로우차트라는 이름으로 더 많이 사용
사용자가 어떤 과정으로 제품을 이용하는지 시각적으로 정리한 순서도라고 할 수 있음
순서도의 예시
와이어프레임과 프로토타입을 만들기 위해서는 사용자 시나리오가 필요한데, 이 사용자 시나리오를 만들기 위해 정보구조도 작성 및 플로우차트를 만든다고 생각하면 됨
와이어프레임은 말 그대로 선(와이어)으로 그려진 화면을 말함
어떻게 만들지 논의 과정을 거치고 나면, 본격적 디자인을 하기 전에 주로 하게 됨
낮은 단계의 프로토타입이라는 뜻에서 Lo-fi Prototype이라고 부를 때도 있음
와이어프레임을 만드는 이유
팀원 간의 다른 생각을 통일할 수 있고 협업을 원활하게 함
디자인 관리가 쉽고, 불필요한 부분에 시선을 뺏기지 않음
습관 형성 모델을 반복적으로 실험해 볼 수 있음
와이어프레임 그리는 법
와이어프레임 규칙 정하기
표현할 것과 표현하지 않을 것을 과감하게 고르고, 최대한 단순 빠르게 그릴 수 있도록 단색의 선 사용하는 것을 권장
그리고자 하는 화면 스케치하기
최대한 단순하게 그리는 게 핵심
시나리오에 필요하지 않은 부분은 과감하게 글자나 단순한 도형으로 대체
텍스트의 경우 최대 길이를 가늠할 수 있도록 실제 사용할 내용으로 넣어주면 좋음
화면을 선으로 연결하기
화면들이 어떤 관계로 이어져 있는지 파악하기 위함
디자인과 레이아웃을 단순하게 만들어 각 화면들이 어떻게 연결, 이 화면에서 저 화면으로 이동하려면 어떤 동작을 하게 되는지를 알기 쉽도록 선으로 연결
1주차 숙제
숙제 1 : UI 차이점 찾아보기
안드로이드

iOS

윙크
앱 화면의 비율로 인하여 안드로이드의 경우는 두번째 줄의 아이콘 까지 보이나, 아이폰의 경우 두번째 아이콘은 반까지 밖에 보이지 않음
안드로이드와 아이폰 색상 출력값이 다르다 보니, 사진도 다르게 보임
안드로이드

iOS

네이버
안드로이드에는 하단 맨 왼쪽에 뒤로가기 버튼이 존재하여 뒤로갈 수 있는데, 아이폰의 경우 왼쪽에서 오른쪽으로 넘기거나 둘다 적용이 되는 하단 네비게이션바를 통해 뒤로갈 수 있음
비율로 인한 광고 배너가 안드로이드가 좀 더 밑에 배치되고, iOS가 좀 더 위에 배치되는 차이점을 지님
웹
앱

적응형 디자인이 적응된 듯 보이는데,
메시지 입력이 웹에서는 정가운데에 배치되어 있는데, 앱의 경우 하단에 있음
웹 같은 경우 예상 질문 경우에도 메시지 입력 바 밑에 있음을 알 수 있는데,
앱의 경우 메시지 입력 바 위에 위치되어 있음
숙제 2 : 와이어프레임 그리기
가상의 OTT서비스의 콘텐츠 목록 화면과 콘텐츠 상세 정보 화면
복제된 콘텐츠 상세 정보 화면에 구독을 권유하는 다이얼로그