아이디어에서 기능으로: 디자인 측면에서 바라보기

 

Larry는 그가 올린 블로그에 대한 반응과 댓글들을 매우 감사해하고 있습니다.감사합니다! 저희 글에 2000개가 넘는 댓글들이 달리고, 제가 2000통에 달하는 메일들을 받았다는 사실은 아주 고무적입니다. 저는 가능한한 자주 답을 하려고 최선을 다하고 있습니다.

앞으로 PDC가 열흘 밖에 남지 않은 상황이어서 Windows 7 데모 준비를위해 블로그 활동을 잠깐 쉬게 될 수도 있을 같습니다. 물론, 저희들은 댓글을 계속해서 주의깊게 살펴볼 것이고 도중에 어쩌면 한 두 개의 글을 올리게 될지도 모르겠습니다.

그럼 이번에는 저희가 어떻게 제품 안에 들어갈 것들을 고안해내고 하나의 아이디어에서 출발하여 어떻게 실제 기능을 만들어내는지에 대해서 살펴보도록 하겠습니다.

다양한 엔지니어링 측면에서의 도전과 관련한 글들을 올리면서, 저희들은 토론을 통해 몇 개의 결정들을 도출해 내었는데 이러한 결정들은 흔히 두 가지 선택 사항 가운데 놓여지게 됩니다. 예를 들면 어떤 기능을 선택 사항으로 할것인지 아닌지, 창 관리 기능을 둘 중 하나의 방식으로 할 것인지 아닌지 등과 같은 것입니다. 그러나 이것은 “제품 정의의 출발점은 어디인가?” “어떻게 아이디어에서 기능을 도출해 낼 것인가?”라는 도전에 도달하기에는 아직 거리가 먼 것이었습니다. Windows 엔지니어링에서의 선택 사항들은 둘 중 하나를 택하는 경우보다 단지 두어 개의 선택 사항으로 압축하기 위해서라도 수 많은 고려 사항들과 변수와 가능성들 가운데에서 선택해야하는 경우가 많습니다. 이 글에서는 아이디어를 하나의 실제적인 기능으로 바꾸어 가는 과정에 대해 살펴 보도록 하겠습니다.

여러 피드백들에서 볼 수 있었던 일반적인 의견은 “모든 것을 사용자 지정할 수 있도록 하고, 옵션으로 선택하여 사용할 수 있도록” 만들어 달라는 것이었습니다. 물론 직접적으로 이렇게 언급한 글은 없었습니다. 저희들이 플랫폼을 제공할 때에는 API를 활용하여 확장성과 사용자 지정 기능을 극대화할 수 있도록 하는 것을 목표로 하고 있습니다. 그러나 현실적으로 엔지니어링 측면에서 사용자 지정 기능과 확장성을 구현하기 위해서는 그에 대한 비용이 들기 마련인데 성능, 복잡성 그리고 향후의 호환성과 같은 것들입니다. 이 문제에 대하여 하나의 예를 들어 생각해 봅시다. 만약 릴리스에서 어떤 기능에 대하여 새로운 기능을 활성화하거나 이전 기능을 활성화하는 것 중 선택의 형태로 나타나는 두 가지의 모드가 있는데, 그 뒤를 잇는 릴리스에서 만약 그 기능이 변경되어야 한다면 그것은 잠재적으로 ‘구 기능+구 기능,’ ’구 기능+신 기능,’ ‘신 기능+구 기능,’ ‘신 기능+신 기능’의 네 가지 모드를 가지게 될 것입니다. 그리고 장래에는 8가지 모드 등으로 계속 늘어 갈 것입니다. 안정적이고 일관된 플랫폼의 제공이라는 복잡성은 저희가 항상 모든 것을 다 수용할 수는 없다는 것과, 장래에 대한 계획을 세우는 과정에서 한 기능이 어떻게 작동하도록 할 것인가에 관해 실용적인 선택을 해야 한다는 것, 이 두 가지의 비용을 수반하게 됩니다. 기능을 디자인한다는 것은 선택, 그것도 아주 힘든 선택을 해야 한다는 것입니다. 동시에 저희들은 프로그램 시작, 창 관리, 파일 관리, 다양한 주변 장치 사용 등과 같은 핵심 운영 체제의 기능에서 정말 탁월한 경험을 제공하기를 원합니다. 그 경험이란 서로 다른 기술 수준을 보유하고 서로 다른 사양의 PC를 사용하고 있는 다양한 사용자들로 구성된 집합들을 가장 포괄적으로 만족시킬 수 있어야 하는 것입니다. 또한, 그 경험이란 사용자 인터페이스나 코드를 각자의 필요에 맞게 바꿀 수 있는 매커니즘을 제공해 주는 것이어야 합니다. 저희가 계획하는 모든 릴리스에는 저희 모두가 원했던 대로 작동하지 않는 기능들을 고치는 것과 기존의 문제와 새로운 문제 모두에 대한 새로운 솔루션을 개발하는 것들이 뒤섞여 있습니다. 또한 기능과 확장성의 문제, 기존의 하드웨어에 대한 더 나은 지원과 새로운 하드웨어 지원에 대한 문제들이 뒤섞여 있습니다.

