20241010 - 오늘 배운 것(TIL)

👀 돌아보기

◼︎ 오늘 한 일

• 아티클 스터디 [인지 부하를 줄이는 UX디자인의 비밀]
  아티클을 읽고 요약했으며, 인사이트를 도출하여 팀원들과 공유하였다.
• 특강 수강 [현업에서 디자이너가 개발 지식을 가지면 좋은 점]
• 비슷한 직무 JD (Job Descripton) 분석
  Product Designer외 다른 직군들을 리스트업해보고, 그 직군들의 채용공고를 살펴보며 어떤 차이가 있고 협업을 위해 알아둬야할 부분이 어떤 것이 있는지 알아보았다. (↗︎비슷한 직무 JD (Jobe Description) 분석 글)
• 담임 매니저님과 면담 진행

◼︎ 오늘 겪었던 문제점

• 특강 수강으로 인해 기존 타임테이블이 변경돼서 시간 배분에 약간 애먹었다
• 비슷한 직무 JD 분석이 너무 오래걸렸다. 내 분야가 아니라서 하나하나 꼼꼼히 살펴보다보니 생각했던 것보다 시간이 지체되어 다음에는 좀 더 효율적으로 과제를 진행해야겠다고 생각했다.

◼︎ 오늘 배운 점

• 인지 부하에 관련된 아티클을 읽으면서, 앱 사용 과정에서 사용자의 인지 부하를 감소시키는 것이 내가 생각했던 것 보다 훨씬 더 앱의 성과에 큰 영향을 끼칠 수 있다는 사실을 깨달았다.
• 또 아티클을 읽으며 '레퍼럴'이 친구 추천을 뜻하는 용어라는 것도 배웠다.
• 특강을 수강하면서, 잘 몰랐던 React의 특징에 대해 알게 되었다. 개발자들과 협업한 경험이 있기는 하지만, react를 다뤄본 적이 없어서 몰랐던 부분을 배웠다. 왜 react가 아직까지도 가장 대중적인 프론트엔드 개발 툴로 쓰이는지, 그리고 일상에서 react의 특징이 사용자 편의에 얼마나 영향을 끼치는지 알게 된 것이 흥미로웠다.
• PM/PO의 차이점을 배웠다. 과제 '비슷한 직무 JD 분석' 수행 도중, PM/PO의 차이점이 궁금해져 이를 따로 조사해보았다. PO가 좀 더 큰 틀에서 프로덕트를 바라보는 사람이고, PM은 좀더 프로덕트의 세부 기능을 담당하고 기획하는 사람이라는 것을 알게되었다. (아직은 두 직군이 많이 혼용되는 것 같기는 하지만)

 

---

 

✒️아티클 스터디

 

https://brunch.co.kr/@cliche-cliche/209

08화 인지 부하를 줄이는 UX 디자인의 비밀

위 아티클을 읽고 주제를 분석하고, 요약하며, 최종적으로 인사이트를 도출하여 팀원들과 공유하는 과정을 거쳤다.

 

◼︎ 주제 및 요약

[주제]

사용자의 인지 부하를 줄일 수 있는 UX 디자인의 원칙

 

[아티클 요약]

• 왜 인지 부하를 줄여야 할까?
  • 인지 부하(Cognitive Load)란 사람의 두뇌가 정보를 처리하는 데 드는 정신적 노력을 뜻한다. 사용자 인터페이스가 복잡하거나 직관적이지 않을 경우 사용자의 만족도가 현저히 감소하므로, 인지 부하가 낮은 디자인을 사용해 사용자의 작업 수행 시간을 단축시키고 전반적인 서비스 만족감을 높이는 것이 좋다.
• 인지 부하를 줄이는 방법들
  • 간결성과 명확성(Simplicity and Clarity) : 핵심 기능에 집중한 간단한 디자인
  • 직관적인 내비게이션(Intuitive Navigation) : 사용자가 메뉴, 페이지를 쉽게 탐색할 수 있도록 디자인
  • 청킹(Chunking) : 비슷한 역할을 하는 버튼, 또는 정보 구조를 그룹핑하여 디자인
  • 시각적 계층화 (Visual Hierarchy) : 색상, 대비, 크기 등을 활용해 중요한 정보나 CTA를 강조
  • 피드백 가이드 제공 (Feedback and Guidance) : 사용자가 수행한 작업(버튼을 누른다던지)에 대해 즉각적인 반응을 제공
