2012년 2월 28일 화요일

다양한 단말에서 디자인하기 위한 프레임워크

총알이 부족해서 S사 스마트TV 를 가지고 있진 못하지만, 여러 기회로 스마트TV 관련 프로젝트에 관여한 적이 있다.
2000년대 초반에는 셋톱박스 개발업체에서 벤처붐을 타고 Slim PC 에 XP를 깔아서 먼가 IPTV 를 만들면서 처음으로 TV에 대한 UX(?)에 대한 나름의 고민을 했었다. 
2007년에는 일본에 수출되는 셋톱박스에 플래시게임을 만드는 프로젝트를 하면서 어쩌면 플래시 게임이 N스크린의 killer contents 가 되지 않을까 하는 희망에 부풀어 오른적도 있었다.

N스크린, Multi-Device 를 고려한 디자인(설계)이란 어떠해야 하는지 잘 정리된 글이 있어 소개 합니다..

Source : Framework For Designing Multi Devices (2011 1 1, UXMegazine)


abulaphiaa 님이 이 글을 친절히 번역해 놓으셨는데 요약하자면

http://abulaphiaa.wordpress.com/2012/02/09/framework-for-designing-multi-devices/


1) 단말이 다르면 경험도 다르다 (Different Devices, Different Experiences) 
    : 모바일웹이나 앱이 단순이 PC 웹이나 서비스를 옮겨놓으면 안된다는것을 명확히 이해하여야 한다.

2) 이용의 컨텍스트를 이해하라 (Understand Context of Use) 

3) 다양한 단말들을 성능이나 유저의 초점에 따라 그룹핑하라 (Define Device Groups)

4) 디바이스 그룹별로 유저의 목표를 찾아내라 (Identify User Goals For Different Groups)

5) 각 그룹별로 확장가능한 레퍼런스 디자인 만들기(Create a Scalable Reference Design For Each Group)
6) 모바일을 먼저 디자인하라 (Designing For Mobile First)

7) 동기화하라 (Synchronize)

8) 디테일을 똑바로 잡아 내라 (Get the Details Right)
  • User가 서비스를 이용하는 자세 (User Posture) : 정지해 있는지 (stationary), 이동 중인지 (mobile), 등을 기대고 있는지 (lean backward), 앞으로 수그리고 있는지 (lean forward)
  • Device Input Capabilites : 카메라, 마이크, 텍스트, NFC, GPS, 자이로스코프, Accelorator 등
  • Device Display Capabilites
  • Navigation Style

9) Mobile Web vs. Native Web
근래에 제안하는 대부분의 내용이 모바일과 PC 를 동시에 대응하는 서비스 제안인 점을 고려하면, 위의 내용대로 각 상황에 맞는 서비스 Design 에 어떤 노력을 쏟느냐가 제안의 성패 나아가 서비스의 성패를 나누는 기준이 되지 않나 생각한다. 

2012년 2월 23일 목요일

UX 테스트, 페이퍼 프로토타이핑(Paper Prototyping)

재미있는 시뮬레이션 방법을 보았기에, 웃어가자는 의미로 공유합니다.
(하지만 굉장히 UI의 사용성 테스트에 있어서 강한 시뮬레이션이라는거~)

이미 우리도 머리속으로 수백번씩 그려보는 과정을 노동을 통해 체험해보는거죠~

페이퍼 프로토타이핑 (Paper Prototyping), 대충 알겠는데 굳이 만들어 봐야하나요?

전체과정을 종이로 한번 만들어서 시뮬레이션을 해 보는 '페이퍼 프로토타이핑'을 해 봅시다. 대충 다 아는데 왜 굳이 그렇게 해야하냐구요? 하다보면 문제점들을 발견하게되고, 그러한 문제를 해결해 줌으로써 나중에 다시 수정을 하는 시간을 줄여줄 수 있으며, 프로젝트의 방향과 사용자의 경험에 대해서도 팀 전체가 생각해 볼 시간을 가질 수 있게되기때문이죠. 게다가 코드를 작성하지 않아도, 디자이너들이 색을 고르고, 그래픽스타일을 정하지않아도 됩니다. 모두가 알아볼 수 있는 글씨로, 실제 나올 비율과 어느 정도 비슷한 수준으로 만들면 충분하기 때문에 제작에 드는 시간도 그렇게 많지 않습니다. 
물론, 이러한 페이퍼프로토타이핑은 팀원모두가 프로젝트를 함께 이끌어나간다는 인식이 있을 때 힘을 발휘할 수 있다고 생각합니다. 예를 들어, 프로그래머는 UX설계에 대해 귀찮아하며, 기획자는 다른이들의 간섭을 싫어하고, 디자이너는 그래픽 디자인 작업이외에 해야할 일들이 늘어만 가는 것 같아 불만을 표시한다면 이러한 페이퍼 프로토타이핑도 결국엔 시간낭비가 되고 말겠지요.

(Youtube에 올라온 Daum 한메일서비스 프로토타이핑 동영상)

2012년 2월 22일 수요일

모바일웹으로 갈까요? 모바일앱으로 갈까요?

