podium_nam0422

내일배움캠프 8일 차입니당~

오늘도 여러 가지를 배웠지만 그중에 하나인 아이콘을 다뤄 보려고 합니다!

본격적으로 아이콘을 만들어보기 전에 먼저 피그마에서 만들 간단한 아이콘에 대해서 

정의해볼게요.

1. 아이콘의 역할

아이콘은 남녀노소, 동서양을 막론하여 제한 없이 누구나 일관된 의미를 전달할 수 있습니다.

또한 브랜드의 아이덴티티를 나타내기도 합니다. 예를 들어 맥도널드의 브랜드 이미지를 떠올리면 

'M' 자의 아이콘을 떠올리게 되어 브랜드의 성격, 이미지, 의미를 반영한 아이콘은 

사용자의 기억에 오래도록 남아 있게 됩니다.

2. 일관된 아이콘 스타일

무수히 많은 아이콘에는 일반적으로 사용하는 다양한 스타일이 있습니다.

outlined, filled, colored, image와 같은 스타일이 있으며 일관된 스타일을 적용하는 것이 

사용자의 인지 시간을 단축시킬 수 있습니다.

각자의 아이콘 스타일마다 다른 이점이 있으며 오늘 만들어본 아이콘은 outlined 아이콘을 

만들어 보겠습니다.

방금도 말했듯이 아이콘을 만들 땐 일관성이 중요합니다.

outlined 아이콘을 만들 때 stroke 두께에 따라서 아이콘의 분위기도 달라지기 때문에

스트로크 굵기도 일관된 스타일로 만들어야 합니다.

3. 아이콘 단순화

사용자가 모바일로 아이콘을 볼 경우 그 크기가 매우 작아집니다.

그리고 아이콘의 모양이 디테일할수록 어떤 사용자의 경우 그 아이콘의 기능이

무엇인지 인지하지 못할 경우가 생길 수 있죠.

왼쪽의 시계 아이콘이 디테일하게 표현이 되어 완성도가 높아 보일 수 있지만 모바일 화면에서는 

작아지기 때문에 단순화하는 것이 더 좋은 아이콘이 됩니다.

4. 아이콘 레이아웃

아이콘을 만들기 위해서는 일관성이 중요하다고 했습니다.

통일성 있는 아이콘을 만들기 위해서는 아이콘의 크기도 똑같이 만들어 주는 것이 좋습니다.

아이콘을 본격적으로 그리기 전에 레이아웃 영역부터 그려주면 좋은데요.

일반적인 아이콘 사이즈는 24x24 사이즈를 사용합니다.

특히 아이콘은 여러 파일 또는 툴에 자주 이동이 될 수 있기 때문에 24 사이즈의 레이아웃을 잡았다면

24 사이즈를 넘지 않아야 합니다.

피그마에서 아이콘을 만들기 전에 24x24 프레임을 만들어 주었습니다.

그리고 20x20의 라이브영역의 프레임도 만들어 주었습니다.

사진에 있는 각 프레임을 표시한 수치 영역은 이렇습니다.

1) 트림 영역 : 아이콘 실제 사이즈

2) 라이브 영역 : 패딩 영역을 제외한 실질적 작업 영역

3) 패딩 : 트림 영역 안쪽으로 상하좌우 2만큼의 영역

아이콘은 라이브 영역 안에서 작업을 해주되 트림 영역 밖으로 확장되지 않도록 주의해야 합니다.

https://toss.tech/article/senior-usability-research

요즘 앱을 켜거나 웹 사이트를 들어가게 되면 UI 보는 맛에 재미가 들린 것 같아요 :)

어떤 UI가 잘 보이고 어떤 프라이머리 컬러를 사용했는지, 어떤 기능을 하는 건지 궁금해서 

앱 또는 웹에 머물러 있는 시간이 많아지는것 같아요.

앱 또는 웹 개발자 분들은 모두에게 평등한 경험을 제공하기 위해 많은 노력을 아끼지 않는 걸 느끼는데요.

제가 사용하는 모든 앱과 웹들은 많은 디자이너와 개발자 분들이 협력하고 연구한 끝에 이런 서비스를 누리는

거라고 생각해요.

그에 그치지 않고 시니어 사용자와 시각 장애인 등 디지털 시대에 환경에 비교적 덜 노출되는 분들을 위한 

노력에도 아끼지 않는데요. 이 분들의 행동 패턴과 이해 방식을 연구하며 어떤 결과가 생기는지 조사한 

사례도 있습니다.

토스에서는 시니어 사용자를 대상으로 직접 대면하는 UT를 진행했다고 합니다.

조사 방법은 간단했어요. 시니어 사용자들에게 평소처럼 앱을 사용하시되, 그때그때 드는 생각이나 궁금증을

소리 내 표현해 달라고 부탁했는데요. 사용자들의 오인지가 생기는 부분에 대한 맥락과 시니어가 가진 이해력을

충분히 파악할 수 있게 꼬리를 무는 질문을 이어 나가는 방식으로 UT를 진행했다고 합니다.

그렇게 진행한 조사 결과 토스에서는 크게 다음과 같은 5가지의 문제점들이 발견되었다고 합니다!

1) 컴포넌트에 대한 오인지

우리가 생각하는 아이콘(화살표나 설정, 체크 박스 등)을 시니어들은 그 기능을 바로 알아차리기 어려워했습니다.

