figma·2025년 3월 31일·3분 읽기큐레이션 요약

개발자 핸드오프

디자이너와 개발자의 핸드오프는 디자인을 전달하는 마지막 단계가 아니라, 제품의 방향과 구현 방식을 함께 조율하는 협업 과정이다. 개발자는 성능·안정성·기술적 제약을, 디자이너는 일관성과 사용 경험을 중시하므로, 초기부터 소통하고 공통의 언어를 만들어야 한다. 특히 아이디어가 유연한 초기에 개발자를 참여시키는 것이 시행착오와 구현 비용을 줄이는 핵심이다. ## 협업의 기본 원칙 - 디자인은 “원하는 것(what we want)”, 개발은 “실제로 가진 것(what we have)”에 가깝다. - 두 직군의 간극을 줄이려면 다음이 필요하다. - 서로의 관점에 대한 호기심 - 지속적이고 열린 커뮤니케이션 - 좋은 결과물의 기준에 대한 공통된 관점 - 글은 효과적인 핸드오프를 위해 다음 네 가지 영역을 제시한다. 1. 무엇을 만들지 합의하기 2. 어떻게 만들지 결정하기 3. 공통 언어 만들기 4. 개발자 경험을 고려해 의도 명확히 하기 ## 무엇을 만들지 먼저 합의하기 - 초기 와이어프레임 단계부터 개발자를 참여시킨다. - 개발자는 다음과 같은 기술적 문제를 조기에 발견할 수 있다. - 단순해 보이는 디자인이 실제로는 복잡한 기술 로직을 요구하는 경우 - 데이터 계층에서 발생하는 제약이나 처리 비용 - 기존 기능을 재사용하거나 확장해 더 적은 개발 노력으로 해결할 수 있는 기회 - 아이디어가 아직 바뀔 수 있는 단계에서 피드백을 받을수록 수정 비용이 낮다. - 초기 협업의 목표는 다음과 같다. - 프로젝트 범위 정렬 - 기술적 제약 이해 - 잠재적 문제와 새로운 기회 식별 ## 와이어프레임으로 사용자 흐름 구체화하기 - Figma나 FigJam에서 화면 흐름을 와이어프레임으로 표현하면 추상적인 아이디어를 구체화할 수 있다. - Figma는 보다 구체적인 시각 자료를 만들 때 적합하다. - FigJam은 다음과 같은 상황에 유용하다. - 아이디어를 자유롭고 개략적으로 표현할 때 - 외부 협업자에게 중립적인 피드백 공간을 제공할 때 - 완성도 높은 비주얼을 일부러 배제하면 색상이나 스타일보다 전체 흐름과 핵심 문제에 집중할 수 있다. - 개발자는 화면 순서에서 빠진 상태나 예외 흐름을 발견하고, 디자이너는 이를 반영해 요구사항을 보완할 수 있다. ## 개발자에게 구체적인 질문하기 - 개발자는 질문을 받지 않으면 디자이너가 놓친 부분을 알기 어렵기 때문에, 의도적인 질문이 필요하다. - 다음 내용을 질문하면 협업의 깊이를 높일 수 있다. - 구현상의 제약은 무엇인가? - 데이터 계층에서 복잡성을 높이는 요소가 있는가? - 현재 화면 흐름에서 빠진 상태나 예외 상황은 무엇인가? - 제품의 다른 영역에서 재사용할 수 있는 패턴이나 기능이 있는가? - 이러한 질문은 중복 작업을 줄이고, 기존 기능과 디자인 시스템을 활용하게 해준다. - 개발자는 단순히 디자인을 구현하는 역할을 넘어, 기능 구조와 제품 경험을 개선할 기회를 제안할 수 있다. ## 개발자의 작업 방식에 맞춰 협업하기 - 개발자는 여러 작업 사이를 오가며 집중 상태를 유지해야 하므로, 개발자의 실제 워크플로에 맞추는 것이 신뢰 형성에 도움이 된다. - 필요한 정보와 피드백을 개발자가 사용하는 도구와 흐름 안에서 제공하면 커뮤니케이션 비용을 줄일 수 있다. - GitHub 사례처럼 FigJam의 코드 블록을 활용해 디자인 시스템 문서에서 컴포넌트 API를 함께 정의하는 방식도 가능하다. - 디자인과 코드의 연결 지점을 명확히 하면 컴포넌트의 동작, 재사용성, 구현 의도를 더 쉽게 공유할 수 있다. ## 실용적인 적용 방법 - 프로젝트 초기에 개발자를 리뷰에 초대한다. - 화면 디자인 전에 사용자 흐름과 주요 상태를 와이어프레임으로 정리한다. - “구현 가능한가?”보다 구체적으로 “어떤 제약이 있는가?”, “재사용할 수 있는 기능은 무엇인가?”라고 질문한다. - 정상 상태뿐 아니라 로딩, 오류, 빈 상태, 권한 제한 등 모든 화면 상태를 함께 검토한다. - Figma·FigJam·코드 문서 등 양쪽 팀이 실제로 사용하는 도구에서 정보를 관리한다. - 핸드오프를 일회성 전달이 아니라 설계와 구현이 반복적으로 조정되는 협업 과정으로 운영하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)

wireframingFigma디자인 시스템figjam+2

figma·2021년 8월 24일·3분 읽기큐레이션 요약

협업 중심의 교실을 조성

