🎨

프론트엔드 개발자도 UI/UX를 알아야 해

Created

2023/04/16

이 글을 쓰게 된 계기

개발자는 코딩을 잘해야 하는 거 아닌가?

이번주 부트캠프 수업에서는 UI와 UX에 대해 다루었고, Figma를 활용해 웹사이트를 클론해 보았다. 사실 전자는 어느 정도 알아야 하는 이유를 스스로 납득했지만, 후자는 아직도 잘 납득이 되지 않았다. '가뜩이나 개발만 해도 공부할 거리가 넘쳐 하루하루 우선순위 높은 공부만 쳐내기에도 바쁜데 웬 디자인'이라는 생각이 들어 실습 중 현타가 왔기 때문이다.

개인적으로 일이나 공부를 할 때 그것을 해야 하는 이유가 납득이 되지 않으면 몰입에 방해가 되기 때문에, 이번 기회에 어차피 해야 하는 거 아예 정면돌파하여 끝내버리려고 한다. 이 글이 혹시라도 나와 같은 생각을 하고 있던 사람들에게 '이래서 알아야 하는구나' 하고 납득할 수 있도록, 알아두면 좋을 개념을 짧은 시간에 알아갈 수 있도록 도움이 되길 바라면서 시작한다.

UI / UX 란?

UI는 User Interface(유저 인터페이스)로, 대략 눈에 보이는 '디자인'적인 요소라고 생각하면 된다. 즉, 사용자가 서비스를 사용할 때 마주하는 디자인 (ex. 폰트, 컬러, 레이아웃, 간격, 애니메이션 효과 등)을 UI라고 생각하면 된다. UX는 User Experience(사용자 경험)으로, UI의 디자인적 요소들을 바탕으로 만들어진 서비스를 사용하는 사용자가 겪는 경험과 감정 등을 말한다.

정리하자면, 프로덕트를 사용하는 유저가 편리하도록 UI를 디자인해서, 더 나은 사용자 경험을 제공하는 것이 목적이라고 할 수 있다.

위의 하인즈 케첩의 예시를 통해 UI/UX를 쉽게 이해해 보자. 초기 하인즈는 유리병 형태였지만, 사용자가 밑에 조금 남아있는 케첩을 먹기에는 힘들었다고 한다. 유리병 UI는 좋지 않은 UX를 불러왔기에 오른쪽과 같이 플라스틱 형태의 UI로 변경했고, 결국 사용자에게 긍정적인 UX를 줄 수 있었다.

이렇듯 UI와 UX는 별개의 것이 아니라는 것을 알 수 있다. 또한 UX는 UI를 포함한다. 즉, 좋은 UX가 좋은 UI를 의미하거나, 좋은 UI가 항상 좋은 UX를 보장하지는 않는다는 것이다.

개발자가 UX를 신경써야 하는 이유

복잡해진 웹

이전에는 웹이 간단한 편이었지만 요즘은 정보를 표현하는 방식과 모습이 굉장히 다양해지면서, 그 이면의 사용자는 때때로 낯섦과 불편함을 느낄 수 있다. 다들 복잡하고 어려운 애플리케이션을 다운받았다가 짜증이 나서 지워버린 경험들이 한 번쯤 있을 것이다. 커뮤니케이션에도 청자를 위해 듣기 쉬운 언어로 말해야 하듯이, 프로덕트 개발 또한 사용자 입장에서 쉽게 다가갈 수 있도록 만들어야 한다. 그래야 우리가 피 땀 눈물 흘려 만든 프로덕트가 사용자에 의해 널리 널리 쓰이지 않을까.

프론트엔드 채용 공고

넥슨 채용 공고

우아한 형제들 채용 공고

카카오 스타일 채용 공고

아래와 같이 프론트엔드 개발자 채용 공고에서도 지원자격 혹은 우대사항에 UI/UX에 대한 이해나 디테일 측면을 함께 고민할 사람을 찾기도 한다. 우리가 이 역량을 갖추었을 때 시장에서 경쟁력이 있을 거라는 이야기다.

UX에 대해 이야기 해봅시다