이 글은 Windows Experience의 사용자 경험(UX) 디자인 팀 매니저인 Samuel Moreau, Windows 와 Windows Live 사용자 경험 디자인 및 연구 담당 디렉터인 Brad Weed, 그리고 Windows Experience의 Program Management 담당 부사장인 Julie Larson-Green에 의해 공동 작성되었습니다. 특정 기능에 대한 아이디어를 기술한 수많은 댓글들을 보면서 저희는 저희가 전반적인 디자인 프로세스를 어떤 식으로 접근하는지, 그리고 여러분들이 언급했던 그 아이디어들을 저희들이 어떻게 디자인 프로세스에 반영하는지에 대한 전반적인 과정을 여러분에게 보여드리는 것이 좋겠다고 생각했습니다. 또한, PDC에 참가하는 여러분들을 위해 Sam은design principles of Windows 7 세션을 이끌게 될 것입니다. - Steven

Windows 디자인 – 아이디어에서 기능으로

일반적으로 제품을 디자인하기 위해서 저희들은 합리적으로 잘 알려진 접근 방식을 따르지만, 그러나 이런 방식이 디자인을 손쉽게 하거나 또는 “자동화”할 수 있는 것으로 만들어 주지는 않습니다. 이러한 과정은 아이디어들이 개념의 상태에서 프로토타입을 거쳐 구현 및 완성된 최종 결과물로 만들어지는 “디자인 퍼널(design funnel)”이라고 합니다. Starting, Launching and Switching이라는 Chaitanya의 블로그에 대한 댓글에 언급된 다양한 디자인 아이디어를 읽어보면 여러분은 하나의 완성된 기능 디자인에 도달한다는 것이 얼마나 어려운 것인지를 아시게 될 것입니다. 그 댓글들에서 여러분들은 똑같이 타당하지만 다소 상반되는 견해들을 보실 수 있을 것입니다. 그 뿐만 아니라, “모든 것이 가능하게” 라고 바꿔 말할 수 있는 댓글들도 발견하실 수 있을 것입니다. 저희들로 하여금 Windows라는 전반적인 제품의 컨텍스트 내에서 아이디어를 기능으로 바꾸는 문제들을 해결해 나아갈 수 있도록 하는 것이 바로 디자인 프로세스입니다.

