호스트와 시터가 서로를 찾는 과정부터 멤버십, 리뷰, 운영자의 관리 화면까지. 서비스 안의 서로 다른 역할과 상태를 구분하고, 화면의 동작을 Figma 설계서와 컴포넌트로 정리했습니다.
참여 영역: UI/UX 설계 · 화면 정의 · 컴포넌트 구성 이 페이지는 Figma 작업물을 소개하는 디자인 사례입니다.
AS-IS / TO-BE · 04 SCREENS
탐색부터 이용 관리까지, 화면별로 달라진 경험.
기존 서비스의 화면 캡처와 실제 Figma 개선안을 함께 살펴보세요. 호스트·시터 탐색, 리뷰 관리와 멤버십 결제에서 바뀐 정보의 구조와 동작을 정리했습니다.
01 / 호스트 탐색
사진 중심의 목록에서, 조건을 비교하는 탐색으로.
문제 / 적합한 조건을 확인하기까지 긴 탐색
기존 목록은 큰 사진 뒤에 일정·지역·반려동물 정보가 이어집니다. 돌봄에 참여할 수 있는지 판단하려면 사진뿐 아니라 세 조건을 함께 확인해야 하는데, 카드가 길어 여러 후보의 조건을 연속해서 비교하기 어렵다고 보았습니다.
설계 의도 / 지원 가능성을 먼저 판단
공간의 분위기를 보여주는 사진은 유지하되, 후보를 고르는 기준이 되는 일정·지역·돌봄 대상을 사진 옆에 묶었습니다. 매칭 상태는 별도 라벨과 탭으로 구분해, 조건의 적합성과 매칭 진행 상황을 각각 확인하도록 설계했습니다.
적용 / 매칭 상태와 상세 확인을 분리
전체·대기·진행중·완료 탭으로 탐색 범위를 나누고 각 카드에도 매칭 상태를 표시했습니다. 사진과 핵심 조건으로 후보를 비교한 뒤 옵션 더보기에서 추가 정보를 확인하도록 동작을 구분했습니다.
AS-IS
기존 서비스 화면
큰 사진 아래로 제목, 일정, 지역과 반려동물 정보가 이어지는 카드형 목록.
TO-BE
UI/UX 개선안
기본 호스트 목록입니다. 매칭 상태 탭과 사진 옆의 일정·지역·돌봄 대상 정보를 함께 배치했습니다.
02 / 시터 탐색
소개글을 읽기 전에, 신뢰 정보를 먼저.
문제 / 소개글만으로는 비교하기 어려운 신뢰 정보
기존 목록에서 바로 확인되는 정보는 프로필·국가·인증 여부와 소개글입니다. 소개글은 사람마다 내용과 길이가 달라, 돌봄을 맡길 후보를 같은 기준으로 비교하기 어렵습니다. 평점·보험·레퍼런스처럼 별도로 확인할 항목을 목록 단계에서 드러낼 필요가 있다고 판단했습니다.
설계 의도 / 확인된 정보와 자기소개를 구분
평점은 이름 가까이, 국가·보험·레퍼런스는 일정한 위치에 배치하고 소개글은 그 아래로 분리했습니다. 신원 인증과 미인증도 구분해 표시했습니다. 각 항목을 개별 판단 근거로 제시하되, 인증 하나만으로 돌봄 역량 전체를 보증하는 인상을 피하고자 했습니다.
적용 / 목록에서 비교하고 필요한 정보를 더 확인
카드마다 같은 순서로 정보를 배치해 후보 간 비교 기준을 유지했습니다. 옵션 더보기로 추가 확인 동작을 분리하고, 호스트·시터 선택 영역에는 ‘돌볼 집 찾기’와 ‘돌봐줄 시터 찾기’를 함께 적어 이용 목적에 맞는 탐색으로 진입하도록 했습니다.
AS-IS
기존 서비스 화면
프로필 사진과 국가, 인증 완료 표시 아래에 제목과 소개글을 보여주는 목록.
TO-BE
UI/UX 개선안
평점·국가·보험·레퍼런스 공유 여부를 프로필 가까이에 모으고 인증 상태를 구분했습니다.
03 / 리뷰 관리
리뷰를 모아 보는 데서, 역할별로 골라 보는 화면으로.
문제 / 리뷰의 대상과 맥락을 구분할 필요
기존 화면은 받은 리뷰·작성 리뷰를 나누지만, 목록 안에서는 후기와 세부 별점이 길게 이어집니다. 호스트와 시터 역할을 함께 사용하는 서비스에서는 누가 어떤 역할로 남긴 평가인지, 어떤 경험을 평가한 것인지 구분하는 정보가 중요하다고 보았습니다.
설계 의도 / 역할·작성 시점·평가 대상을 함께
받은 리뷰·작성 리뷰 구분은 유지하고 전체·호스트·시터 필터를 더했습니다. 카드에는 역할 라벨, 작성자, 작성일을 모으고 호스트·체류 평가를 탭으로 나눴습니다. 별점만 훑기보다 해당 평가의 대상과 맥락을 함께 읽도록 구성했습니다.
적용 / 공개 규칙을 화면에서 설명
작성한 리뷰가 바로 보이지 않는 상황을 이해할 수 있도록 상단에 공개 조건을 안내했습니다. 양측 작성 후 공개, 한쪽만 작성한 경우 7일 후 자동 공개, 제출 후 수정·삭제 제한을 한곳에 정리해 사용자가 현재 상태와 다음 단계를 해석할 수 있도록 했습니다.
AS-IS
기존 서비스 화면
받은 리뷰·작성 리뷰 탭 아래에 후기와 소통·신뢰·청결 등 상세 별점이 이어지는 화면.
TO-BE
UI/UX 개선안
공개 규칙 안내와 역할 필터를 추가하고 작성자·작성일·평점을 카드 단위로 정리했습니다.
04 / 멤버십 결제
멤버십 선택부터 입력·결제까지, 하나의 흐름으로.
선택 / 역할과 혜택을 비교
멤버십 플랜의 선택 상태와 신청 버튼을 구분하고, 선택한 플랜을 다음 결제 화면에서 다시 확인하도록 연결했습니다.
입력 / 결제 방식에 필요한 정보
계정 정보는 주문 요약으로 확인하고, 계좌이체에 필요한 입금 예정자명·요청사항은 별도 입력으로 구분했습니다. 카드 선택 시에는 해당 방식에 필요한 정보만 보여줍니다.
결제 / 선택한 방식에 맞는 안내
결제 수단을 화면 상단에서 선택하고, 계좌이체에는 입금 정보와 확인 요청 버튼을, 카드에는 주문 요약과 결제 버튼을 보여줍니다. 선택한 방식과 관계없는 입력을 덜어내 다음 행동에 집중하도록 했습니다.
MEMBERSHIP FLOW / 01
멤버십 고르기
기존에는 플랜마다 시작 버튼이 있고 지원하지 않는 플랜의 비활성 버튼도 함께 보였습니다. 개선안은 카드 선택과 신청 동작을 분리했습니다. 역할·혜택·연간 금액을 비교한 뒤 선택된 플랜을 확인하고, 마지막의 공통 버튼으로 신청을 시작하도록 구성했습니다.
AS-IS
플랜별 설명과 개별 시작 버튼
Host·Sitter·Linked Plan이 차례로 이어지는 기존 전체 화면.
TO-BE
플랜 선택 후 하나의 신청 동작
3종 플랜의 역할·혜택·가격과 선택 테두리, 하단 ‘멤버십 시작하기’까지 포함한 시안.
MEMBERSHIP FLOW / 02
신청자 확인과 입금 정보 입력
기존 정보 확인 단계에서는 계정 정보와 입금 예정자명·요청사항을 확인한 뒤 결제 단계로 이동했습니다. 개선안은 이미 등록된 주문자·이메일·연락처를 요약하고, 계좌이체에 필요한 입금 예정자명과 요청사항을 결제 방식 아래에 묶었습니다. 다른 이름으로 입금하면 확인이 지연될 수 있다는 안내도 입력란 바로 위에 배치했습니다.
AS-IS
별도 정보 확인 단계
신청 플랜, 이름·이메일·연락처, 입금 예정자명, 요청사항과 다음 단계 버튼.
TO-BE
계좌이체에 필요한 입력을 한 흐름으로
결제 수단 선택부터 주문 정보, 입력란, 입금·증빙 안내와 ‘입금 확인 요청하기’까지 전체 화면.
MEMBERSHIP FLOW / 03
선택한 결제 방식에 맞는 화면
기존에는 입금 안내 아래에 결제 수단이 있었고 카드·간편결제는 지원 예정으로 표시됐습니다. 개선안은 계좌이체와 카드를 상단에서 선택하게 하고, 카드 선택 시에는 이체용 입력란과 계좌 안내를 빼고 주문 정보·금액·결제 버튼에 집중하도록 설계했습니다. 실제 결제 연동 여부가 아닌 화면과 동작의 설계 사례입니다.
AS-IS
입금 안내 이후 결제 수단 확인
주문 요약, 입금 계좌·해외 결제·증빙 안내, 결제 수단과 요청 버튼이 이어지는 기존 화면.
TO-BE
카드 결제에 필요한 정보만
카드 선택 상태, 주문자 정보, 결제 금액과 ‘결제하기’ 버튼까지 포함한 전체 시안.
멤버십 흐름은 각 화면의 입력란과 하단 버튼까지 전체 길이로 표시합니다. 개인정보·계좌 정보는 공개용 예시로 대체했고 기획용 번호 주석은 제외했습니다. 플랜 금액과 결제 안내는 프로젝트 시안의 내용입니다.
AS-IS는 기존 서비스 캡처, TO-BE는 Figma 개선 시안입니다. 탐색·리뷰 이미지는 같은 높이로 맞춘 상단 영역이며, 멤버십 흐름은 단계별 전체 화면입니다. 예시 콘텐츠와 항목 수는 서로 다릅니다. 개선 사유는 화면 구조에 대한 분석과 설계 의도이며, 사용자 테스트나 운영 지표로 검증한 성과를 의미하지 않습니다.
HOUSE SITTING KOREASEARCH EXPERIENCE / FIGMA
01 / 조건 선택지역, 일정, 검색어와 반려동물 조건을 모은 검색 바텀시트02 / 결과 확인선택한 조건과 결과를 한 화면에서 확인하는 검색 적용 상태
실제 Figma 작업 화면 · 조건 선택과 검색 결과
LOCAL KNOWLEDGE
탐색 이후의 경험도, 이용자의 판단 순서에 맞게.
지역 정보를 찾고 공유하는 로컬팁 화면입니다. 실제 Figma 시안을 바탕으로 설계 의도를 정리했습니다.
05 / LOCAL TIPS
지역의 경험을, 찾을 수 있는 정보로.
탐색 기준 / 지역과 카테고리를 먼저
돌봄을 위해 낯선 지역에 머무는 이용자에게는 게시물의 인기보다 ‘내가 머물 곳에서 쓸 수 있는 정보인가’가 중요한 판단 기준입니다. 목록 상단에 지역·카테고리와 검색 진입을 모아 관심 범위를 좁힐 수 있게 설계했습니다.
정보 구조 / 사진과 글의 역할을 구분
사진은 장소의 분위기를 전달하고, 제목·요약·지역·카테고리는 실제 방문에 참고할 내용을 설명하도록 나눴습니다. 작성자와 작성 시점도 같은 위치에 배치했습니다. 사진이 없는 글도 제목과 요약으로 읽을 수 있도록 카드의 정보 순서를 유지했습니다.
참여 동선 / 읽기에서 경험 공유로
글쓰기 동작은 목록의 플로팅 버튼으로 분리했습니다. 정보를 찾아보던 이용자가 자신의 경험도 남길 수 있도록 진입점을 제공하면서, 게시물 제목과 혼동하지 않도록 아이콘과 강조색으로 구분했습니다.
로컬팁 목록 · 사진을 강조한 카드형 시안. 지역·카테고리와 작성 정보, 본문 요약을 함께 보여줍니다.
LOCAL TIPS / WRITE
지역 정보 입력부터, 경험을 공유하는 순간까지.
분류 / 검색에 쓰일 정보를 작성 단계에서
도·광역시를 선택한 다음 시군구를 고르도록 순서를 안내하고, 카테고리를 본문보다 먼저 배치했습니다. 작성자가 남긴 경험이 어느 지역의 어떤 정보인지 명확히 분류해 목록의 탐색 조건과 연결하도록 설계했습니다.
작성 / 구체적인 경험을 끌어내는 안내
제목과 본문을 나누고, 본문 입력란에는 숨은 맛집·이동 팁·추천 코스·피해야 할 점을 예로 들었습니다. 무엇을 써야 할지 막막한 이용자에게 작성 기준을 제공하고, 각 입력란의 번역 미리보기로 다른 언어에서의 표현을 확인할 수 있도록 구성했습니다.
등록 / 첨부 조건과 저장 목적을 구분
사진은 선택 항목으로 표시하고 최대 12장·10MB 제한과 업로드 개수를 첨부 영역에 안내했습니다. 하단에는 이어서 작성하기 위한 임시저장과 공개하기 위한 게시물 등록을 나란히 두되, 등록 버튼을 강조해 두 동작의 목적을 구분했습니다.
로컬팁 작성 · 지역·카테고리 선택, 제목·본문, 번역 미리보기, 사진 첨부와 임시저장·게시물 등록까지 포함한 전체 시안.
ADMIN / CONTENT OPERATIONS
운영자의 판단과 처리도, 화면의 흐름으로 설계.
로컬팁 관리 목록과 상세 화면을 연결했습니다. 검토할 게시물을 찾고, 원문과 신고 내용을 확인한 뒤, 공개 여부와 신고 처리 상태를 각각 기록하는 구조입니다.
06 / 관리 목록
‘보이는 게시물’과 ‘검토할 게시물’을 구분.
문제 / 공개 여부만으로는 알 수 없는 처리 상태
게시물이 공개되어 있어도 신고 검토가 진행 중일 수 있습니다. 공개·비공개와 신고 검토 대기·완료를 하나의 상태로 묶으면, 노출 여부와 운영자가 해야 할 일을 혼동할 수 있다고 판단했습니다.
설계 / 두 상태를 독립된 열과 필터로
공개 상태와 신고 상태를 별도 열로 나누고 각각의 필터를 목록 상단에 배치했습니다. 검토 대기는 강조색으로 표시해 다른 게시물과 구분하고, 카테고리·제목·내용·생성 일시를 함께 읽도록 구성했습니다.
운영 사례 / 검토 대상을 좁힌 뒤 상세 확인
신고 검토 대기 조건으로 대상 게시물을 추린 후, 제목과 내용 요약으로 맥락을 파악하는 흐름입니다. 공개 상태 변경 일시도 목록에서 확인할 수 있도록 두어, 현재 상태와 최근 변경 시점을 함께 판단하도록 했습니다.
로컬팁 관리 목록 · 작성자 이름·이메일·게시물 ID는 공개용 예시로 대체했습니다.
DETAIL / 상태의 분리
공개 상태는 노출 여부, 신고 상태는 검토 진행 상황.
같은 행에서 두 상태를 비교할 수 있습니다. ‘공개 + 신고 검토 대기’처럼 서로 다른 의미의 상태가 함께 존재하는 경우도 표현합니다.
목록의 상태 열을 확대한 이미지
07 / 관리 상세
신고 내용을 읽는 것부터, 처리 사유를 남기는 것까지.
정보 구조 / 요약 → 원문 → 신고 현황
게시물 기본 정보와 공개 상태를 먼저 확인하고, 본문·첨부 이미지와 신고 내용을 이어서 검토하도록 구획을 나눴습니다. 신고 주장과 실제 게시물 내용을 같은 상세 화면에서 대조할 수 있도록 구성했습니다.
처리 구분 / 공개 변경과 신고 검토를 각각
상단 요약에는 공개 상태 변경, 하단 신고 현황에는 신고 처리 상태 변경을 배치했습니다. 신고 검토 완료가 곧 게시물 비공개를 의미하지 않으므로, 두 판단의 입력 영역과 저장 동작을 분리했습니다.
입력 조건 / 사유를 입력한 뒤 저장
각 처리 영역에 필수 사유 입력과 처리 일시를 두었습니다. 상태와 사유가 입력되기 전에는 저장 버튼을 비활성으로 표현해, 변경 결과뿐 아니라 판단 근거를 남기도록 설계했습니다.
로컬팁 관리 상세 · 원문과 신고 현황을 검토하고 처리 사유를 기록하는 시안입니다.
DETAIL / 처리 조건
상태 선택과 필수 사유를 저장 동작 가까이에.
신고 내용 확인 후 처리 상태와 사유를 입력합니다. 회색 저장 버튼은 조건을 충족하기 전의 비활성 상태를 나타낸 실제 시안입니다.
신고 처리 입력 영역을 확대한 이미지
실제 Figma 어드민 설계 화면입니다. 기획용 번호 주석은 제외하고 식별 정보는 예시로 대체했습니다. 운영 기능의 구현·권한 검증 결과나 측정된 업무 효율 성과를 주장하는 사례는 아닙니다.
호스트·시터 탐색검색 필터로컬팁멤버십 가입리뷰·관리자상태별 컴포넌트
DESIGN DECISIONS
화면마다 필요한 판단을 명확하게 나눴습니다.
01 / SEARCH
역할을 고르고, 조건을 좁히는 탐색.
호스트와 시터 탐색을 상단 탭으로 나누고, 지역·일정·반려동물 조건은 검색 바텀시트에 모았습니다. 검색 후에는 적용한 조건을 목록 위에 보여줘 현재 어떤 결과를 보고 있는지 확인할 수 있도록 했습니다.
02 / MEMBERSHIP
플랜 선택부터 결제까지, 필요한 정보만.
역할과 혜택을 비교해 플랜을 고르고, 신청 정보를 확인한 뒤 결제 방식에 맞는 입력과 안내로 이어지도록 구성했습니다. 계좌이체와 카드의 입력 항목 및 버튼을 구분해 선택한 방식에 집중하도록 정리했습니다.
03 / OPERATIONS
보여주는 화면과 관리하는 화면을 함께.
리뷰 작성·상세·관리와 운영자의 매칭 로그를 연결해 정리했습니다. 관리자 목록에서는 공개 상태와 신고 상태를 별도로 표시하고, 사용자·멤버십 주문·로컬팁도 각각 목록과 상세 단위로 설계했습니다.
REUSABLE COMPONENTS
같은 행동에는 같은 화면의 언어.
사용자 화면과 관리자 화면의 버튼, 입력창, 모달, 내비게이션을 유형별로 분리했습니다. 버튼의 중요도와 비활성 상태, 아이콘 유무, 내비게이션의 선택 상태를 베리언트로 구성했습니다.
사용자 버튼 / 중요도 · 아이콘 · 비활성관리자 버튼 / 주요 · 보조 · 비활성내비게이션 / 선택 전 · 선택 후
SCREEN SPECIFICATION
화면에서 끝나지 않는 설계.
화면 ID와 기능 설명, 케이스별 동작, 확인 항목을 함께 정리했습니다. 기존 화면과 변경안을 비교하고, 조건에 따라 달라지는 상태를 구분해 구현 단계에서 확인해야 할 내용을 남겼습니다.