FIT의 Christie Shin 교수는 Figma를 활용해 학생들이 결과물보다 디자인 과정과 협업을 중시하도록 가르친다. 가상 교실을 팀·프로젝트·파일 구조로 조직하고, 수업 중 실시간 피드백과 반복 작업을 유도해 실제 디자인 현장과 유사한 학습 환경을 만든다. 핵심은 초기 작업을 공유하고, 구조와 자율성을 함께 제공하며, 개인 작업도 공동체 안에서 진행하고, 다른 사람의 영향을 자연스럽게 인정하는 것이다. ## Figma로 구성한 가상 교실 - 수업 섹션별로 Figma 팀을 만들고, 강의 자료와 활동을 프로젝트 단위로 정리한다. - 학생들은 강의 중 각자 파일에 머무르지 않고 동일한 Figma 파일에 모여 작업하고 피드백을 주고받는다. - 학기 초에는 인터랙티브 학생 프로필 만들기 같은 아이스브레이킹 활동으로 협업을 시작한다. - 모든 수업 활동과 최종 발표 자료를 Figma 안에서 관리해 학습 과정을 한곳에 축적한다. ## 초기 작업을 적극적으로 공유하기 - 완성되지 않은 아이디어를 공개하는 부담을 줄이고, 초기 단계부터 작업을 보여주는 습관을 기른다. - 학생들은 수업 중 서로의 파일에 들어가 구두와 댓글 등으로 즉각적인 의견을 전달한다. - 디자인을 완성된 결과물이 아니라 사고하고 발전시키는 과정으로 이해하게 한다. - 반복적인 피드백을 통해 피드백을 요청하고 반영하는 능력을 키운다. ## 구조를 제공하되 성장할 여지 남기기 - 학기 초에 활동별 템플릿과 이름이 지정된 페이지를 제공해 학습 과정을 체계화한다. - 템플릿은 리서치, 요약, 와이어프레임 등 목적에 맞는 작업을 안내한다. - 무한 캔버스의 빈 공간에는 스케치, 실험, 빠른 반복 작업을 자유롭게 추가할 수 있다. - 하나의 Figma 파일을 리서치부터 최종 결과물까지 기록하는 ‘창의적 여정’ 또는 디자인 저널로 활용한다. ## 개인 작업을 공동체 안에서 진행하기 - 개인 프로젝트라도 스터디 그룹 안에서 진행하며, 중간 결과를 지속적으로 발표한다. - 예를 들어 MTA 앱을 위한 디자인 시스템과 영상 사례 연구를 개인별로 제작하되, 그룹에서 진행 상황을 공유했다. - 최종 발표 때 한 번만 평가받는 대신 제작 과정에서 점진적으로 피드백을 반영한다. - 이러한 방식은 실제 디자인 조직의 크로스펑셔널 협업과 디자인 크리틱을 모방한다. - 작업물을 지나치게 ‘소중한 완성품’으로 여기지 않고, 피드백에 따라 계속 개선하도록 돕는다. ## 다른 사람의 영향을 인정하기 - 학생들이 아이디어를 빼앗길까 봐 작업을 숨기는 태도에서 벗어나도록 한다. - 다른 사람의 의견과 작업이 자신의 디자인을 변화시키는 것은 디자인 과정의 자연스러운 일부라고 가르친다. - 프로젝트마다 영감을 준 전문 디자이너나 동료 학생의 디자인 이미지를 수집하게 한다. - 영향을 준 사례와 출처를 프로젝트에 함께 기록하고, 크리틱에서 그 영향 관계를 논의한다. - 이를 통해 아이디어의 차용을 숨기는 대신 맥락과 기여를 투명하게 설명하는 태도를 기른다. 실무적인 관점에서는 학생별 파일에 템플릿과 자유 작업 공간을 함께 제공하고, 정기적인 중간 공유와 동료 크리틱을 운영하는 방식이 효과적이다. 중요한 것은 도구 자체보다 초기 공개, 지속적인 피드백, 영향에 대한 인정이 자연스럽게 일어나는 협업 문화를 만드는 것이다.

원문 읽기(새 탭에서 열림)

wireframingFigma디자인 시스템user-experience-design+2

figma·2020년 12월 15일·3분 읽기큐레이션 요약

드롭박스의 일하는 방식 리

코로나19로 Dropbox는 사무실 중심 문화를 버리고 ‘virtual-first’ 업무 모델로 전환하면서, 온라인에서 협업과 창의성을 재현하는 방식을 다시 설계했다. 디자인팀은 Figma를 단순한 디자인 도구가 아니라 브레인스토밍, 리뷰, 핸드오프, 부서 간 커뮤니케이션이 이루어지는 업무의 중심 공간으로 활용했다. 또한 Figma 사용법을 전사적으로 교육해 디자인 외 조직까지 시각적 협업에 참여하도록 만들었다. ## 사무실 중심 문화에서 virtual-first로 - Dropbox는 12개 글로벌 오피스에 Maker Room과 협업 공간을 운영하며 대면 창의성을 업무 문화의 핵심으로 삼고 있었다. - 디자인팀은 포스트잇, 마커, 장난감 등을 활용해 디자인 스프린트와 즉석 브레인스토밍을 진행했다. - 원격근무에서는 우연히 만나 아이디어를 주고받거나 같은 공간에서 자연스럽게 몰입하는 일이 어려워졌다. - 따라서 기존의 물리적 협업 방식을 온라인 환경에 맞게 의도적으로 재설계해야 했다. ## Figma를 활용한 원격 협업 - Dropbox 디자인팀은 2018년 Sketch에서 Figma로 전환한 덕분에 브레인스토밍, 와이어프레임, 프로토타이핑, 댓글 작성 등 원격 협업의 기반을 이미 갖추고 있었다. - 대면 디자인 리뷰 대신 Figma의 **관찰 모드(Observation mode)** 를 사용해 발표자의 화면을 실시간으로 따라갔다. - 디자이너들은 책상 옆에서 함께 작업하는 대신 Figma 링크를 공유하고 같은 파일에 들어가 아이디어를 빠르게 수정했다. - 엔지니어와 PM도 Figma 기반 디자인 스프린트에 참여하면서 부서 간 협업이 쉬워졌다. - 디자인 파일 자체가 결과물뿐 아니라 논의와 의사결정이 기록되는 커뮤니케이션 공간이 되었다. ## 비동기 핸드오프로 커뮤니케이션 단순화 - Design System 팀과 Brand Studio 팀은 아이콘 전달 과정을 Figma 템플릿으로 표준화했다. - 브랜드 디자이너가 아이콘 작업을 완료하면 해당 페이지에 체크 표시를 남긴다. - 디자인 시스템 팀은 매주 월요일 파일을 확인해 새 아이콘을 마스터 라이브러리에 반영하고 게시한다. - 별도의 반복적인 메시지나 진행 상황 확인 없이 파일 상태만으로 업무 진행 여부를 알 수 있게 되었다. - 이 방식은 다른 협업 라이브러리에도 적용할 수 있는 효율적인 비동기 프로세스로 평가됐다. ## Figma를 전사 협업 도구로 확장 - 디자인팀은 다른 부서가 Figma를 사용할 수 있도록 댓글, 내보내기, 화면 보기 및 따라가기 기능을 중심으로 워크숍을 진행했다. - 워크숍에는 마케팅, 리서치, 데이터 사이언스 등 200명 이상의 구성원이 참여했다. - 교육의 목적은 원격 환경에서도 실제 사무실의 화이트보드처럼 함께 보고, 말하고, 아이디어를 발전시키게 하는 것이었다. - 디자인 외 조직도 Figma에서 다음과 같이 활용하기 시작했다. - QA: 디자인 플로우를 복제해 테스트 계획과 테스트 케이스 작성 - 디자인 리서치: 설문 데이터와 정성적 인사이트를 나란히 배치해 발표 - 여러 조직: 프레젠테이션 공동 제작 - 그 결과 Figma는 Dropbox 전체 구성원이 시각적으로 소통하고 공동 작업하는 공용 공간으로 자리 잡았다. ## 실용적인 시사점 원격 협업을 정착시키려면 기존 대면 업무를 화상회의로 단순히 옮기는 데 그치지 말고, 협업 산출물·상태·의사결정을 하나의 공유 공간에 남기는 방식으로 프로세스를 재설계해야 한다. 특히 명확한 템플릿, 상태 표시, 비동기 핸드오프 규칙을 마련하고 비디자이너까지 도구 교육에 참여시키는 것이 효과적이다.

