슈퍼사이드의 모션 디자이너 레오나르도 리카는 카드 지갑을 시제품으로 만들었다. 쌓인 카드를 스크롤하고 한 장을 누르면 앞으로 나오며, 뒤집으면 뒷면의 정보를 보는 구성이다. 피그마가 10월23일 소개한 코드 레이어 사례 가운데 하나로, 정적인 프레임에 없던 시간과 겹침의 문제가 작업의 중심에 놓였다.
스크롤과 탭, 뒤집기를 한 번에 맡기지 않았다
리카는 먼저 스크롤을 맞춘 뒤 탭과 뒤집기를 추가했다고 설명한다. 카드의 위치와 크기, 스프링 움직임에는 정확한 값을 주고 참조 이미지도 전달했다. 카드가 제자리로 돌아갈 때 위에 있어야 할 다른 카드보다 앞으로 보이는 오류도 다뤘다. 예쁜 전환을 한 번 생성하는 일보다 이미 맞춘 동작을 유지하며 다음 동작을 더하는 과정이 보이는 사례다.
쓸 수 있는 부품과 고르는 기준을 따로 전달한다
같은 날 피그마의 디자인 시스템 안내는 에이전트가 참고할 자료를 구분했다. 게시한 라이브러리를 연결하면 승인된 컴포넌트와 토큰을 사용할 수 있다. 하지만 어떤 버튼을 어느 상황에 쓰는지까지 자산의 모양만으로 알 수 있는 것은 아니다. 라이브러리에 붙는 지침은 비슷한 변형 중 무엇을 고르고 어떤 예외를 지킬지 설명한다.
예를 들어 주문 확정에는 기본 버튼을, 돌아가기에는 보조 버튼을 쓰는 판단을 글로 남길 수 있다. 완성된 주소 입력 폼 같은 예시는 필드가 어떤 줄과 간격으로 묶이는지를 보여준다. 반복할 절차는 스킬로, 이번 작업에만 필요한 화면은 현재 요청의 참조로 전달한다. 부품 목록·선택의 이유·배치된 결과·작업 순서를 한 종류의 긴 설명으로 합치지 않는 접근이다.
델은 실제 부품으로 만든 대안을 곁에 남긴다
델의 제품 디자이너 미겔 베르무트는 개발자가 쓰는 React 컴포넌트를 코드 레이어에 사용한다고 설명한다. 디자인 시스템 팀이 연결한 같은 부품으로 계정 경험의 대화형 화면을 만들고, 이해관계자가 텍스트를 입력해 다음 화면으로 넘어가도록 했다. 검토자는 멈춘 이미지 대신 입력 뒤에 어떤 반응이 오는지 볼 수 있다.
수정할 때에는 코드 레이어를 복제해 이전 안과 새 안을 나란히 둔다. 버전 기록을 번갈아 여는 대신 같은 캔버스에서 어느 동작과 배치를 택할지 비교하는 방식이다. 슈퍼사이드가 한 동작을 고정하며 다음 단계로 갔다면 델은 선택할 대안의 관계를 남긴다. 둘 다 작동하는 결과를 검토의 대상으로 보이게 하지만, 수정 이력을 다루는 단위는 다르다.
카드의 모양, 상태, 상태 사이의 규칙을 나눠 보면
카드 한 장이 올바른 색과 글꼴을 쓰는 것과 카드 지갑 전체가 올바르게 움직이는 것은 다른 문제다. 앞면에서 뒷면으로 바뀌는 순간에는 위치뿐 아니라 어느 카드가 위에 그려지는지도 달라진다. 되돌아온 카드의 겹침 오류는 하나의 화면을 확인하는 일만으로 끝나지 않는 검토 지점을 보여준다.
이 사례를 다른 시제품에 적용한다면 스크롤한 뒤 선택하고, 뒤집은 뒤 다시 목록으로 돌리는 순서를 하나로 이어 볼 수 있다. 각 동작을 따로 시연할 때와 앞 동작의 결과를 이어받을 때의 차이를 찾는 방식이다. 아래 구분은 공개 작업 사례를 읽는 기준이며, 이 기사에서 해당 파일을 직접 실행해 통과시킨 시험 결과는 아니다.
| 구분 | 다루는 대상 | 확인할 장면 |
|---|---|---|
| 시각 자산 | 컴포넌트·색·글꼴 | 앞면과 뒷면의 표현이 제품 규칙을 따르는가 |
| 상태 | 선택한 카드·위치·크기 | 탭한 카드가 의도한 자리로 나오는가 |
| 전환 규칙 | 스프링·겹침 순서·복귀 | 뒤집고 되돌린 뒤에도 카드 순서가 유지되는가 |
카드 지갑과 코드 레이어 사례는 팀의 규칙을 동작하는 시제품에 이어 붙였다. 생성 결과의 모양만 비교하기보다 수치·상태·실제 컴포넌트를 기준으로 수정할 부분을 정한 과정에 주목할 수 있다.
ARCH.B 의견
두 글을 함께 읽으면 디자인 시스템이 어느 지점까지 시제품을 설명하는지 구체적으로 보인다. 브랜드 색과 카드 컴포넌트를 알고 있어도, 카드를 선택할 때 얼마나 이동하고 어떤 순서로 포개지는지는 별도로 정해야 한다. 카드 지갑의 겹침 오류는 정적인 부품이 올바르더라도 시간에 따른 관계가 어긋날 수 있음을 보여준다.
반대로 동작을 세밀하게 설명했더라도 실제 제품에서 쓰지 않는 카드나 버튼으로 만들면 검토의 기준이 바뀐다. 시스템의 자산은 시작점과 형태를, 수치와 단계별 수정은 상태 사이의 관계를 맡는다. 따라서 좋은 입력은 프롬프트 한 문장의 길이보다 무엇을 라이브러리에 남기고 무엇을 이번 실험에서 정할지 나눈 결과로 읽을 수 있다.
카드의 순서가 잘못됐다면 어떤 상태에서 겹침이 바뀌는지 설명할 수 있어야 한다. 두 안을 비교한다면 같은 입력을 넣고 어느 반응이 다른지 볼 수 있어야 한다. 이 사례들의 공통점은 시제품을 멋진 시연의 끝으로 두지 않고 다음 수정의 근거로 사용한다는 점이다. 팀이 합의한 규칙과 눈앞의 동작 사이를 오갈 수 있도록 자료를 배치한다.
피그마도 지침이 새 디자인을 만들 때 가장 잘 작동하며 기존 디자인 편집에서의 일관성은 개선 중이라고 설명한다. 연결해 둔 지침만으로 모든 상태가 정렬되는 것은 아니다. 카드 지갑처럼 작은 동작을 나눠 검토하고, 델처럼 비교할 안을 남기는 실제 작업이 이어진다. 기존 공개 베타 안내가 도구의 왕복 경로를 설명했다면 이번 사례는 그 경로에서 무엇을 고정하고 무엇을 고치는지 보여준다.
