figma2023년 3월 27일

리틀 빅 아웃테이크 | (새 탭에서 열림)

Figma의 30개 이상 소규모 기능 업데이트는 처음 계획한 대로만 구현된 결과가 아니라, 개발 과정에서 발견한 엣지 케이스와 팀의 피드백을 반영해 완성됐다. 다중 선택 검색은 계층 구조를 시각화해 사용자의 혼란을 줄였고, 오버레이 블러는 위치 정보를 전달하는 방식으로 해결했으며, 캔버스 미리보기는 범위를 과감히 줄여 빠르게 출시했다. 이 글은 작은 기능도 실제 사용 맥락과 예외 상황을 깊이 검토할 때 훨씬 나은 사용자 경험으로 이어진다는 점을 보여준다. ## 엣지 케이스에서 출발한 다중 선택 검색 - 기능: 검색 결과에서 `Shift + Click` 또는 `Cmd`(Windows에서는 `Ctrl`)를 사용해 원하는 항목만 여러 개 선택하고 편집·교체할 수 있다. - 기존 Find and Replace 기능을 확장하면 비교적 간단할 것으로 예상했지만, 실제 구현 과정에서 복잡한 문제가 드러났다. - Figma에서는 프레임·컴포넌트·그룹 같은 부모 객체와 그 안의 자식 객체를 서로 독립적으로 선택하기 어렵다. - 검색 결과에 부모와 자식이 동시에 나타나면, 두 번째 항목을 선택하는 순간 의도하지 않은 하위 항목까지 함께 선택될 수 있었다. - 중첩 구조가 많은 파일에서는 어떤 객체가 실제로 선택되는지 파악하기 어려워, 기능은 작동하지만 사용자에게는 버그처럼 느껴졌다. - 해결책으로 검색 사이드바에 시각적 계층 구조를 도입했다. - 자식 항목이 어느 부모에 속하는지 표시 - `Command` 또는 `Shift`를 누른 상태에서 선택될 항목을 미리 강조 - 자동으로 포함되는 간접 선택 항목과 직접 선택한 자식 항목을 구분 - 이 사례에서 엣지 케이스는 부수적인 예외가 아니라, 다중 선택 기능의 핵심 설계를 결정하는 요소가 됐다. ## 팀 피드백으로 해결한 오버레이 블러 - 기능: 프로토타이핑에서 배경 블러가 적용된 오버레이가 실제로 뒤의 콘텐츠를 흐리게 표시한다. - 기존 렌더링 방식은 프레임 바로 아래에 있는 대상을 가져와 블러 처리하는 방식이었다. - 하지만 오버레이는 일반 프레임처럼 바로 아래에 대상이 존재하지 않기 때문에 블러가 안정적으로 렌더링되지 않았다. - 엔지니어 Brandon은 가능한 해결책과 예상되는 문제를 문서로 정리해 팀에 공유했다. - 팀은 오버레이의 위치 정보를 코드에 전달해 어느 영역을 블러 처리해야 하는지 정확히 판단하도록 제안했다. - 이후 오버레이와 해당 프레임의 관계를 명확히 연결하는 데이터를 추가했다. - 그 결과 여러 오버레이가 각자의 위치에 올바르게 그려지고, 서로 겹치는 레이어도 정확하게 합성될 수 있었다. - 이 과정은 특히 새로 합류한 구성원이 자신의 접근 방식을 팀의 검토와 피드백으로 검증하면서 자신감을 얻은 사례이기도 하다. ## 범위를 줄여 완성도를 높인 캔버스 미리보기 - 기능: 디자인 패널의 옵션 위에 마우스를 올리면 설정을 확정하기 전에 캔버스에서 결과를 미리 볼 수 있다. - 초기에는 블렌드 모드와 효과뿐 아니라 다음 기능까지 포함하려 했다. - Boolean 연산 - 컴포넌트 속성 - 폰트 선택기 - 그러나 모든 기능을 한 번에 지원하려 하면 구현 범위와 기술적 복잡도가 크게 증가했다. - 팀은 Figma 편집기에서 드롭다운으로 제공되는 속성을 전수 조사한 뒤, 구현 난이도와 사용자 가치에 따라 우선순위를 정했다. - 최종적으로는 기하 구조를 크게 변경하거나 캔버스 렌더링 방식을 대폭 수정하지 않아도 되는 기능을 우선 구현했다. - 처음에는 기능 수가 적으면 충분한 가치가 없을 수 있다는 우려가 있었지만, 제한된 범위만으로도 미리보기 경험은 충분히 강력하다는 결론에 도달했다. - 작은 기능을 빠르게 출시하려면 모든 경우를 다 지원하기보다, 사용자에게 즉시 가치를 주면서 기술적 위험이 낮은 영역부터 선택하는 것이 효과적이다. ## 작은 업데이트를 만드는 방식 - 30개 이상의 기능은 거대한 단일 프로젝트가 아니라 여러 팀의 작은 개선과 반복적인 의사결정으로 만들어졌다. - 초기 아이디어를 그대로 구현하기보다 실제 사용 상황에서 발생하는 혼란과 실패 가능성을 먼저 확인했다. - 설계와 엔지니어링이 긴밀하게 협업하며 시각적 피드백, 데이터 구조, 구현 범위를 함께 조정했다. - 문서화와 팀 리뷰는 특히 복잡한 문제를 구조화하고, 새로운 구성원이 해결책을 검증하는 데 중요한 역할을 했다. - 결과적으로 “작은 기능”도 사용자의 선택 방식, 렌더링 구조, 프로젝트 범위 같은 세부 사항을 깊이 고려해야 완성도 높은 기능이 된다. 실무적으로는 기능을 설계할 때 정상 동작만 확인하지 말고, 중첩 구조·동시 선택·레이어 순서 같은 엣지 케이스를 초기에 테스트하는 것이 좋다. 동시에 모든 기능을 한 번에 구현하려 하기보다, 사용자 가치가 크고 구조 변경이 적은 범위부터 출시한 뒤 점진적으로 확장하는 접근이 현실적이다.