원문 읽기(새 탭에서 열림)

wireframingFigma디자인 시스템프로토타이핑+2

figma·2020년 6월 17일·4분 읽기큐레이션 요약

개발자와 더 가까워지는 방법 |

엔지니어를 제품 디자인 과정에 일찍 참여시키면 기술적 제약과 예외 상황을 빠르게 파악해 더 나은 해결책을 만들 수 있다. 디자이너는 완성된 시안을 전달하기보다 초기 아이디어 단계부터 엔지니어와 함께 가설을 검토하고 대안을 탐색해야 한다. 이를 위해 빠른 목업, 공동 브레인스토밍, 핵심 질문 정의가 효과적인 협업 방식으로 제시된다. ## 기술 지식이 아이디어를 구체화한다 - 디자인 초기의 아이디어 구상 단계에서 엔지니어와 긴밀히 협업하면 구현상의 제약을 빠르게 이해할 수 있다. - 엔지니어는 기술적 지식을 바탕으로 다음을 파악하는 데 도움을 준다. - 예상하지 못한 예외 상황 - API나 시스템 구조에서 발생할 수 있는 제약 - 구현 난이도와 선택지별 트레이드오프 - 초기부터 제약 조건을 알면 나중에 구현이 불가능한 시안을 수정하는 대신, 현실적이면서도 더 사려 깊은 해결책을 설계할 수 있다. - 완성된 결과물을 평가받는 방식이 아니라, 문제를 함께 정의하고 아이디어를 발전시키는 파트너로 엔지니어를 참여시켜야 한다. ## 지속적으로 협업할 엔지니어를 정한다 - Coda의 Packs Tables 기능을 개발할 때 전체 엔지니어링 팀과 별개로, 디자이너와 전 과정에서 협력할 엔지니어 파트너를 두었다. - Packs Tables는 Spotify, Google Calendar, Gmail 등 외부 앱의 데이터를 Coda 문서로 가져오는 기능이다. - 여러 앱의 API를 지원해야 하므로 특정 앱에만 맞는 해결책이 아니라 다양한 서비스에서 작동하는 구조를 고민해야 했다. - 한 명의 엔지니어와 지속적으로 협업하면 아이디어를 즉시 검토하고, 기술적 질문과 디자인 방향을 함께 조정할 수 있다. ## 빠르고 불완전한 ‘스트로맨 목업’을 만든다 - 스트로맨 목업은 완성된 디자인이 아니라 토론과 질문을 유도하기 위한 시각적 초안이다. - 다음 원칙을 따른다. - 빠르게 만든다. 초기 아이디어에는 오해나 잘못된 가정이 포함될 수 있으므로 많은 시간을 투자하지 않는다. - 해결책보다 질문을 더 많이 담는다. - 하나의 방향으로 좁히기보다 다양한 가능성을 보여준다. - 먼저 “모든 것이 쉽게 작동한다면 어떻게 보이고 동작할까?”를 가정해 초안을 만든다. - 엔지니어와 검토할 때 다음 질문을 적극적으로 던진다. - 가장 큰 오해나 잘못된 가정은 무엇인가? - 아직 고려하지 못한 요소는 무엇인가? - 흥미로운 방향은 무엇인가? - 구현하기 어려운 방향은 무엇이며, 그 어려움의 대가는 무엇인가? - 어려운 방향을 무조건 배제하는 것이 아니라, 난이도와 트레이드오프를 이해하는 것이 목적이다. ## 함께 아이디어를 시각화한다 - 초기 단계에는 자신의 목업만 검토하지 말고 엔지니어와 함께 새로운 아이디어를 브레인스토밍해야 한다. - 디자이너의 시각화 능력은 자신의 아이디어뿐 아니라 팀원의 질문과 가설을 구체화하는 데도 활용할 수 있다. - Coda에서는 컴포넌트가 준비된 와이어프레임 키트를 사용했으며, 새로운 요소가 아니라면 하이파이 형태로도 빠르게 탐색했다. - 원격 환경에서는 다음과 같은 방식으로도 협업할 수 있다. - 펜과 종이를 카메라로 공유하기 - iPad 화면 공유하기 - 온라인 화이트보드 사용하기 - Packs Tables 개발 과정에서는 화이트보드에 UI를 그리며 질문과 잠재적 문제를 구체화했다. - 이 단계의 목표는 최종 UI를 확정하는 것이 아니라, 아이디어와 문제에 대해 서로 같은 이해를 갖는 것이다. ## 핵심 질문을 먼저 정의한다 - 핵심 질문은 이후 발생하는 세부적인 의사결정의 기준이 되는 원칙이다. - 질문을 먼저 정리하면 다음과 같은 효과가 있다. - 문제를 올바른 순서로 해결할 수 있다. - 초기부터 특정 해결책을 두고 논쟁하는 일을 줄일 수 있다. - 설계 결정을 더 빠르게 내릴 수 있다. - 예를 들어 행사에 맞춤 냅킨을 사용할지 결정하려면 먼저 예산, 시간, 인력, 행사 분위기 같은 상위 조건을 정해야 한다. - Packs Tables에서는 브레인스토밍 중 핵심 질문을 만들고 이를 Coda 문서에 기록했다. - 이후 해당 기능에 참여하는 모든 엔지니어와 질문 및 가능한 선택지를 함께 검토해 공통된 판단 기준을 마련했다. 엔지니어를 마지막 검수 단계에만 참여시키지 말고, 초기 가설과 아이디어를 함께 탐색하는 파트너로 초대하는 것이 좋다. 빠른 목업을 만들고, 화이트보드로 대안을 시각화하며, 핵심 질문을 문서화하면 기술적 제약을 창의성을 제한하는 요소가 아니라 더 나은 디자인을 만드는 정보로 활용할 수 있다.

