기획

기획서(스토리보드) 작성 방법 | 03 - IA (Information Architecture)

mk(엠케이) 2021. 2. 27. 15:36

연관 글

 

 

IA (Information Architecture)란

  • 서비스를 기획함에 있어 IA는 기획자의 설계 구조를 전반적으로 정리하는 문서로 이해하면 될 것 같습니다.
  • 서비스 구성요소를 단계적으로 표기하며 해당 단계에서 제공되는 기능 및 정보를 정리할 수 있습니다.
  • 작성자의 경우 상세 기획 이 전 이 단계를 필수적으로 거치며, 이 안에서 대부분의 흐름을 파악하는 용도로 사용됩니다.



IA 구성요소

작성자, 회사, 서비스 특성에 따라 다를 수 있으나 작성자의 경우 아래와 같은 구성요소를 기준으로 작성합니다.

1. Role (권한/역할)
2. Type (플랫폼) 
3. Depth (진입 단계)
4. Component (구성요소)
5. Description (개요 및 설명)
6. Featured (기능)
7. Data (활용 데이터)
8. Comment (기타 참고사항 비고)

상기 내용 외 페이지 제목, 페이지 타입(팝업, 전체 페이지, 메일 등) 등 기타 요소가 포함될 수 있으나
개인적으로 이 는 IA 문서의 특성상 초기에 정의된 후 충분히 변동 될 가능성이 있음에 따라 포함하지 않는 편입니다.


IA문서 작성의 목표

  • 결과적으로 IA 문서는 아래와 같은 목표를 가지고 작성됩니다.

  • 기획자

    • 목표
      • 기획과정에서 전체적인 설계 정리
      • 설계 결과에 대한 흐름 검토
    • 효과
      • 데이터의 흐름을 선행검토 하고 데이터가 어디에서 생성되고 가공되는지에 대한 누락을 줄일 수 있습니다.
      • 이 후 상세 기획 과정에서 작성되어야하는 기획요소를 1차적으로 정리할 수 있습니다.
  • 협업자

    • 효과
      • 서비스 내 구현해야하는 (디자인, 개발 등) 기능 선행 검토가 가능합니다
      • 기능 검토에 따른 일정산출이 용이해집니다



IA 작성 방법

  • IA에서 주요하게 생각해야하는 부분은 프로세스(흐름)입니다.
    프로세스에 따라 depth를 설정하고 해당 단계에서 할 수 있는 행위를 정리하는데 초점을 두고 진행 할 수 있습니다

  • 두번째로 겹치지 않으면서 빠짐없이 나누는 방법을 꼭 염두해야합니다.

    물론 depth 단위로 진행하다보면 겹치는 영역이 나올 수 있으나 이는 프로세스를 전환 또는 연결하는 과정임에 따라 해당 내용을 명시합니다

  • 각 단계의 행위를 위해 필요한 구성요소를 나열해겠습니다

아래는 토이프로젝트로 진행하는 스터디 매칭 플랫폼의 예시입니다.


링크로 보기 : 구글 스프레드시트 새 창으로 열기