이제부터는 조금 더 딥하게 UI와 UX의 개념을 알아보자. 널리 알려진 법칙/효과와 사례를 통해 쉽고 재미있게 알아보고, 내가 만들 프로덕트에도 아래의 개념들을 어떻게 적용할 수 있을지 고민해 보자.

제이콥의 법칙

사용자는 새로운 경험을 이해하기 위해 기존 경험을 활용한다는 관점이다. 즉, 새로운 웹사이트를 방문하더라도 기존에 다른 웹사이트를 이용했던 경험을 기반으로 UI를 이해한다는 것이다.

마켓컬리 홈 화면

29CM 홈 화면

예를 들어 아래와 같이 우리는 쇼핑몰에 접속했을 때 설정 버튼, 장바구니, 마이페이지 버튼을 누르면 어떤 화면이 나타날지 직관적으로 알 수 있다. 만약 '통상적으로' 사용되는 아이콘이나 위치에 배치하지 않는다면 사용자는 꽤 불편하게 느낄 것이다. 따라서 우리가 프로덕트를 개발할 때는 기존 웹사이트에서 차용하고 있는 방식들을 많이 참고한다면 더 좋은 사용자 경험을 줄 수 있는 말이기도 하다.

피츠의 법칙

터치 대상의 크기는 사용자가 정확하게 선택할 수 있도록 충분히 커야 하며, 터치 대상 사이에 충분한 거리를 확보해야 한다는 개념이다. 이때, 터치 대상의 크기가 작으면 대상을 문제없이 선택했을 때조차 사용성이 떨어지기에 서비스 기획 시 위 개념을 알아두면 좋다.

한국투자증권 앱 화면

배달의 민족 홈 화면

위의 두 가지 대비되는 예시를 살펴보자. 한국투자증권 앱의 화면에는 한 화면에 굉장히 많은 정보와 선택지가 주어져 있다. 각 터치 대상의 크기가 작아 사용자가 원래 선택하려고 했던 대상이 아닌 다른 대상이 눌릴 수도 있기에 좋지 않은 사용자 경험을 줄 수 있다. 반면에 배민의 경우, 항목 하나하나의 크기가 큼직해서 사용자가 어렵지 않게 원하는 것을 터치할 수 있다.

힉의 법칙

의사결정에 걸리는 시간은 선택지의 개수와 복잡성에 비례해 늘어난다는 법칙이다. 즉, 선택지가 많을수록 결정하기까지의 고민하는 시간이 늘어나기에 의사결정 시간이 사용성에 큰 영향을 받는다면 선택지의 개수를 최소화는 것이 좋다.

할머니 할아버지 리모콘

애플 리모콘

위의 예시처럼 할머니 할아버지의 UX를 위해 잘 사용하지 않는 기능의 버튼들은 테이프로 가려두었고, 애플의 리모컨 또한 정말 필요한 기능들만 남긴 심플한 UI를 갖추었다. 사용자에게 불필요한 선택지를 줄여줌으로써 불필요한 고민을 하지 않도록 하는 좋은 디자인이다.

피크엔드의 법칙

인간은 경험 전체의 평균이나 합계보다, 절정의 순간과 마지막 순간에 느낀 감정을 바탕으로 경험 자체를 판단하는 경향이 있다. 더불어, 사람들은 긍정적인 순간보다 부정적인 순간을 더 강렬하게 기억하고는 한다. 따라서 사용자 여정 중에 갑작스러운, 혹은 피크의 순간을 세심하게 신경 쓰면 더 유려한 사용자 경험을 줄 수 있다는 말이다.

평범한 404 페이지

귀엽거나 재밌거나 404 페이지

첫 번째 사진처럼 평범한 404 페이지도 좋지만, 사용자가 접하는 부정적이고 갑작스러운 순간에도 약간의 양해 혹은 재미를 준다면 오히려 더 즐거운 경험으로 바꿀 수 있는 기회가 되기도 한다. (물론 장애나 에러가 없는 것이 가장 좋기는 하다..) 더불어, 해당 페이지의 접근이 사용자의 잘못 때문인 것처럼 느껴지게 해서는 안된다. 참고로 왼쪽의 아마존의 404 페이지는 아마존 직원들의 반려동물 사진이 랜덤으로 나온다고 한다. 정말 신박하고 귀엽다..!