제품 디자인이라는 관점에서, Windows를 만든다는 도전은 단지 하나의 단일 제품일 뿐이라고 생각하는 의식의 폭을 넓히는 것입니다. 어떤 의미에서 소프트웨어의 신기한 요소중 하나는 바로 “소프트(soft)”하다는 것이고, 따라서 여러분들은 거의 똑같은 “원재료”를 사용하여 적은 추가 비용으로 모든 고객들에게 모든 기능을 제공할 수 있을 것입니다. 많은 분들이 댓글을 통해 모든 기능에 대하여 사용하는 시점에 컴포넌트를 선택할 수 있도록 하는 옵션을 두어야 한다고 계속해서 제안하고 있고, 저희는 제품 내에 있기는 하지만 사용되지 않는 컴포넌트와 기능들에 대한 비용을 최소화하는 것에 대해 계속해서 언급했습니다. 그리고 동시에 개발자들이 어떤 주어진 PC가 공통적인 기능들의 집합을 가지고 있다는 것을 선험적으로 알수 있고, 거기에서 어떤 특정한 방식으로 동작할 것이라는 것이 알려져 있는 API들을 이용할 수 있다면, 개발자들은 많은 혜택을 볼 수 있게 될 것입니다. 물론, 이러한 혜택은 개인들에게도 마찬가지로 적용되는데 사람들은 아무 PC에서나 익숙한 사용자 경험을 할 수 있을 뿐 아니라, 특정 장치를 사용하거나 어떤 프로그램을 해당 PC에서 사용하여 자신에게 필요한 작업을 수행하기를 원한다면 그렇게 할 수 있을 것입니다. 이러한 폭넓은 기능성은 Windows PC가 가진 가치의 핵심적인 부분입니다. 그러나 그것은 디자인 측면에서 상당한 도전 거리이기도 합니다. Windows 디자인 과정에 투입되는 의견들의 광범위한 집합을 배우고 이해하며 또 그에 따라 작업의 방향을 정한다는 것은 Windows를 디자인하는 데 있어서 굉장히 재미있으면서도 아주 도전적인 부분입니다.

Larry가 지적했듯이 디자인과 기능의 선택은 조직 내에서의 역할로 이루어지게 됩니다. 저희가 앞으로 올리게 될 글에서 전반적인 릴리스와 관련된 주제들에 대한 접근 방식과, 기능들이 서로 잘 조화를 이루고 일관된 통합체를 형성하기 위해서 저희가 어떻게 하나의 릴리스에 대한 포괄적인 접근을 만들어 가는지, 그리고 어떻게 고객들의 요구를 처음부터 끝까지 처리하는지에 관한 내용을 다루게 될 것입니다.

저희 내부에는 Windows의 전체적인 인터랙션 디자인(interaction design) 및 Windows의 화면과 시각화를 담당하고 있는 제품 디자이너 그룹이 있습니다. 프로젝트 매니저들은 스펙을 작성할 때 제품 디자이너들과 함께 작업합니다. 전에 말씀드렸던 것처럼, 디자이너들 외에도 디자인을 테스트하고 유효성을 검증하는 UX 연구원들이 있습니다. 가장 핵심적인 것은 저희가 어떤 기능을 개발하기 위해 모든 범위의 기술을 적용하는 과정에서 누가 무엇을 담당하는지와 엔드투엔드(end-to-end) 디자인을 명확히 한다는 것입니다. 그렇게 하지 않는 유일한 경우는 모든 것을 한 사람이 책임지고 있는 제품의 경우입니다. 어떤 분들은 그것이 잠재적인 문제의 근원이라고 여기실 수도 있고, 다른 분들은 많은 사람들이 사용할 폭넓은 범위의 기능들을 포함할 제품을 한 분야의 관점에서 (그것이 개발이든, 테스트이든, 디자인이든, 마케팅이든 상관없이) 만들어 낼 수 없다고 생각하실 것입니다. 저희들은 ‘엔지니어들이 엔지니어링에 대한 책임을 진다’라는 것을 확실히 하고자 합니다. 그렇게 된다면 그 제품은 우리 모두가 구현(implementation)이라는 목적을 향해 함께 일하고 있다라는 명확한 정의를 가지게 될 것입니다. 또한, 그 제품은 전 세계에 있는 고객들에게 Windows를 공급하기 위해 일하는 모든 팀들이 가지고 있는 각각의 목표들을 대표할 수 있게 될 것입니다. 그리고 무엇보다 중요한 것은, Windows 7를 위해 저희들은 엔드투엔드(end-to-end) 디자인에서 많은 새로운 노력을 기울이고 있다는 것입니다.

그럼 Windows엔지니어링 과정에서의 제품 디자인의 주요 단계들을 한 번 살펴보도록 하겠습니다. 물론, 여기서 말씀드리려고 하는 것은 전체를 개괄적으로 말하는 것이므로, 개별적인 경우에 일일이 동일하게 적용할 수는 없습니다. 저희가 내부적으로 늘 언급하는 것은 저희 조직은 항상 무언가를 배워가고 있다는 것입니다. 그러므로 어떤 프로세스도 완벽하지 않으며 매번 새로운 Windows 제품을 만들어 나가는 과정을 통해 좀 더 나은 프로세스를 만들어 나가기 위해 노력하고 있습니다.