원문 읽기(새 탭에서 열림)

wireframing프로덕트 디자인collaborationAPI+2

figma·2020년 4월 20일·4분 읽기큐레이션 요약

Inneract Project가 유색인종

Inneract Project는 흑인 및 유색인종 청소년이 어린 시절부터 디자인을 접하고, 교육과 직업으로 이어지는 진로를 준비하도록 돕는 비영리 프로그램이다. 초기에는 종이와 손을 활용한 창의적 사고 교육으로 시작했지만, UX/UI 디자인 수요가 커지면서 Figma를 도입해 교육 기회를 확대했다. Figma의 무료·웹 기반·협업 기능은 비용과 장비의 장벽을 낮추고 학생들의 실습과 창작을 크게 늘렸다. ## 디자인 교육을 통한 진로 기회 확대 - Maurice Woods는 2004년 자신의 커뮤니티와 같은 소외된 환경의 흑인·유색인종 학생들이 일찍부터 디자인을 진로로 고려하도록 Inneract Project를 설립했다. - 디자인을 단순한 표현 수단이 아니라 다음과 같은 변화의 도구로 보았다. - 지역사회의 문제와 목소리를 표현 - 다양한 세계의 현실을 제품과 서비스에 반영 - 학생들이 디자인 교육과 직업에 접근할 수 있도록 지원 - 중학교 시기부터 체계적으로 디자인을 배우게 해 대학 진학이나 직업 선택을 준비하도록 하는 것이 목표였다. ## 초기 교육: 도구보다 사고와 창의성 - 초기 프로그램에서는 소프트웨어나 하드웨어를 사용하지 않고 종이와 손만으로 활동했다. - 학생들이 직접 만들고 실험하면서 다음 역량을 키우는 데 집중했다. - 비판적 사고 - 창의적 사고 - 아이디어를 시각화하는 능력 - 이러한 입문 과정은 현재까지도 유지되며, 학생들이 디자인에 흥미와 열정을 느끼게 하는 출발점으로 활용된다. ## 전문 디자인 교육과 장비의 한계 - 학생들이 더 정식적인 교육을 원하면서 ‘Pathway to Design’이라는 체계적인 커리큘럼을 개발했다. - 당시 수요가 높았던 그래픽 디자인을 중심으로 교육했으며, 전문 디자인 소프트웨어와 하드웨어도 포함했다. - 그러나 디자인 도구의 높은 비용 때문에 다음과 같은 문제가 있었다. - 기부에 의존해 소프트웨어 라이선스를 구매 - 충분한 라이선스를 확보하지 못해 학생들이 컴퓨터를 공유 - 모든 학생이 전문 도구를 직접 사용하기 어려움 - 학생들에게 실질적인 디자인 경험을 제공하려면 비용과 장비 접근성 문제가 해결되어야 했다. ## Figma 도입과 접근성 향상 - 모바일 앱과 인터페이스 디자인이 중요해지면서 IP의 교육 과정도 그래픽 디자인에서 UX/UI 디자인으로 확장됐다. - Figma 도입은 교육 접근성을 높이는 핵심 계기가 됐다. - 무료로 시작할 수 있어 학생과 프로그램의 비용 부담 감소 - 초보자에게 친숙하면서도 전문 기업에서 사용할 수 있는 수준의 기능 제공 - 별도 설치 없이 브라우저에서 사용 가능 - 학생들은 집에 개인 컴퓨터가 없어도 도서관이나 학교 컴퓨터실에서 자신의 파일에 접근할 수 있었다. - 수업 외 시간에도 파일을 열어 연습할 수 있어 디자인 학습 속도와 이해도가 높아졌다. ## 브라우저 기반 협업과 프로젝트 확대 - Figma를 사용하면서 IP는 교실 안팎의 협업 프로젝트를 더 많이 운영할 수 있게 됐다. - 학생들은 다음과 함께 작업했다. - 같은 수업의 다른 학생들 - 자원봉사자 - 지역 기업과 외부 파트너 - 교육 프로그램도 단일 워크숍, 여러 날에 걸친 수업, 해커톤, 기업·기관과의 협업 등으로 다양해졌다. - 도구의 접근성이 높아지면서 학생들은 단순히 디자인 기능을 배우는 것을 넘어 실제 문제를 해결하는 프로젝트를 수행했다. ## 학생들의 프로젝트와 성장 - Leigh는 학교 포스터와 그래픽을 제작한 뒤 Academy of Art University에서 그래픽 디자인을 공부하고 있다. - Saaleha는 UC Berkeley를 졸업하고 디자인 리서치 분야의 진로를 모색하고 있다. - Sierra는 콘크리트 위에서 사용하기 어려운 할머니의 보행기를 개선하는 디자인을 구상했다. - 노인을 위한 보행 보조기 콘셉트 제작 - 예술가와 팬을 연결하는 모바일 앱 디자인 - Noah는 노숙 청소년을 위한 지원 서비스 앱의 디지털 광고 캠페인을 만들었다. - 거리 예술과 그래피티를 다룬 잡지 ‘Esoteric’의 무드보드 제작 - 지역 예술가 인터뷰와 직접 촬영한 사진을 활용 - 학생들의 사례는 디자인 교육이 창의성뿐 아니라 지역사회 문제 해결과 진로 탐색으로 이어질 수 있음을 보여준다. ## 실용적인 시사점 - 디자인 교육은 고가의 장비보다 창의적 사고와 문제 정의에서 시작할 수 있다. - 이후 전문 도구를 도입할 때는 무료 사용, 웹 접근성, 협업 기능이 교육 격차를 줄이는 중요한 기준이 된다. - 학생들이 자신의 경험과 지역사회의 문제를 프로젝트 주제로 삼도록 하면 디자인 학습의 몰입도와 사회적 의미를 함께 높일 수 있다.

