작성일: 2024-07-26

# 디자인 프로세스 정립을 위한 리서치

**목적:** 디자인 업무 프로세스의 정립을 위한 리서치

**내용:** 여러 방법론과 도구를 참고하여 과정을 정리하고, 그 내용을 현재 버전의 방화벽 제품에 적용해보는 테스트를 진행.

**사용:** perplexity, 파이어플라이, Clarity

내부 제품을 사용하여 진행했던 작업이므로 블로그에는 실제 제품과 관련된 내용은 제외하고 작성하였습니다

—

‘듀얼 트랙 프로덕트 디자인’에 내용을 작성해보고, 디자인 실무에서의 유효성을 판단해보고자 함. 특히 이 테스트의 대상인 페이지는 ‘방화벽 정책 신청’이며 내가 디자인 해본적이 없는 분야라 최소 정보에 대한 이해가 필요하여 진행.

---

## 1. Define

### 1.1. 리서치

방화벽의 성장, 방화벽을 도입한 기업의 특징, 방화벽의 주요 유형

듀얼 트랙 모델에서 리서치는 스프린트0 단계에 해당한다. 리서치는 대화형 ai 서비스인 ‘perplexity’를 사용하여 작성했고, 이 내용은 프로젝트의 디자인 기획 단계 뿐만 아니라 도메인에대한 지식과 경험이 전무한 사람이 접근할 때 도움이 될 수 있다.

### 1.2. 사용자

기업에서 방화벽 정책을 신청하는 사람은 주로 네트워크 관리자, 시스템 관리자, 보안팀 담당자라고 정리했다. 그리고 사용자의 사용 흐름을 더 정확하게 정의하기 위해 네트워크 보안의 주요 업무와 일상 업무를 간단하게 조사하는 것과 함께 파이어플라이를 통해 이미지 생성을 시도했다.

**특징:**

남성 / 현대적인 사무실 / 네트워크 보안 담당자 / 남자는 컴퓨터 앞에 앉아서 키보드를 타이핑 하고 있고, 모니터에는 복잡한 네트워크 트래픽 데이터와 보안 로그가 표시되어 있음 / 전문적이고 신뢰할 수 있는 이미지

**컨텍스트:**

   – 강화되는 보안 감사에 대한 부담감

   – 사람에 의한 보안 정책 운영/관리에 어려움을 느낌

   – 정책은 증가하는데 전문 인력은 항상 부족함

   – 정책 관리 업무의 과부하로 발생할 수 있는 보안 위협에 적극적인 대처가 어려움

   – 방화벽 정책 솔루션을 통해 정책과 정비 이력을 쉽게 관리하고 업무의 효율성을 높이고자 함

### 1.3. 사용 흐름에 대한 이해

**신청 이유**

– 네트워크 관리자: 새로운 서비스나 시스템이 도입될 때 보안 규정을 준수하기 위함

– 시스템 관리자 또는 개발자: 특정 서버나 애플리케이션에 대한 접근 권한이 필요할 때 신청하기 위함

– 보안 팀: 보안 정책을 업데이트하거나 개선하기 위함

**신청 과정**

– 요청 작성: 정책 변경 요청서를 작성. 여기에는 변경하고자 하는 정책의 세부 사항(예: IP 주소, 포트 번호, 프로토콜 등)과 변경 이유가 포함된다.

– 승인 절차: 보안 팀 또는 IT 운영팀에서 요청을 검토하고 승인 여부를 결정. 필요할 경우 상위 관리자의 승인을 받을 수도 있다.

– 정책 적용: 요청이 승인되면 네트워크 관리자가 방화벽 설정을 변경하여 새로운 정책을 적용한다.

– 테스트 및 모니터링: 변경된 정책이 제대로 적용 되었는지 테스트하고, 문제가 없는지 지속적으로 모니터링한다.

## 2. 사용자 테스트