2011년은 Mobile Web 과 App 프로젝트를 진행하면서 많은 시행착오를 겪어왔던 한해였다.
모바일 채널의 역할은 ? 어떤 컨텐츠를 담지 ? 공인인증 등 보안솔루션은...
하이브리드 자동차는 알겠는데, 하이브리드 App 은 머지 ? 모바일웹을 App 에 띄우는 건가 ?
고객사, 에이전시, 소규모 개발업체 할것 없이 분주하게 고민을 하는 동시에, 
국/내외 대형 SI는 이 기회를 놓칠세라 앞 다투어 MEAP(Mobile Enterprise Application Platform) 솔루션을 들고 나와 더욱 머리만 복잡해지는 한해였다.

그럼 2012년은 어떻게 될까 ?



기존 기업 웹서비스에서 제공하던 조회/거래, 사이버고객센터 등의 트랜잭션형 App은 이미 다 만들었다. 그럼 Next 는 멀까? 
계속해서 새로운 단말이 나오는데 트랜잭션형 App을 계속 유지해야되나 ? 아니면 모바일웹 형태로 갈까? 

1. Native App 의 특화/심화 (신규 서비스)
2. WebApp 형태의 모바일 웹 서비스 (트랜잭션 App 대체)
3. 반응형 웹으로 모바일 단말까지 대응

기업은 모바일 채널에서 새로운 고객을 찾아야 하고, 이에 필요한 새로운 서비스가 Native App 형태로 최적의 UX를 고려하여 출시 될 것이다. 
다만 아직도 많은 기업이 Hybrid 플랫폼 = 비용절감 이라는 개념을 벗어나지 못하고 있어 당분간은 Hybrid 에 대한 수요도 지속적으로 발생 할 것으로 예상된다. 

트랜잭션형 App은 안드로이드 브라우져개선(크롬 모바일), 보안솔루션 모바일웹 대응, 다양한 WebApp 오픈소스 Front-end 라이브러리 사용이 가능해 지고 있어, 모바일 웹 서비스로 대체될 수 있다.
IE9 보급이 급물살 타고 있고, 크롬의 점유율도 높아지고 있다. 주변에 맥을 쓰는 사람들도 계속 증가하고 있다. 
공인인증을 기반으로 한 다양한 기업 웹서비스들이 웹 접근성 압력, ActiveX 대체 논의가 본격적인 궤도에 오르면서 IE용 PC웹만 만들 논리가 줄어들고 있다.
정보전달형 웹은 당장이라도 반응형으로 만들어서 모든 디바이스에 대응할 수 있다.

결론적으로 웹, 모바일웹, 모바일앱이 자기분야를 제대로 찾아가는 해가 2012년이 아닐까 생각해 본다. 

2012년 2월 21일 화요일

HTML5 Application Cache (appcache)



HTML5에 추가된 appcache 기능
  • 오프라인에서 웹사이트, 앱을 실행시킬 수 있다.
  • 퍼포먼스를 효율적으로 향상시킬 수 있다(페이지 로딩 속도 향상)
<사용법>

html 태그에 manifest 속성을 추가해주면, 오프라인 상태에서도 컨텐츠를 볼 수가 있다.
cache된 파일들에 대한 정보는 아래와 같이 확인 할 수 있다 (개발자툴, F12)

CACHE MANIFEST CACHE: #images /images/image1.png /images/image2.png #pages /pages/page1.html /pages/page2.html #CSS /style/style.css #scripts /js/script.js FALLBACK: / /offline.html NETWORK: signup.html

위와 같이 접속 시 "cache.manifest"에 있는 파일을 읽어 캐쉬에 저장하여, 다음에 접속시 "cache.manifest"만을 받아와서 화면에 뿌려주며, 이 파일을 업데이트 하여 적용할 수 있다.

또한 캐쉬될 파일과 그렇지 않은 파일을 "NETWORK" 스트링을 통해 분류할 수 있으며, 
FALLBACK 리소스로 분류하여 사용자가 네트웍에 연결되지 않았을 때 또는 사이트에 있는 리소스가 캐쉬되지 않았을 때, offlline html이 대신하여 사용자에게 보여질 수 있다.


<설명>
  • # : 캐쉬될 파일들을 지정하는 곳
  • NETWORK : 항상 네트웍을 통해 받아와야만 하는 파일을 지정
  • FALLBACK : 네트웍에서 파일을 받아올 수 없을 때 보여줄 파일
UX디자이너를 위한 5가지 원칙 
5 Guiding Principles for Experience Designers


 
1. 디자인하기 전에 상황을 이해해라.

UX디자이너로 어떤 상황에 직면하게 되었을때는 아무리 급하더라도 비용과 일정을 파악하기전에 그 안건에 대해 근본적인 문제의 원인 그리고 상황을 이해하기 위해 상황에 맞는 적절한 질문을 하는 능력이 필요합니다. 당신이 이해하지도 못하는 문제를 해결하기 위해 소중한 시간을 낭비하지 마세요.


2. 아무도 다치지 않게 한다.

이 원칙은 당신이 이 일을 하는 동안 당신을 보호해주며, UX 디자인의 긍정적인 측면을 주위로 전파하기 위해 아주 중요한 원칙입니다. 어떠한 경우라도, 최소한 당신이 함깨 일해야 하는 동료에게 상처를 주는 일은 꼭 피해야 합니다. 만약 본의 아니게 누군가가 상처를 받게 되었다면 이후에라도 그 이유와 의도를 충분히 설명하고 빨리 상처를 치료해 주도록 합니다.


3. 유연한 UX디자인을 한다.


우리가 디자인 한것은 쉽게 만들어야 하고, 가능한 의도가 쉽게 이해되고, 결정이 아니라 논의가 가능한 유연한 상태라야 합니다. 그리고