• 인지의 던전 : 각 사용자 프로세스에서 디자이너가 고려해야 할 점들
  • 1단계 [온보딩] - 온보딩 과정에서 정확하고 간결하게 정보를 제공해야 함.
  • 2단계 [메뉴탐색] - 메뉴에 대한 선택지를 너무 많이 제공하지 않고, 필요한 메뉴를 쉽게 찾을 수 있어야 함.
  • 3단계 [상호작용 기능들] - 슬라이더, 버튼, 토글 등의 UI패턴을 활용해 사용방법이 쉽게 예상되게 디자인 해야함.
  • 4단계 [일관성 유지] : 같은 기능을 하는 버튼은 같은 디자인, 혹은 위치 등을 고수하는 등 일관성을 가져야함.
  • 5단계 [간결한 레퍼럴] : 다른 사람들에게 쉽게 추천할 수 있는 시스템을 제공해야 함.
• 인지의 던전을 나가며 : 간결함과 명확성, 질서 부여, 그루핑 활용, 단계별 접근, 일관성 등의 방법론을 잘 활용하여 UX를 설계하는 것이 필요함. 이는 사용자가 제품이나 서비스를 효율적으로 이용할 수 있게 돕고 제품이나 서비스를 성공으로 이끄는 중요한 열쇠가 될 것이다.

 

◼︎ 개인 인사이트

• [ 토스의 송금 프로세스 vs 시중 은행 앱의 송금 프로세스]
  처음 토스가 출시되었을 때, 간편 송금은 말그대로 센세이션이었다. 요즘은 시중 은행 앱들도 많은 개선이 이루어졌지만 처음에는 그 복잡도가 매우 높았다. 토스 앱은 모바일에 익숙하지 않은 사용자도 쉽고 간편하게 송금을 할 수 있도록 인지비용을 최소화한 UIUX를 제공해 성공을 거뒀고, 현재까지 성장했다. 마치 뜬구름 잡는 소리처럼 추상적이게 들리는 ‘인지비용 최소화’가 비즈니스에 얼마나 큰 파장을 가져다주는지 다시 한 번 생각하게 됐다.
  
  
• [ 딱 필요한 기능을 쉽고 간편하게 ]
  기존에 있던 앱들도 기능을 추가하고 있고, 새로 출시되는 앱들도 기존 출시된 앱과 경쟁하기 위해 너도나도 다양한 기능을 앞다투어 출시하고 있는 상황이다. 하지만 사용자에겐 ‘엄청나게 많은 기능’보다는 ‘나에게 꼭 필요한 딱 하나의 기능’을 ‘아주 쉽고 간편하게’, 즉 인지 비용을 최소화할 수 있게 디자인해서 제공하는 것이 필요하다는 생각이 들었다. 이는 많은 앱들의 숙제이고, 앞으로 일하면서 반드시 고려해야 하는 부분이라는 생각이 들었다.

 

◼︎ 팀원 전체 인사이트

[공통 인사이트]

• 일상생활에서 추상적이고 모호하게 인지만 하고 있던 ‘인지 비용’에 대한 개념을 명확한 워딩과 방법론으로 정리해서 하나의 이론으로 제시해준 것이 굉장히 도움이 되었다.

[의미 있었던 의견]

• 던전을 비유해서 글을 작성한 것이 글 작성자가 독자의 인지 부하를 줄이기 위해 채택한 수단이라고 생각했다. 이처럼 일상생활에서도 인지 부하를 줄일 수 있는 다양한 방법론을 생각해보고 적용해보는 것이 좋은 것 같다.
• 그러나! 던전에 대한 비유는 오히려 ‘인지 혼란’을 야기했다는 점에서 팀원 모두 동의했다. 또한 글의 시각적 계층화나 구조화 부분이 아쉬워서 독자의 집중력을 떨어뜨렸던 점이 아쉬웠다. 이 글을 타산지석으로 삼아서 사용자가 직관적으로 이해할 수 있는 프로덕트 디자인을 해야겠다는 생각이 들었다.
• 토스, 아이폰의 와이파이 선택 화면 등 일상생활에서 인지 부하를 최소화해 사용자 편의를 도모한 다양한 UIUX 예시를 떠올려보는 것이 도움이 될 것 같다. 또한 그 반례도(사용자의 pain point) 같이 생각해보면 좋을 것 같다.

 

---

 

💻 특강 : ' 현업에서 디자이너가 개발지식을 가지면 좋은 점'

[강의 내용 요약]

