brunch

You can make anything
by writing

C.S.Lewis

by 이안 Aug 11. 2020

3명을 위한, 디자인 매뉴얼 제작기-2

지난 1편에서는 매뉴얼을 만들게 된 계기, 대략적인 구조, 후기 등의 성격으로 글을 남겼다면,

이번 2편에서는 실질적으로 어떻게 사용하고 있는지를 보여드리고자 합니다.


그중 가장 신경 쓴 건 총 4가지 부분입니다!

  

1. 업무 분류별 프로세스 및 정보 기록

2. 폴더링 및 파일 트리 구분

3. 컨펌 및 공유 프로세스

4. 업무 진행 현황 및 히스토리 파악



1. 업무 분류별 프로세스 및 정보 기록

앞편에서 말했듯이 업무 분류는 크게 R&R 기준으로 분류가 되어있고, 각 분류별 해당하는 업무로 나누어져 있습니다.

(업무 분류 구성)


각 분류 안 업무들은 아래 형식의 맞게 내용이 작성되어 있습니다.

(업무 추가 시 작성해야 하는 템플릿)

제목

별거 있나요, 업무명을 적습니다.


개념, 정의, 소개

간단한 업무에 대한 설명을 적습니다. 보편적인 업무(마케팅, 광고 등) 이외의 저희 사업상, 내부에만 있는 업무 들도 있어서 간단한 설명은 필요했습니다.


주기 및 관련 부서

업무의 빈도수와 주로 어떤 부서와 소통해야 하는 지를 적습니다.


관련 디자인 업무

관련된 디자인 업무 등의 종류 등을 적습니다.


세부내용

보통 이 부분에 업무 관련된 진행 프로세스나 인쇄 관련이나, 관련 참고 옵션 등을 적습니다.


관련 링크

관련 파일 드라이브 폴더나, 관련 시트, 관련 업체 링크 등을 기재합니다.


주의사항 및 기타

추가 진행하면서 더 빠르게 처리할 수 있는 노하우나

특이사항, 특히나 신경 써야 하는 부분 항목 등을 보통 적습니다.


(실제 사용하는 스플매거진 업무 예시)

저희는 스플매거진 관련 업무를 위에 형태로 정리하고 있습니다.(가장 간략한 버전)

웹이나 발주 관련된 부분은 더 내용이 확실히 많고요.


해당 형태로 기록했을 경우,   

모든 업무의 프로세스 및 정보가 기재되어 갑작스러운 담당자 공석에도 업무의 연속성을 유지할 수 있습니다.

추가 신규 업무 발생 시 관련 기준에 맞게 업무 규격화 및 파일 템플릿 화를 빨리 적용할 수 있습니다.

제 마음이 편해졌습니다^^.. 업무의 큰 판이 그려지고 각각 항목의 맞게 정리가 되어 있다 보니.. 마음이 편해졌습니다...



2. 폴더링 및 파일 트리

이 또한 업무 분류 기준으로 업무별 어떤 파일을 저장해야 하는지 간략한 설명을 적고, 폴더별 구분 기준도 정해 놓았습니다.

예를 들어 웹의 경우 구성 페이지 별로 구분이 되어 있어야 히스토리 파악이나 관련 파일 찾기가 편하기 때문에, 크게는 날짜별 구분 후 안에는 지점 / 서비스 / 혜택 등 페이지 별로 파일을 관리하고 있습니다.

시설이나 운영 등과 같은 업무는 프로젝트 건마다 지점별 히스토리가 중요하기 때문에 프로젝트 - 지점별로 관리 기준을 잡았습니다.

파일명 구성은 슬로워크의 글과 플러스엑스 강의 중 내용을 참고해서 지정하였는데,

기본적으로 <날짜_프로젝트명_세부사항>을 기준으로 잡고 1개 프로젝트 기준 가장 많은 파일 생성되는 상황을 기준으로 잡았습니다. 이 외의 디테일한 부분 및 예외 규칙도 기록하여, 기준과 다르게 추가로 생기는 사항도 정리해 갈 수 있는 규칙을 만들어 가고 있습니다.

(파일명 기준)



3. 컨펌 및 공유 프로세스

기존에는 작업을 공유하고 컨펌하는 과정에도 명확한 프로세스가 존재하지 않았다 보니 디자인 톤, 퀄리티 등의 문제 혹은 컨펌을 받는 과정에 있어서 불필요한 요소들이 많더라고요. 컨펌이나 공유하는 과정에서는 정말 불필요한 프로세스만 없게 하기 위해 순서 정도의 간단한 기준만 정하였습니다.