4. 모든 유져가 당신과 같지 않다는 사실을 인정한다. 


사람은 모두 자신만에 생각과 주관을 가지고 있습니다. 그리고 각자의 개성과 DNA와 가족관계, 문화적차이, 생활수준, 현재와 과거의 경험의 영향을 받습니다. 가장 흔한 실수 중에 하나인 UX디자이너를 위한 산출물을 만들고 지나친 확신을 갖지 않도록 늘 조심해야합니다. 항상 유져들의 대부분이 이해할만한 객관성을 확보하기 위해 적합한 방법을 검증하며, 새로운 의견에 귀를 열어두어야 합니다.


5. 공감하고, 더 좋은 경험을 디자인하라.



공감은 다른사람을 이해하고 감정을 느낄 수 있는 특별한 능력이지만 한 걸음 떨어져서 당신의 관점으로 다른사람을 이해하는 일이 결코 쉬운일은 아닙니다. 사람들을 이해하기 위해 다양한 방법을 시도해보고, 명확하지 않은 부분이 있다면 더 많이 질문하세요.

당신이 어떤 방법을 통해서든 유져를 이해하고 공감할 수 있다면 우리는 UX를 통해 더 좋은경험을 느끼는 멋진 세상을 더 빨리 만들 수 있습니다.


[출처] [본문스크랩] UX 디자이너를 위한 5가지 원칙 + 가이드모듬 (어비의 웹표준, 모바일 웹) |www.standard.pe.kr

인포그래픽과 SNS

바이스 버사 디자인 스튜디오에서 만든 인포그래픽이다.
진행중인 프로젝트에서 금융상품의 특징에 대한 커뮤니케이션을 인포그래픽으로 하고자 하는 디자인PL 의 의지가 있었지만...
실상 금융상품 특히 펀드나 보험은 상품마다의 특징이나 설계의도를 뽑아내기가 쉽지 않게 되있어서 컨셉을 포기했다.

디자인 영역에서 인포그래픽이라는 특화된 부분으로 포지셔닝을 한 바이스 버사 멋지다.

온라인 채널 특히 모바일, SNS 채널에서 그래픽을 통한 커뮤니케이션이 텍스트에 비해 매우 효과적인것은 상식적인 이야기일텐데, 인포그래픽 수요는 국내시장에서도 꾸준이 증가할 것이며, 특히나 SNS 마케팅 붐이 ROI 나 운영적인 측면에서 한풀 꺽여가고 있는 마당에 좋은 소재가 되지 않을까 싶다.

각 업체에서 자체 보유한 데이터를 분석하고 멋진 인포그래픽으로 SNS 로 흘려보낸다면, 이벤트나 가쉽거리 일색인 SNS 마케팅에 활력으로 다가오지 않을까 생각해본다.


http://v-vdesign.com/

2012년 2월 20일 월요일

반응형 웹 - 현대자동차 기업문화 홍보사이트


현대자동차의 기업문화 홍보사이트
국내에 반응형 웹 디자인이 소개된지 1년여 지난시점에서
지금까지 제작된 상업용 국내 사이트 중 가장 훌륭한 수준의 사이트다.
경쟁사에서 제작하였지만 여기에 쏟았을 그들의 노력에 찬사를 보낸다.

http://pr.hyundai.com/































2012년 2월 14일 화요일

UI사용성 테스트


사용성 테스트란?
사용자의 니즈를 충족시키는 지를 더 명확히 이해하기 위해 반구조적인 인터뷰 방식



사용성 테스트를 하는 이유는 ?
코딩에 앞서 사용성 테스트를 진행하면 시간과 비용을 절약할 수 있다.
UX 문제점이 발견된다면 코딩이 끝난 앱보다는 프로토타입을 수정하는 편이 훨씬 적은 비용이 든다.

사용성 원칙이 잘 지켜지는 사이트란?
사용자가 사이트에서 찾고자 하는 정보를 쉽게 찾거나 기능이나 서비스를 쉽게
이용할 수 있도록 환경이(UX) 잘 조성된 사이트를 의미.

사용성원칙 1. 시각적 명확성
- 사용자가 사이트에 방문한 목적과 의도에 의한 정보가 한눈에 보일 수 있도록 시각적으로 명확하게 화면 구성을 해야 한다.

사용성원칙 2. 행동 유도성
- 메뉴/버튼/아이콘/이미지 등 사용자의 눈에 잘 띄도록 배치하여 사이트에서의 행동패턴을 유도한다.

사용성 원칙 3. 시스템의 반응
- 화면 구성 요소 선택 시 직관적인 반응이 일어나 사용자에게 시스템적 현재 상태를 명확하게 인지 할 수 있게 해주어야 한다.

사용성 원칙 4. 사용 편의성
- 사용자가 내비게이션이나 기능을 조작할 때 통제/제어/취소 등 기본적인 툴을 이용하기 쉬워야 한다. 메뉴에 대한 기능을 쉽게 조작할 수 있도록 도움말을 제공하여 기능 조작의 편의성을 높여야한다.

사용성 원칙 5. 사용자가 예상하는 행위와 대응의 일치성
- 사용자가 수행하기 전 예상한 행위와 실제 수행 했을 때 결과가 일치


1단계 – Step.1 사이트 역할을 정의한다.
일반적으로 기업은 사이트 운영을 통해 매출이나 광고 수익 증대 등 어떤 특정 목적이 있다.
하지만 특정 목적이 명확하지 않다면 사용성 테스트를 통해 무엇을 확인하고 검증해야 하는지 조차 명확히 정의하기 어렵다.

