2011.08.16

아이폰 업무용 앱 개발 : 버릴 것과 취할 것

Tom Kaneshige | CIO
기술은 특징과 기능을 선호하는 경향이 있다. 하지만 비즈니스 사용자들은 좀더 간소한 기능과 속도를 중시한다. CIO들은 아이폰용 비즈니스 앱을 개발할 때 이 두 세계의 균형을 추구해야 한다.

두께만 10cm가 넘는 3링 바인더를 들고 다니는 영업사원들에게 아이폰 애플리케이션의 보급을 시도한 한 소매제조 기업 사장이 있었다. 이 사람은 결국 실패하고 말았다. 모바일 BI 애플리케이션 롬비(Roambi)를 개발한 멜모(Mellmo)의 공동 창업자인 퀸튼 알즈버리는 실패 원인으로 현장업무의 특성을 무시한 애플리케이션 개발을 지적했다. 방대한 데이터와 기능을 내포한 애플리케이션을 3.5인치인 터치스크린에서 조작하기란 현실적으로 불가능했기 때문이다.

이처럼 오늘날 CIO들은 직원들이 아이폰을 비즈니스 분석과 현장 업무에 활용할 수 있도록 애쓰고 있지만, 대개의 CIO들이 이 과정에서 실패를 경험한다.

부적절한 사용자 경험(UX)을 제공하는 아이폰 애플리케이션은 CIO에게 있어선 골칫거리로 다가온다. 알즈버리는 이에 대해 “사용자들은 새로운 것에 대해 거부감부터 느낀다. 만일 어떤 작업을 수행하는 데 너무 복잡하다 느끼는 순간, 그들은 휴대폰을 다시 주머니 속에 집어 넣어 버릴 것”이라고 말했다.

아이폰 용 비즈니스 애플리케이션에 대한 사용 기대치는 뚜렷하게 나뉜다. 기술자들은 이것의 특징과 기능성에 주목하는 데 비해, 비즈니스 유저들은 사용하는 데의 간편함과 신속성을 기대한다. 이러한 까다로운 입맛을 모두 만족시켜야 하는 CIO들에게 도움을 줄 몇 가지 원칙들을 다음과 같이 소개한다.

노트북을 따라 하지 마라: 많은 CIO들은 노트북에서 보이는 데이터와 기능들을 아이폰 화면에 모두 가져오려는 경향이 있다. 하지만 이는 실패로 향하는 지름길이다. 많은 혹평을 받고 있는 시트릭스 리시버 앱(Citrix Receiver app)의 사용자 경험을 살펴보자. 이는 본래 아이폰을 가상 데스크톱으로 바꾸기 위한 목적으로 개발됐다. 그러나 이를 위해 매번 텍스트를 잡아 확대시키고 마우스도 없이 조그만 가상 키보드 만으로 데이터를 입력하는 과정에 매력을 느낄 사람은 아무도 없었다.

모빌리티에 주목하라: 위와 같은 실수를 일으키는 원인에는, 사용자들이 아이폰을 노트북과 유사한 방식으로 사용할 수 있을 것이라 기대하기 때문이다. 그러나 실제로 이 둘은 전혀 다른 디바이스라는 알아두기 바란다.

다음 세 가지 상황을 가정해 보자: 어느 판매 사원이 책상에 앉아 자신의 컴퓨터로 비즈니스 인텔리전스(BI) 대시보드를 바라보고 있다. 그는 매일 실시간으로 일어나는 데이터의 변화를 관찰한다. 고객을 방문하는 길에 그는 잠시 커피숍에 들러 자신의 노트북을 켜고, 커다란 스프레드시트를 열어 이를 분석한다. 그리고 고객을 만나기 직전 엘리베이터에서는 주머니 속에서 자신의 아이폰을 꺼내 어떤 문제에 대한 간략한 해답을 검색한다.

