"지금을 알아야 다음을 만들수 있다"
AS-IS분석 즉, 지금 현재 사이트를 분석하는 과정이다.
이 과정은 보통 분석하는 기획자들 마다 아니면 프로젝트의 규모나 웹사이트의 규모에 따라서 그 범위나 수위가 많은 차이를 보인다.
사실 이 과정의 중요성을 대부분의 기획자들이 알고 있음에도 불구하고 프로젝트 일정님 때문에 소홀히 넘어가는 과정중에 하나이다.
크게 말하면 "분석"단계 자체를 번외종목으로 생각하는 에이젼시들도 많이 있다.
AS-IS분석 항목
1. 현 사이트의 메뉴 Depth구조
: 1depth~Xdepth까지의 메뉴구조와 메뉴 그룹핑방법 및 메뉴의 우선순위를 파악한다. 또한, 네비게이션을 통해 이동되는 (가능한) 모든 페이지를 기록하여 전체 페이지수를 파악하는 과정이다.
GNB에 위치해 있는지 LNB에 위치해 있는지 아니면 Tab메뉴구조로 되어 있는지 등 전체적인 메뉴 Depth구조에 대한 가이드를 파악하고 TO-BE모델에의 Depth 구조와 Depth구조에 따른 네비게이션과 UI를 어떻게 가져가는것이 사용성과 확장성에 최적의 모델인지를 분석하는 과정이다.
2. 메뉴별 페이지의 형식
: 각 메뉴별 페이지들이 단순히 html형식으로 만들어져 있는지, DB와 연동되어 움직이는 모듈화(프로그램)페이지인지를 파악하고 관리자페이지(Back Office)에 관리기능이 필요 유무를 파악한다.
또한, 해당 페이지내에 동영상이나 플래시파일이 포함되어 있는지, iframe이나 popup,layer의 구조를 가지고 있는지를 파악하고 왜 이러한 구조를 가져가야만 했는지에 대해서 고민해 볼 필요가 있다.
서비스의 성격이나 구조적인 문제로 AS-IS의 페이지 형식을 그대로 유지해야 하는 경우들이 적지 않기 때문이다.
3. 접근권한
: 서비스 메뉴별로 접근할 수 있는 권한이 어떻게 구성되어 있는지에 대한 파악은 현재 사이트에서 서비스되고 있는 회원등급이 어떻게 관리되어지고 있는지를 파악할 수 있다.
비회원/웹회원/정회원/계좌고객/VIP고객/임직원/관리자 등의 회원등급별로 접근이 가능한 페이지와 서비스이용이 가능한 서비스를 분류해 TO-BE에 적용할 권한 설정의 기초로 반영을 한다. 물론 TO-BE모델에서는 일부 메뉴에 대해서 접근권한에 대해서 변경사항이 있다면 적용을 해야만 한다.
4. 업데이트주기 및 운영이슈
: 서비스 메뉴별 업데이트 주기를 파악하여 업데이트 주기가 많고 적음을 통해서 관리자페이지에 모듈화 하여 구현할것인지 아니면 단순 html로 페이지를 구현할 것인지에 대해서 파악이 가능하다. 또한, 현재 운영되는 여러개의 게시판들에 업데이트 주기가 매우 길다면 서비스통합에 대한 방안도 고려를 해야하는 사항이다.
운영에 있어 특정 페이지의 업데이트 이슈가 빈번하다면 해당 페이지의 운영이슈를 최소화 할 방안을 모색해야 한다.
예를들어 1주일에 한번씩 CEO가 바뀌는 회사라면 CEO인사말 페이지를 CMS(Contents Management System)모듈로 구현하는 방안이나 그렇지 않다면 그에 대응할 수 있는 대안을 제안해야만 할것이다.
5. 관리자페이지
: 반드시 분석해야하는 페이지라는것은 말안해도 알것이다. 현재 사이트의 관리자페이지의 주요 기능 및 관리되고 있는 서비스와 관리프로세스(누구에 의해서)를 파악하는 일은 매우 중요하다.
보통의 운영인력들의 오프라인 프로세스는 쉽게 바꾸기 어려운것이 대부분이다.
그렇기 때문에 사전 운영관리에 대한 이슈를 고려하여 AS-IS에서 기능개선이나 신규서비스에 대한 관리자 기능에 대해 TO-BE모델을 그려야 한다.
기능,권한,사용자페이지와의 연동,DB와의 데이터연동 등 많은 부분에서 분석이 이루어져야 하며, 개발자의 도움을 받아 분석과정을 진행하는것이 리스크를 다소 줄일수 있는 방법중에 하나이다.
AS-IS에 대한 IA분석과 함께 현재 사이트에 대해서 구조적/기능적 분석이 진행되어야 할것이다.
IA분석이 관리자관점에서 본 분석이라면 구조적/기능적 분석은 사용자관점에서 본 분석과정이라고 할수 있다.
먼저 분석할 항목을 설정한다.
내가 정의한 항목은 일반적인 항목이라고 판단한 사항이며, 물론 프로젝트의 성격에 따라서 기획자가 판단하여 가감하여 진행하면 된다.
1. 레이아웃 : 화면구성을 분석한다. 화면의 주요 킬러컨텐츠는 어디에 위치해 있는지 사용자의 접근성이 고려된 것인지를 판단한다.
2. 네비게이션: GNB, LNB, Quick Menu, Footer Menu, Util Menu, Sitemap 등 사용자가 페이지의 이동을 위한 모든것을 네비게이션에서 분석한다.
3. Brand Identity: 사용자가 현재 사이트에서 말하고자 하는 브랜드를 인지할 수 있는 "그 무엇인가"를 찾아야 한다. 네이버에 가면 이제 네이버 로고가 없어도 네이버라고 다들 알수 있는 "그 무엇인가"
4. 서비스채널: Personalization / Product / Application / Corperation / Commnication / Added Service Channel 별로 사용자들이 보여주고자 하는 모든 서비스를 이용할 채널이 열려있는지를 분석한다. 그에 따른 메뉴그룹핑과 메뉴별 접근성을 고려할 수 있을 것이다.
5. 메인UI: 메인페이지의 모든 것을 분석한다. 노출된컨텐츠와 위치부터 비쥬얼영역의 활용, 킬러컨텐츠로의 접근성 등 메인에 대한 모든 UI를 따로 분석해야 한다. 메인을 따로 분석하는 이유는 프로젝트가 끝나는 그 시점까지 메인을 구축하는 이유와 같을 것이다.
6. 비지니스로직: 온/오프라인과 연계되는 비지니스로직에 대한 분석이다. 고객문의는 어떻게 처리되고 있는지, 상품구매 시 오프라인에서 배송처리는 어떻게 되는지, 상품신청 시 오프라인과 연계되는 시스템의 프로세스는 어떻게 구현되어 있는지를 분석한다.
오프라인의 비지니스로직을 무시하고 온라인 로직을 만든다는건 정말 위험한 리스트중에 하나이다. 온라인때문에 오프라인의 로직을 바꾸는 일은 그리 쉬운일이 아닐테니
7. 주요서비스/부가서비스: 온라인에서 이루어지는 메인서비스와 그에 따른 부가서비스를 분석한다. 부가서비스는 사용자가 메인서비스의 이용을 극대화 하기 위한 부가서비스이여야 한다. 금융상품을 보는 페이지에 연예인 동영상을 틀어준다거나 하는 부가서비스는 안하니만 못하다.
8. UI: 분석해야할 부분이 많을 것이다. 사실 위에 열거한 모든것이 사용자와 인터페이스를 하는 모든것이 될것이다.
9. 관리이슈 : IA에서 분석한 업데이트이슈 및 운영이슈를 최소화하기 위한 방안을 모색하기 위한 분석과정이다.
위의 항목에 따라서 AS-IS분석이 끝나면 분석항목에 대한 벤치마킹을 시작해야 한다.
벤치마킹테스트(BMT)를 위해서는 우선 BMT대상을 선정해야 한다.
BMT의 대상은 크게 경쟁사와 우수사로 나누어 분류를 하고 위의 항목별로 어떠한 항목을 경쟁사에서 어떠한 항목을 우수사에서 벤치마킹하는것이 효과적인지에 대해서 판단하고 BMT계획을 수립한다.
물론 BMT의 기본은 타겟에 대한 인지가 될 것이다. 메인타겟에 시점으로 보았을때
사용성,일관성,확장성,명확성,가독성에 대해서 장/단점을 분석하고 그에 따른 시사점을 찾아내어 이번 프로젝트에서 TO-BE모델에 가져가야 할 사항과 버려야 할 사항을 분류해 최적의 TO-BE모델을 만드는 과정을 거치게 된다.
우수사 사이트를 벤치마킹하기 위한 참고사이트를 공유한다.
http://www.webdesignclip.com/
http://bestwebgallery.com/
http://blog.silberbauer-keusch.de/
http://www.cpluv.com/
http://www.designlicks.com/
http://gouw.nu/
http://www.highfloater.com/
http://www.newwebpick.com/
http://www.netinspiration.com.ar/
http://www.pagecrush.com/
http://home.blueidea.com/apps.php?do=pages
http://www.wyldstallyons.com/
http://www.strangefruits.nl/
http://www.webdesignfile.com/
http://www.website-gallery.com/
http://whodidit.jp/category/web/
http://www.xhilarate.com/
http://www.zeroin.gr/