특히 리스트 화면에서 어디를 클릭해야 진입할 수 있는지 혼란스러워 하는 상황도 있었습니다.

2) 예시 이미지에 대한 오인지

입출금 내역 예시 이미지에 대한 내용인데요.

모션이 들어간 예시 이미지 때문에 예시 이미지를 보지 못하고 자신의 정보로 잘 못 인식하는

경우가 있었다고 합니다.

3) 모션 그래픽에 대한 오인지

얼굴을 등록할 수 있는 페널에서는 '얼굴 등록'이라는 서비스를 마주하였을때 문구보다 캐릭터를 집중하여

캐릭터의 동작을 100% 동일하게 따라 해야만 등록에 성공할 수 있다고 생각해 등록에 실패하는 경우가

발생하였다고 합니다.

4) 라이팅에 대한 오인지

대부분의 사용자들은 '어떤 서류가 필요한가?'라는 질문형 텍스트를 통해 '필요한 서류를 안내받을 수 있다'는

점을 떠올리지만 시니어들은 문장을 있는 그대로 받아들여 '나에게 질문한다'라고 생각해 혼란스러운 경우가 

생겼다고 합니다

5) 화면 구조에 대한 오인지

일부 시니어 사용자들은 하단의 추가 콘텐츠가 잘 드러나지 않으면 스크롤을 시도하지 않았다고 합니다.

보이는 내용을 위주로 화면을 이해하다 보니 전반적으로 서비스를 잘 못 이해하는 상황도 발생했다고 합니다.

토스사에서는 이렇게 모은 인사이트를 바탕으로 전사에 배포하여 추가적인 리서치나 논의를 하여

현재도 많은 부분이 수정되었다고 합니다!

또한, 이 글을 읽으면서 시니어나 2030의 세대에 맞추어 UI를 제작할 경우 결국엔 너무 심플해지거나 또는 너무

디테일하게 디자인이 되지 않을까?라는 걱정을 해보았는데요.

토스 앱의 UI가 사람마다 다르다고 하더라고요. 시니어는 시니어에게 맞춤이 되어 서비스가 제공된다고 하니

참 신경을 많이 썼구나 하는 걸 느끼게 되었습니다.

위 다섯 가지의 문제점이 현제는 어떻게 개선이 되었을지 토스 앱을 통해 확인해 보면 많은 공부가 될 것 같네요!

오늘 하루도 열공했습니다.

지난주에는 피그마의 기초 용어에 대해서 공부하느라 정신도 없고 너무 어렵다고 느껴졌는데요

이번에 배운 내용은 그래도 저번보다 재밌게 배울 수 있었습니다.

드디어 앱 개발자에 한 발자국 다가간 느낌이 들어서 재밌는 강의가 되었답니다 :)

그래서 오늘 배운 내용을 블로그로 정리해 보면서 다시 학습하는 시간을 가져볼게요!

01) 프레임 만들기

먼저 프레임을 만들어 보겠습니다. (아무사이즈로나 만들어 주세요)

그리고 왼쪽 패널의 늘 사용하던 디자인 패널이 아닌 프로토타입 패널로 들어가 보겠습니다.

프레임이 선택되어 있는 상태로 프로토 타입을 눌러 주세요! 

그리고 프로토타입 세팅 밑에 있는 선택 바를 다시 눌어보겠습니다.

갑자기 좌르륵하고 뜨는데요 이 옵션이 프레임을 자동으로 잡아주는 아주 고마운 기능이더라고요!

이름을 보시면 친숙한 기기의 이름들이 보이는데요 저는 안드로이드 폰을 사용하고 있기 때문에 안드로이드로 

프레임 크기를 맞추고 진행하겠습니다. 여러분들은 원하는 사이즈로 사용하셔도 상관없습니다.

2) 홈 화면 만들기

프레임이 완성되었다면 위와 같이 이런 바 모양도 만들어 볼게요 (아이콘은 아무 모양 상관없이 사용해도 괜찮습니다)

이렇게 리스트 레이아웃도 만들고

만든 오토 레이아웃 리스트를 여러 개로 복붙 후 오토레이아웃으로 다시 또 묶어 주었습니다.

개수는 몇 개든 상관없습니다. 크기에 맞추지 말고 더 길게 만들어 보세요!

저는 위 와 같이 홈 화면을 만들어 보았습니다.

큰 프레임 안에 들어있는 모든 컨테이너 밑 파운데이션은 오토레이아웃으로 묶어주지는 않았습니다,

※화면 제목 아래 있는 회색 화면은 히어로 영역이라고도 불리며 보이는 메인 화면입니다.

현재 구성되어 있는 모든 UI들은 기능이 있고 목적이 있는 UI들로만 구성된 일종의? 최적화된 화면이네요.

3) 목록 화면 만들기

목록 화면은 앞서 만든 홈 화면과 비슷하게 만들어 주었습니다.

또한 앞 강의에서 만든 Lavel 텝도 컴포넌트로 묶인 상태로 가져와 꾸며 보았습니다 :)

목록 화면은 동일한 형태의 정보 덩어리를 반복적인 패턴으로 보여줄 때 사용하며 리스트 컴포넌트라고도 불립니다.

4) 상세 화면과 로그인 화면 만들기

비슷한 방식으로 만든 상세 화면과 로그인 화면입니다.

버튼 라벨과 체크박스 그리고 플레이스 홀더 텍스트 박스도 이 전 강의에서 만든 컴포넌트를 가지고 와 복붙 해 주었습니다.