폰 레스토프 효과

비슷한 사물이 여러 개 있다면 그중, 가장 차이나는 한 가지만 눈에 들어오고 기억할 가능성이 크다는 개념이다. 따라서 중요한 정보나 핵심 동작을 시각적으로 눈에 띄게 하자. 따라서 특정 요소를 강조할 때는 색상 대비를 확실하게 해 주자.

카카오뱅크 이체 화면

토스뱅크 이체 화면

위의 카카오뱅크와 토스뱅크에서 송금 시, 사용자에게 송금과 종료를 유도하는 버튼은 눈에 띄는 색상으로 표시해 두어, 사용자가 어떠한 동작을 해야 할지 명확하게 알 수 있다. 만약 버튼의 색깔이 화면의 색깔과 크게 다르지 않다면 의도와는 다른 버튼을 누르거나 액션 전에 괜한 고민이 많아질 수 있다.

도허티 임계

시스템의 반응 속도는 전체 사용자 경험을 좌우하는 중요한 요소로, 사용자에게 처리 시간에 대한 시각적인 피드백을 주면 좋다. 피드백을 주면 사용자는 대기시간에 더 관대해지고, 실제 웹이 더 빠르게 작동한다고 느낀다.

유튜브의 스켈레톤 화면

오늘의 집의 스켈레톤 화면

위의 예시는 '스켈레톤 스크린(Skeleton Screen)'이라고 한다. 뼈대 화면을 보여주며 앞으로 로딩될 콘텐츠가 예상되며 느려도 기다린다는 느낌이 덜하며, 실제 속도보다 더 느리게 느껴지지 않는다고 한다.

마켓컬리의 로딩화면

링글의 프로그레스바

위의 예시는 로딩 과정을 보여주는 앱 화면들이다. 좌측의 마켓컬리의 로딩 화면은 따로 진행 과정을 보여주지 않아 사용자가 언제까지 기다려야 하는지 불명확하다면, 우측의 링글 로딩 화면은 프로그레스 바 (Progress Bar)를 활용해 시각적인 피드백을 준다. (1) 로딩 진행률을 %로 보여주며 잔여 대기 시간을 명확히 알려주고, (2) 기다려야 하는 시간에도 영어 문장을 보여주며 자투리 시간에도 영어 공부를 할 수 있게 해 준다. 이 두 가지 요소는 사용자로 하여금 시간을 소중히 여겨준다는 마음이 느껴진다.

추가로, 모든 상황에서 로딩이 빠른 것이 좋은 것은 아니라고 한다. 예를 들어, 보안 점검 프로세스와 같은 상황에서는 의도적으로 작업 완료를 늦게 알리는 것이 신뢰 형성에 도움이 되기도 한다. 빠르다고 무조건 좋은 건 아니라는 것이다.

정리하며,

물론 개발자는 코딩을 잘해야 하는 것이 맞다. 하지만 본질적으로 개발자는 사용자가 쉽고 편안하게 사용할 수 있도록 하며 문제를 해결하는 사람이다. 만약 사용성이 떨어지는 프로덕트라면, 개발자를 포함한 프로덕트를 개발하는 모든 사람들(기획자, 디자이너, 개발자 등)은 성능 최적화 작업 및 사용성 개선 작업을 해야만 한다. 그래야 지속적으로 우리 프로덕트를 찾는 새로운 사용자가 늘고, 기존 사용자의 리텐션까지 방어할 수 있다.

개인적인 경험에 의하면 부모님이 사용에 어려움을 겪으시는 애플리케이션들의 공통점은 위에서 언급한 법칙들에 해당되지 않는다. 개발을 시작하며 어려움을 겪으시는 부모님을 보면 부모님이 답답한 것이 아니라, 이 앱을 만든 사람들이 답답하다. 조금 더 사용자 입장에서 생각을 해주지, 싶다.

개발 공부를 시작할 때부터 지금까지 변하지 않는 이 마음을 잘 간직하고자 한다.

세상 모든 사람들이 어려움 없이 사용할 수 있는 웹을 만들고, 그 과정을 나누고 싶다.

참고 자료

•

Youtube 우아한테크:  [10분 테코톡] 위니의 프론트엔드 개발자에게 UX란