이 글 전체를 통해 저희가 “저희”라고 말할 때 “저희”는 실질적으로 어떤 거대한 기능이나 디자인 위원회가 아니라 함께 협력해서 일하는 개발, 테스트, PM, 디자인 각 부문의 개인들을 지칭하는 것입니다.

질문 선택 또는 아이디어 얻기

저희들은 작업과 관련된 모든 곳에서 아이디어를 얻습니다. 몇 가지 예를 들자면, 그것은 규모가 클 수도 있고(‘터치’와 같은 새로운 입력 방법을 지원하기 위한 UX구축), 급진적인 것일 수도 있고(3D 사용을 위해 전체 UI 의 패러다임 변경), 현재 존재하는 어떤 기능(다중 모니터 지원)을 개선하거나 좀 더 세련되게 하는 것일 수도 있습니다. 창조적인 아이디어의 고갈이란 없습니다. 왜냐하면 솔직히 그것은 제일 쉬운 것이기 때문입니다. 아이디어들은 저희를 포함하여 에코시스템의 구석 구석에서 흘러 들어옵니다. 저희들은 이 블로그에 올라온 댓글들과 피드백에 대해 많은 이야기를 나누었는데 그것도 분명히 한 가지 형태의 의견입니다. 제품 리뷰들, 기업 고객들, 고객 지원 담당자들, PC 제조업체들, 하드웨어 및 소프트웨어 개발자들, 블로그들, 뉴스 그룹들, MVP, 그리고 다른 수많은 경로를 통해 비슷한 의견들이 팀으로 들어오고 있습니다.

핵심적인 것은 Windows를 만드는 동안 실제로 계속해서 이런 의견들이 들어온다는 것입니다. 저희들은 더 쉽게, 더 좋게, 더 빠르게 만들고 싶다는 목표 및 관련 시나리오를 포함하고 있는 릴리스를 위한 프레임워크에서부터 출발합니다. 그리고 그와 더불어 PM은 실제 기능으로 구현될 만한 아이디어 후보들을 축적해 갑니다. 아이디어가 충분히 하나의 기능이 되도록 하는 작업은 PM의 몫인데, 그들은 Larry가 이미 언급했던 것처럼 제품 전반에 걸쳐서 디자이너, 개발자, 테스터와 힘을 합하여 이 작업을 수행해 나갑니다.

아이디어들이 어디로부터 오는지와 관련해서 저희가 이야기하고 싶은 바는 PM의 역할은 모든 훌륭한 아이디어들을 생각해내는 것이 아니라, 모든 훌륭한 아이디어들이 궁극적으로 선택되어지도록 하는 것이란 점입니다. 최고의 PM은 출처와 상관없이 최고의 아이디어들이 선택되어져서 기능으로 구현되는 것을 확실하게 할 수 있는 사람입니다.

정보와 데이터 수집

어떤 아이디어가 주어졌을 때 첫번째 단계는 그 아이디어와 관련하여 어떤 데이터들이 있는지를 이해하는 것입니다. 그 아이디어는 고객 지원 내용과 같이 그 자체로 데이터 중심적인 방식으로 올 수도 있고, 때로는 블로그와 같이 우회적으로 올 수도 있습니다.

저희가 가장 우선적으로 생각하는 것은 가설 수립을 지원하거나, 일반적인 통념을 반박 또는 지원하거나, 또는 문제들에 대해서 어느 정도 해결의 실마리를 제시하거나 하게 될 실제의 사용 방식에 기반한 데이터들이 있는지를 이해하는 것입니다. 기능은 한 의견에 좀 더 다양한 관점을 추가하는 데서 시작된다고 할 수 있습니다.

본질적으로 저희는 가설을 조명하는 객관적인 시각이 필요합니다. 저희는 최종 사용자들, 고객들, 파트너들 등 다양한 원천으로부터 측정(instrumentation), 조사, 사용성 연구, 경쟁 제품 리뷰, 직접적인 고객 피드백, 제품 지원 등 다양한 형태를 통해 이러한 데이터들을 모으고 있습니다.

