Skip to content

UX Research

easylogic edited this page Sep 20, 2026 · 13 revisions

work_id: ux-research artifact_type: research_brief status: 미완료 owner_role: ui-ux-researcher source_request: "제품 사용성, 진행 방향, 공통 UI 범위를 지속 연구하고 필요한 과제를 이슈로 기록" last_updated: 2026-09-20

UI/UX 연구와 판단 기준

현재 역할의 최종 결과물은 사용자 검증 결과·주요 사용 장애·후속 검증 제안이다. 대상 사용자 관찰은 0건이며 기존 회차는 연구자의 합성 자료 점검이다. PM과 대상 사용자·핵심 업무·후보 버전을 맞춘 뒤 실제 관찰을 수행한다. 새 연구 결과는 개발 일정이나 출시 필수 조건에 자동 추가하지 않는다.

목표는 사용자가 도움 없이 자료를 만들고, 결과를 확인하고, 다시 찾을 수 있는지 확인하는 것이다. 기능 수나 화면의 통일감만으로 사용성을 판정하지 않는다. 현재 실제 사용자 관찰 자료가 없으므로 제품 전체의 사용성 합격 여부는 미검증이다.

기존 연구 운영을 따른다. 이 페이지는 UI/UX 연구의 질문과 공통 UI 범위만 관리한다. 고객군 선택은 #289, 업무 계측은 #297, 제품 회귀 검사는 #303에 연결한다.

현재 근거와 우선 검토 사항은 UI/UX 방향·공통 UI 판단표에 모았다. 기능 실행, 코드 확인, 다른 역할의 보고, 사용자 검증 가설을 구분한다.

공통 UI는 어디까지 설계할까

아래는 기존 패키지 경계를 바탕으로 한 연구 권고다. 구현 계약 변경이나 신규 패키지 승인이 아니다.

층 공통으로 맞출 내용 제품에 남길 내용
기본 표현 — office-ui / office-icons 색·타입·간격·포커스·버튼·입력·메뉴·대화상자·상태의 의미와 접근성 문서 본문 스타일과 제품 레이아웃
편집 연결 — office-controls / office-editor-ui 같은 명령의 이름·활성 조건 표현, 선택 변경 시 초안 처리, 적용·취소·오류·재시도 실제 편집 명령과 문서 모델
공통 작업 공간 — office-workspace와 제품 adapter 자료 정체성, 저장 위치와 상태, 자료함 복귀, 검색 범위, 참조·사본 구분, 복구 안내 제품별 파일·출력 형식, 저장 실행 책임
제품 작업 같은 기능은 같은 의미로 식별하고 결과를 확인할 수 있게 함 Note 블록, Word 페이지, Slides 캔버스·발표, Site 편집·미리보기·게시 구분

같은 기능을 일관되게 식별하면 기능을 다시 찾는 부담을 줄일 수 있다. 이는 모든 제품 화면을 동일하게 만들라는 기준은 아니다. W3C 일관된 식별 설명.

공통화 후보는 두 실제 사용처에서 사용자 의도와 상태 전이가 같은지 먼저 확인한다. 장애 시 정보와 복구 경로도 같아야 한다. 한 제품만의 요구는 해당 제품에 둔다. 접근성 결함은 사용처가 하나여도 수정 대상이다. 새 공통 부품이 필요하면 기존 갤러리에서 상태를 보여 주고 실제 제품에서 검증한다.

근거: 현행 디자인 기준, 공통 UI 점검, 작업 공간 경계.

연구 순서

