담당자도 헷갈리는 UX/UI 용어 모음.zip
디자이너&개발자와 소통하기
이런 분들이 읽으면 좋아요!
클라이언트 또는 기획자와 처음 소통하는 프리랜서
시니어나 사수가 딱히 없어 커뮤니케이션이 어려운 스타트업 주니어 디자이너
디자이너&개발자와 좀 더 명확히 커뮤니케이션 하고 싶은 기획자, PM
이런 내용을 알 수 있어요
기획자 or PM - 디자이너 - 개발자 소통 시, 자주 사용하지만 헷갈리는 실무 용어를 정확히 알려드려요.
UX/UI 디자인에서 자주 사용하는 용어를 싹 정리해 드려요.
*아래 컨텐츠는 [패파솔루션] 공식 제휴사 '똑똑한개발자' 박수지님께서 작성해 주셨습니다.
안녕하세요! 똑똑한개발자 수지입니다.
각 실무에서 직무마다 같은 기능을 하는 영역들도 다르게 표현하는 경우가 종종 있더라고요.
오늘은 간략히 UX 실무용어 사전을 준비했습니다!
실제 저희 팀원들도 종종 헷갈려하고, 혼용해 소통하는 용어들 위주로 소개합니다!
1. UX/UI
이왕 이야기를 시작했으니 우리가 이야기하는 UX, UI가 어떤 용어인지 짚고 가보도록 해요!
많이 알고 있고 UXUI라고 연결지어 부르긴 하지만, 디자이너가 아니라면 명확히
어떤 차이가 있는지 잘 모르시는 기획자나 개발자 분도 종종 계시더라고요!
UI
User Interface
화면에 보여지는 인터페이스를 의미합니다.
시각적으로 좀 더 심미적인 디자인에 가깝다고 이해하면 좋을 듯 합니다.
예전에는 GUI (Graphic User Interface)라는 개념으로 더 작게 불리기도 했습니다.
UX
User Experience
사용자 경험을 고려해 기획하고 구현하는 일이라고 이해하면 되겠습니다.
이전에는 서비스 기획자들이 UX를 고려해 플로우를 짜고, IA와 와이어프레임을 그리면서 디자이너, 개발자와 소통했죠.
갈 수록 업무의 구분이 흐려지고 툴의 발전으로 쉬워지면서, 요즘은 GUI 디자이너, UX 기획자 따로 구분하지 않고 디자이너가 초반 기획 단계부터 비주얼 작업까지 관여하게 되는 UXUI 디자이너라는 직무가 많아지고 있습니다.
마치 이전에는 퍼블리셔/프론트엔드 개발자가 따로 있었다면, 시간이 갈수록 퍼블리싱의 단계가 없어지고 있는 것처럼요!
여기서 한 단계 더 나아가서 요즘은 UXUI 디자이너 보다 [Product Designer] 라고 직무를 구분하는 추세입니다. 관련해서 직무 구분에 따른 설명은 다음 뉴스레터에서 자세히 설명해드리도록 할게요!
2. 모달(Modal) vs 팝업(Pop-up)
팝업과 모달은 언뜻 느끼기에 동일한 기능의 단어처럼 느껴집니다. 실제로 저희 똑개팀 내부에서도 디자이너와 개발자 사이에 혼용이 잘 되는 용어이기도 해요.
“여기 이렇게 팝업 띄울까요?”
“이 부분은 모달로 처리하면 될 것 같은데요.”
하지만 실제로 이 두 용어는, 사용자들의 시선을 사로잡으려는 같은 목적과 달리,
매커니즘과 사용 방식이 전혀 다릅니다. 예시로 썸네일 이미지를 첨부하긴 했지만, 단순히 형태 만으로 팝업과 모달을 구분하는 것은 아니에요.
팝업처럼 생겼지만 모달이기도 하고, 모달처럼 생겼지만 팝업이기도 합니다. (이게 무슨 소린고..)
팝업(Pop-up)
기존에 열려있는 브라우저 페이지 위에 또 다른 브라우저 페이지를 띄우는 것
기존 브라우저와 독립적인 관계임
브라우저의 옵션을 통해 열리지 않도록 강제할 수 있음
모달(Modal)
기존에 열려있는 브라우저 위에, 새로운 창이 아닌 레이어를 까는 것
원래 브라우저와 종속적인 관계, 부모 — 자식의 형태를 가지고 있음
브라우저 옵션과 관계없이 띄울 수 있음
결론적으로 말하자면 팝업의 3번 사항 때문에라도 요즘은 대부분 모달을 사용하는 추세입니다.
이 두 가지 용어 관련해서 더 자세한 내용은, 똑개팀의 찬호 디자이너님이 정리해주신 아티클이 있어
꼬리로 링크를 달아둡니다. > 링크
찬호님께서는 개인적으로, 팝업은 이 문장으로 정리된다고 하시네요.
“오늘 하루 이 창을 열지 않음”
3. 토스트 메시지 vs 알럿
모달 & 팝업과 헷갈리는 용어가 여기 또 있습니다. 바로 토스트와 알럿!
Alert(알럿)
알럿은 말 그대로 유저에게 주의를 주거나 알림을 일방적으로 주는 경우에 사용합니다.
알럿에는 버튼이 포함됩니다.
더 디테일하게는 Confirm / Prompt / Alert 으로 나눌 수도 있죠.
버튼이 하나만 있는 경우는 Alert (ex. 필수 입력사항을 입력해주세요 - 확인)
[예/아니오] 등의 버튼 2개가 있다면 Confirm (ex. 저장하지 않고 나가시겠습니까? - 나가기 / 취소)
텍스트를 입력받는 Input Field가 있다면 Prompt 라고 하는데, (요즘은 잘 안쓰는 것 같습니다.)
요런 상세한 단계까지는 디자이너도 잘 모르고 ‘알럿’ 이라고 통일해 표현할 때가 많죠. 모바일에서는 뒤에 불투명한 백그라운드(Dim)가 깔리며 뜨는 경우가 많아서 ‘레이어 팝업' 이라고 부르기도 하는 모양입니다.
P.S. 하지만 앞서 말했듯이 우리가 생각하는 대부분의 ‘팝업'은 ‘모달'일 경우가 많으므로, ‘레이어 모달'이라고 불러야 하는 것인가 하는 생각이 드는데 (저도 갑자기 조금 헷갈리네요.) 너무 복잡하니까 우리는 알럿이라고 이해하도록 합시다.
실제로 최근에 레이어 팝업이나 모달이나 정확하게 칼처럼 구분하지는 않는다고 하네요.
팝 하고 튀어오르니까 팝업(Pop-up)이 아닌가 생각이 들지만, 모두 다 알럿(Alert)입니다.
Toast(토스트)
이 친구야말로 토스터기에서 식빵이 퐁! 하고 튀어오르는 것처럼 나오는 알림이라고 해서, 이름이 ‘토스트'입니다.
토스트에는 버튼이 없습니다. 유저가 “응 나 확인했어!~” 하고 버튼을 눌러주지 않아도, 뿅 하고 나왔다가 시간이 지나면 알아서 스르륵 하고 사라집니다.
디자이너가 가장 많이 참고하는 디자인시스템인 [구글 머터리얼 디자인]에서는, 토스트에 아이콘이나 이미지를 넣는 것을 지양하고 있습니다.
하지만 장바구니에 무언가를 담았을 때 종종 아이콘과 함께 토스트가 뜨는 경우도 많이 있죠. 머터리얼 디자인은 물론 아주 잘 만든 디자인시스템이지만, 정답이라고 생각할 필요는 없는 것 같아요. 우리 제품과 우리 디자인 언어에 맞는 가이드라인을 구축하고 통일감있게 사용한다면 그게 가장 정답에 가까운 디자인이라 생각합니다.
그래서 저희 똑개 팀의 디자인시스템에도 요런 귀여운 토스트 팝업이 존재합니다.
4. Default vs Disabled
버튼에 자주 쓰이는 상태입니다.
UX라는 건 결국 정적인 그래픽이 아니라 유저와 상호작용하는 것이기 때문에, 생각보다 ‘인터랙션' 혹은 ‘상태값’에 대한 고려가 디테일하게 되어야 합니다.
그럴 때 사용되는 상태 값에 대한 용어라고 할 수 있죠.
Default
어떠한 컴포넌트의 기본 상태값을 의미합니다.
유저가 아무 행동도 하지 않은 첫 화면에서 보여지는 상태를 표현하죠.
Disabled
비활성화 상태를 의미합니다.
입력창(Input Field)이라면, 유저의 선택 값에 따라 입력이 필요없는 칸이 있을 때 Disabled로 표현되곤 하죠.
예를 들어, 회원가입단계에서 “필수 입력값(이름 등)”을 입력하지 않았다면, 다음 단계로 넘어갈 수 없도록 버튼을 비활성화 시킬 때 Disabled 상태값이 필요합니다.
더 디테일하게는 'Active'나, 웹이라면 'Mouse Hover'에 대한 상태값이 추가되기도 합니다.
Active
버튼이 눌리는 순간, 눌렸음을 표시해주는 상태입니다. 대부분 색상을 더 진하거나 연하게 조절하는 형태로 많이 적용합니다.
찰나의 순간이기 때문에 굳이 Active 라는 상태값을 적용하지 않는 경우도 많습니다.
가히 디테일의 영역이라 할 수 있죠.
Hover
마우스를 어떤 컴포넌트에 가져다댔을 때 “이건 클릭할 수 있는 녀석이야~” 하고 힌트를 주는 역할입니다.
모바일에서는 해당 상태값이 적용되지 않습니다. (모바일에선 오직 클릭만이 존재하기 때문이죠!)
따라서 반응형을 구현할 때 PC와 모바일 두 가지 상황을 잘 고려하면서 Hover를 사용해야 합니다. Hover로 추가정보를 표기하거나 정보를 주려 한다면, 자칫 잘못하다가 모바일로 들어온 유저들에게 하나도 보여지지 않게 될 수 있어요!
5. MVP vs Production
MVP와 Production 을 설명하는 과정에서 가장 많이 예시로 사용되는 그림이 하나 있죠. 바로 자동차와 킥보드 예시입니다.
MVP
Minimum Viable Product
핵심적인 단 하나의 기술, 단 하나의 기능을 가지고 개발하는 제품을 이야기합니다.
종종 MVP 단계에서 이런 기능 저런 기능 하나 둘 씩 기획하며 추가하고 싶어하시는 클라이언트 분들도 있는데요. 그렇게 되면 아이디어를 빠르게 검증해야하는 MVP에서 실패할 가능성이 높아지는 좋지 않은 방향이라고 이야기드리곤 합니다.
스케이트 보드 > 킥보드 > 오토바이와 같은 순서로 완성과 디벨롭을 단계별로 이어나가야 하지, 바퀴를 만들고 본체를 만들고 슈퍼카를 만드는 순서는 MVP가 아니라 처음부터 Production을 만들고자 하는 것과 같습니다.
개인적으로는 MVP 를 이렇게 정의하고 싶네요. M무지 V바쁜 P프로덕트디자이너… � 오히려 방향성이 명확하고 시장검증 완료와 유저들이 있는 Production 단계보다, MVP 단계에서의 디자이너가 기획하고 리서치하고 정의해야할 일들이 더 많은 것 같아요. 물론 그래서 더 많이 배우고, 초기 단계에서의 기획을 경험해 볼 수 있다는 건 정말 큰 성장점이죠!
Production
앞서서 MVP를 설명해드렸으니 Production은 그 다음 단계로 이해하시면 명확하겠죠?
그야말로 상품 가치를 극대화하는 단계입니다.
MVP에서 시장검증을 끝냈고, 사용하는 유저들도 어느정도 있는 단계라면, 좀 더 살을 붙일 수 있는 시점이 되었다고 볼 수 있죠.
커뮤니티, 커머스, 팔로우.. 서비스를 조금 더 가치있게 만드는 기획과 아이디어들이 이 단계에서 추가됩니다. 혹은 사용성(UX)에 대한 개선이나 디자인(UI)에 대한 개선이 이루어지기도 해요. MVP가 단순히 기능적으로 핵심기술이 돋보이는 형태라면, 좀 더 심미적이고 아름다운, 브랜드 의미와 가치를 담은 이야기들을 이어나갈 수 있기도 하죠.
6. 네이티브 vs 반응형 웹 vs 하이브리드
디자인/개발 에이전시에서 가장 많이 헷갈리고, 또 클라이언트도 어려워하시는 개념인 것 같아 슬쩍 끼워넣었습니다. 이 용어와 개념을 이해하시면 이제 어디가서
“아 그거 이번에 네이티브로 만들고 있는거?” 하고 아는 척 하실 수 있습니다.
네이티브 앱
우리가 흔히 플레이스토어 / 앱스토어에서 다운받을 수 있는 형태입니다.
안드로이드(AOS), IOS 상황에 따라 별도로 동작하기 때문에, 별도로 2가지 타입을 모두 구축해야 합니다.
물론 리액트 네이티브라는 크로스 플랫폼 프레임워크(하나의 포맷으로 AOS / IOS 를 전부 대응할 수 있게 제작하는 프레임워크)가 있지만, 여전히 한계가 있고 리소스가 많이 드는 부분이 있죠.
가장 큰 단점은 ‘웹으로 접근 불가하다'는 점입니다. 무조건 유저가 찾아서 다운을 받아야만 사용이 가능한 형태입니다.
앱스토어 등의 검수 기준이 까다롭고, 수수료를 내야 한다는 단점도 있죠.
하지만 가장 큰 장점은 사용성이 아주아주 좋다는 점입니다. 페이지가 레이어처럼 켜켜이 쌓이는 ‘스택' 구조를 가지고 있기 때문입니다. 그래서 웹 사용 유저가 적다면 네이티브 앱이 무조건 유리합니다. 이 이야기는 하이브리드 앱에서 이어서 진행할게요!
웹앱 (반응형)
웹앱은 우리가 잘 아는 www.와 같은 ‘웹사이트'를 의미합니다.
웹은 접근성이 매우 편하다는 장점이 있습니다. 외부 유입과 공유가 쉽고 URL로도 접근이 가능하죠.
웹은 네이티브와 달리 스택이 불가능한 ‘라우팅 구조'를 가지고 있습니다. 페이지가 켜켜이 쌓이는 것이 안되고 ‘새 탭'으로 전환되는 형태인거죠.
이런 라우팅 구조는 사용성에서 엄청난 UX적 불편함을 가지고 옵니다. 회원가입을 완료하면 이전 페이지로 돌아가기 어렵다든지, 뒤로가기가 부자연스럽고 새로 데이터를 불러와야 해서, 페이지 인터랙션이 자연스럽지 않다든지 하는 문제들이 생기죠.
하이브리드 앱
이러한 네이티브와 (반응형)웹앱을 섞은 것이 바로 하이브리드 앱입니다.
‘웹’으로도 런칭이 가능하고, 동시에 패키징을 통해 ‘앱 다운로드'도 가능합니다.
일부 기능은 네이티브로 구현하는 것과 동일하기 때문에, 기능적인 제한도 없습니다. (블루투스나 QR 등의 기능에 제약이 거의 없죠)
이렇게까지만 들었을 땐 “오 그럼 좋은 걸 반반씩 섞었으니 당연히 하이브리드 해야겠네!” 라고 생각하시겠죠? 그러나 그럼에도 불구하고, 사용자에 따라 웹 사용 유저가 적다면 저희는 [네이티브 앱]을 더 추천합니다.
앞서 말했듯이 하이브리드의 일부는 웹 구현 방식을 적용하고 있습니다. 라우팅 구조가 그러하죠.
이런 스택이 불가한 구조는 생각보다 UX적으로 큰 이슈를 불러옵니다. 그리고 이러한 사용성은 생각보다 큰 이탈률을 야기하게 되죠 (별표 100개입니다!)
이런 개선을 위해 큰 기업에서는, 모바일 웹의 UX 사용성을 개선하는 별개의 팀도 존재합니다. (당근마켓, 라인도 현재 해당 직무의 인턴을 뽑고 있더라고요!)
디자인도 그렇지만, 좋은 것끼리만 합치면 1+1=2 처럼 더 좋은 것이 나오리라고 기대하게 되는 경우가 많은데, 사실은 목적과 사용성에 따라 1+1= -10이 되는 경우도 존재하는 것 같습니다.
역시 가장 좋은 건 목적에 맞는 적절한 선택이 아닐까 싶네요!!
용어가 뭐가 중요해! 하나도 안 중요해! (아마도..?)
와이어프레임, IA, 스토리보드, 화면-기능명세서, 프로토타입, GNB, 네비게이션, 유저플로우, CTA, 플레이스홀더… (아이고 숨차다.)
이번 뉴스레터를 위해 UX 용어들을 리스트업 하다보니 끝이 없더라고요.
소개해드리고픈 용어들은 더 많은데 아쉬운 마음입니다.
UX 용어도 결국은, 소통하고 대화하기 위한 [언어] 아니겠어요?
꼭 정확한 용어와 완벽한 단어가 아니어도, 내가 많은 용어를 알고있지 않더라도!
물어보고 커뮤니케이션하며 만들어나가면 되는 것 뿐이라 생각합니다.
개발자와 소통하며 모달을 ‘팝업'이라고 부르는게 뭐가 중요하겠어요. 그 팝업과 모달이 왜 있어야 하는지, 어디에 있어야 하는지 서로 합의된 내용을 주고받고 함께 만들어나가는 것이 가장 중요한 일 같다고 생각합니다.
그럼 작게나마 오늘의 글이 여러분의 팀과 소통에 도움이 되었길 바라며, 이만 글을 줄입니다. :)
감사합니다!