원문 읽기(새 탭에서 열림)

wireframingFigmagraphic-designmobile-apps+2

figma·2019년 8월 11일·3분 읽기큐레이션 요약

와이어프레임 제작 방법 |

와이어프레임은 웹사이트나 디지털 제품의 구조와 기능을 빠르게 표현하는 설계 청사진이다. 시각적 장식보다 레이아웃과 사용자 경험에 집중하게 하므로, 팀의 의견과 사용성 조사 결과를 반영하며 아이디어를 반복적으로 개선하는 데 유용하다. 초기에는 단순하게 시작하고, 필요에 따라 시각적 디테일을 단계적으로 추가하는 것이 핵심이다. ## 와이어프레임의 의미와 역할 - 웹사이트나 디지털 제품의 **골격과 구조**를 보여주는 간단한 시각 가이드다. - 최종 디자인의 청사진이지만, 색상·그래픽·세부 스타일을 확정하는 단계는 아니다. - 디자이너뿐 아니라 기획자, 개발자, 이해관계자, 사용자도 이해할 수 있을 만큼 단순해야 한다. - 시각 요소를 최소화하면 색상이나 미적 요소에 매몰되지 않고 다음에 집중할 수 있다. - 기능이 제대로 동작하는가 - 사용자가 서비스를 어떻게 이용하는가 - 아이디어를 어떻게 개선할 수 있는가 - 확정된 결과물이 아니라 사용성 테스트와 이해관계자 피드백을 수집하기 위한 반복 설계 도구다. ## 로우 피델리티 와이어프레임 - 가장 기본적인 형태로, 종이와 펜만으로도 제작할 수 있다. - 보통 흑백 또는 회색조로 구성하며 다음을 중심으로 표현한다. - 페이지 레이아웃 - 콘텐츠의 큰 구조 - 주요 상호작용 - UI 요소와 콘텐츠는 사각형, 삼각형, 원, 선 같은 기본 도형으로 표시한다. - Figma로 제작하면 팀원과 쉽게 공유하고, 변경된 아이디어를 최신 상태로 유지할 수 있다. - 전통적인 디자인 과정에서는 손으로 그린 스케치 다음, 고해상도 목업이나 프로토타입 이전 단계에 해당한다. ## 하이 피델리티 와이어프레임 - 로우 피델리티 단계의 구조를 바탕으로 더 구체적인 시각 요소를 추가한다. - 다음과 같은 요소가 포함될 수 있다. - 브랜드를 나타내는 색상 - 그래픽과 이미지 - 글꼴 스타일 - 실제와 유사한 UI 컴포넌트 - 질감과 그림자 - 실제 이미지와 문구 - 경우에 따라 하이 피델리티 와이어프레임을 별도 단계로 거치지 않고, 로우 피델리티 와이어프레임에서 바로 프로토타입으로 진행할 수도 있다. ## 시각 요소를 단순하게 유지하기 - 와이어프레임의 목적은 완성된 디자인을 꾸미는 것이 아니라 구조와 경험을 검증하는 것이다. - 색상은 흰색, 검은색, 회색 중심의 그레이스케일로 제한하는 것이 좋다. - 타이포그래피는 정보의 위계를 전달하는 용도로 사용한다. - 글꼴은 최대 두 종류로 제한하고, 다음 방식으로 중요도를 구분한다. - 글자 크기 조절 - 굵게 또는 기울임꼴 적용 - 제목과 본문의 시각적 대비 조정 ## 이미지와 그래픽을 도형으로 표현하기 - 실제 이미지나 그래픽을 넣기보다 배치될 위치를 보여주는 단순한 기호를 사용한다. - 이미지 영역은 사각형이나 직사각형 안에 X 표시를 넣어 표현할 수 있다. - 동영상 영역은 박스 안에 재생 버튼 모양의 삼각형을 표시한다. - 이렇게 하면 콘텐츠 자체보다 화면 구성과 배치에 집중할 수 있다. ## 화면 크기와 사용 환경 고려하기 와이어프레임은 창의적인 설계 도구인 동시에 기술적 제약을 검토하는 도구이기도 하다. - **지원 기기** - 데스크톱과 모바일에서 디자인이 어떻게 달라지는지 각각 설계한다. - 반응형 레이아웃에서 콘텐츠와 UI 요소가 어떻게 재배치되는지 확인한다. - **화면 방향** - 세로형과 가로형 화면에서 레이아웃이 적절히 작동하는지 검토한다. - 기기와 방향에 따라 별도의 와이어프레임이나 변형 버전이 필요할 수 있다. - 디자인이 실제로 사용될 장소, 단계, 방식까지 고려하면 초기 단계에서 기술적 문제를 발견할 수 있다. ## 실용적인 적용 순서 - 아이디어를 빠르게 손그림이나 로우 피델리티 형태로 표현한다. - 레이아웃, 기능, 사용자 흐름에 대한 팀 피드백을 수집한다. - 사용성 조사 결과를 반영해 구조를 반복 수정한다. - 구조가 충분히 검증된 뒤 필요한 경우 색상, 이미지, 글꼴, 그림자 등 하이 피델리티 요소를 추가한다. - 협업과 버전 관리를 위해 Figma에서 공유 가능한 형태로 제작하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)

wireframingFigma사용자 경험프로토타이핑+2

figma·2019년 3월 20일·3분 읽기큐레이션 요약

피그마 드래프트