1단계 – Step.2 사용자가 사이트에서 주로 하는 활동을 정의한다.
사이트의 역할을 정의하였다면 웹 서비스를 제공하는 목적에 맞춰 사용자가 주로 하는 활동을 정의한다.

1단계 – Step.3 사용성 테스트를 통해 반드시 확인하고 싶어하는 사항을 과제 목록으로 정리한다.
관점이나 목표에 따라서만 확인하고 싶은 사항을 정리해도 좋지만 보다 편리한 테스트 진행을 위해 사이트 전체에 대한 관점 이나 목표를 거시적으로 세워 놓고, 페이지 별로 나누어 페이지 하나하나에서 필요로 하는 목표를 정리한다.

1단계 – Step.4 사용성 테스트 목표를 최종 정리한다.
종합적으로 사용성 테스트를 통해 무엇을 확인하고 무엇을 검증할 것인지 사용성 테스트 목표를 수립한다.



2단계 – Step.1 디지털 소비자의 웹 라이프스타일을 분석한다.
LG경제 연구원에서는 디지털 소비자를 5가지로 정의하였다.

1. 트레져 헌터 Treasure Hunter
가격 대비 최고의 가치를 주는 상품을 구입하기 위해 끊임 없이 정보를 탐색하는 소비자
= 제품정보를 스스로 자세히 파악할 수 있도록 제품에 대한 상세한 소개, 제품 사양 등 스마트한 소비 환경 조성이 필요하다.

2. 아티젠 Arty Generation
-상품에 에술을 결합한 아트 디자인을 선호하는 소비자 집단
= 프리미엄 제품의 고급스러운 이미지를 어떻게 담을 것인가 고려해야 한다.

3. 크리슈머 Cresumer
-창조적 소비자 집단으로 기업의 제품 개발, 디자인, 판매 등에 적극적으로 개입하려 하는 집단
= 제품 체험단이나 커뮤니티 그룹을 양성하여 사이트 운영에 함께 참여 할 수 있는 환경 조성

4. 몰링 Malling
-대형 복합 쇼핑몰에서의 쇼핑을 즐길 뿐 아니라 오락 등 여가 활동을 즐기는 집단
= 사이트에 흥미와 관심을 유도할 수 있는 콘텐츠 제공이 요구 된다.

5. 마이크로 미디어 Micro-media
-1인 미디어인 UCC, 블로그, 미니홈피 등 제작 + 공유하는 적극적 정보 생산자
= 사이트 자체 제공 콘텐츠를 블로그나 SNS서비스에 담아갈 수 있도록 콘텐츠 배포 및 확산 정책 요구

2단계 – Step.2 스마트 소비자의 구매 동선별 웹 라이프스타일을 분석한다.
1. 제품 정보를 습득하려고 할 때
- 쇼핑몰 사이트를 통해 제품 정보를 찾고 후기 위주로 제품 정보를 살펴 본다.
= 제품 모델을 결정하는 데 도움이 될 수 있도록 신제품, 인기제품, 추천 제품을 적극적으로 소개할 필요가 있다.

2. 제품 사양을 비교하려 할 때
- 제품정보 습득 후 포털 사이트의 블로그, 지식IN 등을 통해 특,장점을 파악한다.
= 제품 모델을 결정하는 데 도움이 될 수 있도록 신제품, 인기제품, 추천 제품을 적극적으로 소개할 필요가 있다.

3. 사용자 라이프 성향에 적합한 제품을 찾고자 할 때
- 자신의 라이프 성향과 비슷한 제품을 찾고자 할 때 특화된 제품 정보를 제공하는 카페나 블로그 등에 방문하여 지식을 얻는다.
= 소비자 라이프스타일에 최적화된 제품 모델을 선정할 수 있도록 맞춤형 제품 검색 환경을 조성할 필요가 있다.

4. 대리점에 방문하고자 할 때
- 제품의 성능, 기술, 디자인 등을 직접 눈으로 확인 하려 한다.
= 제품 모델의 기술력이 돋보이도록 제품 체험과 디자인이 시각적으로 잘 나타날 수 있게 해야한다.

2단계 – Step.3 사용자가 사이트에 방문하여 주로 하는 일을 정리한다.
디지털 소비자와 스마트 소비자의 관심 성향에 맞춰 사용자가 사이트에 방문하여 주로 하는 일을 각각 정리한다.

2단계 – Step.4 사용자가 사이트에 방문하여 주로 하는 일을 전체 태스크 목록으로 정리한다.
디지털 소비자와 스마트 소비자의 관심 성향에 맞춰 사용자가 사이트에 방문하여 주로 하는 일을 각각 정리한다.
= 사용자가 사이트에 들어와서 주로 하는 일을 분석하기 쉽다.



3단계 태스크 하이어라키클 구조를 완성한다.
참여자마다 제품 검색 이용 패턴이 달라 제품 검색과 관련된 다양한 태스크를 엿볼 수 있다.


4단계 워크플로우 태스크다이어그램[Workflow Task Diagrams]을 구성
상위 태스크와 하위 태스크 간의 하이퍼링크 연계 구조를 한눈에 파악할 수 있도록 구성