•  프로덕트를 만드는 팀의 구성 : 기획 + 디자인 + 개발 + 런칭
  인하우스 개발팀의 구성에 대해서 잘 이해하고 있으면 도움이 된다. 특히 디자이너가 가장 많이 소통하게 되는 프론트앤드 개발자나 기획자의 업무를 이해하는 것은 취업 면접시에도 도움이 된다.

 

• 디자이너와 프론트엔드 개발자의 역할 차이
  - 디자이너 : UI/UX 설계, 사용자 경험 중심의 디자인
  - 프론트엔드 개발자 : 프로덕트가 실제로 동작하도록 코드로 구현

 

• 개발자와 소통이 어려운 이유
   1. 전문 용어의 차이 - 같은 기능을 설명해도 용어가 다름
   2. 기술적 제약 - 디자이너의 이상을 개발자가 구현하기 힘듦, 복잡한 애니메이션에 따른 성능 저하 등
   3. 작업 흐름의 차이 - 시각요소 및 사용자 경험 중심 vs 기능적 요소 및 코드 중심

 

• 디자이너가 개발지식을 가져야 하는 이유
  디자이너와 개발자간의 원활한 소통 → 프로덕트 제작 과정의 효율 증대 → 비즈니스의 성과를 달성해서 프로덕트의 성장을 도모하는 '경쟁력 있는 디자이너'로 거듭남

 

• 수많은 개발언어 중 React를 배우는 이유?
  - 전 세계 웹 프레임워크 1위 (React의 프론트엔드 개발언어 점유율 47.9%)
  - 싱글 페이지 어플리케이션으로 속도가 빠르고, 서버 부하가 줄어들며, 효율성이 높음
  - 매번 페이지를 새로고침 할 필요가 없어 사용자가 느끼기에도 더욱 편리

 

• 싱글페이지 어플리케이션이란?
  - 리액트 이전 html, css, javascript로만 개발하던 시절에는 페이지마다 개별 html파일을 만들어줬어야 했음 (멀티페이지 어플리케이션)
  - 싱글페이지 어플리케이션은 메인 페이지를 하나만 만들고, 그 페이지 내에서 데이터가 바뀌는 부분만을 유동적으로 반영할 수 있는 기능을 제공함. 매번 새로운 페이지를 그리지 않아도 됨
  - ex) 장바구니에 물건을 담으면 → 그 변경사항을 데이터베이스에 반영하기 위해 물건을 담는 순간 페이지를 한 번 새로고침 했어야 함. 사용자 입장에서는 페이지가 한 번 깜빡임 → 그러나 리액트는 그럴 필요가 없음!

 

• 디자인 시스템과 유사한 리액트의 구조
  - 디자이너가 디자인할 때, figma에서 반복되는 디자인 요소를 컴포넌트로 제작해서 사용하는 경우가 많은데, 리액트도 이와 유사함. ui를 컴포넌트 단위로 나누어서 개발함

 

• UI의 동적인 변화를 위한 상태관리
  - 상태가 변하면 상태에 영향을 받는 컴포넌트는 모두 리랜더링된다
     ex) 장바구니에 물건을 담으면 장바구니 아이콘 하단에 1이라고 숫자뱃지로 표기가 됨
  - 리액트의 상태관리를 이해하면 디자인에도 도움이 된다

 

 

[느낀점 및 배운점]

사용자의 사용성에는 화면의 디자인 뿐만이 아니라, 각 개발언어가 가지고 있는 특징이나 특성 역시 영향을 끼친다는 사실을 새로 알게 되었다.

가끔 사이트를 이용하다보면, 페이지가 계속 깜빡거리는 즉 버튼을 누를때마다 상태를 반영하기 위해 페이지를 새로고침하는 사이트를 만날 때가 있는데 그 별거 아닌 깜빡거림이 사소하게 불편하고 귀찮았다. 그런 사이트와 그렇지 않은 사이트의 차이점이 궁금했는데 해소가 된 것 같다.

개발지식은 배워도 배워도 끝이 없는 것 같다. 더 많이 배워서 경쟁력을 갖추고 싶다.

 

---

 

👉 오늘 총평

사전캠프이다 보니 강제성도 떨어지고 동기부여도 덜해서 사람들의 마음이 왔다갔다 한다는 사실을 대화를 통해 알게되었다. 비록 짧게나마 팀장이 되었으니 최대한 으쌰으쌰 하는 분위기를 만들어 다 같이 좋은 결과를 냈으면 좋겠다.

오늘은 면담도 하고 특강도 수강하느라 굉장히 시간을 많이 썼다. 다음부터는 시간을 좀 더 효율적으로 사용하려고 노력해야겠다. 내일도 화이팅🔥