이러한 작업환경을 위해 CIO들은, 모바일 사용자들이 애플리케이션을 어떠한 작업에 이용하며, 이를 통해 원하는 해결책을 찾을 수 있는지 예측할 수 있어야 한다. 사용자들에게는 데이터를 찬찬히 검토할 만큼 시간이 넉넉히 주어지지 않았을 것이다. 혹은 그들이 위치한 곳에서 인터넷 연결이 어려울 수도 있을 것이다. 하지만 어떠한 상황에서도, 애플리케이션은 신속하고 간편하게 해결책을 제시해줄 수 있어야 한다.

“당신은 사용자들이 (필요한 데이터가 다운로드 될 때까지) 멍하니 스크린을 바라보며 기다리는 것을 원치 않을 것이다. 이를 위해 당신은 서버 기반 솔루션을 적용하기보다는 정보를 접근하기 쉬운 위치에 저장해 두거나, 혹은 적어도 이를 애플리케이션 내부에 캐시(cache)화 해 두어야 한다. 네트워크 접속의 제한이나 단절은 언제라도 발생할 수 있다”라고 알즈버리는 충고한다.

일반화하지 말라: CIO들은 애플이 주는 교훈에 귀 기울여야 한다. 즉, CIO들은 사용자들이 모바일 비즈니스 앱을 좀더 간편하게 작동할 수 있도록 지원해줘야 한다. 많은 경우, 그들은 하나의 애플리케이션 안에 지나치게 많은 기능들을 집어넣으려 애쓴다. 알즈버리는 앞서 소개한 소매제조 업체의 괴상한 애플리케이션을 접한 뒤, 이 애플리케이션을 세 개의 특화된 아이폰 애플리케이션으로 분할하도록 조언했다.

업체의 판매 사원들은 주요 소매점들을 방문해 자신들의 상품이 어느 위치에 진열되어 있으며, 진열 창구에는 어느 정도의 재고가 있는지 등의 정보를 수집하고 기록한다. 그 후 그들은 다른 소매점들이 제품 배치를 변화시킴으로써 판매 증대에 성공한 과정 등과 같은 통계 자료를 활용하여 매장 매니저들과 함께 제품의 판매량을 향상 시킬 방법에 관하여 연구한다. 그리고 마지막으로, 그들은 제품 주문을 성사시킨다.

이 세 단계 모두는 매우 작동이 어려운 하나의 아이폰 애플리케이션을 통해 이루어져 왔다. 멜모는 확연히 구별되는 이 세 단계를 나누고 각각의 과정에 특화된 세 개의 애플리케이션을 개발하였다. 이들 애플리케이션은 몇 초 만에 실행이 가능하도록 설계되어 판매원들은 이제 그들이 필요로 하는 작업을 신속하게 수행할 수 있게 되었다.

이렇게 특화된 개념은 사용자의 영역에 대하여도 적용 가능하다. 모바일 비즈니스 애플리케이션은, 기능과 데이터 측면 전반에 걸쳐, 최대로 간결화할 필요가 있기에, CIO들은 개별 사용자 집단의 요구에 맞춘 다수의 특수 애플리케이션을 개발해야 한다. 모두를 대상으로 만들어진 일반 애플리케이션은, 결국 아무도 조작하지 못하고 사용할 수 없는 것이 되고 만다.

사용자 요구 수집에 시간을 투자하라: 애플리케이션 개발에 착수하기에 앞서, CIO들은 사용자들이 모바일 비즈니스 애플리케이션으로부터 무엇을 원하는지 철저하게 파악해야만 한다. 사전 개발 단계에서뿐 아니라 베타 테스팅(beta testing) 과정에서도 사용자들과 많은 대화를 나눠라. 이는 사용자들이 진정으로 의지할 수 있는 솔루션을 개발하는데 있어 매우 중요한 역할을 한다.

이에 대해 알즈버리는 “효율적인 개발을 진행하려면, 2 주에서 한 달 가량의 시간을 가지고 순수하게 데이터 요구를 정의하는 데에만 집중하라”고 조언했다.

명심하라. 이 단계의 작은 변화가 결과적으로는 사용자 경험을 망쳐버릴 수 도 있다. 시작이 반이라는 격언은, 사용자 수용에서도 예외가 아니다. 이미 벌어질 대로 벌어진 사용자와 애플리케이션간의 거리를 인식하는 순간, 이미 때는 늦었다.




