문제 정의부터 결과까지 살펴보는 프로젝트

프로젝트를 읽는 기준

포트폴리오를 볼 때는 문제 정의, 접근 방식, 결과 세 가지를 나눠서 봅니다. 문제 정의가 없으면 화면만 보고 판단하게 되고, 그 판단은 실제 프로젝트에서 잘 맞지 않습니다. 접근 방식에서는 어떤 제약을 어떻게 처리했는지가 드러납니다. 결과는 기능이 아니라 사용 흐름이 어떻게 바뀌었는지로 확인합니다.

이 세 축을 기준으로 아래 프로젝트 유형을 정리했습니다. 유형마다 먼저 확인해야 할 문서, 결정이 늦어지면 손해가 커지는 지점, 출시 이후까지 이어지는 관리 범위가 다릅니다.

웹 디자인 프로젝트

디자인 프로젝트는 정보 구조 정리에서 시작합니다. 와이어프레임으로 흐름을 잡고 프로토타입으로 검증한 뒤 시각 디자인을 얹습니다. 디자인 시스템을 함께 만들면 이후 화면 추가가 빨라집니다. 개발자가 바로 쓸 수 있는 형태로 넘기는지도 확인할 지점입니다.

시각 완성도만 보고 판단하면 구현 단계에서 다시 손대는 범위가 커집니다. 간격, 타이포그래피, 컴포넌트 규칙이 문서로 남아 있는지가 이후 유지보수 비용을 가릅니다.

자주 묻는 질문

프로젝트 사례를 검토할 때 자주 나오는 질문입니다.