티스토리 툴바


UI Sketchpad

how 2009/11/13 17:35

아무리 기술이 발전해도
종이하고 연필만큼 초기 스케치하기에 좋은 도구는 없다

http://www.uistencils.com/iphone-sketch-pad.html

모양자가 생각나네. ㅎㅎ
Posted by hyber

bitter.

how 2009/10/08 16:18

며칠전 어떤 디자이너랑 얘기를 하다가..
UX/UI 디자인이라는건 common sense지만 methodology에 관한거다..라는 얘기를 했다.
참..솔직하고 정직한 생각이라고 생각했다.

요 며칠 Agile 프로세스에 대한 워크샵를 하고 있는데.
Agile 교육 담당자가 UI 디자인 프로세스는 heavy하다고 했다.
Agile 정신과 맞지 않는다는거다.

2-4주 간격으로 몇개의 Use Cases를 만든다고 한다면
당연히 IA를 만들고 UI flow를 만든담에 그걸 기반으로 개발을 시작하고
그러는 동안 UI 디자이너들은 상세 스크린을 만들고, 텍스트를 결정하고
자잘한 케이스에 대해 방법을 생각해 내면 그걸 또 기반으로 개발을 하고
그게 아무리 시간 간격을 쪼개 하루 간격으로 일을 한다고 해도
분명 디자인-개발-테스트 의 순서는 존재할 수 밖에 없는거 같은데..

Use Case가 어사인 되면
개발자와 테스터와 UI 디자이너가 동시에 일을 시작해야 한다고 한다.
그래서 그럼 UI 디자이너가 디자인 하는 동안 개발자와 테스터는 뭘 하냐고 하니
어떻게 할지에 대해서는 팀원들이 다 같이 의논하고
소프트웨어 개발자가 코드를 만들때 UI 디자이너는 UI 문서를 만들어서
같은 기간동안에는 같은 Use Case를 다뤄야 한다고 했다.
디자인이 먼저 되어야 한다는거는 old working way라고 했다.

이게 뭔가..
UI 디자인의 프로세스와, methodology를 인정하지 않는다면
결국 common sense라는것만 남는건데..
그렇다면 개발팀에 UI 디자이너들은 왜 존재 해야 하는건가.
그들은 과연 UI 디자이너들을 뭐라고 생각하고 있는건가..

가만히 '그래..뭐 되는대로 따라가자..'라고 하고 있으면 뭔가 이상하게 될것만 같다.
그러나 이게 나서야 할 자리인지 아닌지 판단이 잘 서질 않는다..


Posted by hyber

Eliminating and Creating

what 2009/10/06 15:18

폰을 구석구석 들여다보고 있으면
정말 왜 있는걸까..싶은 기능들이 많다.

그래서 이게 어쩌다 생겨난거냐..여전히 필요한거냐 여기저기 물어보면
대부분은 모르고
심지어는 담당자조차도 그게 있었냐?라는 얘기가 나오기도 한다.
아주 오래된 사람들이 아..그거..기억을 해내는 경우들이 있다.
알고보면 완전 isolate된거가 아니라서 깨끗하게 없애지도 못한다..

이런 구석기능들의 문제는
보통은 존재감이 없기 때문에
다른 중요기능이 업데이트 될때, 같이 업데이트되지 못하는 수모를 당하기도 하고
(혼자만 다른 레이아웃/그래픽을 쓰고 있다거나..)
새로운 기능을 만들어낼때
없애지는 못하고, 새로운 것과 맞추기는 해야 하니 maintenance 차원에서
의미없이 additional effort들이 들어가니 미운오리새끼다.

이건 창고 속 잡동사니 같은건데.
이사할때 버릴까 말까 고민하다가..
혹시 모르니까하면서 가지고 있어보자..하고 힘들여 이사해 새집으로 가져가지만,
여전히 박스조차 안뜯어보고 창고로 직행.
다음 이사할때에서 비로소 이게 뭐였드라..하고 열어보게 되는.
그런거다.