5단계 주요 이동 동선별 사용성 이슈 사항을 정리한다.
사용자의 주요 이동 동선별 이슈 사항을 정의하는 이유는
현업에서는 이슈 사항에 대해 어떠한 고민을 하고 있는 지 현업에서 고민하고 있는 문제를 사용자 조사 방법을 통해 검증 하고 사용성 테스트 목표를 정의하는데 실질적인 도움이 되기 때문이다.



출처 :[도서] UI사용성 테스트 실무


성공적인 웹사이트 구축을 위한 9가지 역할

성공적으로 웹사이트를 구축하기 위해서는 크게 3가지 관점에서 고려할 역할들이 있다.

1. 기술적인 역할
2. 사이트와 관련한 역할
3. 콘텐트와 관련한 역할

이 역할들을 우선 전략적인 관점에서 설계하고, 그 후 전술적인 구현과 실행을 하게 된다.
웹 기획자들은 일반적으로 사이트와 콘텐츠에 관련한 역할을 주로 맡아서 프로젝트에 참여하게 된다.
  • 사용자 리서치
    전략적인 설계의 기반은 사용자에 대한 파악에서 시작된다. 사용자 리서치를 수행하고 그 결과를 이용해서 사이트와 기술, 콘텐트 전략을 수립한다.
     
    - 사용자 니즈를 깊이 이해하고 니즈를 충족시키는 방법을 찾는 단계
    - 니즈를 토대로 충분한 정보에 근거한 디자인 결정을 내릴 수 있다.

    리서치방법
    -그림자 기법 : 조사자가 참가자를 일정 기간 따라다니면서 관찰 내용 기록하는 형태
    -현장 인터뷰 : 조사자가 질문을 사전에 준비하고 참가자의 반응을 보며 진행하는 형태
    -전화 인터뷰 : 비용이나 시간적 제약으로 여의치 않을 때, 전화,아이챗,스카이프 등을 이용하여 비디오 컨퍼런스를 이용한 형태
    -길거리 인터뷰 : 길거리에서 사람들이기 직접 접근하여 진행하는 형태
    -포커스 그룹 : 일반적으로 6~10명가량의 참가자로 구성되며 그룹별로 인터뷰를 진행하는 형태

    사용자 인터뷰 기록
    -노트 : 손수 적거나 하나도 빠짐없이 타자로 치는 식
           (기록자의 성향, 활용 가능한 자원에 영향을 받는다)
    -수기노트 : 사용자가 한 말을 빠짐없이 옮길 필요가 없을 때 적절한 노트 작성 방식
               (정확하게 기록하고 싶다면 음성녹음도 함께 진행하는 것이 좋다)
    -카메라(사진) : 평소 행동에 대한 것들을 사진으로 기록하는 식
                 (조사자가 참가자의 컴퓨터 설정과 사용 컨텍스트를 찍는 일이 중요하다)
    -오디오 : 인터뷰의 모든 것을 녹음하는 방식
             ( 손수 노트에 적는 것보다는 효과적인 방식이나 잡음을 고려하지 않는다면 노트보다
              못한 방식이 될 수 있다)
    -비디오 : 인터뷰의 모든 것을 영상으로 남기는 방식
             ( 참가자의 행동을 잡아낼 수 있는 가장 포괄적인 방법)

  • 프로젝트 관리
    전술적인 구현을 진행하는 과정에는 프로젝트의 시작부터 끝까지 전반적인 구현과 개발 상황을 점검하는 프로젝트 관리자가 필요하다. 기술 구현과 사이트 구현, 콘텐트 출판을 전반적으로 관리한다.
     
  • 기술 전략
    사이트 구축 이전에 어떤 기술을 사용할지 결정해야 한다.최근에는 사이트 구축 시 다양한 기술을 사용할 수 있으며, 어떤 기술을 사용하는지에 따라 화면 구성과 기획 내용이 달라질 수 있다.
      경쟁사 분석
      - 경쟁사 UX분석은 우수 사례는 물론 피해야 할 접근 방식을 찾는 데에도 도움이 된다.

     우수 사례
     - 우수 사례는 플로우, 화면 레이아웃, 컨트롤과 용어를 포함한 거의 대부분의 UX측면을 아우른다
    - 경쟁사의 잘못을 제대로 파악하면 진행해야 하는 것에 대한 인사이트는 물론 어떠한 기술을 접목 시킬지 계획할 수 있다.
       

  • 기술 구현
    개발자들이 기술에 대한 실제 구현을 진행한다. 기술의 복잡도가 높을 수록 개발에 전문적인 지식이 필요해지고, 테스트와 디버깅에 많은 시간과 노력을 투자해야 한다.
     
  • 사이트 전략
    사이트의 목표와 수익구조 등을 결정한다. 사용자의 요구 사항을 어떻게 사이트에 반영하고 그것을 수익에 연결할 것인지 고민한다. 사이트의 목표를 어떻게 설정하는지에 따라 이후의 전반적인 설계 방향이 결정된다.

      효과적인 브레인 스토밍은?

     - 충분한 시간을 배정한다.
    - 10분 휴식을 2~3번씩 갖는 2~3시간 가량의 브레인 스토밍을 진행한다.
     - /앱의 컨셉을 브레인스토밍하는 것인가?
       기존의 아이디어를 바탕으로 하는가 ? 명확한 목표가 필요하다. 
   - 혼자서 하는 브레인스토밍보단 공동 세션으로 진행하는 브레인 스토밍이 더 효과적일 수 있다.
     - 여러 관점의 퍼소나 입장에서 해결책을 고려하며 진행한다.
     - 꼭 회의실 안에서만 아이디어가 도출되는 것은 아니니 주제에 맞는 다른 장소에서 경험하며 브레인 스토밍을 진행해도 무관하다.
     - 기본원칙을 세워라
       (Bob Sutton에 의한 대표적인 원칙)
     - 비판금지/엉뚱한 생각 격려하기/질보다 양/다른 아이디어와 조합하거나 개선하기

   - 브레인 스토밍의 원초적 목표는 질보다는 양에 의해 다양한 아이디어를 꺼내어 보는 것이다.



  • 사이트 설계
    구축될 사이트의 구조를 설계한다. 인포메이션 아키텍처와 인터랙션 디자인 은 사이트 전략을 구조화된 설계로 만들어내는 과정이며 사이트의 뼈대를 만드는 작업이다.
     
  • 사이트 디자인
    사이트 설계가 실제 사용자 경험이 되기 위해서는 각종 인터페이스와 내비게이션 및 메뉴, 인포메이션 디자인의 요소들이 비주얼 디자인의 결과물로 나와야 한다.
     
  • 콘텐츠 전략
    사이트의 목적을 달성하기 위해서 사용자에게 어떤 콘텐츠를 제공할 것인지 정의한다. 제공할 콘텐트의 양과 형태를 결정하고, 누가 어떻게 콘텐츠를 생성할 것이며, 콘텐츠를 승인하고 관리 할 주체는 누구인지 등 콘텐트와 관련한 다양한 전략적 이슈를 결정한다.
     
  • 콘텐츠 출판
    콘텐트에 대한 전략을 수립한 이후에는 실제로 콘텐트를 작성해야 한다. 기초 자료를 수집, 정리하고, 원하는 형태의 글을 쓰고, 수정을 하고 승인을 거친 후 최종적으로 사용자에 내용을 전달해야 한다.

