Figma UI 개편:

Figma는 기능 구조를 크게 바꾸기보다 타이포그래피, 레이아웃, 색상, 아이콘 등 UI 표면을 다듬는 방식으로 시각적 리프레시를 진행했다. 기존 UI가 제품 성장에 따라 일관성을 잃고 한계에 부딪혔기 때문에, 전사적 브레인스토밍과 이슈 통합, 정성·정량 조사를 거쳐 변경 범위를 결정했다. 핵심은 모든 사용자를 만족시키려 하기보다 문제를 체계적으로 수집하고, 중요한 개선점에 집중하는 것이었다.

리디자인이 필요해진 배경

• Figma의 UI는 제품과 기능이 성장하면서 점점 일관성을 잃었다.
• 기존 컴포넌트로 새로운 기능을 표현하기 어려워질 때마다 팀이 임시 컴포넌트와 맞춤형 해결책을 만들었다.
• 그 결과 다음과 같은 문제가 누적됐다.
  • 서로 다른 형태의 테이블, 버튼, 입력 컨트롤
  • UI 곳곳에 흩어진 여러 색조의 회색·빨강·파랑
  • 기능마다 다른 알림과 대화상자 처리 방식
  • 가독성, 여백, 아이콘 체계의 불일치
• 마지막으로 UI 전체를 검토했을 때는 아직 Multiplayer나 Components 같은 핵심 기능이 없었다.
• 즉, 기존 UI의 기반이 현재의 Figma를 충분히 반영하지 못하게 된 것이 리프레시의 주요 배경이었다.

표면적 변화에 집중한 전략

• 목표는 사용자가 큰 혼란 없이 새 UI를 받아들이도록 만드는 것이었다.
• 정보 구조나 제품의 기본 동작을 재설계하기보다는 다음과 같은 시각적 요소를 중심으로 개선했다.
  • 타이포그래피
  • 레이아웃
  • 색상
  • 아이콘
  • 컴포넌트의 시각적 일관성
• 출시 전 수개월 동안 정성적·정량적 조사를 진행했다.
• 세부 변경 사항마다 여러 팀이 깊이 논의해 최종 결과에 동의하도록 했다.
• 특히 디자이너는 시각적 변화에 민감하므로, 리디자인이 모든 사람에게 동일하게 환영받을 수 없다는 점도 고려했다.

1단계: 제한 없이 문제 수집하기

• 전체 디자인 팀이 참여하는 2시간 브레인스토밍 세션을 열었다.
• 팀원들은 실제로 Figma를 사용하면서 제품의 구석구석을 살펴봤다.
• 발견한 내용을 다음 방식으로 기록했다.
  • UI의 문제점과 불편한 점
  • 마음에 드는 부분
  • 관련 스크린샷
  • 특정 문제가 미치는 영향에 대한 메모
• 모든 결과물을 Figma 파일에 모아 공동으로 검토했다.
• 팀원들이 강하게 반응한 문제, 즉 모두가 “이건 심각하다”고 느낀 항목을 별도로 표시했다.
• 이 반응은 어떤 문제가 사용자 경험에 큰 영향을 줄 가능성이 있는지 판단하는 초기 신호로 활용됐다.
• 브레인스토밍 직후 결론을 내리지 않고 며칠간 거리를 둔 것도 중요했다. 시간이 지나면서 문제의 우선순위와 구성원들의 의견이 자연스럽게 바뀌었기 때문이다.

2단계: 문제를 통합하고 범주화하기

• 후속 회의에서 각 문제를 다시 검토하며 처음의 판단을 재평가했다.
• 일부 문제는 생각보다 중요하지 않다고 판단했고, 다른 문제는 해결 필요성을 더 강하게 주장할 수 있도록 논거를 보완했다.
• 긴 문제 목록을 팀원들에게 나누어 전달하고, 각자가 이를 포스트잇 형태의 짧은 항목으로 재작성했다.
• 이 과정에서는 개별적인 증상을 그대로 옮기기보다 공통된 근본 문제로 추상화했다.
  • 예: “특정 화면의 알림 모양이 다르다”
  • 통합된 표현: “제품 전체의 알림 처리 시스템이 필요하다”
• 비슷한 포스트잇을 함께 묶어 반복적으로 나타나는 주제를 확인했다.
• 그 결과 다음과 같은 범주가 도출됐다.
  • 아이콘, 타이포그래피, 가독성, 색상
  • 대화상자, 툴바, 말투
  • 에디터와 파일 브라우저
  • 모드, 팀 페이지, 속성 사이드바
  • 컴포넌트, 레이어, 히스토리
  • 공유, 퍼블리싱, 내보내기
• 포스트잇의 반복은 단순한 중복이 아니라 중요한 문제가 여러 방식으로 나타나고 있다는 신호가 되었다.
• 다만 범주를 다시 “시각적 문제에서 기초 구조적 문제까지”라는 축으로 정렬하려 한 것은 지나치게 복잡한 접근이었다.

범주화 과정에서 얻은 교훈

• 문제를 조직화할 때 지나치게 추상적인 기준을 만들면 오히려 판단이 어려워진다.
• “제품의 개성”처럼 거의 모든 문제를 포함할 수 있는 범주는 유용하지 않다.
• 반대로 특정 대화상자 하나처럼 지나치게 좁은 범주도 전체적인 개선 방향을 잡는 데 적합하지 않다.
• 가장 좋은 범주는 서로 비슷한 문제를 묶으면서도, 실제 개선 작업으로 이어질 수 있을 만큼 구체적이어야 한다.
• 완벽한 분류 체계를 만드는 것보다 중요한 문제의 신호를 잡음에서 분리하는 것이 우선이다.

실무에 적용할 때의 추천

• 리디자인을 시작할 때 바로 해결책을 만들기보다, 먼저 팀 전체가 제품을 직접 사용하며 문제를 폭넓게 수집한다.
• 각 문제를 개별 사례가 아닌 반복되는 시스템적 문제로 재정의한다.
• 브레인스토밍 직후 결론을 확정하지 말고 일정한 숙고 시간을 둔다.
• 범주화는 단순하고 이해하기 쉽게 유지하며, 지나치게 추상적이거나 복잡한 분류 축은 피하는 것이 좋다.