상기 예시를 참고하여 각 단계별 상세 내용을 적는 방법을 풀어보겠습니다

  1. Role (권한/역할)

    • 내용
      • 서비스를 이용하는 큰 단위의 역할을 작성합니다
      • 시스템 관리자, 일반 관리자, 사용자를 포함하여 B2B 서비스에서는 클라이언트, 영업 담당자, 회계 담당자 등 여러 유형이 존재할 수 있습니다.
    • 효과
      • 서비스의 권한이 어떤 형태로 구분되며 각 권한별 역할을 설계할 수 있습니다
  2. Type (플랫폼)

    • 내용

      • APP 또는 WEB 등 해당 행위가 이루어지는 환경을 작성합니다
    • 효과

      • 각 행위가 이루어지는 플랫폼을 설계할 수 있습니다
      • 이 과정에서 웹에서만 사용되거나 또는 앱/웹 모두 사용되어야 하는 기능을 검토 할 수 있습니다
  3. Depth (진입 단계)

    • 내용

      • 각 행위가 이루어질 수 있는 단계를 작성합니다.
      • 필요하다면 3rd 이 후 depth를 추가할 수 있습니다
    • 효과

      • 이 과정을 통해 개략적인 프로세스 설계가 선행될 수 있습니다
  4. Component (구성요소)

    • 내용

      • 각 단계의 행위를 위해 필요한 구성요소를 작성합니다
      • 이때 UI 상 즉, 화면구성을 상상할 수 있도록 기준하여 버튼, 내용, 입력필드 등을 작성할 수 있습니다
    • 효과

      • 그려질 화면을 개략적으로 설계할 수 있으며, 추 후 상세 기획 작성 시 용이하게 활용될 수 있습니다
  5. Description (개요 및 설명)

    • 내용

      • 실질적으로 이루어지는 행위에 대해 작성합니다
    • 효과

      • 기 작성한 서비스 목표에 부합하기 위한 과정이 누락되지 않는지에 대해 검토할 수 있습니다
      • 프로세스 상 끊기는 흐름이 없는지에 대해 검토할 수 있습니다
      • 개발 검토를 포함한 일정 산출 시 기능 별 작업사항(TASK)를 개략적으로 유추할 수 있습니다
  6. Featured (기능)

    • 내용

      • 해당 행위가 이루어지는 depth/화면에서 제공되는 기능 전반을 작성합니다
    • 효과

      • 해당 행위를 명확하게 수행할 수 있는 기능의 설계요소를 검토할 수 있습니다
      • 개요와 마찬가지로 개발 검토를 포함한 일정 산출 시 기능 별 작업사항(TASK)를 개략적으로 유추할 수 있습니다
      • Component(구성요소)와 매칭하여 기능에 대한 구성요소 수립 여부, 반대로 구성요소에 따른 기능 수립 여부를 러프하게 검토할 수 있습니다
  7. Data (활용 데이터)

    • 내용

      • 해당 행위가 이루지는 화면의 구성요소에 적용되는데 사용될 수 있는 데이터를 작성합니다
      • 예시로 '회원 내 성비 통계'화면을 구성한다면 전체 회원 수 카운트 , 남성 회원 수 카운트, 여성 회원 수 카운트 가 들어갈 수 있습니다.
      • 이 경우 추 후 상세 기획 작성 시 공식을 수립하는데 용이해 질 수 있습니다
        • 예시 (총 회원 수 : 150 명 , 남성 회원 수 : 60)
          • 공식 : 남성 비율 = (남성 회원 수 카운트 / 전체 회원 수 카운트) * 100
          • 표기 : 40% => (60/150) * 100)
    • 효과

      • 제공하고자 하는 기능 또는 UI component에 사용되는 데이터가 생성되고 제거되는 시점을 검토 할 수 있습니다
      • 개략적인 데이터 흐름을 검토/예상 할 수 있습니다
    • 비고

      • 작성자의 경우 주관적인 Database 내 Table 명을 기준으로 작성하였습니다
      • 해당 데이터는 기획자의 설계에 사용되는 데이터로 다른 구성원에게는 노출되지 않아도 무방합니다
  8. Comment (기타 참고사항 비고)

    • 내용

      • 설계 과정에서 참고되어야하는 참고사항을 작성합니다
      • 간단하게는 상세 기획 시 설정되어야 하는 메모로 사용되어도 무방합니다
    • 효과

      • 작성 내용을 통해 초기 설계 과정에서 모호하거나 정의되기 어려운 사항을 상세 기획 시 누락 없이 검토할 수 있습니다


        정리

IA 는 기획의 가장 큰 설계를 위해 작성합니다

  • 기획자가 상세 기획을 하는 과정에서 모든 걸 생각하고 기억하기는 어려울 수 있습니다.
  • 이러한 휴먼리스크를 감소하기 위해 rough(러프) 하게나마 메인 설계를 하며, 이 후 상세기획 및 기타 정책 수립에 있어서 지속적으로 활용 및 업데이트 되어야 하는 문서입니다.

IA 문서의 형식은 정해져있지 않다

  • IA 문서는 오랜시간 IT 서비스 기획이 이어짐에 따라 어느정도 템플릿이 정형화 되었습니다.

  • 다만, 공유 대상 및 기획자 성향에 따라 comment, data, depth등의 항목은 유동적으로 변경 또는 사용하지 않아도 무방합니다.

    • 가장 중요한 포인트는 기획자의 큰 설계를 위해 작성되는 것을 다시 한 번 더 상기하시면 좋을 것으로 보입니다


      이어지는 글

  • 이어지는 글에서는 주요 서비스 프로세스(Main Process)에 대해 작성될 예정입니다


    본 블로그 글은 작성자의 기준에서 작성된 내용이며 참고용으로만 이용해주세요