UT는 프로젝트의 마지막 단계에서 진행하는게 일반적이지만, 기존 제품의 업데이트와 개선점을 찾고 디자인 프로세스에 반영하기 위한 프로젝트이므로 퍼소나 정의 이후에 바로 시도해보기로 했다. 그리고 현재 제품 버전에서의 UT를 기반으로 유저 저니맵 또는 유저 스토리를 작성한다. 다만 UT 전문 서비스가 대부분 유료 서비스를 제공하고 있기 때문에 테스트 목적인 지금 시점에서는 무료로 제공되는 마이크로소프트의 Clarity를 사용했다.

– 대표적인 UT도구: Maze, Amplitude

– 무료 서비스: google optimize, hotjar, userTesting, UsabilityHub, CrazyEgg, Microsoft Clarity

### 1.1. 마이크로소프트 Clarity

**제공 기능:** 세션 녹화, 히트맵, 인사이트, 필터 및 세그먼트, 비정상 행동 감지, 대시보드

clarity에서는 녹화된 영상을 다시 돌려보면서 사용자가 서비스를 이용하는 맥락을 파악할 수 있다. 회사에서 서비스중인 보안 솔루션은 기업 내부 IP를 쓰기 때문에 일반 UT도구로 접근 할 수 없었다. 그래서 테스트용 사이트를 만들고 clarity 소스 코드를 수동으로 넣고 기능을 체험하는 정도로 사용 해보았다.

### 1.2. 실제 제품 유저 테스트

이 제품을 처음 사용하는 사용자가 매뉴얼(v3.0)을 읽으며 페이지에서 아래 과정을 직접 조작해보도록 했다.

**신청**

   – 정책 신청자: 신청서 작성 – 결재 요청 – 신청 현황 확인 – 완료

   – 신청 부서 결재 책임자: 결재함 확인 – 결재 – 결재함 – 완료

**관리**

   * 방화벽 운영자: 신청 현황 – 관리자 지정 – 승인 요청 – 할당 신청서 확인 – 할당 신청서 승인 – 정책 설계 – 작업 완료

   * 보안 관리자: 승인 대기함 확인 – 결재 – 신청 현황 승인 완료 – 신청서 완료 대기(작업 완료 확인) – 작업 완료 확인 – 완료

**테스트 방식(로컬 주소 접속 – 사용 과정 녹화):**

   로컬 주소 접속이라 계획했던 UT 도구의 사용은 불가능하므로 수동으로 시도

**결과**

  – 소요 시간: 로그인부터 목표 수행 완료까지 걸리는 시간

  – 정책 신청자

    성공 여부: 성공

    수행 내용: 신청서 작성

    소요 시간: 3분 40초

  – 결재 책임자

    성공 여부: 성공

    수행 내용: 신청서 결재

    소요 시간: 1분 10초

  – 운영자/관리자

    성공 여부: 실패

    수행 내용: 승인 및 정책 설계

    소요 시간: 7분 20초

### 1.3. 유저 저니맵

– 정책 신청자

   **유저 액션:** 방화벽 정책 신청

– 결재 책임자  

   **유저 액션:**새로 올라온 신청서를 확인하여 결재 또는 반려 처리

### 1.4. 사용성 평가

사용성 체크는 ‘전자정부 웹사이트 UIUX 가이드라인’ 의 웹 설계평가 부분을 참고하여 메뉴, 브레드크럼, 검색 목록, 등록, 로그인/인증, 신청서 작성, 내역 확인/취소, 모달, 확인, 오류, 도움말에 대해 평가했다.

> **평가 예시:**

> 검색 결과가 없을 때는 사용자에게 결과를 명확하게 알리고 적절한 대안을 제공하나요? [X] → ‘데이터 없음’ 문구가 표시 되지만 대안은 제공하지 않음

### 1.5. Task

마지막으로 저니맵과 사용성 체크를 통해 확인한 이슈 중에서 우선 순위로 정한 task를 정리하여 문서화했다. (테스트에 성공한 신청 페이지 중심으로)