태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.


'화면설계서'에 해당되는 글 2건

  1. 2011.06.30 키스크린(Key Screens)이 나오기까지의 과정 by 전성진
  2. 2009.07.17 UI 설계도에 해당하는 용어들 (4) by 이 재용
2011.06.30 18:52

키스크린(Key Screens)이 나오기까지의 과정

UI디자인 프로젝트에서의 키스크린(Key Screens)은 해당 프로젝트에서의 중요한 전환점에 해당합니다.

키스크린을 그리기 이전까지의 과정이 주로 UI디자이너가 리서치를 통해 프로젝트를 이해하고 자료를 모으고 분석하는 시간이었다면 키스크린은 이러한 고민의 결과가 비로서 구체적인 형태로 표현되는 순간에 해당합니다.

성미급한 고객들은 프로젝트가 시작되자마자 화면부터 그려내라고 하는 경우가 있는데, 이때 그들이 원하는 화면이라는 것이 바로 키스크린에 해당된다고 할 수 있습니다. 이것이 나와야 구체적인 디자인의 모습을 그리면서 본격적으로 기획-개발-디자인 부서가 서로 논의를 할 수 있기 때문이죠. 

UI디자이너 입장에서도 하루라도 빨리 키스크린을 그리고 싶지만, 그리게 되기까지의 과정이 결코 쉽지 않습니다. 설득논리를 갖추기까지의 과정이 만만치 않기 때문인데, 이 과정을 무시하고 고객 요구에 따라 성급하게 키스크린을 그리게 되면 이후 중심을 잡지 못하고 계속 흔들리게 됩니다. 그렇다고 이 과정에 너무 시간을 쓰기도 어렵습니다. 고객의 시간과 비용은 한정되어 있고, 보통 키스크린이 나오는 시점부터를 '본격적인 프로젝트의 시작'으로 인지하고 있기 때문입니다 (본인들이 인정하거나 말거나....)

키스크린을 제대로 그리기 위해서는 신속 정확한 데이터 수집과 분석, 그리고 방향수립의 과정이 필요하게 되는데 이것을 어떻게 해야 할까요? 이럴때 바로 구조화된 접근방법이 필요해지는 순간입니다. 자료를 조사하고 분석하고 고민을 하다보면 언젠가는 방향이 나오기야 하겠지만, 일정에 쫓기면서도 매번 안정적인 결과를 얻기위해서는 접근방법이 체계화 되어 있어야 합니다.

다음은 키스크린을 그리는 과정에서의 정리되어야 하는 덩어리들을 나열하고 이들간의 관계를 설명한 것입니다. 실질적인 내용을 얼마나 잘 찾아내는가는 UI디자이너의 능력과 노력의 결과입니다만, 이러한 것들을 어떻게 구조화 하는지를 염두에 두고 있으면 막연함이 훨씬 줄어들겠죠?

1. 사용자의 요구사항 (from Personas)
ㄱ. Goal
사용자를 관찰하여 발견된 주요 행동패턴에 대한 목표를 말합니다. 사용자가 제품 또는 서비스를 통하여 이루고자하는 바에 해당하며 경험적목표(Experience Goal)/궁극의 목표(End Goal)/인생의 목표(Life Goal)로 나누어 볼 수 있습니다. 여기에서 구체적인 화면을 그리는 데 중요한 역할을 하는 목표는 '궁극의 목표'이며 제품 또는 서비스를 사용하면서 구체적으로 이루고자 하는 작업/행동의 목표라고 할 수 있습니다.
 
ㄴ. Needs
사용자의 행동패턴을 발견하고 정리하는 과정에서 다양한 니즈가 도출됩니다. 이러한 니즈 하나하나는 구체적인 필요기능으로 정리될 수 있습니다. 즉 큰 틀(뼈대)를 만들어주지는 않지만 이를 채울 수 있는 살의 역할을 하는 기능 아이디어들을 얻을 수 있습니다.

2. 사업적인 요구사항 (Business Requirements)
보통 프로젝트 초반에 고객사의 관련자들을 인터뷰하면서 이해하게 되는 내용입니다. 고객이 왜 이 제품 또는 서비스를 만들려고 하며, 기대효과는 무엇인지, 특히 주요 경쟁자들은 누구인지, 경쟁자 대비 어떤 부분에 초점을 두고 사업을 전개하려고 하는지 등에 따라 아웃풋의 전체적인 방향성이 크게 좌우됩니다.
컨설팅의 종류에 따라서는 고객이 생각하는 비즈니스적인 방향 자체를 바꾸도록 하는 제안을 할 수도 있지만, 그러한 경우에도 결국에는 수정된 비즈니스적 방향성에 따라 제품 및 서비스의 큰 방향 자체가 달라집니다.

또한 내부적인 고민과 리서치의 결과로서 사업적인 목적에서의 서비스 feature list가 존재할 수도 있습니다. 이것들은 이후의 과정에서 사용자의 요구사항에 따라 혹은 기술적, 사업적인 환경변화에 따라 가감될 수도 있습니다. 어찌되었건 초기의 제품/서비스의 모습을 결정하는데에 커다란 요구조건이 되는 것은 틀림 없습니다. 

3. 기술적인 요구사항 (Technical Requirements)
현재 확보된 기술의 특성과 수준에 따라, 그리고 프로젝트의 일정에 따라 기술적 제약들이 발생합니다. 기술적 제약을 뛰어넘으면서까지 혁신을 이루어야 하는 프로젝트라면 좀 더 사용자에 초점을 두고 디자인적으로 드라이브를 할 수 있겠지만, 현실적 제약을 안고서 진행해야 하는 경우도 많습니다. 이러한 경우라면 이번 프로젝트에서 가능한 기술의 특성과 한계를 이해하고 이에 맞게 제품과 서비스의 모습을 그려나가야 합니다. 

위의 사업적인 요구사항의 경우와 마찬가지로 해당 프로젝트에서 고려중인 기술적으로 가능한 범위에서의 기능목록들이 이미 존재하고 있을 수 있습니다. 이러한 기능목록들은 디자인을 제한하기도하지만 오히려 가능한 범위를 파악하게 해줌으로써 구현 가능한 모습을 예측하는데 도움을 줍니다.

4. Interaction Framework
사용자 + 사업 + 기술, 이 세가지를 이해했다면 이제 '최초의 스케치'를 할 수 있는 준비가 된 것입니다. 그리고 위의 세가지 사항을 이해하는 과정에서 이미 어떤 그림들이 떠올랐을 수도 있습니다. 그러나 최초의 스케치가 곧 키스크린을 의미하지는 않습니다. 키스크린보다는 매우 러프한 형태이며 '대략 이런 모습'에 해당하는 실루엣이라고 할 수 있고, 사용자의 인터랙션의 모습을 크게 정의하는 역할을 하기때문에 '인터랙션 프레임웍'이라고 부릅니다.

인터랙션 프레임웍이라는 것은 디테일에 치우치지 않고 위 세가지 요소들 사이에서 균형을 잃지 않고 가장 중요한 사용 scene을 만족시킬 수 있는 화면의 구조를 그리는 것입니다. 즉, 화면의 '뼈대, 골격'이라고 볼 수 있습니다. 단순한 스케치 형태이지만 위의 세가지 요소들의 특성과 제약을 어떻게 해석하는지에 따라 접근방법이 달라질 수 있으며, 이는 결과적으로 매우 다른 형태의 제품과 서비스의 모습을 갖게 됩니다.

이때부터는 스케치를 두고서 고객과 기술파트와 긴밀한 협의와 토론이 필요하고, 특정 인터랙션 프레임웍을 선택함으로 인해 얻게 되는 것과 잃는 것을 구체적으로 확인하고 논의하면서 결정을 해야 합니다.