이렇게 만들었다면! 4개의 앱 화면이 만들어졌습니다!

5) 모바일 화면으로 프리뷰 보는 방법

이제 만든 앱 화면을 프리뷰로 한번 확인해 보겠습니다.

피그마 오른쪽 바 상단 박스에 화살표 아이콘을 확인해 주세요!

그리고 옆에 있는 화살표를 눌러보겠습니다.

프리셋과 프리뷰 둘 중 아무거나 눌러도 상관없습니다.

저는 프리뷰를 눌러볼게요.

이렇게 피그마 화면에 재밌는 화면이 나타난 걸 확인해 보실 수 있습니다.

내가 만든 앱이 가상이지만 모바일 화면에 나타나니 뭔가 실감이 나네요 :)

상단에 있는 화살표도 눌러 가면서 조작을 해보니 차례대로 움직이는 걸 확인해 볼 수 있었습니다.

이렇게 재밌는 UI 만들기 하루가 끝났는데요. 요즘 시간이 참 빠른 것 같다는 생각이 듭니다. 

남아있는 부트캠프의 날짜도 어느덧 70 며칠 밖에 안 남았는데 

어서 빨리 실력을 키워서 UI/UX 디자이너로 취업하는 날이 왔으면 좋겠습니다!

P.S

6) 슬라이드 앱 화면 만들기

ㅎㅎ 왠지 아쉬운 글이 될 것 같아서 추가적으로 더 작성해 볼까 합니다!

우리가 홈 화면을 만들 때 사용한 리스트 제목 레이아웃이 있잖아요?

프레임보다 개체가 클 때 사용 가능한 기능입니다. 

우리가 앱을 사용할 때 손가락으로 슬라이드를 하잖아요? 바로 그 기능입니다!

홈 화면 프레임을 선택해 준 상태에서

포지션이 스크롤 위드 페어런트를 확인해 주고 

오버플로우를 버티컬로 바꿔 주신 후 프리뷰로 확인해 주세요!

그럼 이제 프리뷰 화면을 슬라이드 해보시면 이렇게 화면이 움직이는 것을 확인해 보실 수 있습니다!

https://brunch.co.kr/@maju/42

인터뷰를 진행하기 위해서 많은 준비가 필요합니다.

일단 당연히 무엇을 위한 인터뷰인지에 대한 사전 준비는 필수겠죠?

오늘은 UX디자이너에게 필요한 인터뷰 사전 준비에 대해서 다루어 볼까 합니다.

이번 아티클을 읽고 UX디자이너에게 사용자를 어떻게 조사해야 하는지, 사용자를 어떻게 정의해야 하는지

좀 더 심층적으로 알 수 있게 된 글이었습니다.

01. 인터뷰를 하는 목적

UX디자이너에게 사용자란 그저 고객이 아닌 한명 한명의 소중한 자료가 될 수 있겠다는 생각이 들어요.

내가 만약 앱 또는 웹을 개발했다라면 그 앱 과 웹이 어떻게 좋은지? 불편한건 없는지? 각자 사용자들마다

생각도 다르고 사용법도 다르기 때문에 UX디자이너에게는 하나의 이정표가 될 수 있지 않을까 싶은데요.

인터뷰의 목적에 대해선 더블 위 이미지의 더블 다이아몬드 모델을 보며

발견 (Discover)과 정의(Define)에 대해서 알아보았습니다,

발견 단계에서는 사용자들의 경험을 관찰, 문제 정의에 필요한 단서를 찾는 단계입니다. 또한, 여러 현상 속에서 문제의 본질을 찾는 단계입니다.

이 후 정의 단계에서는 발견한 현황과 문제, 그리고 니즈를 정의하여 인사이트를 도출하는 작업을 하는 단계입니다.

이를 통하여 문제를 정확히 이해해 해결해야 할 핵심 니즈를 파악하여 이 후에 진행될 아이디어 발전 단계에 반영하는 것입니다.

프로젝트를 진행하기 전 또는 후에 인터뷰는 진행할 수 있습니다.

문헌이나 리포트 자료들로 충분한 데이터 수집은 가능하지만 우리는 UX디자이너를 위한 인터뷰이죠?

필드 리서치 즉, 사용자가 왜 그런 행동을 했는지 파악하기 위해 사용자와의 인터뷰가 필요합니다.

인터뷰를 통해 오랜 시간 동안 경험을 쌓은 대상에게 직접 질문하고, 이해함으로써 겉으로 드러나 있지 않은 

숨은 니즈를 발견할 수도 있습니다. 이런 경험은 UX디자이너에게 혼자서 고민해서 얻을 수 없는 '진짜 인사이트'를

발견할 수 있을 것 입니다.

02. 인터뷰 진행 과정

리서치 대상 선정에는 리서치 결과의 신뢰도를 높이는 결정짓는 중요한 작업입니다.

'어떤 이커머스'를 만들지에 대한 목표에 따라 리서치 대상을 정하는 것은 생각보다 까다로운 작업이 될 수 있습니다.

장소와 시간 어떻게 리서치 대상을 모을지는 위 링크에 상세하게 나와 있습니다.

인터뷰에 역시 중요한 건 질문이라고 할 수 있겠죠? 얼마나 중요한 질문을 하는가?, 인터뷰자의 속에 있는 인사이트를

어떻게 도출해 내는냐?는 질문의 품질에 따라 내가 원하는 인사이트를 받아 내는지 달라질 수 있습니다.