find-and-replacefigmaprototypingfigjam+2

figma2022년 10월 5일

기능 비하인드: 찾 (새 탭에서 열림)

Figma의 ‘찾기 및 바꾸기’는 단순한 검색창 추가가 아니라, 캔버스 구조에 맞는 결과 정렬과 탐색 경험을 설계해야 하는 복합적인 기능이었다. 팀은 기존 플러그인 경험과 프로토타입을 바탕으로 FigJam에서 핵심 검색 경험을 먼저 검증한 뒤, 섹션과 공간적 근접성을 활용해 자연스러운 결과 순서를 구현했다. 이 과정에서 실험, 실제 파일 사용, 사내 피드백을 반복하며 기능을 다듬었다. ## 직관적인 검색 경험을 설계하기 - 기능 범위를 정하기 전 디자인 팀과 브레인스토밍을 진행했다. - 엔지니어링, 제품 관리, UX 라이팅, 제품 마케팅이 참여하는 협업 그룹을 구성했다. - 다른 도구의 검색 경험을 분석해 다음 원칙을 세웠다. - 빠르고 가벼울 것 - 캔버스를 이동할 때도 매끄러울 것 - 브라우저 등 익숙한 검색 방식과 유사할 것 - 실제 파일에서 사용해 보기 전에는 검색 경험을 정확히 평가하기 어려웠기 때문에, 디자이너가 기존 플러그인 개발 경험을 활용해 초기 프로토타입을 제작했다. - 이후 엔지니어링 팀이 디자인과 구현을 함께 반복했고, Figma 구성원들이 일상 업무에서 사용하며 피드백과 버그 탐색에 참여했다. ## FigJam에서 핵심 경험부터 검증하기 - 팀은 복잡한 Figma 파일보다 FigJam에서 먼저 기능을 구현했다. - 초기 목표는 다음 두 가지로 제한했다. - 파일 안의 텍스트 찾기 - 검색 결과 사이를 순서대로 이동하기 - 이를 통해 다양한 객체 유형과 복잡한 파일 구조를 지원하기 전에 검색의 기본 동작과 사용성을 검증했다. ## 캔버스에 맞는 검색 결과 정렬 - 웹페이지나 문서와 달리 Figma와 FigJam의 콘텐츠는 위에서 아래로 흐르지 않는다. - 객체가 캔버스의 여러 방향에 흩어져 있고, 사용자가 만든 공간적 구조도 파일마다 다르다. - 따라서 검색 결과의 순서가 예측 가능하면서도 캔버스의 시각적 구조와 어울려야 했다. - 정렬이 부자연스러우면 검색 결과를 따라갈 때 화면이 갑자기 멀리 이동해 탐색 경험이 끊길 수 있었다. ### 기존 행 단위 정렬의 한계 - 첫 구현에서는 프로토타이핑 엔진이 사용하던 행 단위 정렬 로직을 재활용했다. - 슬라이드처럼 객체가 규칙적으로 배치된 문서에서는 이 방식이 효과적이었다. - 하지만 FigJam처럼 스티키 노트와 도형이 캔버스 곳곳에 흩어진 경우에는 논리적인 그룹을 반영하지 못했다. - 단순히 좌우·상하 위치만 기준으로 삼으면 사용자가 인식하는 주제별 묶음과 검색 순서가 달라질 수 있었다. ## 섹션과 공간적 근접성 활용 - FigJam에 섹션 기능이 도입되면서 캔버스 콘텐츠를 더 명확하게 구조화할 수 있게 됐다. - 검색 결과를 섹션별로 정렬하면 사용자가 시각적으로 묶어 둔 그룹을 따라 자연스럽게 탐색할 수 있었다. - 실제 팀 사용 패턴을 분석한 결과, 브레인스토밍에서는 다음과 같은 구조가 자주 나타났다. - 관련 스티키를 한곳에 모아 핵심 주제를 도출함 - 답변이나 후속 의견을 겹쳐 배치해 대화의 흐름을 표현함 - 섹션에 속하지 않은 객체를 위해 공간적 정렬 알고리즘도 도입했다. - 이 알고리즘은 객체 사이의 거리를 기준으로 가까운 요소를 그룹화해, 흩어진 스티키에서도 논리적인 검색 결과 묶음을 만들었다. ## 휴리스틱을 통한 정렬 방향 결정 - 섹션의 위치와 형태가 검색 결과의 진행 방향에 어떤 영향을 주는지 분석했다. - 다양한 캔버스 배치와 실제 사용 사례를 테스트하며 정렬 규칙을 휴리스틱으로 정리했다. - 즉, 하나의 고정된 정렬 알고리즘만 적용하기보다 섹션 구조, 객체의 위치, 주변 요소와의 거리 등을 종합해 결과 순서를 결정하려 했다. - 이 접근은 Figma와 FigJam처럼 사용자가 자유롭게 구조를 만드는 캔버스 제품에서 검색 결과를 예측 가능하게 만드는 데 초점을 둔다. ## 실용적인 시사점 캔버스 기반 제품의 검색 기능은 텍스트 매칭만으로 완성되지 않는다. 검색 결과를 어떤 순서로 보여주고 화면을 어떻게 이동시킬지가 핵심이므로, 제품의 공간적 구조와 사용자의 그룹화 습관을 반영해야 한다. 특히 초기에는 제한된 환경에서 핵심 경험을 검증하고, 프로토타입과 실제 사용자 피드백을 반복적으로 결합하는 방식이 효과적이다.

find-and-replacefigmafigjamuser-interface-design+2