(불필요한 프로세스를 없애기 위해 또 다른 불필요한 기준이 생기고 싶게 하진 않았거든요)


그 외에 굳이 컨펌 등이 필요 없는 반복 작업(명함이나, 로고 리사이징, 텍스트만 변환하는 작업) 등은 별도 프로세스 과정을 만들지는 않았습니다.


단 하나, 기준을 강조해서 추가한 건   

1차 시안은 1가지 항목에 대해 70% 정도 완료 후 공유
완성된 디자인으로, 모든 베리에이션 작업 후 공유하게 되면 수정 요청 시 시간 소모가 많으며, 수정 요청해야 하는 입장에서도 요청에 부담이 된다(좋은 방향임에도 불구하고)

이 부분이었습니다. 수정을 요청해야 하는 팀에서 주신 피드백이었는데 제가 생각지 못한 부분이었습니다. 피드백도 상대 입장에서 생각해 보아야 하는 의미가 담긴 항목이겠네요.



4. 업무 진행 현황 파악 및 히스토리 파악

기존 디자인 파트 위클리는 워드에 업무 분류별로 그 주 이슈를 써 내려가는 형태였는데 기존 타 팀에서 사용되던 형식을 그대로 가져온 거라 디자인 파트에 딱 맞지는 않았습니다.

디자인 파트에서는 진행 상황, 담당자, 업무 분배 등의 확인 목적이 더 크기에 아래와 같은 형태로 사용하고 있습니다.

(진행 현황별 / 작업자별 보기)

크게 진행 현황별 / 작업자 별 보기로 분류를 하여 이번 주에 진행되는 업무 파악과 담당자별 업무량을 확인하고 특정 인원에서 업무가 몰려 있으면, 서포트를 진행하는 식으로 활용하고 있습니다.


각 프로젝트 보드 별 상세 내용은 아래 사진과 같이 구성되어 있습니다.

(실제 위클리 업무 작성법에 있는 내용입니다)

작업 요청자 - 해당 업무 담당자와 바로 소통하기 위해

요청 마감 기한 - 실제 요청한 마감 기한에 끝냈는지

기획안 링크 - 업무 관련 기획 및 수정 내용 확인이 바로 필요할 때

드라이브 링크 - 시안 및 최종 파일 바로 확인을 위해

리스트 및 일정 - 해당 업무 진행이 어떻게 되었는지 파악하기 위해

기타 - 기존 업무 매뉴얼과 다르게 진행된 점이 있거나, 해당 업무 시 유의 사항 등을 알려줘야 할 때


등을 한 보드 안에서 확인할 수 있도록 작성해 가고 있습니다.




대략적인 저희가 사용하는 매뉴얼은 이 정도입니다.

사실 저도 아직 주니어이기에 이런 내용을 쓴다는 것 자체가 부담스럽기는 했지만 그래도 팁을 드리자면!


1. 이왕이면 실무자가 매뉴얼을 만드는 것이 좋다.

실제 업무를 하면서 가장 좋은 프로세스를 무엇일지, 어떤 부분에 문제가 있는지 등 해당 업무에 있어서 어떤 오류가 있는지를 가장 잘 아는 사람이기 때문에 실무자가 매뉴얼을 직접 만드는 것이 가장 좋다고 생각합니다.


2. 완벽하게 만들려는 목적? 생각? 을 줄이자.

저는 사실 완벽주의 성향이 강하고, 실패를 두려워하기도 합니다. 그러다 보니 매뉴얼 구상은 오래전에 했지만, 실행에 옮기기까지는 많은 시간이 걸렸습니다. 그리고 그렇게 해서 만든 매뉴얼을 실제 사용해 보니 오히려 비효율적인 부분이 보이거나, 보완이 필요한 부분도 점점 많아져 갑니다. 그럼에도 일단 만들어 놓으니, 효율성이 많이 올라갔습니다. 일단 지르세요! 만들고 보완해도 꽤 괜찮은 방법입니다. (물론 전 그렇게 못했지만요..^^)


린 매뉴얼 만들기

저는 매뉴얼을 만들고 난 후 해당 글을 보았는데, 매뉴얼을 만들기 전 참고하면 좋을 것 같습니다!     


저는 어찌 되었든 브런치 혹은 다른 글을 통해 많은 도움을 받아 만들었기에,

단 1명의! 실무자라도 도움을 받을 수 있다면 이 글의 목적은 달성했다고 생각합니다.




1편 보러가기 ▼

https://brunch.co.kr/@2an/4


브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari