제품의 정보 아키텍처는 웹 사이트의 IA보다 더 높은 추상화 수준에서 발생하므로 인식, 인정 및 논의하기가 더 어렵습니다. 1991년 내가 젊은 시절 철학을 전공했을 때 사회철학 교수가 물었다. 그래?” 우리의 에세이는 두 페이지로 제한되었습니다. 내 것은 끔찍했다. 항상 용어를 정의하십시오. 그는 여백에 썼습니다. 그 교훈은 지난 30년 동안 저에게 붙어 있었습니다. Information Architecture : 사용자의 디지털 공간 경험을 구성하는 구조의 디자인 구조 : 제품이나 사이트에 나타나는 개념과 개념 간의 관계 집합 제품 : 개별 트랜잭션 및 정보 교환을 가능하게 하는 독립형 장치 기반 디지털 경험 웹 사이트 : 주로 소모성 콘텐츠 제공에 중점을 둔 화면 기반 디지털 경험(예: 제품을 설명하는 마케팅 사이트) 추상화(Abstraction) : 개념이 실제 세계에서 얼마나 제거되었는지를 측정하는 것 제품 IA를 설명하는 과정에서 길 찾기, 탐색 및 콘텐츠 분류와 주로 관련된 정보 아키텍처인 콘텐츠 중심 IA와 제품 IA를 구별하는 것이 필요하다고 생각합니다(성가시긴 하지만). 정보 아키텍처는 내비게이션과 동의어가 되었으며 가상 구조에 대해 이야기하는 대부분의 은유는 물리적 공간을 비교 대상으로 사용합니다. 이것은 잘못된 것은 아니지만 절망적으로 불완전합니다. 물리적 공간과 평행하지 않은 디지털 도메인의 구조에 대해 결정해야 할 사항이 있습니다. 다음은 내가 의존한 몇 가지 다른 은유입니다. Family : 디지털 엔티티 간의 소속감과 상속에 대한 아이디어 전달 수명 주기 : 디지털 사물이 정적이지 않고 시간이 지남에 따라 변하므로 해당 변화를 캡처하고 전달하기 위한 프레임워크가 필요하다는 생각을 전달합니다. 환경 : 같은 것이 상황에 따라 다르게 보이고 행동할 수 있다는 생각을 전달하기 위해(공간적인 것 같지만 길 찾기는 아닙니다) 요리 : 사물이 서로 다른 상태로 존재하고 여러 사용자가 개발에 참여할 수 있다는 생각을 전달하기 위해 보드 게임 : 사물이 서로 상호 작용하는 방식을 제어하는 ​​설계된 규칙이 있다는 생각을 전달하기 위해 슈퍼히어로 : 큰 힘에는 큰 책임이 따른다는 생각을 전달하기 위해 (그러나 책임은 거의 없습니다 ???? ) 즉, 나는 내 생각과 공동 작업에서 이러한 은유조차 제거하려고 노력했습니다. 다시 말하지만, 정보 아키텍처의 일부 측면을 강조하면서 다른 측면을 가리는 경향이 있습니다. 이것은 아마도 디지털 도메인에서 구조를 생성하려면 더 높은 수준의 추상화에서 생각해야 하기 때문일 것입니다. 보이는 구조 제품을 보고 있다고 가정해 보겠습니다. 얼마나 많은 구조를 보고 있습니까? 즉, 의도적으로 설계된 관계를 나타내는 화면의 부분 수입니다. 화면 자체에는 레이아웃이 있습니다. 화면의 요소가 정렬되어 일부는 더 많은 공간을 확보하고 일부는 페이지 위로 올라갑니다. 이것은 공간과 배치를 통해 표현되는 관계가 있는 엔터티(사용자 인터페이스의 요소)인 구조입니다. 화면에는 사용자가 제품의 다른 측면으로 이동할 수 있는 수단인 탐색 메뉴가 포함되어 있습니다. 이것은 눈에 잘 띄는 또 다른 구조입니다. 화면은 사용자가 자신이 보고 있는 것이 제품의 다른 측면과 어떻게 관련되어 있는지 식별할 수 있는 방법인 컨텍스트를 보여주기를 바랍니다. 우리는 때때로 공간적 은유를 사용하여 컨텍스트가 사용자가 "어디에" 있는지를 보여준다고 말합니다. (모바일 장치를 더 많이 사용한다는 것은 가상 컨텍스트와 물리적 컨텍스트를 구분하는 것을 의미하기 때문에 이것이 점점 더 문제가 된다고 생각합니다.) 보이지 않는 구조 하지만 지금은 이상해집니다. 나는 달력을 예로 들겠지만 아마도 당신이 가장 좋아하는 제품으로 같은 운동을 할 수 있을 것이다. 이것은 우리 가족에게 매우 가벼운 주입니다. 화면의 요소는 엔터티를 나타냅니다. 여기서 명백한 것은 이벤트입니다. "이벤트"는 개념이며 이벤트와 관련된 많은 데이터가 있습니다. 이러한 메타데이터 중 일부(예: 상자의 크기, 색상 및 배치)는 화면에 이벤트를 표시하는 데 유용합니다. 다른 메타데이터는 반복 여부와 같은 이벤트 동작을 결정합니다. 다른 메타데이터는 미리 알림과 같은 다른 작업을 트리거합니다. 또 다른 메타데이터는 이벤트에 초대된 사람 및 그들의 상대적 상태(필수 또는 선택)와 같은 다른 사람과의 공동 작업을 지원합니다. 내 예에서 두 번 나타나는 이벤트(수요일 개 훈련 수업)의 사본이 있음을 알 수 있습니다. 이것은 복사본이지만 이벤트도 연결되어 있으므로 하나를 변경하면 다른 하나도 변경될 수 있습니다. 그것은 구조입니다. 관계가 있는 두 개의 별개의 엔터티이지만 실제 은유로는 쉽게 설명되지 않는 엔터티입니다. 이벤트의 파생물 인 초대장도 있습니다. UI를 통해 표현되는 일종의 가정법 같은 다른 상태로 달력에 나타납니다. 초대장은 별개의 개체일 수도 있고 이벤트의 풍미일 수도 있습니다. 이는 제품 팀이 디자인한 방식에 따라 다릅니다. 이 전체 제품은 달력이지만 실제로는 많은 달력을 위한 컨테이너입니다. 우리 가족이 그것을 최대한 활용했다는 것을 알 수 있습니다. 왼쪽 목록에는 모든 캘린더가 표시되며 캘린더는 고유한 엔터티 유형입니다. 그 자체로 이벤트의 컨테이너입니다. 캘린더에는 액세스 권한이 있는 사람과 같은 메타데이터가 있습니다. 또한 여기에 포함된 이벤트에 대한 기본 설정이 있으므로 이벤트는 특정 캘린더에 표시됨으로써 품질을 상속받습니다. 달력 제품을 위한 편리한 실제 아날로그가 있습니다. 실제 종이 달력입니다. 그러나 그것을 디지털로 옮기는 것은 우리가 사건이 무엇을 의미하는지와 같은 실존적이고 의미론적인 질문을 던지도록 강요합니다. 다른 유형의 이벤트는 무엇입니까? 캘린더란 무엇입니까? 이러한 질문은 정보 아키텍처의 유일한 영역이 아니지만 정보 아키텍처는 답변을 알릴 수 있는 관점을 제공합니다. 막간: 더 어려운 질문 이러한 차이점을 설명하기 위해 개념 모델을 구축할 때 더 어려운 질문을 해야 합니다. 캘린더를 "소유"하지는 않지만 액세스할 수 있는 사람을 무엇이라고 합니까? 그들을 "구독자"라고 부른다면 그들은 정확히 무엇을 구독하고 있습니까? 사용자가 이벤트를 생성한 후 복제하면 복제된 것이 원본에 속하는 부모 자식 관계인가요? 아니면 별개의 개체입니까? 사용자가 이벤트를 변경하는 경우 원래 버전의 이벤트 사본을 보관해야 합니까? 사용자가 한 캘린더에서 다른 캘린더로 이벤트를 이동하는 경우 새 캘린더의 기본값이 다른 경우 이벤트가 변경됩니까? 제 말은, 제가 여기 앉아서 몇 분 동안 그것에 대해 생각하고 있다는 것입니다. 이런 질문이 많습니다. 실존적 질문과 마찬가지로 답변은 전적으로 도메인 정보 아키텍처에 있지는 않지만 구조적 관점에서 정보를 얻습니다. 그리고 대답은 제품의 다른 영역에서 반향을 일으킬 기본 구조에 영향을 미칩니다. 추상 구조 Google 캘린더를 사용하면 집중 시간이나 작업 위치와 같은 다른 항목을 캘린더에 추가할 수 있습니다. 이러한 이벤트의 특징입니까, 아니면 완전히 새로운 개체입니까? 나는 팀이 이것에 대해 생각하는 데 시간을 보냈기를 바랍니다. 기본 구조에 대한 추가는 의심할 여지 없이 구조의 기존 엔터티(캘린더, 이벤트, 초대)에 파급 효과를 미쳤습니다. Google 캘린더의 메뉴 이 제품은 또한 사용자가 다른 사람을 초대하여 일정에 이벤트를 추가할 수 있는 약속 일정을 제공합니다. 어떤 의미에서 이것은 캘린더 내의 캘린더입니다. 또 다른 컨테이너, 잠재적인 이벤트 중 하나입니다. 이러한 이벤트는 다른 사람이 작성한 것이지만 캘린더에는 표시됩니다. 당신은 그 이벤트의 소유자입니까? 레이아웃, 내비게이션, 컨텍스트보다 추상화 수준이 더 높은 답변이 필요한 모든 질문과 고려 사항입니다. 우리는 "일정 관리"의 디지털 도메인을 구성하는 엔티티와 이들이 서로 어떻게 관련되는지에 대해 신중한 결정을 내리고 있습니다. 우리는 실제 프로세스를 에뮬레이트하지만 좋은 실제 아날로그가 없는 새로운 유형의 엔터티를 만들고 있습니다. Google 캘린더에 대한 결정은 경쟁 제품 팀에서 내린 결정과 다를 수 있습니다. 제품 IA의 언어를 향하여(그러나 도달하지는 못함) 이 분야는 이러한 더 높은 수준의 고려 사항에 대해 이야기할 훌륭한 언어를 개발하지 못했습니다. 디지털 제품의 엔터티와 엔터티 간의 관계에 대한 대화는 복잡하고 미묘합니다. 이러한 대화는 팀이 제품 비전과 일치하는지 확인하는 데 필요한 종속성과 영향을 파악하는 데 필요합니다. 비전은 제품의 구조 이상을 수반할 수 있지만 비전이 구조에도 반영되지 않으면 비전 실현이 손상될 수 있습니다. 따라서 Nathan Curtis가 제안한 "백엔드 IA"가 있습니다 . 제품을 뒷받침하는 구조의 의도적인 디자인. "프론트 엔드 IA"와 달리 이 구조는 보이지 않을 수 있습니다. 가시성이 부족하여 논의하기가 어렵습니다. 범주를 넘어서는 범주, 시간과 그 너머의 차원, 역설에 가까운 관계에 대해 생각해야 합니다. 제품 IA로의 여정이 의미 있는 언어를 낳을 수 있을지 모르겠습니다. 아마도 엄청나게 기술적으로 발전하지 않고는 불가능할 것입니다. 내가 궁금한 것은 디지털 제품의 구조에 압력을 가하는 시간, 협업 및 규칙과 같은 반복되는 주제입니다. 아마도 이러한 주제와 함축된 구조적 요소에 대한 탐색을 통해 이를 논의할 수 있는 실행 가능한 언어를 발견할 것입니다. 아니면 그러한 언어는 결코 존재할 수 없으며, 우리가 계속해서 재발명해야 하는 복잡성과 특이성, 창의성이 필요하다는 것을 알게 될 것입니다.