Figma Drafts는 완성된 결과물을 공유하기 전, 아이디어를 자유롭게 실험하는 개인 작업 공간이다. 글쓴이는 공개 협업 환경에서 파일의 완성도나 정리 상태를 평가받을까 하는 두려움을 Drafts로 완화했고, 이를 디지털 노트처럼 활용했다. 핵심 원칙은 먼저 만들고 나중에 정리하며, 발전시킬 아이디어만 프로젝트로 옮기는 것이다. ## 공개 협업에서 생기는 부담 - 다른 사람이 작업 중인 파일을 볼 수 있으면 다음과 같은 걱정이 생길 수 있다. - 8px 그리드를 지키지 않았다는 평가 - 레이어 이름을 정리하지 않았다는 지적 - 아이콘을 만드는 과정이나 파일 구조가 미숙해 보일 가능성 - 이 부담 때문에 실제 문제 해결이나 다양한 시도보다 파일을 “보여줄 만한 상태”로 꾸미는 데 시간을 쓰게 된다. - 글쓴이는 이러한 두려움이 공개적이고 협력적인 디자인 환경에서 더 커졌다고 설명한다. ## Drafts의 역할과 장점 - Drafts는 팀이나 프로젝트와 마찬가지로 파일을 보관하는 조직 단위지만, 개인 폴더라는 점이 다르다. - 팀이나 프로젝트의 권한 및 공유 설정에 종속되지 않는다. - Drafts 전체를 다른 사람에게 공개할 수는 없고, 필요한 경우 개별 파일만 선택적으로 공유할 수 있다. - 완성품이 아니라는 의미가 이름에 내포되어 있어, 실험과 미완성 작업을 심리적으로 허용한다. - 디자이너의 블록을 극복하고 색상, 타이포그래피, 화면 흐름 등을 정하기 전에 우선 아이디어를 시각화하는 공간으로 활용할 수 있다. - 글쓴이는 Drafts를 낙서, 스케치, 미완성 목록이 섞여 있는 개인 노트의 디지털 버전으로 사용한다. ## “먼저 만들고, 나중에 정리하기” - Drafts에서는 iOS 앱 아이디어나 Figma 기능을 활용한 실험처럼 빠르게 떠오른 생각을 즉시 기록한다. - 파일 이름이 없거나, 기본 회색 도형만 있거나, 구조가 엉성해도 문제로 보지 않는다. - 중요한 원칙은 **Create first, organize second**이다. - 먼저 다양한 해결책을 시도한다. - 아이디어가 발전한 뒤 파일명, 레이어, 구성 등을 정리한다. - 초기 단계에서 정리와 완성도를 지나치게 신경 쓰면 탐색의 폭이 줄어들 수 있으므로, Drafts에서는 혼란스러운 상태를 작업 과정의 일부로 받아들인다. ## Drafts를 프로젝트로 옮기는 방법 - 아이디어가 더 발전해 팀과 공유하거나 체계적으로 관리해야 할 시점이 되면 Drafts 파일을 프로젝트로 이동한다. - 파일 브라우저에서 파일을 선택한 뒤 원하는 프로젝트로 드래그 앤 드롭하면 된다. - 파일 내부에서 파일명 왼쪽의 “Drafts” 메뉴를 클릭하고 이동할 프로젝트를 선택할 수도 있다. - 예를 들어 와이어프레임을 고해상도 화면으로 발전시키려는 경우, 전체 파일을 프로젝트로 옮기는 방식이 적절하다. ## 원본 보존과 반복 작업 - 아이디어를 여러 페이지나 파일에서 계속 발전시킬 예정이라면, 먼저 Drafts 파일을 복제한다. - 복제본은 Drafts에 남겨 초기 아이디어의 스냅샷으로 보존한다. - 복제한 파일을 프로젝트로 옮겨 팀 작업이나 정리 작업을 진행한다. - Drafts에는 정리되지 않은 원본을 유지하고, 프로젝트 파일에서는 실제 작업에 필요한 요소를 다듬는 방식이다. ## 파일 관리와 검색 - Drafts가 많아지면 파일 브라우저의 필터 기능을 활용할 수 있다. - 파일명, 생성일, 마지막 수정일 등을 기준으로 파일을 찾고 정렬할 수 있다. - 다만 정리 자체를 너무 일찍 시작하기보다, 아이디어가 충분히 발전한 뒤 필요한 파일만 프로젝트로 옮기는 흐름이 권장된다. 개인 작업에서는 Drafts를 “공개 전 검수 공간”이 아니라 자유롭게 실패하고 탐색하는 디지털 스케치북으로 사용하는 것이 좋다. 완성도와 정리는 아이디어가 검증된 뒤에 진행하고, 팀 공유가 필요해졌을 때 파일을 복제하거나 프로젝트로 이동하면 창의성과 협업을 모두 확보할 수 있다.

원문 읽기(새 탭에서 열림)

wireframingFigma디자인 시스템프로토타이핑+2

figma·2018년 6월 4일·3분 읽기큐레이션 요약

웹사이트 제작, 무엇이 먼저