저희를 포함해서 많은 분들이 지적해 주셨듯이 원격 측정은 한계가 있습니다. 첫째로, 그것은 어떤 사람이 실제로 하려고 했던 것이 무엇인지는 알려줄 수는 없고 이미 수행된 작업들에 대해서만 알려줄 뿐입니다. 사용성 연구, 조사 및 관찰을 통해서 저희들은 좀 더 사용자들이 의도했던 바, 즉 실제로 하려고 했던 작업이 무엇인지를 알 수 있습니다. 고해상도에 관해 우리가 이야기했던 방식, 그리고 실제 의도는 원격 측정이 보여준 결과와는 전혀 달랐다는 사실 및 그러한 선택의 결과도 실제 사용자가 원한 것이 아니었다는 사실 등을 예로 들 수 있을 것입니다. 이것을 이해하는 가장 좋은 방법은 PC를 사용하는 사람은 PC 사용법을 배우는 데에는 관심이 없으며 오직 자신의 작업을 끝마치려고 노력하고 있다는 것을 기억하는 것입니다. 그리고 어떤 “문제”가 생겼을 때, 사용 가능한 유일한 해결책은 바로 거기에 있는 단추들과 메뉴 명령들입니다. 즉, 모든 해결책은 이미 존재하는 소프트웨어에서 나오는 것입니다. 저희의 역할은 그러한 문제들의 뿌리를 찾아서 솔루션들을 더 많이 늘리거나 그 문제들을 완전히 없애버리는 것입니다.

논리적이지 못한 요구들은 어떻게 할까요? 의도가 더해진 데이터는 “이미 알려진 세계” 및 “이미 알려진 솔루션 영역”을 보여 주지만, 저희의 역할은 한 발 앞선 진보적인 사고를 바탕으로 모든 잠재적인 솔루션 영역을 고려하는 데에만 시간을 다 보낼 수 없는 사람들에 의해 분명하게 표현되지 못한 요구나 갈망들을 고려하는 것입니다. 그 솔루션 영역이란 것은 이미 사용 중인 기존 제품에서 분명히 드러나는 것보다 잠재적으로 훨씬 넓을 수도 있습니다. 또한 구조 변경, 새로운 하드웨어 또는 새로운 사용자 인터페이스의 고안 등을 포함할 수도 있습니다.

이것의 가장 좋은 예는 작업 표시줄과 관련된 글의 댓글 중 하나에 언급된 것입니다. 그 댓글에서는 작업 표시줄 위의 아이콘들의 순서들이 문제가 될때 프로그램들이 작업 표시줄 위에 선호하는 순서대로 놓여지도록 하기 위해 프로그램을 그냥 종료시켰다가 다시 실행하는 경우가 있다고 지적하고 있습니다. 여기에서 데이터는 “실행/종료/실행/종료/실행/실행”이라는 이상한 순서가 될 것입니다. 따라서 다른 방법을 사용해야만 저희들은 어떤 사람이 왜 그런 행동을 하는지를 배우게 될 것입니다. 여러분들이 아무런 배경 정보 없이 데이터를 보고 “우리가 어떻게 Windows를 더 사용하기 쉽게 만들 수 있을까”라고 말한다면, 그 문제가 요구 사항 목록의 가장 중요한 순위로 올라갈 수는 없을 것입니다. 이와 같이 저희들은 이러한 하나의 예에서 참고가 될 만한 수많은 사실들을 배울 수 있습니다. 데이터만으로는 그 의도를 알 수 없고, 그 요구 사항이 어떤 목록에서도 중요한 위치를 차지하지 못할 것이고, 그에 대한 솔루션이 얼마든지 다양한 형태로 만들어 질 수 있으며 만약 제대로 해결된다면 꽤 쓸만한 기능이 될 것이라는 것도 알 수 있습니다. 무엇보다도, 지나고 나서 나중에 돌이켜 봤을 때 이것은 해결 방법이 정말 명백해 보이는 그런 문제들 중의 하나일 것이고, 여러분들 중 상당수가 “나한테 물어보기만 했으면 되는데”라고 말하고 있을 것이라 확신합니다. 따라서 저희가 어떤 데이터나 어떤 정보를 모으는지 또는 어떤 디자인에 대해 이야기하는지에 상관없이, 어떤 분들은 항상 그런 것들을 이미 알아차리고 제안했었다는 것을 배우게 됩니다.

가설 수립

다음 단계는 명확한 가설을 제시하는 단계입니다. 예를 들면 “사용자들은 작업 표시줄 위의 아이콘들을 재 배열할 수 있음을 통해 혜택을 볼 것입니다. 왜냐하면, 여러 다른 세션 사이를 오갈 때 사용되는 위치 메모리가 응용 프로그램을 전환하는 시간을 줄여주고 Windows를 강력히 통제하고 지배하고 있다는 느낌을 줄 것이기 때문입니다.”와 같은 것입니다.

어떤 기회가 존재하는가, 어떤 문제들을 해결할 것이고 솔루션은 어떤 형태가 될 것인가, 또는 왜 그 문제가 존재하는가에 관한 저희들의 (다소 과학적인 방식의) 가설은 무엇일까요? 기능 디자인의 핵심적인 부분 중 하나는 “왜 그 문제가 존재하는가?”등의 질문을 통해 그 문제를 충분히 생각하는 것입니다. 그리고 그 문제를 해결함을 통해 얻게 되는 혜택을 제시하는 것입니다. 제시된 솔루션을 기반으로 이에 따라 얻게 될 혜택을 따져보는 것은 아주 중요한 일입니다. 바꾼다는 것은 더 기분 좋은 것이고 뭔가가 고장나면 새 것은 항상 더 나은 것이어야만 하기 때문에 수정 혹은 변경을 장려하는 것은 상당히 쉬운 일입니다. 그러나, 과연 그것이 고객들에게 어떤 혜택을 줄 수 있는 것인가에 대해서 강력한 동기 유발을 가지는 것이 아주 중요합니다.

가설과 관련된 또 다른 핵심적인 부분은, 특히 가설이 최종 사용자나 열성팬 또는 PC제조업체 등과 같은 특정 고객군과 관련되어 있을 때 그 분야의 통념을 이해하는 것입니다. 통념이라는 것은 오늘날 어떤 기능이 어떻게/왜 이런 방식으로 작동하는지를 이해하는 것과 어떤 문제가 어떤 방식으로 해결되어야 하는지에 대한 공동의 견해가 존재하는지를 이해하는 것, 이 두 가지 모두를 포함하고 있습니다. 통념이 매우 중요했었고 디자인에서 고려되어야만 했었거나 디자인에서 고려하지 않을 것임을 알기에 디자인에서 고려되었어야 했던 역사적인 유명한 예들이 있습니다. 그 유명한 예중의 하나는 “DOS” 세계에서 느끼기에는 모든 PC에 마우스가 있는 것은 아니기 때문에 필요하다고 생각되었지만 Mac에는 항상 마우스가 있기 때문에 Mac에서는 “불필요”하다고 생각되었던 메뉴에 있는 키보드 단축키의 역할입니다. 그 때까지DOS세계에서의 통념은 마우스는 있어도 되고 없어도 되는 선택 사항이었습니다.

실험

어떤 가설이든 그에 대한 수많은 디자인 대안들이 존재합니다. 다양한 옵션들을 찾아내기 위해 넓은 그물을 던지는 단계가 바로 실험 단계입니다. 저희는 밑그림을 그리고 시나리오 및 스토리보드를 작성하고 와이어프레임을 만들고 다양한 현실성을 가지는 프로토타입을 만듭니다. 저희들은 이런 과정을 거치면서 최고의 해답을 찾으려 할 뿐만 아니라 문제의 핵심을 밝혀내어 다음 단계인 유효성 검증에 필요한 다양한 관점을 반영할 수 있도록 작업해 나갑니다.

이것은 정말 재미있는 디자인 프로세스입니다. 저희들의 사무실 복도를 걸어보신다면 여러분들은 아마 벽에 붙어 있는 포스터에서 모든 종류의 대안들을 보실 수 있을 것입니다. 또한 각종 기능 프로토타입을 가지고 있는 PM 또는 디자이너를 만나시거나, 디자이너들이 실험실에서 철저하게 테스트할 수 있도록 아주 현실적인 프로토타입을 만들고 있는 것을 보실 수 있을 것입니다. 참고로, PowerPoint는 현실성 있는 시나리오와 클릭하기에 적당한 프로토타입을 짧은 시간 안에 만들 수 있는 아주 좋은 UI 디자인 도구입니다. 그리고 Visio도 그런 작업에 사용할 수 있는 상당히 좋은 도구입니다.