너무 딱딱하게 내가 얻고 싶은 것에만 몰두해 질문하게 된다면 당연히 100%로 좋은 인사이트를 얻어내기 힘들어 질 수도 있습니다.

리서치 대상과의 인터뷰가 힘들다면 아래 내용을 숙지 후 인터뷰를 진행하는 방법도 좋은 방법이 될 것 같습니다!

1) 라포 형성하기

인터뷰 시간이 60분이라고 했다면 5~10분 정도는 신뢰 관계를 쌓는 작업이 좋습니다. 

2) 인터뷰에는 정답이 없다는 말을 해주기

대부분의 대상자는 인터뷰가 처음인 사람이 많을겁니다. "인터뷰에는 정답이 없습니다."라는 말을 해주고, 어떤 대답이든 

공감과 가벼운 칭잔을 해주는 것이 좋습니다.

3) 인터뷰 중 답변을 받아 적지 말자

인터뷰 중 답변을 받아 적는 행동은 대상자의 말에 집중하지 못 하고 있다는 생각을 하게 할 수도 있습니다.

이 후에 녹음한 내용을 다시 들으면서 정리하는 것이 성공적인 인터뷰가 될 것입니다.

4) 꼬리에 꼬리를 무는 질문 ( 5 whys)

답변에 단순한 '왜요?'가 아닌 원인, 회의, 맥락, 제기, 패턴에 대한 질문이 좋습니다.

5) 질문에 중요도를 부여하자

인터뷰 질문지 작성 시 줄문의 중요도를 상, 중, 하로 구분하여 우선순위를 부여하는 것이 시간관리가 되어 효율적인 인터뷰가 가능해집니다.

03. 인터뷰 후, 분석 단계

인터뷰를 진행하였다면 발견한 문제와 정보를 간추리며 인사이트를 도출하는 것이 중요합니다.

리서치를 통해 사용자들이 어떻게 행동하는지, 어떤 문제를 겪고 있는지, 어떤 니즈가 있는지 등을 한눈에 볼 수 있도록 정리해보아야합니다,

이렇게 보기 좋게 정리가 되었다면 정리한 문제를 분류하고 유형화하여, 어떤 문제에 집중할지 고민하는 단계가 되면 

더욱 좋은 개발이 될 수 있게 되겠죠?

문제에 대한 자각,

자각이 되었다면 어떤 문제를 집중적으로 변화를 줄지 정해보는 시간이 좋겠죠?

저는 UI디자이너가 목표기는 하지만 UX디자인도 흥미가 생기는 글이였습니다 ^^

분명 앞으로 여정에서 UI만 할 거다! 라는 확신은 가지고 걸어가고 있지는 않기 때문에

사용자에 대한 조사가 이런식으로 이루어 지는 구나! 라는걸 알 수 있게 된 좋은 아티클 이었다고 생각합니다.

원문 : https://brunch.co.kr/@maju/47

오늘의 아티클은 삶의 질을 높여주는 10가지 UX 사례를 주제로 이야기를 해보았습니다~

저는 10가지의 사례를 읽고 일반 사용자들도 프로덕트를 사용할 때 느끼는 불편함과 궁금증 등 다양하면서 

어찌 보면 사소함을 UI로 접목시켜 사용자의 편의가 개선된 사례라고 생각이 들었습니다.

해서, 제목을 사소함에서 시작한 10가지 UX 사례라고 지어보았습니다.

해당 내용에 대해서는 위 링크에서 보다 더 자세하게 안내하고 있으니 위 링크를 봐주시면 됩니다.

저는 위의 사례에 대한 저의 생각을 정리와 함께 작성해 보았습니다.

1. 에어비엔비 - 숙소 와이파이 연결

여행을 갈 때, 특히 해외에 여행을 가거나 노트북 또는 태블릿을 사용할 때 쉽게 와이파이를 연결해 주는 부분이 

인상적입니다! 저도 숙소에 갈 때 매번 공유기를 찾고 비밀번호 입력하고 하던게 여간 귀찮았던 게 아니었는데요.

그리고 0과 알파펫 o를 틀리거나 할 때 다시 입력해야 하는 수고스러움도 불편함을 느끼고 있었지만

에어비앤비는 숙소 예약과 와이파이 연결을 쉽게 할 수 있는 서비스를 제공한다고 해요.

2. 산타 - 문제 소거 기능

저는 이 서비스가 참 신박하다고 느낀 게 누군가가 '이런 문제 푸는 방식을 온라인으로 접목시켜 보면 어떨까?'라는 생각을

하고 이 서비스를 만든 게 아닐까?라는 생각을 해보았는데요.

저도 시험을 보거나 문제를 풀 때, 또는 공부할 때에도 1번에서 5번의 답 중 답이 아닌 것을 지워 나가는 방식의 공부가

훨씬 더 좋더라고요. 이러한 문제 풀이 방식은 실수 또한 줄여준답니다.

3. 카카오뱅크 - 중복 이체 방지 안내

여러 사람에게 이체를 해야 할 경우 간혹 실수로 두 번 이체를 하게 되는 경우도 생기더라구요.

그럴 때 다시 뒤로 돌아가서 확인해 보고 다시 처음부터 이체하려니까 너무 번거로웠던 기억이 있었습니다.

카카오뱅크에서는 저 같은 사용자들의 편의성을 개선해서 중복된 이체자일 경우 메세지를 띄워주는 참신한