웹사이트 제작에서 카피와 디자인은 어느 하나가 먼저 완성되는 작업이 아니라, 서로 영향을 주고받으며 함께 발전해야 한다. 기존에는 Google Docs와 Sketch처럼 도구가 분리되어 반복적인 수정과 전달이 발생했지만, Figma 같은 클라우드 기반 협업 도구를 사용하면 카피 작성자와 디자이너가 동시에 작업할 수 있다. 그 결과 제작 기간과 회의, 커뮤니케이션 비용을 줄이고 더 효율적으로 웹 페이지를 완성할 수 있다는 것이 글의 결론이다. ## 카피와 디자인이 충돌하는 이유 - 카피의 길이와 내용은 디자인의 레이아웃과 직접 연결된다. - 카피 작성자는 문서를 작성하고, 디자이너는 별도 도구에서 화면을 설계하는 방식이 일반적이었다. - 디자인에 카피를 넣은 뒤 텍스트가 너무 길거나 짧다는 사실을 발견하면서 수정 작업이 반복된다. - 디자인 리뷰, 카피 리뷰, 추가 이해관계자의 의견이 순차적으로 개입해 작업이 여러 차례 되돌아간다. - 도구와 파일이 분리되어 있어 프로젝트 관리자조차 최신 상태를 파악하기 어려운 ‘블랙박스’ 같은 과정이 된다. ## 반복되는 협업과 커뮤니케이션의 문제 - 작성자는 Google Docs에서 카피를 만들고, 디자이너는 Sketch에서 별도로 작업한다. - 카피가 디자인에 맞지 않으면 양쪽이 다시 수정하고, 이후 리뷰 결과에 따라 전체 작업을 재조정해야 한다. - 원격 디자이너와 협업할 때는 파일을 주고받는 과정이 더욱 복잡해진다. - 글에서는 과거에 디자인을 출력해 펜으로 수정한 뒤 스캔해서 공유하기까지 했던 사례를 소개한다. - 이러한 반복적인 ‘핑퐁’ 과정은 프로젝트를 불필요하게 지연시키고 참여자의 피로를 높인다. ## Figma를 활용한 동시 작업 방식 - 마케팅 담당자는 각 페이지에서 전달할 핵심 카피를 하나의 Google Docs에 정리한다. - 디자인팀은 Figma 프로젝트 안에 웹사이트 페이지별 프레임을 만든다. - 이후 고해상도 와이어프레임부터 최종 디자인까지 카피와 디자인을 함께 수정한다. - 카피 작성자는 디자인 문맥 안에서 텍스트가 너무 길거나 짧은지 즉시 확인할 수 있다. - 디자이너는 카피 전달과 파일 관리에 시간을 쓰기보다 실제 시각 설계에 집중할 수 있다. - 카피 수정 때마다 디자인팀에 별도 요청하거나 디자인 파일을 내보낼 필요가 줄어든다. ## 하나의 작업 공간이 제공하는 효과 - 프로젝트 URL 하나로 최신 디자인과 카피를 모든 이해관계자가 확인할 수 있다. - 참여자는 같은 화면에 댓글을 남기고 피드백을 주고받을 수 있다. - 버전 기록을 통해 변경 사항과 이전 작업 상태를 확인할 수 있다. - 디자인을 이메일로 내보내거나 회의 직전에 수정본을 다시 취합하는 일이 줄어든다. - 동일한 URL을 사용자 테스트에도 활용해, 내부 관계자들이 고객 피드백까지 함께 확인할 수 있다. - 회의 자체를 완전히 없애지는 않지만, 회의 횟수와 비효율적인 논의가 줄어든다. ## 실용적인 적용 방향 웹사이트 프로젝트에서는 카피를 모두 확정한 뒤 디자인을 시작하기보다, 초기 핵심 메시지를 정리한 후 카피와 디자인을 병렬적으로 발전시키는 방식이 효과적이다. 이를 위해 공유 가능한 디자인 파일, 실시간 댓글, 버전 관리, 사용자 테스트 결과를 한곳에 통합하면 수정 주기를 줄이고 협업 효율을 높일 수 있다.

원문 읽기(새 탭에서 열림)

wireframingFigma사용자 경험web-design+4

figma·2018년 1월 9일·4분 읽기큐레이션 요약

Figma가 이 버클

UC 버클리의 HCI 수업 CS 160은 디지털 제품 디자인을 가르치면서, 기존 디자인 도구와 환경의 한계를 Figma로 해결했다. Figma는 운영체제 제약과 높은 학습 곡선을 낮추고, 학생들이 수업에서 배운 사용성 원칙을 곧바로 팀 프로젝트에 적용하도록 도왔다. 특히 실시간 공동 편집과 맥락 기반 피드백은 디자인 경험이 적은 컴퓨터과학 전공자도 프로젝트에 적극 참여하게 만들었다. ## 디지털 디자인 교육의 현실과 CS 160 - 대학 교육은 빠르게 성장한 디지털 디자인 산업을 충분히 따라가지 못하고 있었다. - UC 버클리의 CS 160은 컴퓨터과학 전공자에게 사용성 및 인간-컴퓨터 상호작용의 원리를 가르치는 드문 디지털 제품 디자인 수업이었다. - 학생들은 3~4명씩 팀을 이루어 매 학기 주제에 맞는 Android 앱을 제작했다. - 의료, 선거 등 다양한 주제가 사용됐다. - 매주 수업에서 배운 내용을 프로젝트에 반영했다. - 수강 수요가 높아 정원이 기존 100명에서 두 배로 늘어난 적도 있었다. ## 기존 도구와 운영 방식의 문제 - 학생들이 Linux, Windows, macOS 등 서로 다른 컴퓨터를 사용했고, 개인 노트북이 없는 경우도 있었다. - 특정 소프트웨어가 작동하지 않는 학생을 위해 컴퓨터실을 마련했지만 효과적인 해결책이 되지 못했다. - Photoshop 등 Adobe 도구는 기능이 많고 학습 곡선이 가팔라 디자인 경험이 없는 학생에게 부담이 컸다. - 조교들은 디자인 원리보다 Photoshop 사용법을 가르치는 데 더 많은 시간을 써야 했다. - 결과적으로 일부 프로젝트에서는: - 디자인 경험과 적절한 컴퓨터를 가진 학생만 와이어프레임과 프로토타이핑을 담당하고 - 나머지 학생은 사용자 테스트나 코딩을 맡는 식으로 역할이 분리됐다. - 피드백도 이메일 등으로 일괄 전달해야 해서, 어떤 디자인 요소를 지칭하는지 학생들이 이해하기 어려웠다. ## 한 시간 만에 익힌 Figma Figma는 수업의 기술적·교육적 문제를 동시에 해결하는 도구로 선택됐다. - 학생에게 무료로 제공됐다. - 운영체제와 컴퓨터 종류에 관계없이 사용할 수 있었다. - 인터페이스가 단순해 디자인 도구 경험이 없는 학생도 빠르게 배울 수 있었다. - 디자인 화면에 직접 댓글을 달아 구체적인 위치에 피드백을 남길 수 있었다. - 버전 관리 기능으로 교사가 작업 진행 상황을 확인할 수 있었다. - 여러 학생이 하나의 디자인 파일을 동시에 편집할 수 있었다. - 프로토타이핑 기능이 내장되어 별도 도구 없이 발표용 결과물을 제작할 수 있었다. 컴퓨터과학 전공자인 Ryan Kapur는 디자인 도구 경험이 없었지만 약 한 시간 만에 Figma를 익혔다. 덕분에 도구 사용법에 시간을 빼앗기지 않고 Nielsen의 10가지 사용성 휴리스틱과 같은 수업 개념에 집중할 수 있었다. ## 수업 내용과 프로젝트의 직접적인 연결 - 학생들은 수업에서 배운 사용성 원칙을 즉시 팀 프로젝트에 적용했다. - Ryan의 팀은 의료를 주제로 알코올 의존자가 가까운 Alcoholics Anonymous 모임을 찾을 수 있는 앱을 제작했다. - Figma의 직관적인 사용성 덕분에 팀원들은 주당 약 한 시간의 대면 시간만으로도: - 새로운 기능을 브레인스토밍하고 - 화면을 설계하며 - 프로토타입을 제작할 수 있었다. - 이론을 실제 디자인에 반복적으로 적용하면서 사용성 개념을 더 깊이 이해하게 됐다. ## 실시간 협업으로 달라진 팀 프로젝트 - 여러 학생이 같은 파일을 동시에 편집할 수 있어 한 공간에서 함께 디자인할 수 있었다. - 팀원들은 서로의 작업 과정을 실시간으로 확인하고, 파일 안에서 아이디어를 논의할 수 있었다. - 마감 직전에도 여러 명이 동시에 수정할 수 있어 협업 효율이 높아졌다. - 파일을 덮어쓰거나 잘못 저장할 걱정 없이 수업 밖에서도 작업할 수 있었다. - 디자인 경험이 없는 학생도 파일에 직접 참여할 수 있어 역할이 특정 학생에게만 집중되지 않았다. - 교사는 디자인의 정확한 위치에 댓글을 남길 수 있어 피드백의 전달력과 이해도가 향상됐다. ## 교육적 의미 - Figma는 단순히 디자인 제작 도구가 아니라 컴퓨터과학과 디자인을 연결하는 협업 환경으로 활용됐다. - 도구 학습에 드는 시간을 줄여 수업의 초점을 사용성, 문제 정의, 사용자 경험에 맞출 수 있었다. - 실시간 공동 작업은 서로 다른 전공과 역량을 가진 학생들이 함께 문제를 해결하도록 도왔다. - 이 사례는 교육용 디자인 도구가 접근성, 협업성, 피드백 기능을 갖춰야 학습 효과를 높일 수 있음을 보여준다. 실무적으로는 디자인 수업이나 팀 프로젝트에서 특정 운영체제나 고가의 전문 소프트웨어를 전제로 하기보다, 누구나 빠르게 접근하고 동시에 작업할 수 있는 협업 도구를 선택하는 것이 효과적이다. 도구 자체보다 학생들이 사용성 원칙을 실제 결과물에 반복 적용하고, 교사의 피드백을 디자인 맥락 안에서 즉시 반영할 수 있는 환경을 만드는 것이 중요하다.