해석 및 유효성 검증

저희들의 앞에 쌓여 있는 옵션들을 가지고 저희가 밟게 되는 다음 단계는 저희 자신들의 견해 및 사용성 테스트 데이터, 그리고 외부에서 저희 팀으로 들어오는 피드백을 해석하는 단계입니다. 이것은 예를 들자면 “옵션 A를 선택하면 새로운 기능을 더 많이 발견할 수 있다는 장점이 있지만, 옵션B는 전반적인 사용자 경험에 매우 강한 통합의 느낌을 준다.”와 같은 대화로 끝을 맺게 되는 단계입니다.

우리 모두가 잘 알고 있듯이 미시적인 수준에서 여러분들은 특정 문제에 대한 완벽한 솔루션을 발견하실 수 있을 것입니다. 그러나 여러분들이 거시적인 수준을 고려한다면 어떤 솔루션이 주어진다 하더라도 그것의 장점과 단점을 보시기 시작할 것입니다. 이것이 바로 저희가 “테스트”라는 함정에 빠지지 않도록 매우 조심해야 하는 이유입니다. 여기에서 함정이란 사용법의 전체적인 컨텍스트 내에서 기능을 테스트하는 것은 불가능한 때가 있고, 특정한 일련의 시나리오들의 컨텍스트 내에서만 기능을 테스트하는 것이 가능하다는 것입니다. 의도와 관련된 풍부한 피드백들을 계속 접수하면서 어떻게 하나의 기능이 모든 잠재적인 시나리오 및 사용법과 관련이 있는지를 테스트한다는 것은 불가능합니다. 이것이 테스트를 디자인하고 결과를 해석하는 것이 저희 연구원들이 이끌고 있는 전반적인 UX 노력의 핵심적인 부분이 되는 이유입니다.

이것을 바라보는 수학적인 방식은 “극소(local min)” 대 “최소(global min)”입니다. “극소(local min)”는 곡선 위의 잘못된 지점에서 최적화를 시작한다면 여러분들이 발견하게 되는 것입니다. 소프트웨어에서 이것을 보여주는 좋은 예제 중 하나는 여러분들이 새로운 컨트롤이나 UI위젯을 개발할 때 사용성 문제에 부딪히게 되는 경우입니다. 그것은 완벽하게 합리적인 것처럼 보이고, 특히 그 위젯이 해당 문제에 대해 요구되는 작업을 적절히 처리한다면 테스트가 아주 원활히 진행될것입니다. 그러나 저희가 추구하는 것은 새로운 위젯을 도입함으로써 얻게 되는 잠재적인 이익을 통해 코드, 품질 그리고 사용성 면에서 다른 위젯의 잠재적인 비용을 지워버릴 수 있는 “최소(global min)”입니다. 여러 옵션 중에서 선택하는 것과 관련해서 결정 이론의 역할에 대해 많은 자료들이 있지만 디자인과 관련된 저희의 도전은 질적인 요소들이 훨씬 우세를 차지하고 있습니다.

선택

궁극적으로 저희는 하나의 디자인을 선택해야 하고, 그 선택은 모든 범위의 질적 양적 데이터로부터 얻은 정보에 기반하여 이루어 집니다.

디자인을 선택한 후 그것을 어떻게 구현할 것인가에 대한 이해하고 그 비용이 정해지면, 해야할 선택이 아직 하나 더 남아있습니다. 바로 그 기능을 선택해야만 하는가 하는 것입니다. 이 모든 작업들을 거쳤는데도 아직 특정한 기능을 만들지 않을 수도 있다고 한다면 다소 이상하게 들리실 것입니다. 하지만 결국은 편집실 바닥에 버려질 어떤 장면을 찍고 있는 영화 감독처럼, 디자인이 저희가 희망했던 것 만큼의 결과를 내지 못하거나, 때로는 합당한 이유로 인해 구현 계획이 완성되지 못했거나, 때로는 단지 더 괜찮아 보이는 다른 아이디어가 있을 수도 있습니다. 그리고 이것은 전부 저희가 구현이라는 단계에 이르기 전의 일들이며, Larry가 지적했던 것처럼 구현에도 많은 도전들이 기다리고 있습니다.