웹사이트를 구축하고 운영할 경우 지금 소개한 9가지 역할은 필수적인 것들이다.
이 중 한 두 가지 역할이 요청되는 수준보다 약하게 충족된다면, 사이트의 전반적인 품질은 나빠질 것이다.
각각의 기업에는 다른 영역보다 강점을 가진 영역이 있다.
기술적인 기반이 튼튼한 경우, 디자이너의 능력이 뛰어난 경우, 그리고 많은 필진을 보유한 경우 등 다양한 경우가 있겠지만 그것만으로는 한계가 있다. 성공적인 사이트 운영을 위해서는 강점을 가진 영역 외의 다른 역할들도 균형 있게 고려할 필요가 있다는 것을 명심해야 한다.

출처 : http://bahns.net/2642847
          [도서] Designing the iPhone User Experience

2012년 2월 13일 월요일

Agile(에자일) 방법론

UX design process 중 Agile 방법론에 대한 자료 공유합니다.


Agile 방법론이란, 프로세스나 도구보다 의사소통을 강조함으로써 요구사항변경에 적극적으로 대처하고,  시스템 변경사항을 유연하고 기민하게 대응할 수 있도록 하는 개발 방법론을 뜻하는 총칭이다.
전통적인 개발 방법론과 Agile 개발 방법론은 각각의 장단점을 가지고 있다.
따라서 전체적인 개발 방법론은 전통적인 개발 방법론과 같이 각 단계별 절차와 계획에 따라 정하고, 경우에 따라 각 모듈 별 세부 개발시에 Agile 개발방법론을 도입학는 것이 유용하다.



Agile의 주요 방법론 유형
  • XP(eXtreme Programming) : 개발방법론 혹은 개발 기법 중심
  • SCRUM : 프로젝트 관리 방법론 중심
  • RUP : 반복, 점진적인 개발방법론을 대표
  • LSD(Lean Software Development) : 식스시그마 품질 선도
  • DSDM(Dynamic System Development Method) : 점진적 개발, 일정 확정, 범위예측
  • FDD(Feature-Driven Development) : 기능주도 개발

XP (eXtreme Programming)
1) XP 개요
  • 1990년대 후반 만들어진 개발 기법 중심의 Agile 방법론 중 하나이다.
  • 반복형 모델의 개발주기를 극단적으로 짧게 함으로써 개발자가 설계, 구현, 테스트 활동을 전체 소프트웨어 개발 기간에 걸쳐 조금씩 자주 실시하도록 하고 소프트웨어 변경의 비용을 최소화하는 기법이다.
2) XP 목적
  • 기본 가치, 원칙, Pracices을 통하여 변경 비용 및 일정 감소
3) XP 주요 활동
  • Coding : 시스템 개발활동의 진짜 중요한 산출물은 코드
  • Testing : 단위테스트는 코딩의 불확실성을 검증하고 승인테스트는 의도에 대한 불확실성을 검증
  • Listening : 비즈니스에 의하여 기능 결정, 기능 결정에 의하여 비즈니스를 파악
  • Designing : 시스템의 복잡성, 종속성 회피를 위한 방법
4) XP 프로세스
  • 유저스토리
           고객이 자신이 원하는 내용을 기술한다.
           릴리즈 계획 및 승인테스트 계획의 기반이 된다.
  • 스파이크솔루션
           기술적 또는 설계상의 어려운 문제를 해결하기 위한 것이다.
           기술적인 문제를 줄이고 유저스토리의 추정한 개발일정의 신뢰도를 높이는 것이다.
  • 메타포어
           일관된 명명규칙을 이용하여 클래스와 메소드 등을 명명
  • 릴리즈계획
           주기(1~3주)의 시작마다 회의를 통한 처리할 유저스토리를 고객과 선정한다.
           고객관점의 유저스토리를 개발자관점의 프로그램으로 변경하여 진행한다.
  • 주기
           릴리즈 계획에 따른 개발을 의미
           해당 주기가 시작될 때 주기 계획회의를 통해 주기에 해야할 일을 결정한다.
  • 승인테스트
            각 주기의 유저스토리에 대한 처리완료 기준이 된다.