기능이 있습니다.

4. 무신사 - 모자필터 내 '모자 깊이'

무신사에서는 모자깊이 텝을 추가하여 다른 앱들과 다르게 좀 더 섬세한 옵션이라고 생각이 들어요.

저는 모자가 잘 어울리지 않는 사람이라서 오프라인으로 깊이감을 보고 선택하는 스타일이었는데 무신사에 

이런 옵션이 있는 줄 처음 알았네요! 다음에 모자 구매할 일 있을 때 깊이감 있는 모자를 한번 구매해 보아야겠습니다.

5. 유튜브 뮤직 - 샘플 텝

많은 사람들이 음악을 찾을 때 앞부분만 듣고 음악을 선택하는 경우가 많다고 해요.

유튜브 뮤직 샘플 텝은 이런 사용자의 특성을 반영하여 후렴구 30초나 전주나 1절 부분을 들려주면서 

음악을 즐기는 새로운 경험을 제공한다고 합니다.

요즘 또 쇼츠의 시대이니 이런 부분에서 참 편리한 기능이라고 생각합니다.

6. yes24 - 책 사이즈 비교 기능

온라인에서 책을 구매 시 이 책 사이즈가 어느 정도 인지 궁금할 때가 간혹 있으신가요?

저도 책을 좋아하는 편이지만 책 사이즈를 고려하면서 구매해 본 적은 없는 것 같아요!

그러나 yes24 개발자 분들은 이런 사소함을 추가하여 책을 선택하는데 편의성을 제공해주고 있습니다.

7. 정육각 - 리뷰어의 구매 횟수 정보

제품을 살 때, 맛집을 갈 때, 배달 음식을 시킬 때 등등 다양한 리뷰와 평점을 참고해 보곤 합니다.

그러나 요즘은 댓글알바, 블로그 마케팅 등 다양한 사람들과 업체를 들여 작성한 것 같은 느낌을 받곤 하는데요..

정육각 앱에서는 '사용자의 구매 횟수 정보를 구매자 정보와 함께 제공'합니다.

사용자의 재구매에 대한 직접적인 데이터가 되기 때문에 해당 제품에 만족해서 몇 번이고 구매했다는 데이터가 됩니다.

8. 현대카드 - 소비 잔소리 기능

'돈 아껴 써라' , '다음 달에 쓸 돈 남겨둬라' 등등 현실에서 부모님께 들을 잔소리를 

현대카드에서는 순화해서 앱이 알려준다고 해요.

원하는 알림 금액을 설정하고 푸시 알림을 통해 '잔소리'를 해주는 기능인데요

오프라인에서 듣던 말을 UI로 접목시켜 재밌게 개발한 서비스라고 생각이 들었습니다.

9. 여다 - 자동 여행일정 계획받아보기

저는 엠비티아이가 J이지만 여행은 편해서 가는 여행이라고 생각을 하게 되어서 완벽한 계획보단 널럴한 계획을 

세워두는 편이에요. 솔직히 그 마저도 귀찮을 때가 있어서 어디 가야지, 어디 가야지만 대충 정해서 가는 경우도 있는데요.

여다에서는 이런 귀찮음을 개선해서 사용자의 여행 일정을 대신 짜주는 기능이라니 참 신박하네요.

하지만, 이런 남이 짜주는 계획은 원치 않기 때문에 저는 참고만 하는 걸로 ㅎㅎ

10. 다락 - 짐 유닛 정보

다락은 대용량의 짐을 보관할 수 있는 서비스입니다.

다양한 크기의 보관 공간(유닛)을 제공하는 서비스가 있는데요.

보관함 크기를 3D로 보여주어 공간감을 인지할 수 있도록 도와주는 서비스를 제공해 줍니다.

지난 주 피그마 기초적인 공부를 얼추? 끝 마치고 이제 본격적으로 UX/UI 디자인 공부를 들어가게 될 것 같습니다 ㅎㅎ

그런데... 강의는 들었지만 아직까지 어렵고 생소한 단어들이 얼마나 많은지.. 

들으면 들을 수록 '그게 뭐였지?' 하는 단어들이 너무 너무 많더라고요.

이런 단어를 모르고 지나가는게 쌓이고 쌓이다 보면 분명 큰 어려움이 닥칠 것으로 예상하기에

기초 부터 튼튼히 지나가고자 하는 마인드로! 복습을 합니다!

그래서 오늘은 지난 주를 복습할 겸 피그마에 나오는 그런 단어들을 정리하면서 알아보겠습니다!

(용어 하나 하나가 중요하지만 특히나 더 중요한 용어에는 ★을 붙여 볼게요)

▶ 8포인트 그리드 디자인 : 일반적으로 가장 많이 사용하는 규칙, UI를 8의 배수에 맞춰 배치하는 레이아웃 규칙

(일정한 규칙이 있다면 디자이너와 개발자가 서로 물어보는 번거로움을 줄일 수 있기 때문)

※레이아웃 이란 문자, 그림, 기호, 사진 등을 제한된 공간 안에 효과적으로 배열하여 시각적 구조와 디자인 요소를 조직하는 뜻

▶ 프레임 : UI를 설계할 때 디자인은 코드로 변환 할 수 있는 구조로 만들어야함.

프레임은 디자인을 코드로 바꿀 때 개발이 가능한 코드 블록으로 만들어짐 , 컨테이너 라고도 불림