질문 다음 방법 기록 상태
저장 위치와 저장 완료의 범위를 설명할 수 있는가 네 제품 정상 화면 비교 완료. 실패·충돌과 실제 사용자 이해는 후속 검증 UX-01 첫 관찰, UX-02 제품 비교, 제안 #306
자료함·최근 자료·문서 보관함의 이름과 목록 범위가 맞는가 범위·정렬 확인. Slides 최근 자료의 휴지통 항목과 일반 오류 재현 UX-03 관찰, #314
제품 보관함을 키보드로 닫으면 시작 버튼으로 돌아오는가 Slides·Site 실패 관찰. Word의 단일 정상 관찰과 PR #323의 실패 보고를 구분. 수정·재검증 대기 UX-04 관찰, #319
제품 메뉴에서 자료함으로 돌아가는 길을 찾는가 네 제품 정상 자료의 메뉴 키보드 복귀 확인. 처음 쓰는 사람의 발견성은 고객 연구에서 관찰 UX-05 관찰, #289 연결
제목에 없는 본문과 제품 필터로 자료를 다시 찾을 수 있는가 Note·Site 본문 검색과 빈 결과 초기화 확인. 실제 선택 정확성은 미검증 UX-08 관찰. 신규 이슈 없음
이름을 나중에 정해도 같은 자료로 이어지는가 Word 빈 이름·Site 공백 이름 생성 후 이름 변경·재열기에서 주소 유지 확인 UX-10 관찰. 동일 기본 이름의 구별은 미검증
백업 복원 전 결과와 잘못된 파일의 다음 행동을 설명하는가 새 사본·기존 자료 유지 안내, JSON 오류·선택 해제 직접 확인. 정상 복원·사용자 이해는 미검증 UX-11 관찰. 신규 이슈 없음
Site 원본 저장과 전달용 출력의 차이가 드러나는가 메뉴와 저장·페이지 출력 후 안내 확인. 실행 전 목적 이해는 미검증 UX-12 관찰. 신규 이슈 없음
Note와 Word 중 무엇으로 시작해야 하는지 아는가 같은 업무 설명에 대한 선택 이유와 첫 결과물 작성 관찰 #289 고객군·업무 선정과 연결
참조·사본·변환을 구분하는가 Note→Site 단순 문단 사본과 원본 참조의 실제 결과 확인. 사용자 예상은 미검증 UX-06 관찰, #291 보완. #292 변환은 미실행
실패 후 자기 작업을 보존하고 다시 진행하는가 Slides 다른 자료 열기 실패 뒤 재시도 대상 불일치 확인. 저장 장애·충돌 주입은 미실행 UX-07 관찰, #314 보완. #303 검사 정의 연결

새 자료 작성→편집→저장 확인→자료함 복귀→재열기를 첫 공통 여정으로 삼는다. 그 뒤 필요한 제품의 출력·발표·게시를 붙인다. 네 제품을 모두 거치도록 강제하지 않는다. 구현 우선순위는 입력 손실·작업 중단 문제, 상태와 복구, 첫 시작·탐색 순으로 제안한다. 예쁜 화면이나 새 부품의 수를 성과 지표로 삼지 않는다.

각 회차의 증거

  • 날짜·고정 commit·실행 버전·화면 크기·호스트·합성/실제 자료 여부를 남긴다.
  • 실제 화면 관찰, 코드 확인, 기존 검사 기록, 사용자 발언, 연구자 가설을 구분한다.
  • 단계별 기대/실제 결과, 가림 없는 스냅샷, 재현 경로를 남긴다. 고객 원문과 개인 정보는 공개하지 않는다.
  • 문제의 영향과 근거의 확실성을 별도로 쓴다. 작은 표본을 전체 사용자 비율로 일반화하지 않는다.
  • 이슈에는 목적·범위·완료 기준·검증·기존 이슈와의 차이를 쓴다. 구현 완료와 사용성 검증 완료를 구분한다.

이슈는 재현 가능한 문제 또는 명확한 검증 과제가 있을 때 만든다. 선택안의 비용과 결과가 달라 판단이 필요할 때 Discussion을 만든다. 같은 관찰을 5분마다 새 이슈로 만들지 않는다.

지속 실행

사용자 요청으로 이 Codex 연구 작업에 5분 간격 예약을 설정했다. 한 연구가 끝나면 UTC 완료 시각과 다음 질문을 기록한다. 완료 후 최소 5분이 지난 첫 예약 실행에서 다음 연구를 시작한다. 정확히 완료 시각 +5분을 보장하는 타이머는 아니다. 실행 환경이 사용 가능해야 한다.

매번 최신 이슈·PR·댓글과 연구 기록을 확인한다. 진행 중인 연구는 재개한다. 새 근거가 없으면 조용히 종료한다. 모바일 화면 검사는 별도 요청 전까지 제외한다. 사용자 모집·외부 연락을 자동 실행하지 않는다.

Clone this wiki locally