5) XP 핵심가치
  • 의사소통 : 단순한 디자인, 공통의 메타포어, 사용자/개발자간 협업, 빈번한 구두 의사소통, 피드백
  • 단순성 : 단순한 솔루션, 단순한 설계, 단순한 코드(의사소통의 질 향상)
  • 피드백 : 시스템, 고객, 팀으로부터의 피드백
  • 용기(Courage) : Practice 수행을 위하여 용기 필요. 간단한 디자인, 간단한 코딩
6) XP 원칙
  • 피드백, 단순한 가정, 변화 수용
7) XP Practices
  • 정교한 피드백 : 페어 프로그래밍, 게임 계획, TDD, 전체 팀
  • 지속적 프로세스 : 지속적 통합, 리팩토링 또는 디자인 개선, 작은 배포주기
  • 이해의 공유 : 코딩 표준, 코드 공동 소유, 간단한 설계, 시스템 메타포어
8) XP 활용 분야
  • 모바일이나 쇼핑몰처럼 소비자의 변화에 따라 짧은 시간에 민첩하게 변화되어야 하는 분야
  • 요구사항 등의 변화가 자주, 많이 발생하거나 개발자가 소규모이고 같은 공간을 사용하는 경우에 높은 효과
  • 유동성이 큰 프로젝트, 단 기간의 프로젝트
  • 기술적으로 신기술을 도입하였거나 경험이 없거나 한 경우
 SCRUM
1) SCRUM 개요
  • 비즈니스 요구를 충족시키는 소프트웨어를 개발하는데 초점을 맞추기 위해 복잡함을 제거하는 관리 및 제어 프로세스이다.
  • 사람들이 효과적으로 협업할 수 있게 해주며 그로 인해 복잡하고 정교한 제품을 생산할 수 있게 해준다.
  • 프로젝트 관리 방법론 중심의 Agile 방법론이며 XP의 실천 방법으로 사용한다.
  • 작은 개발팀, 짧은 개발주기(4~6주) 반복 등의 특징이 있다.
2) SCRUM Process
  • 제품 백로그(Product Backlog)
           시스템이 해결해야 하거나 시스템에 포함되어야 할 모든 것으로 기능, 특성과 기술을 모두 나열한다.
           모든 요구사항을 우선순위에 따라 나열한 목록을 말하며 결코 확장되지 않고 제품과 함께 성장하고 진화한
           다.
           우선순위가 가장 높은 항목이 가장 필요한 항목이다.
           백로그 내용은 누구나 제안할 수 있지만 제품 책임자만이 백로그 항목들의 우선순위를 부여할 수 있다.
  • 스프린트(Sprint)
           약 30일의 반복 주기로 개발 가능하다고 생각되는 만큼의 기능을 제품 백로그에서 선택한다.
           매 스프린트 끝에는 새로운 기능이 추가되어 실행 가능한 제품이 인도되어야 한다.
           아키텍쳐와 설계는 첫 스프린트에서 완료되는 것이 아니라 여러 번의 스프린트를 거쳐야 드러나게 된다.
  • 스프린트 백로그(Sprint Backlog)
           팀이 해당 스프린트에서 수행할 태스크 목록
  • 스크럼 마스터(SCRUM Master)
           팀원들이 스크럼의 실천법을 실천하도록 강제하고 팀이 결정을 내리거나 혹은 자원을 얻을 수 있도록 돕는
           다.
           스프린트 동안 팀은 외부의 어느 누구에 의해서도 방해를 받거나 지시를 받아서는 안된다.
  • 일일스크럼(Daily SCRUM)
           약 15분 정도의 매일 하는 짧은 회의
           일일 스크럼에서 관리자는 진행 사항을 검토하고 제거해야 하는 장애물을 확인한다.
           일일 스크럼에서 팀의 진척 정도를 확인할 수 있다.

TDD (Test Driven Development)
1) TDD 개념
  • 미리 작성되는 테스트를 기반으로 짧은 반복주기를 이용하여 소프트웨어를 개발하는 기법이다.
  • 테스트 작성을 통해 요구사항을 정의한다.
  • TDD는 단순한 테스트 기법이 아닌 소프트웨어 설계의 한 기법이다.

2) TDD 요구사항
  • 테스트 작성 -> 코드 작성 -> 테스트 실행 -> Refactoring
  • 반복주기 1~n 수행
            테스트작성 : 요구사항을 명확히 이해, 유스케이스, 유저스토리 등 이용
            테스트검증 : 테스트케이스의 올바른 작동 여부 확인
            코드 작성 : 완벽하지는 않지만 테스트는 성공할 수준        
            자동화된 테스트 실행 : 모든 테스트 요구사항 충족 확인
            Refactoring : 불필요한 코드, 중보코드 제거
            반복 : TDD 사이클이 길어지면 규모 조정 필요