2011.08.16

아이폰 업무용 앱 개발 : 버릴 것과 취할 것

Tom Kaneshige | CIO
기술은 특징과 기능을 선호하는 경향이 있다. 하지만 비즈니스 사용자들은 좀더 간소한 기능과 속도를 중시한다. CIO들은 아이폰용 비즈니스 앱을 개발할 때 이 두 세계의 균형을 추구해야 한다.

두께만 10cm가 넘는 3링 바인더를 들고 다니는 영업사원들에게 아이폰 애플리케이션의 보급을 시도한 한 소매제조 기업 사장이 있었다. 이 사람은 결국 실패하고 말았다. 모바일 BI 애플리케이션 롬비(Roambi)를 개발한 멜모(Mellmo)의 공동 창업자인 퀸튼 알즈버리는 실패 원인으로 현장업무의 특성을 무시한 애플리케이션 개발을 지적했다. 방대한 데이터와 기능을 내포한 애플리케이션을 3.5인치인 터치스크린에서 조작하기란 현실적으로 불가능했기 때문이다.

이처럼 오늘날 CIO들은 직원들이 아이폰을 비즈니스 분석과 현장 업무에 활용할 수 있도록 애쓰고 있지만, 대개의 CIO들이 이 과정에서 실패를 경험한다.

부적절한 사용자 경험(UX)을 제공하는 아이폰 애플리케이션은 CIO에게 있어선 골칫거리로 다가온다. 알즈버리는 이에 대해 “사용자들은 새로운 것에 대해 거부감부터 느낀다. 만일 어떤 작업을 수행하는 데 너무 복잡하다 느끼는 순간, 그들은 휴대폰을 다시 주머니 속에 집어 넣어 버릴 것”이라고 말했다.

아이폰 용 비즈니스 애플리케이션에 대한 사용 기대치는 뚜렷하게 나뉜다. 기술자들은 이것의 특징과 기능성에 주목하는 데 비해, 비즈니스 유저들은 사용하는 데의 간편함과 신속성을 기대한다. 이러한 까다로운 입맛을 모두 만족시켜야 하는 CIO들에게 도움을 줄 몇 가지 원칙들을 다음과 같이 소개한다.

노트북을 따라 하지 마라: 많은 CIO들은 노트북에서 보이는 데이터와 기능들을 아이폰 화면에 모두 가져오려는 경향이 있다. 하지만 이는 실패로 향하는 지름길이다. 많은 혹평을 받고 있는 시트릭스 리시버 앱(Citrix Receiver app)의 사용자 경험을 살펴보자. 이는 본래 아이폰을 가상 데스크톱으로 바꾸기 위한 목적으로 개발됐다. 그러나 이를 위해 매번 텍스트를 잡아 확대시키고 마우스도 없이 조그만 가상 키보드 만으로 데이터를 입력하는 과정에 매력을 느낄 사람은 아무도 없었다.

모빌리티에 주목하라: 위와 같은 실수를 일으키는 원인에는, 사용자들이 아이폰을 노트북과 유사한 방식으로 사용할 수 있을 것이라 기대하기 때문이다. 그러나 실제로 이 둘은 전혀 다른 디바이스라는 알아두기 바란다.

다음 세 가지 상황을 가정해 보자: 어느 판매 사원이 책상에 앉아 자신의 컴퓨터로 비즈니스 인텔리전스(BI) 대시보드를 바라보고 있다. 그는 매일 실시간으로 일어나는 데이터의 변화를 관찰한다. 고객을 방문하는 길에 그는 잠시 커피숍에 들러 자신의 노트북을 켜고, 커다란 스프레드시트를 열어 이를 분석한다. 그리고 고객을 만나기 직전 엘리베이터에서는 주머니 속에서 자신의 아이폰을 꺼내 어떤 문제에 대한 간략한 해답을 검색한다.