대부분의 사람들은 새로운 것을 add하는 거에 가치를 두기 때문에
이런 '청소'주장은 늘 low priority로 뒷전에 밀리게 된다.
청소를 하고 필요없는걸 가져다 버리는 것보다
쇼핑하고 새 물건을 사는걸 더 좋아하는것과 별 다를게 없다.

누가 이런 쓸데없는 것들때문에 발생되는 낭비를 계산해서
전자제품내 불필요한 기능 removing 하여 이런 이득을 얻었네 하는
best practice를 만들었음 좋겠다.

나도 시도해보고자 하는 방법이 하나 있긴 한데.
얼마나 먹히는지는..해봐야 알겠지..
Posted by hyber

CogWalk

how 2009/07/13 21:44

다른 부서에서 진행한 cognitive walkthrough에 평가자로 참여할 기회가 있었다.

선정된 태스크를 한단계 한단계 집어가면서 리뷰 하는 것은
이제까지 해봤거나 알고 있었던 것과 같았는데
평가 참여자(전문가)에게 각기 다른 persona를 나눠주고
내가 그 사람이라고 생각하고, 코멘트를 하는 것이 다른 점이자 흥미로웠던 점

장점을 꼽자면, 타겟 유저에 집중할 수 있다는 것.
단점을 꼽자면, 시간이 오래 걸린다?
시간은 진행하기 나름인듯한데, 한 태스크에 대해 시간이 지날수록 평가자들이 점점 persona에서 본인으로 돌아오는 경향이 있는거 같긴 했다.

다음에 필요하면 나도 이 방법을 써봐야겠다고 생각하니
감정이입(빙의-_-;;)할 수 있는 persona 만드는게 중요하겠더라.
Posted by hyber

paper prototype

how 2009/06/11 18:33

시뮬레이션 기술이 점점 쉬워지고 있긴 해도
여전히 사용자 평가를 위해 high-fidelity prototype을 만드는데는
learning curve도 있고 시간과 노력이 많이 든다.
그래서 low fidelity. quick and discount method로
paper prototype이 널리 이용된다는 사실엔 의심의 여지가 없는데..

(이미지출처: 구글검색)

생각해본적 없는, 들어본 적도 없는 문제(?)가 어디선가 제기되었다.
이런 종이/혹은 조금 두꺼운 보드로 만들어진
Toy 같은 프로토타입을 participant (일반사용자)에게 보여준다면 실망하지 않겠냐..
회사 이미지에 영향을 줄 수도 있다??
그래서 일반사용자를 초대할때 페이퍼프로토타입을 이용하는건 좀 그렇다?

Posted by hyber

Agile + UX

how 2009/06/03 16:16

소프트웨어 개발 프로세스를 모르니.
이 프로세스내외로 어떻게 UX가 들어가줘야 하는지 감이 잘 잡히질 않는다.

대강의 자료를 보면서의 첫인상은 빠른 iterative + increment.

이제까지 많은 사람들의 노력으로 Interaction design & Usability가 SW development에서 자리를 잡은 이상 개발 프로세스가 바뀐다고 이 역할들이 없어지지는 않겠지만. Agile process라는 것의 태생이 SW이기 때문에 UX가 간과되어있는 것은 사실이다. 그러나 Agile의 궁극적인 목표가 빠른 결과물을 통해 User Needs에 보다 부합하겠다는 것인만큼 UX practitioner에게는 보다 원하는 방향으로 갈 수 있는 기회가 될 수도 있겠다는 것이 개인적인 생각이다. 

그렇게 되기 위해서는 이 프로세스를 잘 이해하고, 적절한 시기에 필요한 역할을 수행해서 가치있는 결과물을 제공해주는 것이 관건. 많은 공부와 많은 discussion과 active한 참여가 필요하다.

Posted by hyber
TAG agile