3) TDD 효과
  • 품질 및 생산성 향상
  • 더 빠르고 좋은 소프트웨어 빌드
  • 작성 코드에 대한 테스트 커버리지 보장
  • 모듈화, 유연한/확장 가능한 코드 생성

4) TDD 제약


  •  성공 확인을 위하여 모든 기능을 테스트 하여야 하는 경우 적용 어렵다.
  • 관리자의 지지가 필수적으로 필요하다.
  • 전통적으로 테스트에 대하여 개발자가 아키텍트에 비하여 상대적으로 낮은 인식을 가지고 있다.
  • 테스트 자체가 프로젝트 유지보수 오버해드가 된다.


출처 : [사이트] http://searchstory.tistory.com/268

모바일/웹 UI 패턴, 쇼케이스, 가이드라인 및 리소스 URL

UI Guidelines by OS provider

AppleApple Human Interface Principles
iPadiPad UI 가이드라인 (번역)
AndroidAndroid User Interface Guidelines
Windows Mobile UX Guideline
User Experience Design Guidelines for Windows Phone (2011.12.15)  updated!
Windows Mobile Design Guideline
WM Design Guidelines  (2010.4) - WM 6.5 기준
BlackBerryBlackBerry Smartphones UI Guidelines
WebOSWebOS User Interface Summary
MotorolaBest Practices for User Interfaces
NokiaDesign and User Experience Library 
SonyEricssonSony Ericsson UI Rulebook
BadaBada Application UI Guide
Design Pattern - Mobile

콤포넌트별 모바일 UI 패턴
  
PttrnsApple iOS Patterns
Mobile Patterns콤포넌트별 모바일 UI 패턴
Mobile UI Patterns콤포넌트별 모바일 UI 패턴 ※ FourSquare 리드 디자이너 Mari Sheibley가 운영
Mobile Design Pattern GalleryUI Patterns for iOS, Android and More
Pattern of Design베스트 앱 디자인 갤러리
Lovely UI모바일 UI 콤포넌트 갤러리 
ANROID PATTERNS안드로이드 - 사용자 액션별 UI 패턴 가이드
Cocoa ControliOS와 Mac OS X를 위한 커스텀 UI 컨트롤

Showcase - App
베스트 모바일 앱 디자인 모음
IOS Inspires MeiOS 베스트 앱/웹 및 앱 아이콘 갤러리
iOSpirations베스트 아이폰/패드/웹/아이콘 디자인 쇼케이스 (게임앱 포함)
Refined Mobile모바일 웹 UI 디자인 쇼케이스 
TappGala베스트 모바일 인터페이스 디자인
TheyMakeApps앱 전문 에이전시 및 업체별 포트폴리오 디렉토리
FWA Mobile Showcase모바일 웹/앱 쇼케이스 (mobile view)
MakeBetterApps아이폰 아이패드 맥 앱 쇼케이스 (독일어 - 유럽쪽 앱들)
Landing Pad베스트 아이패드 앱 쇼케이스
Dribble디자인 공유 사이트인 드리블 'Mobile' 태그 - 각종 베스트 디자인 요소


Showcase - Mobile Web

베스트 모바일 웹 디자인 모음
29 Simple Intuitive Mobile Web Designs심플하고 멋진 모바일 웹 디자인 모음 updated!
Mobile Awesomeness모바일 웹사이트 쇼케이스
jQuery MobilejQuery로 만들어진 사이트/앱 모음
CSS iPhone아이폰 모바일 웹 디자인 쇼케이스

Showcase - Website for app
앱 프로모션용 웹사이트 모음

App Sites아이폰 아이패드 앱용 웹사이트 쇼케이스
D-Lists아이패드용 웹사이트 쇼케이스
34 Inspiring iPad Application Websites아이패드 앱용 웹사이트 34 
30 Beautiful iPhone Application Websites아이폰용 웹사이트 30 updated!


Design Pattern - Web (PC)
컴포넌트별 웹사이트 UI 패턴
UI Patterns컴포넌트 웹 UI 패턴 
Patternry컴포넌트 웹 UI 패턴 
Pattern Tap컴포넌트 웹 UI 패턴 
Yahoo Design Pattern Library야후 디자인 패턴 라이브러리
Design Pattern Library컴포넌트 웹 UI 패턴 
50 Interesting Navigation Menus50개의 이색적인 네비게이션 링크
Creattica그래픽, 플래시, 로그, CSS, 웹인터페이스 등 종합 디자인 쇼케이스



Tip & Etc., 


디자인, UX 팁
Android UI Design Tips안드로이드 UI 디자인 팁 (구글)
Designing For Android Tablets안드로이드 허니컴 태블릿 앱 디자인 (번역)
Android UI Desing PatternsGoogle I/O 2010년 발표 자료
Top 10 Mobile Site Best Practice구글의 GoMo initiative에 있는 10 Mobile Site Best Practices 


디자인 리소스 모음
아이폰 아이콘 디자인 소스GLYPHISH 아이콘 디자인 소스
아이폰 GUI 소스 아이폰 GUI 소스
안드로이드 아이콘 디자인 모음안드로이드 아이콘 디자인 참고 사이트 모음

모바일 UX 기초
Getting Started with Mobile UX Design모바일 UX 디자인 기초 강의
Mobile UX Essentials모바일 UX 기초

디자인 전용 검색엔진
find:Design디자인 검색 엔진


모바일용 와이어프레임 산출물 

Mobile UX Deliverable모바일용 와이어프레임 샘플
MOObileFrames모바일용 와이어프레임과 스케치 모음