저희에게는 기능과 디자인에 대한 우선 순위를 정할 때 도움을 주는 두 개의 도구가 있습니다. 그 첫 번째 도구는 제품 계획입니다. 제품 계획은 시나리오, 비지니스 목표, 일정 등의 관점으로 어떤 제품이 달성해야만 하는 것을 말합니다. 기능은 릴리스의 전반적인 목표와 일치하지만은 않을 것이기 때문에, 대부분의 경우 프로토타입 과정과 테스트를 완전히 통과하지는 못합니다. 이러한 목표들은 중요한데 그렇지 않다면 그 제품은 앞뒤가 들어 맞지 않게 되고 단지 여러 기능들의 묶음이라고 느껴지게 만드는 위험을 감수해야 합니다. 이러한 전반적인 목표는 릴리스를 위해서 저희가 어떤 코드를 다루고 어떤 시나리오를 고려할 것인가 하는 관점에서 상당히 많은 것을 알게 해 줍니다.

그리고 저희가 가진 두번째 도구는 릴리스를 위한 “디자인 원칙”입니다. 이 원칙은 저희가 사용하는 언어나 어휘를 나타냅니다. 이것은 핵심 가치를 나타냅니다. 저희는 종종 “만약 Windows가 사람이라면 이런 모습일텐데…”와 같이 제품을 의인화해서 디자인 원칙을 생각합니다. 이것이 PDC에서 Sam이 다룰 내용입니다.

서두에서 언급했던 것처럼 모든 것을 두 번 한다는 것은 불가능합니다. 저희는 결정을 해야만 하고 사용자 지정, 호환성 모드 등 이 주제를 다룬 블로그 글만 여러 개가 될 수도 있습니다. 저희는 이러한 주제에 대해서 항상 여러분들의 의견을 듣고 있으며, “미세 조정” 과 “그대로 추진” 모두가 가능하도록 항상 엄청난 분량 일을 하고 있습니다. 그와 동시에 저희는 이러한 목표와 더불어 안정적이고 우수한 성능의 플랫폼을 제공하고 탁월한 OS를 만들고자하는 목표 사이에 균형을 유지할 필요가 있습니다. 저희들 중 일부는 Office 2007 프로젝트에 참여했었는데, Office 2007에서 호환성 모드를 제공 또는 제공하지 않는 결정과 관련한 Harvard Business School의 사례 연구가 있습니다. 이것은 그 당시에는 매우 어려웠던 선택이었고 몇몇 분들은 일부 댓글에서 이것을 계속 언급하고 계십니다.

구현 및 통합

최종적으로 선택된 솔루션을 완성시키기 위해 구축하고 반복합니다. 필연적으로 구현 과정에서 새로운 사실이 발견되기 마련이며 이에 따른 수정 과정을 거치게 됩니다. 솔루션을 Windows로 통합하는 과정에서도 새로운 사실은 계속 발견됩니다. 베타 기간은 사용 현황과 피드백을 통해 좀 더 많은 사실을 배우고 그에 따라 저희의 노력을 확장시킬 수 있는 좋은 예입니다. Windows 베타를 통해 저희는 특히 호환성 및 실제 성능에 관련한 피드백을 얻기를 원하고 있습니다. 이 두 분야는 디자인 측면에서 보자면 훌륭한 베타 제품을 내놓음으로써 파악할 수 있는 실제 사용 현황에 대한 지식이 없이는 검증이 어렵기 때문입니다.

리뷰, 블로그 및 원격 측정 등 제품이 어떻게 사용되는지에 대해 알려주는 모든 형태의 피드백을 중점적으로 따르는 것은 매우 중요합니다. 특히 베타가 선택된 사람들에 의해서만 사용되는 것을 고려할 때 다양한 피드백의 중요성은 더욱 강조됩니다.

이 블로그를 통해 저희가 바라는 바는IE 8 Blog에서 보신 바와 같이 실시간으로 제품 개발의 과정을 논의하는 것입니다. 저희는 이런 변화에 아주 가까이 다가가 있으며 저희가 결정한 디자인에 대하여 더 많이 알려드릴 수 있게 되기를 기대합니다.

-- Sam, Brad, Julie