슾이 지은 고봉밥

인하우스 서비스 기획 업무를 하다 보면 디자이너 없이 기획자가 화면을 빠르게 그려야 하는 상황이 자주 생긴다. 초기 기획 단계에서 빠르게 아이디어를 시각화해야 하거나, 디자이너 리소스를 확보하기 전 구조를 미리 정의해야 하는 경우가 그렇다.이때, 피그마(Figma)는 기획자에게도 충분히 활용 가능한 화면 설계 도구다. 별도의 설치 없이 웹에서 사용할 수 있고, 협업과 버전 관리에도 강점을 갖고 있어 실무에서 유용하다.이 글에서는 기획자가 피그마를 활용해 효율적으로 화면을 설계할 수 있는 실질적인 팁들을 정리하려고 한다.1. 템플릿이나 컴포넌트 없이, 기본 도형으로 시작하자화면 설계의 목적은 시각적으로 예쁜 디자인이 아니라, 화면의 구조와 기능 흐름을 정의하는 것이다. 따라서 기본 도형(Rectangle)..

지난 통합테스트 시나리오 작성 방법 첫번째 글에 이어 두번째 내용이다.첫번째 문서 생성과 구성에 대한 내용은 아래 글을 참고하면 된다.https://soupsrice.tistory.com/31 기획자 QA - 통합테스트 시나리오 작성 방법 (1)오늘은 테스트 단계인 통합테스트 문서 작성 방법 중 문서 구성에 대한 내용이다.테스트 세분화 시 통합테스트 외 단위테스트, 인수테스트 등이 있지만그 중 필수로 수행되는 통합테스트에서soupsrice.tistory.com 오늘은 통합테스트 시나리오 작성에 대해 좀 더 자세히 설명해 보려고 한다.  통합테스트 시나리오 작성 방법통합테스트는 앞의 설계 단계에서부터 정의된 내용이 여러 환경(연동 솔루션, api, 연계 데이터 등)에 정상적으로 구현이 되었는지 모든 상황을..

오늘은 테스트 단계인 통합테스트 문서 작성 방법 중 문서 구성에 대한 내용이다.테스트 세분화 시 통합테스트 외 단위테스트, 인수테스트 등이 있지만그 중 필수로 수행되는 통합테스트에서 요구사항 및 설계를 담당한 기획자가 테스트시나리오 케이스를 작성하는 경우가 많다.진행하는 프로젝트 상황에 따라 테스트시나리오는 알맞게 변경해 작성한다는 점을 참고하면 좋을 것 같다.  1. 통합테스트 시나리오 문서 생성 1) 엑셀 사용정해진건 아니지만 통합테스트 시나리오의 문서 형식은 주로 엑셀을 사용한다. 상황에 따라 내용이 많아지고, 통계 기준 결과 분석을 진행하기 용이하기 때문이다.2) 테스트 수행을 위한 준비물을 하나의 문서로 구성설계 내용 외 테스트를 수행하기 위해 필요한 모든 데이터, 버전 관리 등 테스트 케이스를..

최근 한 프로젝트를 수행하면서 생각했던 UX 라이팅 업무와 달랐던 점을 공유하려고 한다.이미 많은 온라인 상의 가이드, 아티클, 도서를 통해 UX 라이팅에 대한 중요성과 작성 방안이 소개된다.적용될 브랜드의 이미지와 서비스 이용자들에 맞게 서비스 용어 통일, 추구하는 말의 분위기, 해당 브랜드만의 문구 작성 가이드 등 기준을 세우고 지켜가야 한다. 생각했던 업무와 달리 들어가고 나서 아래와 같은 경우들이 있었다. 1. 모두 토스처럼 UX 라이팅에 대해 고민하지 않는다.담당 UX 라이터가 있었고 임원들 또한 해당 업무에 대한 보고를 받지만, 담당자 외 UX 라이팅에 대한 중요성이나 가이드라인을 살펴보지 않았다.회사에서는 본인에게 주어진 업무를 수행하는 것이 중요하다.그래서 서비스에 적용되는 UX 라이팅에 ..

요구사항정의서는 회사 혹은 프로젝트 규모에 따라 조금씩 변형하여 작성하기 때문에내 기준 서비스 규모에 따라 요구사항 정의서를 그에 맞게 적용한다.이번 글은 규모가 크거나 요구사항 목록이 많을 경우 사용하는 예시이다. 작성 예시 2 위의 양식의 경우는 진행할 개발의 최종 비즈니스 목표와 같이 직무와 상관없이 공통으로 참고해야할 요구사항도 표 윗부분에 추가되어있다.예시와 같이 한 시트에 작성하거나 표지처럼 나누어 작성하기도 한다. ID: 요구사항정의가 완료되고난 후 해당하는 ID를 부여하여 적는다.구분: 사용자와 관리자로만 나뉜 서비스가 아니라, 여러 시스템을 연계해서 프로젝트를 진행하는 경우가 있다. 이때 공통, 사용자, 관리자 시스템 1, 관리자 시스템 2와 같이 구분하여 작성한다.서비스(메뉴): 해당 ..

요구사항 정의서는 서비스 개선 혹은 구축 전 이해관계자들과 협의된 내용들을 적는 문서이다.해당 문서에 명시된 내용들은 모두 협의된 내용이기에 프로젝트 초기 설계부터 테스트가 완료되는 시점까지 지속적으로 참고한다. 서비스(혹은 프로젝트) 규모에 따라 작성 범위가 다르다.사용자 중점 기능들 위주로 적고 비기능적 요소(보안, 품질, 시스템 효율 등)은 필수적인 것들만 적거나,사용자 중점의 기능적 요소와 비기능적 요소 모두를 구체적으로 적는 경우도 있다.해당 문서는 워터폴 방식 프로젝트의 경우 설계 이후 단계에서 수정하기 어렵기 때문에 명확하고 자세히 적는 것이 좋다.(애자일 프로젝트의 경우는 지속적으로 요구사항을 변경될 수 있다.)보통 회사에서 필요로 하는 요구사항정의서는 명확하게 작성되어야 추후 이해관계자들..

서비스 설계 단계에서 요구사항을 기반으로 한 구조를 짤 때 IA를 작성한다.IA를 요구하지 않는 곳도 있지만 나의 경우는 내 스스로의 대략적인 구조를 짜거나 변경하기 위해 항상 작성하는 편이다.오늘은 기획 단계에서 중요한 IA를 작성하는 방법과 어떻게 이를 다음 단계로 이어가면 좋을 지에 작성해 보려고 한다.명확한 정답은 없으나 대략적인 방법을 알고 이를 본인의 회사, 프로젝트 환경에 맞게 변형하여 적용하는 것이 좋다. Information Architecture 란?서비스(웹/앱) 구축 시 필요한 화면과 메뉴의 정보 구조를 설계하는 문서정확한 정의나 뜻은 위와 같지만 설명을 추가하자면 내가 구상한 서비스 혹은 요구사항으로 받은 서비스에큰 틀을 짜기 위한 문서다.사이트를 예로 들자면 보통 대메뉴(GNB)..