※프레임은 코드 블록을 만드는 기능이고, 그룹은 편집이나 조정이 필요할 때, 또는 편의를 위햇 여러 개체를 하나로 담는 기

★

▶ 오토레이아웃 : 레이어를 쌓고, 프레임을 배치하고 정렬하는 피그마의 핵심 기능

개체를 패딩으로 감싸 컨테이너를 만들 때 사용함

UI의 크기는 개체의 크기 + 패딩으로 만들어짐, 개체를 둘러싼 분홍색 박스가 패딩 입니다

▶ 컨스트레인트 : 제약(조건),제한이라는 뜻 (오토레이아웃 안에 있는 개체들이 움직이는 방식을 제한함)

오토레이아웃을 정말로 오토-레이아웃으로 만들어주는 기능

파란색 점선이 자식 개체(파란색 박스)가 부모 개체(하얀색 프레임)에 대해 가진 조건을 컨스트레인트라고 함

자식 컨테이너가 부모에 고정되어 움직이는 일종의 '핀' 위치 - 다른 말고 Anchor(앵커)라고 함

▶ 프레임 리사이징 : 부모 컨테이너의 리사이징 값에 따라 자식의 리사이징 값이 영향을 받거나

반대로, 자식 컨테이너의 리사이징 값에 따라 부모의 리사이징 값도 영향을 받게하는 기능

-> 말 그대로 사이즈가 변경된다는 뜻

리사이징 옵션으로 수정 가능 

- 리사이징의 종류

※자식이 고정값(Fixed)라면, 부모는 감싸(Hug)게됨 : 자식은 고정, 부모만 수정

자식 사이즈가 수정값(Fill)이라면 부모는(Fixed)가 됨 : 자식은 부모의 값에 맞게 사이즈가 수정됨

자식과 부모는 둘 다 고정일 수도 있음

▶ 파운데이션 : UI를 구성하는 가장 작은 알갱이, 

예) 버튼 하나를 만들기 위해 존재하는 모든 요소 (컬러, 레디우스. 폰트, 아이콘, 간격 등)

 → UI는 기초 재료인 파운데이션과, 이 파운데이션을 조합해 만드는 컴포넌트로 나눌 수 있음

▶ 헥스코드 : 빛의 3원색(RGB)를 16진법으로 구성괸 컬러를 부르는 말 

ex)#FFFFFF

▶ 컬러 스타일 : 디자인에서 사용할 색상을 모아두는 팔레트

컬러 스타일은 기본적으로 2~3가지의 색상으로 만들어짐

포인트 컬러 : 정말 중요하고 핵심적인 부분을 강조할때 사용하는 컬러 (프라이머리 컬러, 엑센트 컬러라고도 불림)

백그라운드 컬러 : 배경색 컬러 (일반적으로 흰색을 씀)

세컨더리 컬러 : 배경색에서 도드라지는 부분을 만들어 포인트 컬러를 뒷받침하는 색 (서브 컬러라고도 불림)

▶ 컴포넌트 : 파운데이션을 조합해서 만들어지는 구성품, 디자인 단위의 개념, 피그마로 만든 UI블록

※개발에서는 조금 다른 개념으로 쓰이는 등 맥락에 따라 개념이 조금씩 달라짐, 컴포넌트라는 표현을 쓸 때는 

서로 같은 걸 의미하는 지 확인해서 써야함

▶ 마스터 컴포넌트 : 반복적인 디자인을 빠르게 하기 위해 디자인을 복사해서 사용할 수 있도록 해주는 기능

따라서 마스터 컴포넌트는 원본이 되어 복사된 컴포넌트를 한번에 수정하거나 편집할 수 있도록 도와 줌

▶ 인스턴스 : 마스터 컴포넌트의 복제본, 마스터 컴포넌트의 속성을 그대로 이어 받음

마스터 컴포넌트는 이름에 ❖ 아이콘이 붙지만 인스턴스는 ◇ 아이콘이 붙음

※인스턴스를 먼저 수정하면 컴포넌트를 수정해도 반영되지 않음

(컴포넌트 수정보다 인스턴스를 수정하는 것이 더 우선 적용되기 때문에)

컴포넌트를 지우더라도 인스턴스는 남아 있음

연결을 해제하면 인스턴스는 컴포넌트와 분리되고 일반 프레임으로 변경됨(Detach(디테치 : 분리하다)라고 불림)

★

▶ 디자인 시스템 : 다른 디자이너와 개발자들이 같은 생각을 하고 같은 정도로 이해력을 돕기 위한 효율적인 업무 시스템

UI 구조, 쓰는 방법, 유의해야 하는 부분까지 모든 부분을 '문서'의 형태를 가지고 있음

▶ UI 키트 : 디자인 시스템과는 다르게 사용하는 규칙과 방법은 없고, 단순히 UI를 모아둔 것에 지나지 않음

▶ 의사 상태(Pseudo State) : 가짜의, 가상의라는 뜻으로 컴포넌트의 가상의 상태를 표시할 때 사용

마우스를 올리면 색상이 변하는 것도 의사상태,

버튼이 눌렸을 때,텍스트를 입력하려고 눌렀을 때, 체크박스를 눌렀을 때, 누를 수 없을 때 등 다양한 경우가 있음

 □ UI의 분류
▶ 액션(Action) : 버튼과 같이 사용자가 중요한 행동을 수행할 때 사용하는 UI

▶ 인풋(Input) : 사용자의 입력을 받을 때 사용 (검색창과 같은 기능)