원문 읽기(새 탭에서 열림)

wireframingFigma사용자 경험프로토타이핑+4

figma·2017년 11월 1일·2분 읽기큐레이션 요약

피그마 페이지를 소개합니다

Figma Pages는 하나의 파일 안에서 브레인스토밍, 와이어프레임, 최종 디자인 등을 여러 페이지로 나누어 관리할 수 있게 해주는 기능이다. 디자인 단계나 플랫폼별 작업을 분리하면서도 파일을 벗어나지 않고 탐색·편집할 수 있어 정리와 협업이 쉬워진다. 다만 페이지를 버전 관리 용도로 사용해 대형 파일을 반복 복제하면 성능이 저하될 수 있으므로, 버전 관리는 별도의 Version History를 사용해야 한다. ### 디자인 단계를 분리하는 페이지 구성 - 브레인스토밍, 와이어프레이밍, 픽셀 단위의 최종 작업을 각각 다른 페이지에 배치할 수 있다. - 초기 단계의 자유로운 스케치와 최종 결과물을 분리해 파일 내 혼란을 줄인다. - 여러 작업 단계를 하나의 파일에서 관리하므로 문서를 오가며 작업할 필요가 없다. ### 플랫폼과 요소별 분류 - 모바일 앱을 제작할 때 iOS 화면과 Android 화면을 별도 페이지에 구성할 수 있다. - 복잡한 인터페이스에서는 공유 컴포넌트, 아이콘 등 특정 요소를 별도 페이지에 모아 관리할 수 있다. - 하나의 파일에서 여러 프로토타입을 제작해야 할 때 프로토타입별로 페이지를 나눌 수 있다. ### 페이지 관리 방식 - 디자인 파일의 왼쪽 패널에서 페이지를 추가·전환·삭제할 수 있다. - 페이지 메뉴는 조작이 끝나면 자동으로 접히며, 패널을 Control-click하면 열린 상태로 고정할 수 있다. - 컴포넌트를 다른 페이지로 옮기려면 마우스 오른쪽 버튼을 클릭한 뒤 **Move to Page**를 선택하면 된다. - Sketch 파일을 가져올 때는 Sketch에서 구성한 페이지와 심볼 구조가 Figma에도 동일한 방식으로 import된다. - 페이지 수에는 제한이 없다. ### 썸네일과 파일 탐색 - 브라우저에서 파일을 쉽게 훑어볼 수 있도록 대표 썸네일에 사용할 페이지를 설정할 수 있다. - 왼쪽 패널에서 원하는 페이지를 첫 번째에 배치하면 해당 페이지가 파일 썸네일에 활용된다. ### 공유 시 개인정보와 접근 범위 - 특정 페이지만 공유하더라도, 공유받은 사람은 그 페이지가 포함된 파일의 나머지 내용도 볼 수 있다. - 따라서 페이지를 보안 경계나 접근 권한 분리 수단으로 사용해서는 안 된다. - 민감한 디자인을 분리해야 한다면 별도의 Figma 파일을 만들어야 한다. ### 버전 관리와 성능 주의사항 - 페이지를 버전 관리 목적으로 추가로 만드는 것은 권장되지 않는다. - Figma에는 별도의 Version History 기능이 있으므로 이전 버전 확인과 복원에는 이를 사용해야 한다. - 큰 디자인 파일을 여러 페이지에 반복 복제하면 파일 용량과 렌더링 부담이 커져 성능이 저하될 수 있다. 실무에서는 페이지를 작업 단계, 플랫폼, 디자인 요소, 프로토타입 단위로 나누고, 접근 권한 분리와 버전 관리는 각각 별도 파일과 Version History로 처리하는 것이 적절하다.

원문 읽기(새 탭에서 열림)

wireframingFigma사용자 경험프로토타이핑+2