[Process] SI, 솔루션개발, IT운영에서 UX는 어떤 프로세스로 일하는가? Waterfall, Agile에서의 UX는 무엇이 다른가?
출처 url : https://m.blog.naver.com/7minkee/221356690738
이 글은 IT회사에서 12년간 경험했던 노하우를 정리한 개인 포스팅으로, 회사의 공식 업무 프로세스와는 다릅니다. 또한 다른 전문가분들과 의견이 다를 수 있습니다. 유형이 다른 프로젝트, 다양한 방법론에서 UXer의 역할은 무엇이고 어떻게 일해왔는지 기술해보았습니다. (완성된 글은 아니고, 하고 싶은 말이 생각하면 틈틈이 수정하고 있습니다.)
Agenda
1] ERP 컨설팅과 SI구축 프로세스
2] PI/ISP/BPR 그리고 UX컨설팅은 무엇인가?
3] 새로운 서비스를 제안하고 기획하는 서비스기획,
UX라는 단어가 유행하다
4] IE방법론에 따른 Waterfall 개발방식의 시스템 개발
5] 솔루션 개발, R&R이 구체화되다
6] 오픈 후, IT운영단계에서의 UX 유지보수
7] UX에서 자주 나오는 더블다이아몬드, 디자인씽킹
8] 실리콘밸리에서 온 Agile방식과 Lean UX,
스타트업이 일하는 방법
9] Waterfall에 익숙한 한국에서 Agile처럼 일하기
과도기 단계의 UX 프로세스
10] Data Analytics를 활용한 사용자행태분석,
점진적인 UX의 개선
IT 기술은 날마다 진화하고 있다. 그리고 어떻게 하면 더 효율적으로 IT 업무를 할 것인지에 대한 생각도 함께 발전하고 있다.
IT 프로젝트는 개발목적에 따라 여러가지 종류로 구분된다. 고객이 원하는 기능을 납기내에 구현하는 것이 최우선 되는 프로젝트도 있고(흔히 SI 라고 부른다. System Integration), 이미 구축된 시스템을 운영하고 개선하는 업무도 있다.(흔히 SM이라고 말한다. System Management). 세상에 없던 서비스를 기획하고 만드는 일도 있으며, 그것을 솔루션, 플랫폼으로 만들어 지속발전하는 생태계(Eco-system)을 만드는 일도 IT 프로젝트이다.
사용자에게 익숙한 경험을 주기위해, 기획자와 개발자간 커뮤니케이션 효율화를 위해, Pilot 검증을 받으며 개발하기 위해 개발방법론도 다양하게 늘어나고 있고 여러가지 시도가 일어나고 있다. 최근 5년 사이에 IT에서 유행하는 키워드는 아마도 Agile, Lean UX, Prototype Tool, Data Analytics ...이런 것일 것이다.
나는 IT 회사에 근무한지 그것도 같은 회사에서 근무한지 12년차가 되었는데, 부서를 5번 이상 바꾸게 되었다. 입사를 했던건 ERP시스템을 구축하는 SI 개발부서 였고 그곳에서 지방을 돌면서 4년간 근무했다. 스마트폰이 확산 되기 전에는 B2C(Business to Customer)용 App의 서비스기획을 2년정도 해봤었고, 교육솔루션을 개발하는 부서에서 3년간 제안-UX기획-UX운영업무를 수행하였다. 그리고 2년간 솔루션사업팀에서 스탭업무를 하였고, 지금은 사내 in-house-designer로서 UX 업무와 여러 프로젝트의 QAO(Quality Assurance Officer)역할을 수행하고 있다.
다양했던 프로젝트 경험 속에 여러 방법론과 프로세스를 경험해 보았는데 꼭 맞는 정답도 없고, 꼭 트렌드를 따라가지 않아도 된다. 다만 같이 일하는 멤버들과 어떤 프로세스로 일한건지 Ground Rule을 만들고 Goal을 세팅하는 의미에서 방법론과 프로세스는 좋은 노하우가 될 수 있다.
이제 회사에서도 연차가 쌓여서인지 “어떤 프로세스로 일하면 좋은가, UX Senior로서 Junior 후배들에게 어떻게 가이드를 줄 것인가?” 라는 질문을 많이 받고 있기에 이번기회에 정리해본다.
[1]
ERP컨설팅과
SI(System Integration)구축
프로세스
‘07~’11년에 ERP컨설팅부서에서 근무하던 때를 돌이켜보면 SAP을 이용하여 ERP를 구축하던 컨설턴트라는 역할이 여러회사에 있었던 것 같다. SAP이라는 시스템 자체가 어렵기도 하거니와 그 시스템을 알기 위해서 특정모듈 (예: 재무모듈, 관리모듈...)의 전문가가 되어서 프로세스를 세우고, 개발하는 업무를 하다보니 ‘컨설턴트’라는 네이밍이 붙여진것 같다. 한가지 모듈로 여러 프로젝트를 뛰다 보니 Industry 전문가가 되기도 한다. 지금은 많은 기업에 이미 ERP가 구축되었고, 신규로 수행할 프로젝트 수가 줄어들다보니 이 역할을 가져가는 회사들이 많이 없어졌다. 엑센추어(Accenture)같은 글로벌 컨설팅회사가 그 예가 될 수 있겠다.
어쨌든 이 ‘컨설팅’이라는 조직은 이름에서 부터 느껴지듯이 프로세스와 업무방식이 체계화, 조직화 되어있다. 나는 회사에서 4년차가 될 때 QAO(Quality Assurance Officer) 역할로 PM(Project Manager)를 도와서 산출물을 정비하는 일을 하게 되었는데, 이때 프로세스에 대해서 제대로 공부할 기회가 되었다.
ERP컨설팅에서의 프로세스는
보통 5단계로 이야기 한다.
(‘11년버전이라 지금은 다를 수 있다)
1. Preparation (사전작업)
2. Blueprint (분석설계)
3. Realization (개발구축)
4. Final Preparation (이행)
5. Go-Live (안정화)
ERP의 경우는 SAP라는 검증된 스탠다드 솔루션을 사용하고 있고, 이 시스템자체가 세계 최고라 불리기에, IT 컨설턴트가 해야할 일은 어떻게 Workflow를 효율화하여 SAP에 configuration할 것인가? 그리고 스탠다드가 제공하지 않지만 고객이 원하는 기능을 어떻게 CBO(customer bolt-on)개발 또는 추가개발할 것인가? 각 모듈별 E2E(End-to-End) Process를 어떻게 연계할 것인가? SAP가 아닌 Legacy System과 Interface 개발은 어떻게 할 것인가? 다양한 사용자군에게 각 시스템의 메뉴 및 CRUD 권한(Role & Authorization)을 어떻게 부여할 것인가? 부분을 주로 고민하게 된다. 그래서인지 UX디자인에 대한 관심은 조금 적은편이다.
ERP는 B2B시스템이고, 특히 SAP이라는 시스템의 Dependancy가 강하기 때문에 요즘 스타트업이나 B2C 서비스를 하는 mobile App에서 UXer가 고민하는 Design Concept, UX Trend, Interation Design 이런부분에서 아주 차별화된 특징을 가지긴 어렵다.
다만 SAP화면이 User Freindly하지는 않기에, 일반 사용자들이 친숙한 Java로 만들어진 웹화면으로 포장할 때는 UX이야기가 나올 수 있겠다. DB와 Reposotory는 SAP시스템이고, 웹화면은 Java로 구현된 경우, RFC(Remote Function Control)로 Data를 주고받는 방식을 구현하기도 하는데, 이럴경우 SAP 모듈컨설턴트, ABAP개발자 외에 Java 개발자, 웹화면을 디자인하는 UX기획자와 비쥬얼디자이너까지 필요하게 되니 인력(비용)이 많이 투입된다는 문제가 있다. 그리고 이는 나중에 유지보수나 업그레이드를 할때도 항상 비용의 이슈를 끌고 온다.
ERP시스템 자체가 외부고객에게 오픈하는 서비스형 사이트가 아니라, 회사 내 일부 인력이 사용하는 시스템이다보니, 좀 불친절한 시스템이어도 매뉴얼을 잘 만들고 파워유저를 교육하면 된다는 관점의 의사결정자도 많다. 그래서 많은 직원이 보는 화면만 웹으로 구현하고, 나머지는 SAP화면으로 구현하는 사례가 많이 발생한다.
’15년부터 프론트엔드(Front-End) UI부분과 백엔드(Back-end) 비즈니스 로직영역을 완전분리시켜 앱개발을 단순화 하는 HTML5 표준기반의 SAP Fiori가 나왔다. 이때는 내가 ERP프로젝트를 하지 않아서 자세한 내용은 모르겠지만, SAP에서도 UIUX에 대한 컴플레인을 해결하기 위해 노력하고 있다고 볼 수 있을 것 같다.
[2]
PI / ISP / BPR 그리고
UX컨설팅은 무엇인가?
일단 용어부터 정리해보면 아래와 같다.
ISP(Informatiom Strategy Planning)는 비즈니스와 환경의 변화에따라 시스템의 리뉴얼, 또는 신규구축이 필요할 때 현재 프로세스와 이슈를 진단, 분석하고 Insight 있게 새로운 방향을 제시해 주는 프로젝트이다.
PI(Process Innovation)는 ISP에서 나온 핵심과제에 대해서 어떠한 프로세스로 구축할 것인지 설계하는 단계라고 볼 수 있다.
BPR(Business Process Reengineering)은 이미 전문화, 분업화 되어있는 조직과 프로세스를 근본적으로 재검토하고 최적화, 단순화하여 재설계하는 경영혁신 기법이다.
보통 대형프로젝트일수록 ISP, PI 컨설팅을 마친 이후에 구축프로젝트를 들어가는 경우가 많은데, 경영진에게 무엇을 할 것이니 비용을 쓰는 것을 허락해달라는 설득하는 자료로 활용되기도 한다. 이렇게 앞단에서 컨설팅 자료가 잘 만들어지고 나면 명확한 목표, 일정, 조직이 세팅되게 되고 그 후에 발생하는 구축 프로젝트가 훨씬 수월하게 진행될 수 있다.
개인적 경험으로 돌아보면 ‘10년에 ERP구축 프로젝트에서 A.T.Kearney(AT커니) 출신의 PI컨설턴트와 협업했던 적이 있다. 보통 ERP구축 프로젝트는 전체 프로세스를 각각의 모듈별로(재무모듈, 관리모듈 등) 최적화 하는데에 포커스 하면서 가장 최측근의 모듈간의 인터페이스(인풋, 아웃풋)를 설계하게 된다. 이때 전체적으로 E2E(End to End)관점에서 프로세스를 보는 View를 누군가는 가져야 하는데, 그 역할을 PI컨설턴트가 수행했던 것이다.
모두가 합의된 프로세스를 바꿀때는 어떤 의사결정을 통해 바꾸어야 하는지 그 체계(정책)도 수립하였는데 그 보고서를 프로세스 거버넌스(Process Governance)라 칭했었다. 하나의 약속된 프로세스 원칙, 그 산출물이 만들어진 이후에 현업과 모듈 컨설턴트들 간의 커뮤니케이션이 더 수월하게 진행되었던 기억이 있다.
‘10년에 투입된 프로젝트의 PI컨설팅 산출물 중 하나. 프로세스가 어떻게 연계되는지 전체 View로 E2E를 연결한다. 상세 내용은 보안이슈가 있어서 내용을 알아볼 수 없도록 해상도 조절을 하고 포스팅 한다.
요즘은 PI컨설팅을 할 때 UX컨설팅(or CX컨설팅 : Customer Experience)를 같이 하기도 하는데, PI컨설팅이 비즈니스 관점에서 접근한다면(Top-Down 방식) UX컨설팅은 사용자 관점에서 분석하기 때문에(Bottom-Up 방식) 통합기획의 시너지를 기대할 수 있다.
UX컨설팅에서는 사용자리서치, 심층 인터뷰 등을 통해 사용성 관점의 Pain Point를 확보하고 UX전문가 평가(Heuristic Evaluation)을 통해 문제점을 구체화 한다. 그 결과물을 살펴보면 PI컨설팅에서는 To-Be프로세스를 그리는 것에서 마무리 되지만 UX컨설팅에서는 그 시나리오를 프로토타이핑으로 제작하여 비쥬얼로 소통함으로써 빠른 피드백을 얻을 수 있다는 장점을 가지고 있다.
[3]
새로운 서비스를
제안하고 기획하는
서비스기획, UX,
라는 단어가 유행하다
갤럭시탭이 처음 런칭한 시기는 ‘12년이었다. 초기모델은 갤럭시탭을 안주머니에 넣을 수 있는 사이즈였고 전화도 받을 수 있었다. 6년이 지난 지금, 태블릿으로 전화받는 모습을 상상하면 너무 어색하겠지만 그때는 그랬다. 내가 정확하게 언제인지 기억하는 이유가 ‘11년에 그 태블릿의 시료버전(아직 런칭하기 전의 디바이스)에 앱을 만드는 프로젝트에 참여했기 때문이다.
그 당시를 다시한번 생각해보면 2010년 3월에 카카오톡이 처음 출시를 했고, 2011년 4월에 가입자수가 1,000만명, 2012년 3월 4,000만명 이었다. 스마트폰이 확산되는 시점의 초기였던 것이다. IT에 종사하는 사람들조차 스마트폰앱을 어떻게 개발해야하는지 모르는 사람들이 많았고, 스마트폰을 사용하는 사람이 50% 미만이었던 것 같다. 내가 아이폰을 처음 산 것도 ‘11년이었다. 우리 회사에 UX조직이 처음 만들어진 것도 이때부터 이다.
그 시기를 잘 활용한 사람들이 많았다. '11~'12년에 모든 상품이름에, 부서이름에 "Smart"라는 이름이 붙기 시작했다. 그당시 내가 있던 부서의 이름도 'Smart Study 사업TF' 였다. 컨퍼런스에서는 스마트시대의 도래 와 같은 주제로 시끄러웠고, 10년전 오프라인에서 온라인으로 변했던 게임시장과 쇼핑몰을 예로 들면서 이 시대에 뒤쳐지면 선두를 놓치게 된다고 경고하기 시작했다. 그리고 이미 플랫폼이라는 이름으로 많은 유저를 가지고 있던 카카오톡과 네이버는 기존 시장이 아닌 새로운 문화를 개척했다는 평가를 받기 시작했다.
그리고 이 시기를 캐즘이론(Chasm : 초기 시장에서 주류 시장으로 넘어가는 과도기에 일시적으로 수요가 정체되거나 후퇴하는 단절현상)과 연관하여 말하면서 빨리 PC에서 모바일로 갈아타야 한다고 강조하는 Opinion Leader들이 많았다. 몇년 지나고 보면 실제로 Mobile First가 되었으니 맞는 선견지명이었던 것 같다.
다시 프로젝트 이야기로 돌아오면, 그 당시 시장은 스마트폰이 세상을 바꾸게 될 것이라는 것은 모두 동의하는 분위기였다. 하지만 어떻게? 라는 부분에서 의사결정자들은 투자를 할 것인가 말것인가 고민하기 시작하였고, 그 “어떻게”를 보여주기 위해 “서비스기획”이라는 일을 하는 사람들이 생겨났다.
‘11~’12년에 내가 쓰던 제안서와 보고서는 리서치방법론(Global Player 벤치마킹, 트렌드분석, Survey, FGI : Focus Group Interview, in-depth-interview 등) 및 사용자모델링(Persona, Journey map, User Scenario 등)이 많이 들어가기 시작하였다. 기존에는 기능중심의 제안서였다면, 이때부터는 사용자 관점에서 어떤 기능이 제공되고 어떤 가치를 주는지를 시나리오 관점으로 설명하는 방식으로 바뀌기 시작한 것이다.
이 업무를 하는 사람을 꼭 UX를 하는 사람이라고 표현하지 않았다. 기획자, 분석자, 서비스기획자, 화면설계자, UI디자이너, 인터랙션디자이너 모두 비슷한 일을 하는 사람들이었고 각 프로젝트마다 부르는 이름이 달랐다. 사실 나는 그 당시 마케팅담당자였다.
마케팅 업무는 B2C App에서 쿠폰, 포인트 등의 정책과 경품 등 정책을 정하고, 콘텐츠를 주는 CP사(Contents Provider Company)를 만나서 이익이 발생했을 때 Share를 어떻게 할 것인가를 논의하는 역할이었는데, 몇개월 지나고 나니 그것이 서비스 기획으로 발전했고 Web Agency와 같이 화면설계를 시작했으며, 1년쯤 지나고 나서는 다음버전의 App의 화면설계를 내가 직접 하게 되었다. 어찌보면 요즘 유행하는 스타트업처럼 일했던 것 같다. 그리고 각 부서에서 나와같은 일을 하는 사람들이 생기기 시작했고 자기역할을 “UX Designer”라고 표현하기도 했다.
‘11년~’12년에 UX담당자로 처음 작업했던 스토리보드, 당시만 해도 PPT에 와이어프레임으로 그림을 그리고 각 기능에 대해 Description을 쓰곤 했다. 인터랙션이 필요한 화면은 PPT 애니매이션 기능을 활용하여 개발자와 커뮤니케이션 하였다. (이 App은 B2C서비스로 대외오픈되어 안드로이드마켓, 앱스토어에 등록되었고, 몇번의 업그레이드 후 지금은 서비스가 종료되었기에 그 당시 산출물을 공유한다)
‘11~’12년 경 내가 제일 힘들어했던 정책 부분. ‘18년인 지금 생각하면 [네이버웹툰에서 미리보기로 결제한 콘텐츠와 구매하지 않아서 미리볼 수 없는 콘텐츠, 구매했으나 유효기간이 지난 콘텐츠, 무료로 볼 수 있는 콘텐츠를 어떻게 표시할 것인가, 그리고 전권 구매하기는 어떻게 표시할 것인가] 와 매우 흡사한 기능이다. 그 당시는 네이버웹툰에서 콘텐츠 구매하기 기능이 없어서 혼자 고민하다보니 힘들었던 기억이 난다. 뭐든지 처음 고민하는 사람이 힘들다.
[4]
IE방법론에 따른
Waterfall 개발방식의
시스템 개발
‘13~’14년에 내가 했던 프로젝는 전형적인 IE방법론을 따랐다. (내 생각에) 고객이 있고, 시스템을 신규 구축하는 프로젝트에서 일반적으로 사용하는 방법론은 IE (Imformation Engineering, 정보공학)방법론이다.
1. 프로젝트착수
2. 요구정의
3. 분석
4. 설계
5. 아키텍쳐정의
6. 개발
7. 이행
8. 프로젝트 종료
‘14년에 IE방법론에 따라 시스템 SI개발 완료 후, 프로젝트 정료시점에 QAO로서 최종 취합한 산출물 리스트, IE방법론에 따라 단계별로 산출물을 리스트업 하였다. (엑셀라인이 1,700줄인 것을 보면 알겠지만, 대형 SI 프로젝트 하나 하고 나면 산출물만 해도 엄청나게 많이 나온다. 몇년 후 산출물의 양을 줄이는 액션들이 나오게 되었다.)
여기서 내가 가장 중요하게 보는건 요구사항정의서이다. PM마다 스타일이 다르긴 한데, 이 요구사항정의서를 요구사항추적표라는 문서로 바꾸어서 넘버링을 만들고, 그 요구사항들이 나중에 어떻게 구현되었는지 Feature 넘버링과 연계하여 구현이 되었는지를 추적하기도 한다. 난 개인적으로 이 방식을 매우 선호한다.
인터뷰를 하고 문제점을 발견했을 때 그것을 해결할
수 있는 것이 시스템개발일 수도 있고, 프로세스개선일 수도 있고, 인력의 추가일 수도 있고, 정책의 문제일 수도 있다. 그 각각의 요구사항에 대해서 이건 이렇게 처리, 이건 이렇게 개발했다는 증빙을 남기면서 가는게 PM으로서 중요한 역할 중 하나일 것이라 생각한다.
여기에 하나 더 동일한 방법으로 관리하는 것이 이슈리스트이다. 프로젝트를 수행하다보면 많은 이슈가 발생할 수 밖에 없는데 그것들을 따로 리스트업하고 관리하지 않으면 언제 어떻게 의사결정이 났고, 왜 그렇게 하기로 했는지가 명쾌하지 않아서 나중에 문제가 될 소지가 크다. 노파심에 이야기하면 이슈는 숨기지 않고 빠르게 오픈하는 것이 좋다. 그것이 개발코드 에러이든, 고객의 컴플레인이든, 아니면 퇴사 등 개인사유에 의한 것이든... 그 이슈를 안고 시간이 지나면, 리스크라는 이름으로 돌아오는데, 이때는 해결하는 것이 더 힘들다
아무튼 이 IE방법론에는 UX에서 중요하게 생각하는 벤치마킹, 인터뷰, 페르소나, 유저저니맵, UX전략, 디자인키워드 이런것이 Task에서 빠져있다. 이 것에도 이유는 있는게 대부분 IE방법론은 ‘무엇을 개발할지 이미 많이 구체화가 되어있고 고객과 계약까지 마친상태’에서 주로 쓰는 방법론이다. 그러다보니 UX Task들은 계약하기 전 제안서 등에서 작업이 주로되고, 어떤 경우는 제안서에 키스크린이 들어가기도 한다. 물론 구축단계에서도 UXer가 해야할 일은 많지만, IE방법론상에서는 프로젝트총괄(PM : Project Manager), 분석 및 개발리더(PL : Project Leader), UX리더 간 R&R(Role & Responsibilty)이 명쾌하지는 않다.
통합테스트를 할 때도 그렇다. 테스트 시나리오를 작성하는 역할을 PL에게 줄지, UX리더에게 줄지 명확하지 않다. 물론 제일 그 프로세스를 잘 아는 사람이 그리는 것이 맞고, 니것 내것 나누지 않고 같이 한다면 좋겠지만, 담당할 책임자가 있는 것과 없는 것은 천지 차이이다. (이 경우는 그 프로세스를 기획한 UX리더가 시나리오를 세우는 것이 맞다고 본다. 그래야 본인이 그린 기획안대로 개발이 이루어졌는지 확인할 수 있다)
[5]
솔루션 개발
R&R이 구체화되다
고객(시스템 구축에 대한 비용을 지불할 자)가 존재하고, 그것을 정해진 납기내에 구축하던 SI 개발에서 자체적인 솔루션을 만들어야한다는 의견이 생기기 시작했다. 정부가 공공사업SI에 대기업 입찰제한을 걸기도 했고, 더이상 대기업에서도 인력비(M/M: Man/Month)로 수익을 내는게 아니라 솔루션을 판매하여 라이센스비를 가져가야 한다는 생각을 하게된 것이다.
‘14년 즈음에 국내 IT대기업들은 솔루션을 만드는데 집중했고, IT회사 선도적으로 기술에 투자하기 시작했다. 이때 회사는 R&R(Role & Responsibility)과 Process에 대해서 다시한번 고민하게 된다.
‘13년즈음 솔루션방법론이 처음 나왔을 때, 당시 개발조직의 리더가 나에게 역할자 별로 주, 부를 동그라미, 세모로 표시하여 작업해달라하여 매트릭스로 표시해본 내용 (회사의 공식 입장이 아닙니다). 이때만 해도 UX기획자는 상품기획자가 기획하라는대로 화면만 설계한다고 생각했었다.
R&R이 구체화 되기 전까지 서비스기획자, 화면설계자, UX기획자 등이 혼용되어서 사용되었다면, ‘14년부터 상품기획자, UX기획자, Visual Designer, 퍼블리셔, 개발자, Tester로 세분화 되기 시작했다.
이 외에도 UX(User Expeience)와 CX(Customer Experience)를 구분하는 의견도 있는데 이것은 학회나 기업마다 다르게 쓰이고 있기도 하고 컨셉적인 이야기라 길어질 수 있으니 UI(User Interface)와 함께 비교하여 별도로 포스팅 하도록 하겠다. 여기서는 CX가 UX보다 조금 더 큰 개념을 가지고 있다(포괄하고 있다) 까지만 언급한다.
상품기획자(PM : Product Manager)는 시장의 트렌드를 읽고, Global Player의 동향을 살피고, 우리 솔루션이 가야할 방향성과 로드맵을 수립하는 역할을 수행한다. 이 작업을 하면서 기존 솔루션의 Pain Point를 분석하고, 우리만의 Key Feature를 고민하게 된다. 사업성도 고려해야 하고, 기존 고객의 VoC(Voice of Customer)도 분석해야하며, 프로젝트 기간동안 개발이 가능할지에 대한 커뮤니케이션도 해야한다. 상품기획자 개개인의 역량에 따라 다르긴 하지만, UX에 관심이 있는 상품기획자는 Key Feature와 상품의 Concept을 작성하는 과정에서 사용자모델링(Persona, Journeymap 등)을 같이 고민하기도 한다. 그럴경우 Feature를 시나리오 기반으로 재해석 할 수 있기 때문에 기획이 더 탄탄해진다. SI 사업은 특정 고객이 확실하게 존재하지만, 솔루션사업은 잠재고객을 대상으로 미래의 상품을 만드는 것이기 때문에 상품기획자는 고객(Customer)의 입장을 대변한다고 볼 수 있다. SI 프로젝트에서 고객의 의견이 절대적이었다면, 솔루션개발에서의 상품오너십(Ownership)은 상품기획자가 가져간다고 할 수 있다. 따라서 정책을 수립하는 역할도 가져가게 되며, 상품기획이 기획한대로 UX설계와 개발이 되었는지 추적하는 책임을 가지게 된다. 또한 상품기획자는 개발조직이 아닌 사업조직에 속하기 때문에, 상품의 라인업, 가격, 라이선스 등을 총괄하여 정의하고 관리해야 한다. 일부 상품기획인력은 마케팅 업무도 지원하는데, 영업활동을 위한 세일즈툴킷(Sales Tool Kit) 및 상품의 차별화 포인트, Value Proportion 등을 정리하기도 한다.
UX기획자는 상품기획에서 정의한 컨셉을 UX측면에서 재해석하며 기획하는 역할을 수행한다. ‘어떤 기능이 필요하다’라는 Feature단위의 관점을 화면설계로 풀어내는 Task를 진행하면서 IA(information Architecture)를 정의하고, Main Component와 menu체계를 고민하고, Key Flow를 설계하는 역할을 한다. 이 과정에서 UX 전략과 방향성을 수립하는 보고서를 작성하기도 하는데, 그 근거가 될 자료를 찾기 위해 리서치방법론, 디자인씽킹방법론 등을 꺼내기도 한다.
위에서 말한 상품기획자, UX기획자를 섞은 업무를 가진 역할도 존재한다. 마이크로소프트사의 PGM(ProGram Manager)라는 역할이 그 대표적인데, Key Faeature에 대한 시나리오, 흐름도, 대략적인 UI, 기능정의까지 수립한다. PGM에 대한 추가적인 설명은 MS의 Exel파트 PGM인 Joel의 Blog를 보면 자세히(재미있게) 나와 있다.
How to be a program manager
Having a good program manager is one of the secret formulas to making really great software. And you probably don’t have one on your team, because most teams don’t. Charles Simonyi, the brilliant p…
www.joelonsoftware.com
위 링크에서는 PGM의 역할을 5개로 정의하고 있다. (1)Design Ui / (2)Write Funtional SPec / (3) Coordinate Teams / (4)Serve as customer advocate / (5)Wear Banana Republic chinos
WhatTimeIsIt
This is a sample functional specification, a part of Joel on Software, a site about software management. It is intended for educational purposes, not to refer to a real product, in case you didn…
www.joelonsoftware.com
위 링크에서는 PGM이 작성한 Functional Spec의 샘플을 볼 수 있다.
난 ‘15~’16년에 마이크로소프트사 출신의 팀장님을 모시고 프로젝트를 하게 되었고, 이때 PGM이라는 역할을 6개월 정도 수행하였다. 한국식으로 말하면 개발PL(Project Leader)과 UX기획을 합한 업무를 했다고 보면 될 것 같다. 역할에 대한 정의(Job Description)는 상황에 따라 달라질 수 있다. 이쪽 일을 더 할 수도 있고 힘든 쪽을 도와줄 수도 있는 일이다. 단 너무 과도한 의욕으로 선을 넘지만 않는다면!
‘15년 PGM(ProGram Manager)로서 Feature를 도식화 한 내용, 개발자에게 기능을 설명하기 위한 용도로 사용하는 와이어프레임 정도이다. [내가 ‘15년에 그린 이미지, 실제로 구현하지는 않았다]
이것이 살짝 UX기획자의 롤을 침범한 PGM의 산출물. [내가 ‘15년에 그린 이미지, 실제로 구현하지는 않았다. 당시 나는 새로운 버전을 개발하는 PGM이면서 동시에 (이미 릴리즈 된) 이전 버전 솔루션의 UX 유지보수 PM이어서 R&R의 선을 넘나들었다]
이것은 UX담당자로서 작업한 시나리오 기반의 Feature소개한 나용 특별한 기능은 아니고 ‘15년 당시 현존하던 서비스를 우리솔루션에 적용하면 어떻게 될지를 그린 그림이다. [내가 ‘15년에 그린 그림. 보고할 기회를 못찾아서 혼자 그려놓고 아무에게도 못보여줬었다. 이런일이 많다.]
[6]
오픈 후, IT운영단계에서의
UX 유지보수
흔히 IT운영(or SM : 시스템운영)이라고 하면 ‘SI보다 쉽다’라고 착각(?)할 수 있다. 나도 ‘15년에 UX유지보수PM이란 역할을 맡기 전에는 그렇게 생각했었다. 하지만 운영이라고 하는 것이 단순히 콜센터만 가지고 있는게 아니고 SR처리(or VoC처리) 프로세스도 가지고 있어야 하고 운영단에서 마이너하게 수정할 것인지 개발로 올려서 기능을 개선할 것인지 등을 의사결정 해야하며, 시스템의 개선포인트를 발견해야 하며, 무엇보다 고객의 2선대응을 해야한다는 것이 가장 큰 업무부담일 수 있다.(1선 대응은 콜센터가 진행한다.)
운영을 조금 더 쉽게 해주는 개발자툴(시스템)으로 JIRA, Confluence, Redmine 등을 쓰기도 한다. VoC가 접수되면 번호 하나를 따게 되고, 담당자가 바뀌어가면서 히스토리를 남겨서 종결처리하는 것이다. 예를들면 무엇을 수정하라는 VoC가 접수되면 콜센터가 내용을 듣고 정리하려 운영담당자에게 넘기고, 운영담당 개발자가 프로그램 로직을 수정하다가 디자이너가 필요한 상황이 생기면 UX담당자에게 넘기고, 또 테스터에게 넘기고, 이런식으로 히스토리를 남기는 방식이다.
VoC중에는 그냥 종결처리해야 하는 건도 있다. 예를들면 이런 VoC를 받은 적도 있다. 로고를 누르면 홈으로 돌아가게 만든 App에서 “왜 집모양 아이콘이 없냐? 로고를 눌러서 홈으로 가는게 말이되냐?”라며 전화를 한 고객이 있었다. (결론적으로는 잘 설명드려 종결처리하였다.) 하지만 어느 담당자 한명이 종결처리를 하면 안되기 때문에 일단 VoC가 접수되면 다음날 아침에 스크럼미팅(Scrum Meeting)을 하면서 개발PM, 운영PL, 테스트PL이 모여서 협의를 하는 문화가 있다.
구축을 하는 인력은 시스템개발을 하고 다음 프로젝트로 떠나는 경우가 많아서(지속적으로 버전업을 하기 위해 남아있는 개발인력도 있긴 하다.) 시스템에 대한 이해도나 노하우는 운영담당자가 가장 높을 수 밖에 없다. 그러다 보니 운영담당자에게 기대하는 역할이 하나 더 있으니, 그것이 기존시스템의 연장계약을 위한 개선사항 도출과 업그레이드 제안이다. 특히 이 역할은 UX유지보수 역할을 가진 사람이 수행하게 된다.
업그레이드 제안 시 고객측 의사결정자(보통 고객사 임원)는 구현되어진 화면시안을 보고 싶어한다. 사실 글로 아무리 Feature를 설명하는 것 보다 ‘이런걸 만들려고 합니다’ 라고 시안 한장 보내는 것이 나을 수 있다. 하지만 사실 제안이 통과되고 팀을 구축하고 사람을 섭외한 다음 디자이너가 소싱하는 것이 순서이기 때문에, 그 멋진 시안 한장은 운영에서 할 수 밖에 없다.
위에서 말한 부가적인 업무 이외에, UX운영담당자가 기본적으로 해야할 일은 역시 디자인 산출물 관리(화면리스트, 스토리보드, 디자인가이드, PSD파일 등)이다. ‘15-‘16년에 내가 작업했던 내용들을 일부 설명할 예정인데, 개인노하우일뿐 회사의 공식 프로세스가 아님을 먼저 밝혀둔다. 당시 나와 함께 UX운영프로세스를 만들고 운영해갔던 파트너사 미디어포스의 아이디어도 많이 들어가있다.
먼저 산출물 폴더 구조를 정의해야 한다. 파일서버를 이용하는 경우에 활용한다. (요즈음은 클라우드나 협업툴 들이 많이 나와서 파일서버는 잘 사용하지 않는 추세이나, 전체적인 산출물 관리 이해 차원에서 정리해둔다.)
UX산출물 폴더는 크게 4개(관리/기획/디자인/퍼블리싱)으로 나누는 것이 경험상 좋다. 관리폴더는 WBS, 제안서, 보고서, 인력프로필 등을 넣어둔다.
폴더에는 들어가있는 산출물의 갯수를 표기해 놓으면 파악하기 수월하다. Back-up폴더를 만들어서 이전 산출물을 관리하는 것도 매우 중요하다. 운영하다가 이전으로 돌아가는 경우도 매우 빈번하게 발생한다.
디자인 폴더의 경우, PSD파일을 등록하는 공간과 디자인가이드를 넣는 공간을 분리한다. 그리고 디자인의 경우 디바이스별로 또 구분하고, 메뉴별로 구분해둔다. 이렇게 작업해야 체계적으로 관리할 수 있다.
두번째로 파일네이밍(File Naming) 룰을 정한다. 명확하게 정리하지 않으면 버전관리가 어렵기 때문에 처음에 구체적으로 잡아두어야 한다.
스토리보드의 경우 [솔루션명+SB+디바이스+솔루션출시버전+문서최종 업데이트 날짜]로 네이밍을 가져가면 좋다.
PSD파일의 경우 [화면ID+화면이름+포토샵 최종 업데이트 날짜]로 네이밍을 가져가면 좋다.
디자인 가이드의 경우 날짜별로 업데이트 하는 것 보다 최종파일 하나만 관리하는 것이 괜찮겠다 싶어서 [화면ID+화면이름]의 순으로 네이밍을 가져갔다. 디자인 가이드를 PPT로 만들어서 여러페이지로 작업하는 경우도 있는데, 경험상 PSD파일로 만들어서 JPG로 변환하여 개발자에게 한장 한장 전달하는게 서로가 효율적이라 판단되어, 우리는 그렇게 작업하였다.
화면리스트(Raw)
화면리스트(Raw) 3Level의 Raw Data의 엑셀로 정리하였다. 사실 작업하다 보면 2Level에서 멈출 수도 있고, 4Level까지 갈 수도 있는데, 가능하면 3Level에서 멈출 수 있도록 조정한다. 그정도 융통성을 발휘해야 뒤의 작업들이 자동으로 세팅된다. 각 3Level에 적힌 화면명이 포토샵파일(PSD) 한장과 매핑된다.
L1+L2 화면리스트
앞에서 작업한 Raw Data가 잘 만들어져있다면, Level 1 과 Level 2의 값들을 자동으로 가져와서 엑셀의 다른 Sheet에서 IA의 형태로 보여질 수 있다. 이 Sheet를 나는 [L1+L2 화면리스트] 라고 불렀다.
L1+L2+L3 화면리스트
앞과 마찬가지로 엑셀 수식을 통해서 화면에 대한 전체 관리를 하는 하는 Sheet이다. 나는 [L1+L2+L3 화면리스트] 라고 이름붙였다. 이 화면에서 전체 화면 수, 디바이스 별 화면 수 등을 필터링 할 수 있다. 그리고 각 화면별로 WBS를 만드는 엑셀Sheet도 있는데, 그런 엑셀 만드는 방법은 별도로 포스팅 하도록 하겠다. (혹시 이 글을 읽는 우리 회사 사람들이 있다면 메신저 주면 엑셀을 보내 드리겠습니다. 엑셀은 회사의 공식 산출물이 아니고 제가 필요해서 따로 수식걸어서 만든 템플릿 입니다.)
다자인 가이드는 우측상단에 수정한 날짜를 입력했다.
디자인가이드는 수정이 자주 일어나는 문서라 화면단위로 한장씩 PSD파일로 만들고 JPG로 변환하여 개발자에게 전달하는 방식을 선택하였다. (다른 프로젝트에선 PPT로 만들기도 했는데, 사실 이 작업하는 사람은 디자이너라 PPT보다 포토샵이 편하다. 그리고 개발자도 본인이 바꾸어야 하는 내용만 한장으로 받는게 훨씬 편하다고 한다.) 다만 1개의 파일로 관리하기 위해선 폴더관리, 화면리스트 관리가 필수이다.
위에서 캡쳐한 이미지들은 ‘15년도 산출물로 그 이후로 Major버전 업데이트를 2번 더 하였으며, ‘18년부터 종료된 서비스이다. 그래서 화이트라벨링(White Labeling)없이 원본 이미지를 캡쳐해서 올리긴 하는데, 혹시 문제가 있다면 댓글이나 쪽지로 알려주시길
[7]
UX에서 자주 나오는
더블다이아몬드,
디자인씽킹
디자인씽킹(Design Thinking)은 내가 있는 팀에서 가장 중요하게 생각하는 방법론이자 문화 중 하나이다. 이 이론과 실행에 관련해서는 팀의 디자인씽킹 전문가가 잘 정리하여 포스팅한 내용이 있어서 링크로 공유한다.
‘18년부터 회사 공식 블로그에서 시리즈로 설명하고 있다.
디자인씽킹 ① 디자인 편견 깨기! 처음부터 완벽하거나 아름답지 않아도 된다
[BY 삼성SDS] 디자인이라 하면, 흔히 ‘디자인 전공자만 할 수 있는 일’이라는 편견이 있습니다. 필자 ...
naver.me
디자인 씽킹 ② 디자인 씽킹으로 디지털 트랜스포메이션에 날개를 달자!
[BY 삼성SDS] ‘DT(Design Thinking)로 DT(Digital Transformation)를 할 수 있을까?’는 요즘 필자가 많이...
naver.me
디자인 씽킹 ③ 디지털 트랜스포메이션의 날개를 단 리테일 서비스의 새로운 경험
[BY 삼성SDS] 지난 글에서는 디자인 씽킹으로 디지털 트랜스포메이션의 날개를 다는 방법에 대해 이야기...
naver.me
디자인 씽킹 ④ 디자인 씽킹으로 올바른 질문에 올바른 답을 찾는다!
[BY 삼성SDS] 지난 아티클에서는 “디지털 트랜스포메이션의 날개를 단 리테일 서비스의 새로운 경험!”에...
naver.me
디자인 씽킹 ⑤ 아이디어는 혼자가 아닌 ‘함께’ 만드는 것!
[BY 삼성SDS] 지난 아티클에서 “올바른 질문에 올바른 답을 찾는 차량(이동)서비스의 새로운 경험”에 대...
naver.me
디자인 씽킹 ⑥ "상상이 실현되는 순간"
[BY 삼성SDS] 지난 아티클에서는 고객에 대한 이해를 넘어 공감, 소통하며 ‘탁월한 아이디어’를 찾기 위...
naver.me
디자인 씽킹 ⑦ "고객기대를 뛰어넘는 가치 전달하기!"
[BY 삼성SDS] 지난 아티클에서는 디자인 씽킹 (Design Thinking) 네 번째 단계인 ‘상상이 실현되는 순...
m.post.naver.com
디자인 씽킹 ⑧ "고객의 마음을 읽는 지도: Empathy map"
[BY 삼성SDS] 고객이 원하는 제품, 서비스를 기획하고 싶으세요? 고객이 무엇을 원하는지 알고 싶으세요?...
naver.me
웹사이트 중에 this is service design thinking 을 띄어쓰기 하지 않고 쓰는 URL이 있다. 한글버전도 지원하고 있는데, 메뉴 중 ‘Customer Journey canvas’ 라는 템플릿이 무료로 배포되고 있다. UX나 CX 전문가가 아니어도, 서비스 기획을 할 때 템플릿을 따라 Text를 채우다 보면 생각이 정리되는 경험을 할 수도 있다.
This is Service Design Thinking
THIS IS SERVICE DESIGN THINKING This book outlines a contemporary approach for service innovation. »This is Service Design Thinking.« introduces a new way of thinking to beginners but also serves as a reference for professionals. It explains the approach, its back...
www.thisisservicedesignthinking.com
[8]
실리콘밸리에서 온
Agile방식과 Lean UX,
스타트업이 일하는 방법
Agile과 Lean UX 관련해서 잘 설명된 글로, 회사 공식 블로그 URL을 링크한다. 나랑 같은 팀에 있는 동료가 ‘17년에 작성한 글인데, Agile관련하여 (내 주변에서는) 가장 많은 연구를 하고 적용하려고 애쓴 동료이다.
린앤 애자일 UX란? 애자일하고 린하게 UX(Lean&Agile UX) 디자인 하기
[BY 삼성SDS] 최근 한국 기업에서 Lean UX나 Agile UX는 더 이상 낯선 단어가 아니다. 주위를 보면 스타...
naver.me
Agile이란 단어가 세상에 처음나온건 2001년, 올해로 17년이 되었다고 한다. 이제는 Agile이 개발에서 쓰이는 용어라기 보다는 사회의 트렌드로서 자리잡고 있다. 그러다보니 조직이나 프로세스가 아니라 문화로서 Agile을 이야기하는 분위기이다.
[참석후기] UX World 2018 / IDG 주관 / 에어비앤비,페이스북,구글,HSBC,프로그,투비소프트의 UX사례
행사 : UX World 2018 fall 부제 : The Evolution of UX 일시 : ‘181031(수) 9:40-16:50 장소 : 엘...
m.blog.naver.com
위 링크에서 5번째 세션을 보면, HSBC에서 진행한 UX 프로젝트 중에 Design Thinking, Lean UX, Agile을 진행한 이야기가 있다.
Agile만 하더라도 엄청나게 많은 이야기를 해야하지만, 일단 가장 기본이 되는 부분만 말한다면, Happy path 라고 불리는 가장 핵심이 되는 프로세스를 먼저 기획하고, 개발하고, 검증받으면서 계속적으로 개선하며 더 확장한 프로세스를 구축하는 것이다. 이 핵심이 되고 기본이 되는 프로세스를 Agile에서는 MVP(핵심존속제품 : Minimum Viable Product)라고 부른다.
[9]
Waterfall에 익숙한 한국에서
Agile처럼 일하기
과도기 단계의 UX 프로세스
‘16년즈음부터 Agile하게 일하는가? 라는 화두가 스타트업말고 대기업에서도 나오기 시작했다. PM(Project Manager)이 전체적인 요구사항을 분석하여 계획과 범위, 일정, 비용까지 수립한 후, Stakeholder에게 의사결정을 받고나서야 프로젝트를 착수하는 것에 익숙했던 대기업에서는 시행착오가 있을 수 밖에 없었다.
그래서 B2B향 시스템/솔루션 구축에서 약간 변형된 Agile 방식이 나오기 시작했다. 서비스기획부터 UX전략과 디자인 컨셉이 완료되기까지는 Waterfall방식, 그 이후의 양산단계에 이르러서는 프로토타이핑툴을 이용하여 사용자 검증을 받아가며 기능을 개발하는 Agile방식이 혼용되기 시작했다.
솔루션 개발 Process에서의 UX Task와 산출물 (UX 전략과 디자인 컨셉을 뽑을 때까지는 Waterfall방식 + 양산단계에 들어가서는 프로토타입을 통해 사용자 검증을 받아서 기능 개발하는 Agile방식)
일반적인 UX Process는 아래와 비슷할 것이다.
(어디 논문에 나온게 아니고 내가 그린거라 다른의견이 많을 수 있다)
1. Kick-off
2. 비즈니스분석, 사용자분석
3. 사용자 리서치
4. UX전략 수립
5. UI설계
6. 사용자테스트, 검증
7. 비쥬얼디자인
8. 개발
9. 테스트
이 중에서 5~9번 Task를 반복하는 행위에서 Agile하게 일할 수 있는 환경이 만들어지고 있다. 그것 중 하나가 프로토타이핑툴이다.
‘17년즈음부터 프로토타이핑툴(XD, Sketch 등)이 확산되기 시작하면서 UXer 입장에서는 일하는 방식의 큰 변화가 생겼다. 기존에는 UX기획자가 PPT에서 스토리보드를 그리고 정책을 정의하고 비쥬얼디자이너가 포토샵을 열어서 디자인 작업을 했다면, 이제는 두가지 일을 동시에 하는 Full-stack Designer라는 역할이 생긴 것이다.
물론 프로토타이핑툴의 기능도 많이 개선되어야 하고, 툴이 있다고 한들 기획자가 비쥬얼디자이너처럼 디자인센스가 갑자기 생기는건 아니다. 하지만 적어도 기획자가 기획한 내용을 URL로 만들어서 프로토타이핑 형태로 볼 수 있으니 커뮤니케이션 측면에선 좋아진게 확실하다.
그런 관점에서 본다면 짧게는 UXer-개발자 간 커뮤니케이션, 길게는 UXer-고객 간 커뮤니케이션이 빨라지고 피드백을 반영하기 쉬워졌으니 일부 Agile하게 가고 있다고 말할 수도 있겠다.
Agile이란 개념이 처음 생긴 이유가 기획 다 끝난다음에 (혹은 개발중간에) 처음부터 다시 하는 일이 없게 하기 위해서라면, 이 것만으로도 커뮤니케이션의 이슈는 많이 좋아졌다고 본다.
단 ‘18년 기준으로 아직까지 해결이 안되어 고민인 부분은 있다.
먼저 컨셉수립 단계의 문제를 이야기하면, 양산단계(화면을 뽑아내는 단계)는 Agile하게 이렇게 진행할 수 있는데, UX전략과 디자인컨셉을 뽑기까지의 단계는 어찌보면 Insight단계라 Agile하게 되지 않는 문제가 있다. 어찌보면 그 앞단은 개발프로세스가 아니고 기획프로세스이니 Agile이 아닌 것이 맞을지도 모르겠다.
또하나 구축할때의 큰 고민은, 컴플라이언스 중 하도급법의 이슈이다. ACT(Agile Core Team)의 경우 상품기획자-UXer-개발자가 같은 공간에서 긴밀하게 협업하는 모습을 지향하고 있다. 만약 SI사업이라면 고객-UXer-개발자가 같은 공간에서 일한다고 보면 된다. 대형 프로젝트의 경우 자체인력으로는 구축할 인력이 부족하기 때문에 대게 파트너사 계약(외주 소싱)을 하게 되는데, 하도급법에서는 파트너사에게 직접지시 금지를 방지하는 차원에서 공간분리, 업무분리를 가이드 하고 있다. 긴밀하게 붙어서 계속 협업하는데 공간분리를 한다!? 약간 앞뒤가 안맞는 것 같다. 그렇다고 해결할 방법이 없는 것은 아니다. 파트너사에 현장관리자를 리더급으로 놓고, 그 현장관리자가 다른 영역의 사람들과 지속 커뮤니케이션 하고, 그 결과를 다시 수행원에게 전파하는 방식이다. 이 경우 커뮤니케이션 채널 역할을 하는 관리자만 한명 더 생긴게 아닌가 하는 아쉬움이 남는다. 또한 파트너사의 현장관리자가 꼭 한명일 필요는 없다는 가이드가 있기에 파트너사 6명 계약하면서 3명을 현장관리자로 두는 사례도 있다. UXer 업무를 하는 사람 중에 정규(in house Designer)와 외주(파트너사 UX Agecny)의 업무를 명확히 구분해야 하는 문제도 여전히 남아있다. 정규가 UI 기획, 외주가 GUI 디자인, 이런식으로 명확하게 R&R(Role & Responsibilty)가 나누어있는 케이스가 아니라면 결국 애매하게 정규인력이 PMO(Project Management Officer)역할만 수행하고 실제 구현은 외주인력이 진행하는 모습으로 진행되는 것이 다반사다. 스타트업에 최적화된 Agile 프로세스가 파트너사와 함께하는 대형 프로젝트에서도 꼭 적용되어야 하는가? 적어도 프로젝트 기간이 몇개월이 아니라 년단위로 되는 상황에서는 Agile 문화를 Customizing해서 재해석해야 하지 않을까? 라는 개인 생각이다.(회사의 생각이 절대 아니다.)
[10]
Data Analytics를 활용한
사용자행태분석,
점진적인 UX의 개선
처음 구축을 하는게 아니라 기존 버전을 업그레이드 하면서 새로운 기능을 추가한다면 피드백을 받는 범위가 확대될 수 있다. VOC를 받고 사용자행태분석을 통해 지속적인 개선이 가능할 경우의 Agile방식
‘16년에는 빅데이터(Big Data)와 데이터사이언티스트(Data Scientist)라는 말이 유행했고, ‘17년부터는 UX와 Data Analytics가 합쳐지면서 사용자행태분석이라는 단어가 유행하기 시작했다. Google Analytics 뿐만 아니라 Beusable이나 Userhabit처럼 사용자행태분석을 하는 툴들이 나오기 시작했고, 그것을 UX의 개선사항으로 도출하는 UXer, 또는 Data Scientist가 나오기 시작했다. 그 업을 전문으로 하는 컨설팅 Agency가 만들어지기도 하였다.
[책 리뷰] 월간DI (‘18년 2월~7월) / 디아이 / Digital Insight / UX / CX / 디자인 / Data Driven UX
websmedia에서 매달 발간하는[DIGITAL iNSIGHT]라는 책이 있다. (올해가 창간 18주년이라고 ...
m.blog.naver.com
‘18년부터 (주) 아이뱅크에서 월간DI에 Data Anaytics에서의 UX의 중요성에 대해 기술하고 있다. Data-Driven UX Consulting이 중요한 이유로 기존의 UX Research에서는 정량적인 데이터가 아닌 정성적인 분석으로 인해 오차가 발생하고, UX가 개선된 이후에 성과측정의 한계가 있었다는 점을 지적하였다.
최근엔 대규모 페이스리프트 방식(처음부터 다 뜯어고치는 리뉴얼방식)의 IT프로젝트 보다는 마이너하게 사용성을 개선하는 IT프로젝트가 많아지고 있다. 이미 확보된 고객(유저)의 사용성을 행태분석하면서 개선요소를 찾고, 다시 Iteration을 돌면서 업그레이드 하는 방식은 또 하나의 큰 써클이 만들어진다. 이것 역시 Agile이라고 볼 수 있다고 본다.
이 글은 정답이 아닙니다. 제 경험을 기반으로 IT에서의 UX업무 노하우를 정리한 내용이라 보는 사람마다 생각이 다 다를 수 있습니다. 잘못된 내용이나 업데이트 해야할 내용이 있다면 댓글/쪽지로 알려주세요 수정하겠습니다^^ 혹시 다른 노하우를 공유해주실 분들도 연락부탁드립니다
작성자가 투입했던 프로젝트 히스토리
제일모직 ERP 멀티랭기지 적용 (‘07)
코닝정밀유리-코닝 ERP 통합 구축 (‘08)
에버랜드 ERP 구축 (‘08-‘09)
삼성토탈 설비변경 ERP 업그레이드 (‘09)
SDI-Bosch ERP 구축 (‘10)
B2C 교육 서비스 기획 (EBS, 토마토토익 등) (‘11-‘12)
삼성그룹 임직원 교육포탈 SI 구축 (‘12-‘14)
리테일/교육 솔루션 개발 (‘14-‘15)
리테일/교육 솔루션 UX유지보수 PM (‘15-‘16)
사업팀 스탭, 인사담당 (‘16-‘17)
Design Program Manager, UX QAO (‘18)
AI Analytics 솔루션 CX기획 (‘18)
AI, ChatBot 기반 컨택센터 CX PL (‘19-)
'설계 > UX' 카테고리의 다른 글
| UX 디자인 리서치 - 에스노그라피 (0) | 2020.07.10 |
|---|---|
| 가설 수립 방법 - 서비스 기획/UX (0) | 2020.01.05 |
| 전환율을 높이는 쉽고, 구체적인 15가지 social proof 전략 (0) | 2019.12.29 |
| IDEO 디자인 프로세스 (0) | 2019.09.28 |