이러한 작업환경을 위해 CIO들은, 모바일 사용자들이 애플리케이션을 어떠한 작업에 이용하며, 이를 통해 원하는 해결책을 찾을 수 있는지 예측할 수 있어야 한다. 사용자들에게는 데이터를 찬찬히 검토할 만큼 시간이 넉넉히 주어지지 않았을 것이다. 혹은 그들이 위치한 곳에서 인터넷 연결이 어려울 수도 있을 것이다. 하지만 어떠한 상황에서도, 애플리케이션은 신속하고 간편하게 해결책을 제시해줄 수 있어야 한다.

“당신은 사용자들이 (필요한 데이터가 다운로드 될 때까지) 멍하니 스크린을 바라보며 기다리는 것을 원치 않을 것이다. 이를 위해 당신은 서버 기반 솔루션을 적용하기보다는 정보를 접근하기 쉬운 위치에 저장해 두거나, 혹은 적어도 이를 애플리케이션 내부에 캐시(cache)화 해 두어야 한다. 네트워크 접속의 제한이나 단절은 언제라도 발생할 수 있다”라고 알즈버리는 충고한다.

일반화하지 말라: CIO들은 애플이 주는 교훈에 귀 기울여야 한다. 즉, CIO들은 사용자들이 모바일 비즈니스 앱을 좀더 간편하게 작동할 수 있도록 지원해줘야 한다. 많은 경우, 그들은 하나의 애플리케이션 안에 지나치게 많은 기능들을 집어넣으려 애쓴다. 알즈버리는 앞서 소개한 소매제조 업체의 괴상한 애플리케이션을 접한 뒤, 이 애플리케이션을 세 개의 특화된 아이폰 애플리케이션으로 분할하도록 조언했다.

업체의 판매 사원들은 주요 소매점들을 방문해 자신들의 상품이 어느 위치에 진열되어 있으며, 진열 창구에는 어느 정도의 재고가 있는지 등의 정보를 수집하고 기록한다. 그 후 그들은 다른 소매점들이 제품 배치를 변화시킴으로써 판매 증대에 성공한 과정 등과 같은 통계 자료를 활용하여 매장 매니저들과 함께 제품의 판매량을 향상 시킬 방법에 관하여 연구한다. 그리고 마지막으로, 그들은 제품 주문을 성사시킨다.

이 세 단계 모두는 매우 작동이 어려운 하나의 아이폰 애플리케이션을 통해 이루어져 왔다. 멜모는 확연히 구별되는 이 세 단계를 나누고 각각의 과정에 특화된 세 개의 애플리케이션을 개발하였다. 이들 애플리케이션은 몇 초 만에 실행이 가능하도록 설계되어 판매원들은 이제 그들이 필요로 하는 작업을 신속하게 수행할 수 있게 되었다.

이렇게 특화된 개념은 사용자의 영역에 대하여도 적용 가능하다. 모바일 비즈니스 애플리케이션은, 기능과 데이터 측면 전반에 걸쳐, 최대로 간결화할 필요가 있기에, CIO들은 개별 사용자 집단의 요구에 맞춘 다수의 특수 애플리케이션을 개발해야 한다. 모두를 대상으로 만들어진 일반 애플리케이션은, 결국 아무도 조작하지 못하고 사용할 수 없는 것이 되고 만다.

사용자 요구 수집에 시간을 투자하라: 애플리케이션 개발에 착수하기에 앞서, CIO들은 사용자들이 모바일 비즈니스 애플리케이션으로부터 무엇을 원하는지 철저하게 파악해야만 한다. 사전 개발 단계에서뿐 아니라 베타 테스팅(beta testing) 과정에서도 사용자들과 많은 대화를 나눠라. 이는 사용자들이 진정으로 의지할 수 있는 솔루션을 개발하는데 있어 매우 중요한 역할을 한다.

이에 대해 알즈버리는 “효율적인 개발을 진행하려면, 2 주에서 한 달 가량의 시간을 가지고 순수하게 데이터 요구를 정의하는 데에만 집중하라”고 조언했다.

명심하라. 이 단계의 작은 변화가 결과적으로는 사용자 경험을 망쳐버릴 수 도 있다. 시작이 반이라는 격언은, 사용자 수용에서도 예외가 아니다. 이미 벌어질 대로 벌어진 사용자와 애플리케이션간의 거리를 인식하는 순간, 이미 때는 늦었다.


X