공공기관의 사업은 일반적으로 제안요청서라는 RFP(Request for Proposal)를 기준으로 수행된다.
제안요청서는 해당 기관에서 직접 작성할 수도 있지만 기관에는 생각보다 IT에 대한 전문지식이나 경험이 많은 사람들이 없는 것이 사실이다.
완전히 새로운 신규사업이라면, 큰 프로세스나 아이디어는 해당 기관에서 기획할 수 있지만 보통은 해당 서비스에 대한 전반지식이나 기술을 보유한 기업의 도움을 받아서 진행하는 경우가 더 많다.
물론 그렇게 시작하면 RFP 작성에 도움을 준 기업이 해당 프로젝트를 수주할 가능성이 높다.
RFP는 조달청을 통해 공개되고, 업체들은 제안서를 작성하여 입찰을 진행하게 된다.
접근 가능 브라우저 안내
차세대 나라장터 안정적인 지원을 위해 HTML5를 지원 하는 브라우저로 접근 가능합니다. 크롬, 엣지 브라우저로 접근 부탁 드립니다.
www.g2b.go.kr
나라장터 UI가 바뀌었다. 적어도 10년은 같은 UI였는데 ...
RFP는 크게 아래와 같은 목차를 가진다.
- 제안 요청 개요
- 1.1 목적
- 1.2 배경 및 필요성
- 1.3 사업의 범위 및 목표
- 2. 사업 내용
- 2.1 주요 업무 내용
- 2.2 수행 범위 및 대상
- 2.3 세부 요구사항
- 2.4 일정 및 마일스톤
- 3. 제안서 작성 지침
- 3.1 제안서 제출 방법
- 3.2 제출 서류
- 3.3 작성 형식 및 분량
- 3.4 주요 평가 항목
- 4. 계약 조건
- 4.1 계약 방식
- 4.2 사업 예산
- 4.3 대가 지급 조건
- 4.4 지식재산권 및 비밀유지
- 5. 평가 및 선정 절차
- 5.1 평가 기준 및 배점
- 5.2 심사 절차
- 5.3 우선 협상 대상자 선정
- 6. 기타 사항
- 6.1 질의응답 절차
- 6.2 참고자료
- 6.3 유의사항
대부분은 영업담당이나, 전략기획팀 같은 곳에서 기존의 레퍼런스를 참고하여 작성한다. UI 디자이너도 제안 작업에 참여하는 경우는 2.3 세부 요구사항에서 시스템에 대한 화면 요구사항이 있는 경우다.
보통은 포털, 또는 회원관리 등의 기능을 요구하며, 구체적으로 "3가지의 시안을 제시해야 한다." 등의 요구사항이 명시된 경우도 있지만 보통은 2개의 시안을 작성하는 것이 좋다.
인터페이스 요구사항이라는 항목에는 웹접근성, 웹호환성 등 UI/UX에 관련된 요구사항들이 있지만 보통은 일반적인 방법론 적인 내용이라 굳이 디자이너의 손이 필요한 항목은 아니다.
시안 작업을 할 때는 요구사항에 명확하게 명시된 기능은 반드시 표기가 되어야 한다. 디자인에 맞지 않거나 화면 구성에 벗어나는 것 같더라도, 반드시 넣어야 한다. 그렇지 않으면 요구사항을 이행하지 않은 시안처럼 보이기 때문이며, 제안서에 시안에 대한 설명을 작성할 때도 해당 기능에 대해서 언급하여 작성하는 것이 좋다.
그리고 세부 기능 요구사항에서 요청하는 기능에 대한 표현 방식을 화면으로 풀어내는 경우 시안이 필요하다.
예를 들어 "로그인"이라는 기능이 있다면, 자동으로 회원관리가 된다는 얘기다. 그리고 로그인을 한다는 것은 ID와 PW가 존재하는 것이며, ID와 PW는 작성규칙 및 기관에서 이미 운영하고 있는 방침이 있기 때문에 해당 정책을 적용하는 기능도 추가된다.
ID/PW를 분실했을 경우의 프로세스/화면 등의 기능은 자동으로 따라오는 것들이다.
- 로그인 시도 횟수 (5번 로그인 실패 시 계정 정지)
- 장기 미사용 고객에 대한 처리(휴면계정관리)
- 회원탈퇴 기능 여부
- 가입 시자동 승인 또는 관리자 권한 승인 프로세스
잘 모르는 사람들은 그냥 쉽게
"로그인 기능 추가해 주세요"
이렇게 얘기할 수 있지만, 개발을 아는 사람이라면 저 말에 얼마나 많은 공수가 필요한지 알 수 있다.
로그인 기능 추가에 대한 대략적인 화면 목록
- [회원관리]
- - 회원가입 페이지
- · 약관동의
- · 회원정보입력
- · 가입완료 화면
- - 회원정보 수정 페이지
- - 탈퇴
- · 탈퇴 동의
- - 관리자 화면에서의 회원정보 조회 및 관리 기능
- - 회원가입 페이지
- [로그인]
- - 로그인 화면
- - ID/PW 찾기 화면
- [기타 화면]
- - 휴면안내 화면
- - 가입안내 화면
일단 제안서에 들어가는 UI 디자인은 제안서를 작성하는 기획팀과 협의하여 어떤 화면에 대한 시안을 만들 것인지 그 화면에 들어가는 콘텐츠가 무엇인지 정의하는 과정이 필요하다.
대략적인 화면 구성안을 작성하는데, 화면설계서보다는 러프한 느낌이다.
이런 화면구성안은 좋긴 하지만 디자이너한테는 안 좋을 수도 있다. 위치를 정해버린 것 같아서, 시안을 작업하면 대략적으로 저 위치에 저 콘텐츠를 담아서 시안을 작성한다.
그럼 이런 상황이 벌어진다.
딱 저렇게만 해오면 어쩌자는 거냐?
왜 구성안대로 해오지 않았냐?
어쩌라는 것인지..
그래서 차라리 구성안 없이 콘텐츠만 대략적으로 말해주는 것이 좋다.
일단 디자이너는 해당 공공기관의 아이덴티티를 조사한다. 일반적으로 해당 기관의 홈페이지에 들어가 보는 것을 시도한다. 하지만 공공기관의 홈페이지는 대략적인 느낌이 통일되어 있고, 대부분 해당 기관의 공무원들은 자신들의 기관 홈페이지 느낌을 싫어하는 경우가 많다.
그러면서도, 그 고유 아이덴티티나 색상을 버리면 그것도 싫어한다. 알 수가 없다.
조사를 할 때는 해당 기관의 관련사이트나 해당 부서의 사이트를 다 방면으로 조사하는 것이 좋다. 그리고 해당 서비스와 유사한 서비스를 운영하는 기관 또는 기업들을 조사한다.
제안서를 기획하는 사람에 따라서 벤치마킹한 내용을 작성하는 경우도 많고, 만약 사업을 시작하게 된다면 고객을 설득하는데 좋은 자료가 된다.
시안을 그렇게 작성하면 된다.
이건 나의 개인적인 의견인데.
공공기관의 제안서 UI 시안작업은 너무 길면 안 된다.
개인적으로는 3일을 넘겨서는 안 된다. 물론 풀타임 기준이며, 만약 업무 요청이 온다면 넉넉하게 일주일을 요청하면 된다. 더 길면 높은 퀄리티를 기대하게 되고, 너무 타이트하게 잡으면 결과물이 좋더라도 성의가 없어 보일 수 있다. 물론 합을 맞춰온 관계라면 다르다.
만약 디자인이 중요한 시스템이라면 공을 들어야 하는 것이 맞지만 대부분의 공공 SI 사업에서는 포털의 디자인은 실제 사업 진행 후 다시 디벨롭되거나 이미 고객이 생각하는 안이 있는 경우가 대부분이다.
하여, 성의 없어 보이지 않는 선에서 적당한 노력이 보이는 시안을 정해진 제안 기간 내 작업할 수 있어야 한다.
지금까지 일을 잘했던 디자이너의 경험은 퀄리티가 놓은 디자인 결과물을 가져오는 것도 중요하지만 약속한 시간 내에게 결과를 내어주는 사람과 다음에 또 일을 하고 싶은 게 사실이다.
시안은 보통 A, B안 두 가지로 하는 것이 좋다. 그리고, A와 B안은 명확하게 차이를 보여야 한다.
고객으로 하여금 구분할 수 있도록 명확한 차이를 줘야 한다. 다만 콘텐츠가 동일하기 때문에 어쩔 수 없이 유사한 경우가 많다. 그러면 결국 색상에서 차이를 줄 수 밖에 없다.
많이 쓰는 방식은 색을 대비해서 구성하는 것이다.
A 안이 하얀바탕에 파란 글씨를 쓴 느낌의 시안이라면 B안은 파란바탕에 하얀 글씨를 쓴 느낌의 시안을 작성해야 고객도 확실하게 구분을 지어 줄 수 있다.
그리고 제안서는 보통 A4를 세로로 하여 작성하는 정성적 제안서가 있으며, 대략 300~400 페이지 내외가 된다. 여기 기능이나 시안을 위한 제안서는 대략 5~6페이지가 할당된다.
UI를 기획하는 관점이나, 방향성 그리고 시안 및 구성에 대한 설명을 작성하는 경우다.
그리고 사업을 이끌 PM이 발표하는 발표자료가 있다. 이는 대부분 가로본의 PT 자료인데 화면구성을 위하여 메인화면이나 디자인 시안은 제안서 사이즈에 맞춰야 어필이 쉽다.
너무 새로가 긴 구성이나, 가로가 넓은 구성은 제안서를 작성하는 사람에게 시련을 줄 때가 있다.
마지막으로 제안서의 UI는 수정할 시간이 없는 경우가 많다.
4~5억 규모의 사업이라면 보통 제안서를 작성하는 기간을 길어야 한달 즉 4주 정도를 잡고 진행할 수 있다.
그래서 제안서 시안에는 요구사항이 명확하게 표현되어야 한다.