▶ 인포메이션(Information) : 사용자에게 서비스의 상태나 안내 사항을 전달할 때 사용 (메세지나 스낵바, 라벨 등)

▶ 내비게이션(Navigation) : 사용자가 페이지를 이동할 때 사용 (네비게이션 바, 앱 바, 화면 하단의 탭 바, 사이드 바 등)

▶ 컨트롤(Control) : 사용자가 설정이나 값을 수정할 때 사용 (라디오, 체크박스, 스위치 등)

▶ 텍스트 필드 컴포넌트 : UI의 분류중 인풋에 해당하는 컴포넌트

▶ 플레이스홀더 : 플레이스(자리) + 홀더(지키고 있는 것)로 '자리표시자'라고 함

사용자가 입력해야하는 예시를 제공하는 용도로 사용

▶ 밸리데이션 : 텍스트필드에서 사용자가 입력한 텍스트가 유효한지 아닌지를 검사해 주는 것

즉, 유효성 검사(밸리데이션 체크)라고 불림

▶ 컨트롤 컴포넌트 : 사용자가 선택지를 특정할 수 있도록 하는 요소

▶ 프로퍼티 : '속성' 이라는 뜻을 가지며 디자인 구조가 바뀌지 않는 선에서 변경할 수 있는 요소들을 다룸

▶ 컴포넌트 프로퍼티 : 컴포넌트 안의 요소가 바뀌거나 의사 상태일 때 이런 변화와 변경을 만들 수 있는 컴포넌트 기능

★

▶ 배리언츠(Variants) : '변종'이라는 뜻으로 '변화'와 관련

컴포넌트가 가질 수 있는 또 다른 모습을 만들 수 있게 하는 컴포넌트 기능

즉, 컴포넌트의 가상의 상태를 만들때 사용

컴포넌트 프로퍼티 알아보기

▶ Boolean : Y or N을 선택하는 형식이라는 뜻
컴포넌트 안에있는 특정 요소를 보이게 하거나 안 보이게 설정할 수 있는 속성
아이콘 또는 텍스트에 적용하면 키거나 끄고 할 수 있음

▶ Instance swap : 말 그대로 인스턴스를 스왑하는 기능 
인스턴스를 다른 인스턴스로 교체하는 기능(인스턴스를 인스턴스가 아닌 것으로는 바꿀 수 없음)

▶ Text : 컴포넌트 안에 있는 텍스트를 수정하기 쉽도록 컴포넌트 속성으로 만들어 주는 기능

▶ 위계(Hierarchy, Priority)

'얼마나 중요한 행동을 하기 위한 버튼인가'를 담으며 사용자가 반드시 해야하는 중요한 행동이라면 가장 돋보이는

1순위의 버튼을 사용하고 2~3순위의 버튼으로 나누는 방식

1순위 부터 프라이머리(Primary), 세컨더리(Secondary),터시어리(Tertiary)의 순위로 나눔

▶ 합성 컴포넌트 : 컴포넌트를 모아 또 컴포넌트를 만든 것

▶ 네스티드 인스턴스 : 감싼 인스턴스 기능, 재료로 쓰인 컴포넌트를 하위 컴포넌트, 본체를 상위 컴포넌트라고 볼 때

하위 컴포넌트의 속성을 조작할 수 있도록 하는 기능

nest(둥지) 안에, 다른 컴포넌트 안에 들어가 있다

UX/UI 디자인 교육 과정이 4일 차입니다. 내일이면 벌써 일주일이 지나가네요.

역시 작심삼일은 과학인가봅니다...

오늘은 지난 3일 보다 약간 해이해진 상태로 공부를 했는데요 ㅎㅎ,,, 

하 지 만~! 작심삼일도 삼일에 한 번씩 해주면 된다고 하잖아요? ㅋㅋ

저는 다시 내일부터 또 힘내서 열심히 공부해볼까 합니다!

해이하면서 공부했다고는 해도 그래도 오늘도 여러 가지를 배울 수 있었습니다.

오늘은  UI키트와 디자인 시스템이 무엇인지에 대해서 다뤄 볼 건데요.

먼저 디자인 시스템이 무엇인지 살펴보겠습니다!

1. 디자인 시스템

- 디자인 시스템의 개념

디자이너들은 웹과 앱을 디자인합니다. 이때 웹과 앱을 제품(프로덕트)라고 부르는데요.

프로덕트를 만드는 디자이너들은 사용자들이 겪는 문제를 찾아 디자인으로 개선하는 일을 합니다.

이 때 디자이너들은 UI를 매번 새로 만들게 된다면 작업의 량도 늘어나는 수고스러움을 겪게 될 것이고

UX(사용자의 경험)의 문제가 무엇인지에 대해 파악할 시간도 부족해지게 됩니다.

이럴 때 UI를 만들어 놓고 필요할 때 가져와서 사용한다면 어떨까요? 

작업량은 줄어들고 사용자의 니즈를 파악할 시간이 더욱 늘어나겠죠?

그런데, 디자이너는 혼자 일하는 사람들이 아니에요. 다른 디자이너들도 있고, 또 개발자들과도 일해야 합니다.

내가 머릿속으로만 생각한 UI 디자인이 다른 디자이너나 개발자도 같은 생각을 가지고 만들어 갈 순 없어요.

이때 필요해지는 것이 디자인 시스템입니다.

디자인 시스템은 UI구조, 쓰는 방법, 유의해야 하는 부분까지 상세하게 적혀 있는 문서라고 생각하시면 됩니다.

- 디자인 시스템의 목적

디자인 시스템의 목적은 반복적인 UI를 효율적으로 관리할 수 있게 만들어 줍니다.

한번 만들어 두고 다음에 또 쓰게 될 때 복사해서 붙여 넣으면 작업 시간도 그만큼 줄겠죠?

그다음 팀 전체가 같은 정도로 이해할 수 있게 됩니다.

피그마는 개발자와 디자이너가 공통 작업이 가능하기 때문에 어떤 디자이너가 UI를 사용하더라도 일관된 사용법을

지킬 수 있게 됩니다.

코멘트도 섞어가면서 디자인을 하게 된다면 여러 번 할 미팅도 단 몇 번으로 줄일 수도 있을 것입니다.

2. UI키트

UI키트는 쉽게 생각하면 디자인 키트의 하위 개념이라고 생각하면 쉬워요!

디자인 시스템과는 다르게 사용하는 규칙과 방법은 없고, 단순히 UI를 모아둔 것에 지나지 않을 뿐입니다.

만약 개발자와 디자이너 단 둘이서 프로덕트를 만들어보자라고 했을 때

디자인 시스템은 오히려 작업의 수량만을 늘리게 될 수도 있습니다.

서로 합이 잘 맞고, 팀 인원이 적다면 오히려 완벽한 문서를 갖추는 게 비효율적일 수 있습니다.

이럴 때는 UI 키트 수준만 유지한 채로 빠르게 만드는 게 더 효율적일 수 있겠죠?

디자인 시스템과 UI키트의 차이점이 무엇인지 예시를 들어 볼게요!

김치, 돼지고기, 대파, 마늘, 고춧가루 등등

이런 요리 재료들이 있습니다.

이 요리 재료들을 가지고 어떤 음식을 만들어 볼까요?

김치찌개?

김치제육?

김치찜?

어찌 보면 삼겹살 구워 먹기도 가능하겠네요

이렇게 요리재료들만 나열이 되어 있다면 우리는 이 요리재료를 가지고 무엇을 만들지 예상하기 힘들어요.

이런 요리 재료들을 UI키트라고 할게요.

그럼 이 요리 재료에 디자인 시스템이 들어간다면

배추김치 1 포기, 돼지고기 목살 300g, 대파 1컵(200ml), 다진 마늘 1큰술, 고춧가루 2큰술 등등


김치는 5cm 크기로 썬다, 목살은 3cm 크기로 썬다, 대파는 어슷썰기 해서 준비한다, 마늘은 다져둔다 등등


김치찌개 레시피 : 냄비에 목살을 넣고 적당히...

이렇게 디자인 시스템은 재료 목록과 다듬는 방법, 조리법까지 상세하게 나와 있는 요리책이 되는 셈인 거죠!

디자인 시스템은 UI 자체뿐만 아니라 규격과 스펙, 사용 사례, 주의 사항 등이 모든 게 들어간 종합적인 제품 가이드라인이 됩니다!

사용자가 사용하는 웹 또는 앱의 대부분의 UI들은 명확한 명시성을 가지고 있습니다.

그 주요한 옵션들의 차이점이 명확히 보이지 않으면, 사용자는 잘못된 옵션을 선택하거나 기능을 오해하게 될 가능성이 있습니다.

더불어 선택의 폭이 넓은 웹 또는 앱 사이트에서 선택 옵션을 명확하게 구분하는 것이 사용자의 스트레스를 줄이며 정확한 정보를 

주는 좋은 서비스겠죠?

유저가 옵션을 스스로 파악하고 우선순위를 잘 정한다고 가정할 수 없습니다.

디자인 한 UI에 명시성이 없다면 유저의 의사 결정 프로세스가 느려지고 불필요하게 복잡해질 수 있습니다.

결국 UI 디자인에는 유저가 올바른 결정을 내리도록 도와주어야합니다.

그럼 왜 중요할까요?

유저가 웹 또는 앱을 사용하다가 차이점이 명확하지 않은 옵션을 만들게 되면 사용자가 실수를 하게 되면 서비스의  잘 못을 탓하게 

됩니다.  좋은 UX는 유저가 처음에 올바른 선택을 하도록 돕는 것이 중요합니다.

잘못된 옵션을 선택하면 때로는 돈을 낭비할 수도 있습니다.

실수를 할 때 올바른 선택을 찾기 위해 수고로움도 들게 됩니다.

서비스에서 저지른 실수 하나만으로 회사의 평판이 손상될 수도 있는 무서운 상황도 생기겠죠?

UI 디자인에 있어서 정말 많은 부분을 봐야 한다는 걸 알게 된 아티클이었습니다.

저는 웹, 앱을 만들 때 어느 정도 정형화된 가이드라인이 있지만 심미성 있게 독특하게 만들어보고 싶다는 

생각도 가지고 있었는데요.

유저에게 있어서 명시성이 내가 생각하는 명시성이 아닐 수도 있겠구나 나는걸 알게 해주는 글이었습니다.

우리는 유저가 아님을 명심하고 나에게는 당연한 게 남에게는 당연한게 아니다 나는걸 다짐해야겠습니다.

더 명확하게 설명할수록 사이트가 성공할 수 있다는 걸 깨달아야겠습니다.

원문 : https://www.nngroup.com/articles/explicit-differences/