5. Features (from Persona's Needs)
위의 사용자 요구사항에서의 Needs로부터 도출된 필요기능들입니다. 각각의 기능들은 서로 상충될 수도 있고 중요도와 비중도 서로 다릅니다. 퍼소나의 Goal에 따라 중요도와 비중을 나누어보고, 각각에 대해 기술검토를 통하여 당장 구현 가능한 것과 구현의 어려움이 있는 것을 구분해야 합니다. 그리고 비즈니스적인 관점에서 중요한 기능들도 체크해볼 필요가 있습니다. 추가로... 필요기능들은 사용시나리오와 함께 검토되어야 어느 부분에서 상충이 되는지 등의 관계를 파악할수 있습니다.



6. Key Screens (4+5)
자...이제야 키스크린을 그릴 수 있게 되었습니다!
4번의 인터랙션 프레임웍 (뼈대)에 5번의 기능들을 얹고 기본적인 제품/서비스가 가져야 할 사항들을 이에 따라 정리를 하면 바로 키스크린이 그려지는 것입니다.

키스크린을 그리고 나면 고객과 기술파트와 함께 논의를 하면서 앞서 결정했던 사항들을 구체적으로 검증을 할 수 있게 되고 잘못 판단한 부분은 수정할 수 있게됩니다. 그리고 키스크린은 사용 시나리오가 연결되는 중요한 지점이 되고, 키스크린이 탄탄하게 그려지면 이후의 flow는 자연스럽게 도출됩니다.



지금까지의 과정을 간단하게 도표로 나타내면 다음과 같습니다.



2011.6.30. 전성진 

[참고##Process##]

팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 0
Ad Test...
2009.07.17 11:33

UI 설계도에 해당하는 용어들

User Interface Design은 매우 어린 학문이어서 자신의 주요 결과물을 무엇이라 부를 건가에 대해서조차 합의된 용어가 없습니다. 우리말로 하면 이른바 "UI 설계도"라고 할 수 있을까요? 하여간 업계에서 사용하는 용어를 모아보면,


1. UI 문서
GUI 문서에 대비되는 개념으로 UI를 설계한 문서라는 뜻인데, 웬지 정통성 없는 단어 같은 느낌이 듭니다.

2. 화면 설계서
제가 개인적으로 가장 선호하는 말은 '화면 설계서' 인데 다소 '흐름'에 대한 부분이 약한 느낌은 있지만 적어도 무엇을 이야기하는지는 어느 정도 설명하는 용어가 아닐까 생각합니다.

이것을 영어로 하면,

3. Wireframe
wire 즉 철사줄을 생각하시면 되겠죠. 철사줄로 만들어 놓은 조형물이 wire frame입니다. 이것이 3D 모델링에서는, 랜더링하기 전에 윤곽선만 잡아 놓은 것을 말하기도 합니다. 이 개념에서 차용해 온 것으로, 화면 설계에 있어서 구체적으로 면과 색을 칠하기 전의 상태, 즉 뼈대 혹은 윤곽선만 잡아 놓은 형태를 말합니다. 웹디자인에서 각 페이지의 영역 구분과 컴포넌트 배치, 콘텐트 배치 등을 해 놓은 문서를 말합니다. 우리 말로 하면 '윤곽선틀' 정도로 번역이 되겠네요. (미국 웹디자인 업계에서 주로 사용합니다)

4. Workflow
작업의 흐름을 말합니다. 우리 말로 하면 '작업 흐름도' 정도로 번역할 수 있겠습니다. 처음에 어떤 일을 하고, 그 다음에 어떤 일을 하느냐에서 아이디어를 착안하여, 디지털 제품 인터페이스가 처음에 어떤 일을 하고 다음에 어떤 일을 하는가를 설명해 놓은 문서입니다. 원래 이 용어는 생산 관리에서 나온 용어이겠죠, 식스 시그마나 TQM (Total Quality Management) 등이 이에 해당하는 용어입니다. (우리 회사에서 주로 사용하는 용어죠)

5. Storyboard
영화나 만화 제작할 때 어떤 식으로 이야기가 진행되는지 설명하기 위하여 스틸 컷과 함께 글로 설명을 해 놓은 문서를 말합니다. 우리말로 하면 '그림이야기' 정도라고 할까요? 여기에서 착안하여 디지털 제품 인터페이스가 처음에 어떻게 보이는지 그림과 글로 설명하고, 그 다음에 어떻게 보이는지 그림과 글로 설명한 것입니다. (학계에서 주로 사용하는 듯)

6. Flipbook
두꺼운 책 형태에 조금씩 다르게 그림을 그리고 빠르게 넘기면 마치 그림이 움직이는 것처럼 보이는, 어렸을 때 많이 장난치던 그것을 영어로 Flipbook이라고 부르는데, 거기에서 착안하여 빌려온 용어입니다. 인터페이스의 장면 장면을 매 페이지에 그리고 그 흐름을 볼 수 있다는 뜻에서 차용한 것이죠. (삼성전자 사람들이 주로 사용하는 듯)

7. MMI 문서, MMI 규격서
MMI는 Man-Machine Interface의 약자입니다. 예전에 세상의 대부분이 '기계'이던 시절. 인간과 기계간의 인터페이스가 매우 중요했겠죠. 이 때 (1950년대)는 '인간'이라하면 무조건 '남자'를 지칭하던 시절입니다. 따라서 기계 : 인간 인터페이스를 설명한 문서라는 뜻입니다. 이 개념은 GUI 문서와 대비되어 사용하는데, 즉 UI 설계 문서를 MMI 문서라고 하고, GUI Guideline 문서를 GUI 문서라고 하는 식입니다. (SKT, LG U+ 사람들도 많이 사용합니다. 또 산업공학 한 사람들도 많이 사용합니다)

8. Scenario, UI Scenario
영화에서 대사와 함께 지문으로 상황을 설명하는 문서를 말하죠. 사용자가 어떤 식으로 디지털 제품을 사용하는 상황이다라는 측면에서 UI 문서를 지칭할 때 사용합니다. (LG전자 사람들이 많이 사용하더만요) 시나리오라고 했을 때, 진짜로 시나리오처럼 글로만 상황을 설명하는 문서를 지칭할 때도 있지만, 대개 UI업계에서 시나리오라고 하면, 우리가 일반적으로 말하는 UI 문서처럼 화면 그림과 함께 설명이 들어가 있는 것을 말합니다.

9. Sketch
우리말로 하면 '흩그림' '밑그림' 이렇게 이야기하면 잘 전달 될까요? 디자인 된 것이 아니라, 디자인을 입히기 전의 상태라는 개념에서 이렇게 표현합니다. 사용 빈도는 낮습니다.

10. 콘티
Continuity의 약자로서 실제로 영미에서는 Conti라고 줄여서 말하지는 않는 것 같습니다만, 우리 나라에서는 공연 업계에서 주로 공연의 흐름이 어떻게 진행되는 지에 대하여 글과 그림으로 간단하게 설명하는 문서를 이렇게 지칭합니다. 영미권에서는 공연 뿐만 아니라 방송에서도 많이 사용하는 듯 합니다. 여기에서 착안하여 빌려온 용어로서 UI 흐름이 어떻게 되는지를 보여준다는 측면에서 이 용어를 사용합니다만, 사용 빈도는 낮습니다.

11. Interaction Framework
'Framework'이란 단어는 어떤 일에 있어서 기초가 되는 부분, 또 기초가 되어서 주로 반복하여 사용할 수 있는 부분을 말합니다. 예를 들어 건물을 세우거나 소프트웨어를 만들 때, 프레임웍을 잘 만들어 놓으면 다시 그 위에 쉽게 건물을 올리거나, 아니면 반복하여 다른 소프트웨어를 만들기 쉽죠.
여기에서 빌려와서, 앞에 Interaction을 붙인 용어입니다. 사람과 디지털 제품 사이의 상호작용에 있어서 큰 틀을 설명해 놓은 문서라는 관점에서 많이 사용합니다.

우리말로 하면 '상호 작용의 큰틀' 정도로 번역이 되겠네요.

12. Blueprint
우리말로 '청사진'이라고 말할 수 있는데, 건축업계에서 말하는 설계도라는 개념에서 차용하여 UI 문서를 지칭할 때 사용하는 사람들이 있습니다. 상대적으로 사용 빈도는 낮습니다. 최근 서비스 디자인쪽에서는 '서비스 블루프린트'라는 용어를 많이 쓰고 있습니다.

13. 기타
시방서, 스펙(Spec, specification), UI Guideline,draft, UI Requirement, UI 규격서


모두 다 다른 데서, 다른 측면에서, 빌려온 용어이긴 하지만, (11번과 12번을 제외하고는) 대부분 같은 결과 문서를 지칭하는데 사용합니다.
pxd에서는 '화면설계서'라는 말을 가장 많이 사용하고 그 다음에 'UI 문서','Workflow'라는 말을 사용하는 순으로 빈도가 되지 않을까 생각하는데, 다른 분들은 어떻게 생각하시는지요?
업계가 발전하려면 우선 용어부터 통일해야 한다는 생각이 간절하게 드네요. 적어도 우리 회사에서만이라도요.

(이 문서는 계속 수정하고 있습니다. 2012-07-27)

[참고##ux란##]

팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 4
Ad Test...